Can ClassLoader not delegate?

[voger]

My problem is that i want to make a ftp client and i want that client to
be run from a java shell. The problem is that both of them need
classloaders to load commands. If i try to load my ftp client from
within the shell i delegates the classes to shell's class loader. And
then i get a casting error. The shell is not made by me so i can't touch
it's classes.

My application runs fine on it's own when i try to run it from command
line (using .class files from a directory or packed to a .jar). My class
loader is an extension of java.lang.Class loader. Is there any way not
to delegate to the parent class loader? And how can it make look only
within it's own .jar or package? Can anyone point me to any resources?
Google confused me a bit.

I am very new to this so any help would be welcome.

 

[Roedy Green]

The shell is not made by me so i can't touch
it's classes.

What you can do is decompile the class files to figure out what they
are doing, and in a pinch, modify the decompiled code and recompile
it. This is usually against the licence agreement, however. At the
very least you could not expect the vendor to support the modified
code.

See http://mindprod.com/jgloss/decompiler.html

 

[voger]

What you can do is decompile the class files to figure out what they
are doing, and in a pinch, modify the decompiled code and recompile
it. This is usually against the licence agreement, however. At the
very least you could not expect the vendor to support the modified
code.

See http://mindprod.com/jgloss/decompiler.html

Wouldn't it be better if I could fix my own program? There are good
reasons for that

First i don't want to have to modify every java programmed shell my
program will run
Second i am new to java and i wouldn't know what to do anyway
Third i want to learn how to this things

By the way, thanks for the link. I knew only jad.

 

[Roedy Green]

Wouldn't it be better if I could fix my own program? There are good
reasons for that

Yes, but you are in a much better position to do that if you
understand what the problem is with the code you are trying to kludge
into working.

It may or may not be possible to solve the problem only by changing
your own code.

An analogy might be a PET scan to study the insides of a body. With
that knowledge you may come up with a non-invasive treatment, but you
could also prove to yourself that would be futile. In any case, you
are better at prescribing a treatment with the additional knowledge
from the PET scan.

 

[Chris Uppal]

My problem is that i want to make a ftp client and i want that client to
be run from a java shell. The problem is that both of them need
classloaders to load commands. If i try to load my ftp client from
within the shell i delegates the classes to shell's class loader. And
then i get a casting error. The shell is not made by me so i can't touch
it's classes.

The simplest thing would be to put ensure that the classes you want to load are
not visible to the shell's class loader. If you don't have duplicate class
names (name /and/ package) then it would suffice to put the classes somewhere
off the shell's classpath. It might be as simple as using your own package
names.

If that doesn't work for you, then I think you should be able to create a
non-delegating classloader by overriding loadClass() rather than the more usual
findClass(). I've never tried it myself, and there might be problems (e.g.
with the security manager), but it /looks/ as if it should work.

-- chris

 

[voger]

voger wrote:




The simplest thing would be to put ensure that the classes you want to load are
not visible to the shell's class loader. If you don't have duplicate class
names (name /and/ package) then it would suffice to put the classes somewhere
off the shell's classpath. It might be as simple as using your own package
names.

If that doesn't work for you, then I think you should be able to create a
non-delegating classloader by overriding loadClass() rather than the more usual
findClass(). I've never tried it myself, and there might be problems (e.g.
with the security manager), but it /looks/ as if it should work.

-- chris

Well the classes have both package and class name (eg the ls command) .
But i have the same problem
when i try to run commands that do not belong to the shell (e.g the by
command or the get command). Maybe there should be a way to look only
into the filename.jar instead or to isolate the client from the rest of
classpath.

 

[Chris Uppal]

Well the classes have both package and class name (eg the ls command) .
But i have the same problem
when i try to run commands that do not belong to the shell (e.g the by
command or the get command). Maybe there should be a way to look only
into the filename.jar instead or to isolate the client from the rest of
classpath.

I'm sorry but I don't really understand what you are saying here. "ls" is a
Unix command, for instance, not (as far as I know) a class.

But still, since you seem to say that the shell is finding classes that it
should not, it sounds as if you have put /your/ classes on /its/ classpath, and
if you can avoid doing that then the problem will only occur when there is an
actual name clash. In that case -- as I suggested -- you may (but remember
that I have not tried it) be able to use a custom classloader with a
loadClass() override.

-- chris

 

[voger]

voger wrote:




I'm sorry but I don't really understand what you are saying here. "ls" is a
Unix command, for instance, not (as far as I know) a class.

The shell has it's own class loader. It also has built in commands that
imitate
the standard Unix commands ls, cd etc.. With this class loader it can
also load
the entry points (i think this is the correct term for classes
containing the main method)
of other jar files, as long as they are defined in the same class
path. This is how it loads
my program.

But still, since you seem to say that the shell is finding classes that it
should not, it sounds as if you have put /your/ classes on /its/ classpath, and

Well this is the problem :/. The FTP client also must use commands like
ls and cd.
And i thought that the best approach would be to make them classes that
can be
loaded from my class loader.

if you can avoid doing that then the problem will only occur when there is an
actual name clash. In that case -- as I suggested -- you may (but remember

Not exactly. You see i also have classes in my FTP client for the put
command, the
get command and the by command. Those classes don't exist in the shell.
Shouldn't
they work ok? This is that makes me believe that it actually delegates
the search for classes
to the shell and the shell returns whatever it fiend's casted to it's
own class loader

that I have not tried it) be able to use a custom classloader with a
loadClass() override.

I tried this and it didn't work. I guess i am doing something wrong but
can't find appropriate
documentation. But i found this today
http://java.sun.com/docs/books/tutorial/jar/api/jarclassloader.html

I will study this and hope i get some good information from it.