On Fri, Apr 02, 2004 at 09:20:06AM -0800, David Jencks wrote: > > On Friday, April 2, 2004, at 09:11 AM, Jeremy Boynes wrote: > > >Jacek Laskowski wrote: > > > > > >>It's just an non-tested idea, but as it's already a stream of > >>resources (classes as well), why it's not possible to build a > >>classloader that would deal with that stream. What else is in the > >>input stream of a JSR88 tool other than stream-ified war, ejb-jar or > >>rar? > >>Would the classloader be a solution to the question? > > > >That would work too - pull the bytecode from the stream into memory > >(HashMap?) and have a ClassLoader work from that. For an EAR we would > >need several of these to handle the nested modules. > > > >Seems a little more complex but does avoid the temp file issue. > > I considered both this and trying to use a URLClassloader on the > partially written output file (by the time we need classes, the bytes > containing the classes have been written out and could be flushed) but > couldn't convince myself that there were any real advantages over the > very simple if ugly temp file solution. Why would we want to maintain > the code for such a classloader?
Agreed. The current openejb deploy tool also uses temp files, works just fine. As you say, why maintain that code. Additionally, loading the classes into a classloader that is unlike the one they will run in can introduce strange deployment problems--why we started using temp files in the first place. -David Blevins > > thanks > david jencks > > > >-- > >Jeremy > >
