[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openejb-development
Subject:    Re: [OpenEJB-dev] Understanding OpenEJB's 0.9.2 ClasspathUtils
From:       David Blevins <david.blevins () visi ! com>
Date:       2003-09-24 14:20:18
[Download RAW message or body]

On Wed, Sep 24, 2003 at 01:49:07PM +0200, Jacek Laskowski wrote:
> Dalibor Topic wrote:
> > Hi David,
> > 
> > I'm a kaffe developer trying to get OpenEJB to run on top of kaffe, 
> > which is a free, clean-room runtime for programs written in, you guessed 
> > it, java.
> > 
> > Currently OpenEJB doesn't load on kaffe because it breaks in 
> > ClasspathUtils method getUcpField. I tried to grasp what the code does, 
> > but the lack of comments didn't help ;)
> > 
> > I don't understand why you need to take the route via an undocumented 
> > variable in some particular implementation of Sun's code, instead of 
> > using the portable system property java.class.path. Could you elaborate 
> > on the design and intentions of your implementation?
> 
> Hi Dalibor,
> 
> Although I didn't write the code, I'm going to help you by answering the 
> questions. David, correct me if I make a mistake in it.
> 
> The goal of the connector is to tie up OpenEJB and Tomcat. As we know 
> the main problem in every integration is how appropriate classes are 
> visible to each component. The code David wrote made the integration 
> possible with *no* dependency on Tomcat-specific jars. If it had been 
> written so that OpenEJB classes directly referenced Tomcat-specific 
> classes, OpenEJB would have required Tomcat jars during its build and at 
> runtime. With the hack it is not required.
> 
> Thus, if you know about any other way to get at classes available in a 
> classloader so that it would also be available to OpenEJB *and* after 
> the changes OpenEJB would compile with no additional container-specific 
> jars, it means you're able to fix it without any problems.
> 

Just to add to this, we also use it for starting the remote server and all of our \
other command line tools.  Windows has a limit to the number of characters any line \
on the command prompt can be.  When we started appending the full path to the jar \
files so that people could deploy from outside the openejb.home directory, we quickly \
exceeded that length.  Windows just gives you a "line input too long" error.


Another thing it is useful for is that someone who wants to embed OpenEJB only has to \
include the openejb_loader-xxx.jar in their classpath, we import the rest of the \
OpenEJB libraries and dependent libraries automatically.

Basically, the short story is that because OpenEJB is embeddible, we aren't usually \
the tool being started on the command line and aren't the ones who control the \
CLASSPATH system variable.  We can make everyone else add all those jars, but that \
becomes a real PITA for them due to the large number of dependent libraries -- and as \
I mention, it isn't possible in windows to add that many jars in the classpath \
variable when you use the full path of the jars.

If you can find another way to get the job done, we're all ears (or eyes as it were).

-David


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
http://OpenEJB.sf.net
OpenEJB-development mailing list
OpenEJB-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openejb-development


[prev in list] [next in list] [prev in thread] [next in thread]