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

[Dalibor Topic]

Hi David,

sorry for the long delay on my side, I was busy with kaffe 1.1.2, and 
then the classpath developer meeting, catching up with real life ... I 
guess you know what it's like ;)

I haven't thought much about it, but wouldn't a ResourceBundle / 
Property file based approach solve your problems?

Using a separate text/xml/whatever format you like/ file allows you to 
build without having to depend on tomcat, and configure OpenEJB on 
startup by changig a line or two in that file (like the numbered 
property approach used to configure java.crypto providers in JDK), 
beside it should also solve the 'too long input line' problem as all 
you'd need to do is to pass an openejb.classpath.resourcefile property 
to openejb, and load the classpath resources from there.

For importing stuff and addting it to a jar's classpath automatically, 
the Class-Path: attribute in a JAR's manifest seems to be appropriate, 
which is what tomcat 5 developers seem to be doing.

cheers,
dalibor topic

David Blevins wrote:
> 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
> 
> 
> _______________________________________________
> kaffe mailing list
> kaffe at kaffe.org
> http://kaffe.org/cgi-bin/mailman/listinfo/kaffe