geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Problem with DeploymentContext
Date Fri, 02 Apr 2004 18:34:02 GMT
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
> >

Mime
View raw message