[kaffe] Re: [OpenEJB-dev] Understanding OpenEJB's 0.9.2 ClasspathUtils

[David Blevins]

Hi Dalibor,

Just wondering what your thoughts were on how better to solve the classloading
issues.  As I mentioned, we are totally open to other ideas.

-David

On Wed, Sep 24, 2003 at 10:20:18AM -0400, David Blevins wrote:
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openejb-development