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 > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/openejb-development _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
