Can ClassLoader not delegate?

Thread view:

voger - 02 Oct 2005 23:21 GMT

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.

Reply to this Message

Roedy Green - 02 Oct 2005 23:51 GMT

>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

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Reply to this Message

voger - 03 Oct 2005 00:36 GMT

>>The shell is not made by me so i can't touch
>>it's classes.
[quoted text clipped - 6 lines]
>
> 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.

Reply to this Message

Roedy Green - 03 Oct 2005 04:50 GMT

>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.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Reply to this Message

Chris Uppal - 03 Oct 2005 13:33 GMT

> 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

Reply to this Message

voger - 03 Oct 2005 18:14 GMT

>>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
[quoted text clipped - 15 lines]
>
> -- 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.

Reply to this Message

Chris Uppal - 04 Oct 2005 08:36 GMT

> 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

Reply to this Message

voger - 04 Oct 2005 20:10 GMT

>>Well the classes have both package and class name (eg the ls command) .
>>But i have the same problem
[quoted text clipped - 5 lines]
> 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.

> -- chris

Reply to this Message

Can ClassLoader not delegate?

Free Magazines