You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@coredevelopers.net> on 2004/04/02 01:07:03 UTC
Problem with DeploymentContext
Jeremy and David J,
I think I might have run into a structural problem with
DeploymentContext while writing the EJB deployer. If you take a look
at EJBConfigBuilder in the openejb cvs, you will see it follows the
structure of the war deployer. I ran into a problem while attempting
to write a test for buildConfiguration(File, JarInputStream, XmlObject)
method. This method starts by coping the file contents from the
JarInputStream to the output file, and then builds the EJB
configuration. To build the EJB configuration I need to load and
inspect the EJB classes, and this is a problem because the output jar
file doesn't seem to be on the classpath of the DeploymentContext (we
get the classpath from the context on line 222).
Any idea on how to get around this?
-dain
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
Re: Problem with DeploymentContext
Posted by Dain Sundstrom <da...@coredevelopers.net>.
Just to clarify, this is the code that is using addStreamInclude (in
the last if block)...
protected XmlObject generateClassPath(URI configID, JarInputStream
jarInputStream, DeploymentContext context) throws DeploymentException {
URI moduleBase = URI.create(configID.toString() + "/");
XmlObject j2eeDoc = null;
try {
for (JarEntry entry; (entry =
jarInputStream.getNextJarEntry()) != null; jarInputStream.closeEntry())
{
String name = entry.getName();
if (name.endsWith("/")) {
continue;
}
if (name.equals("META-INF/ra.xml")) {
j2eeDoc = getConnectorDocument(jarInputStream);
continue;
}
if (name.endsWith(".jar")) {
URI uri = moduleBase.resolve(name);
context.addStreamInclude(uri, jarInputStream);
}
It looks like the .rar file contains several .jar files, which need to
be added to the class path. This is a bit different from an ejb-jar
where we want just the outer jar added to the class path, but I
actually think this is what we want for ejb-jars. What I plan on doing
is to construct a car file that contains just two entries
META-INF/config.ser and ejb.jar (at the root level).
Any objections?
-dain
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
On Apr 1, 2004, at 6:00 PM, David Jencks wrote:
> yes, I had this problem also. I wrote
> DeploymentContext.addStreamInclude to deal with it. I'd be happy if
> you found a better way, but I didn't.
>
> david jencks
>
> On Thursday, April 1, 2004, at 03:07 PM, Dain Sundstrom wrote:
>
>> Jeremy and David J,
>>
>> I think I might have run into a structural problem with
>> DeploymentContext while writing the EJB deployer. If you take a look
>> at EJBConfigBuilder in the openejb cvs, you will see it follows the
>> structure of the war deployer. I ran into a problem while attempting
>> to write a test for buildConfiguration(File, JarInputStream,
>> XmlObject) method. This method starts by coping the file contents
>> from the JarInputStream to the output file, and then builds the EJB
>> configuration. To build the EJB configuration I need to load and
>> inspect the EJB classes, and this is a problem because the output jar
>> file doesn't seem to be on the classpath of the DeploymentContext (we
>> get the classpath from the context on line 222).
>>
>> Any idea on how to get around this?
>>
>> -dain
>>
>> /*************************
>> * Dain Sundstrom
>> * Partner
>> * Core Developers Network
>> *************************/
>>
>
Re: Problem with DeploymentContext
Posted by David Blevins <da...@visi.com>.
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
> >
Re: Problem with DeploymentContext
Posted by Dain Sundstrom <da...@coredevelopers.net>.
This should work with a read only systems such as a CD only computer or
embedded system. The trick is the deployment phase happens on a
general purpose computer, and the output of that would be burned on the
CD or flashed on the embedded system. This is one of the big
advantages of the two phase deployment of JSR-88.
-dain
On Apr 2, 2004, at 4:56 PM, David Jencks wrote:
> The deployment construction phase, of which this temp file usage is a
> part, already won't work without file system write access -- one of
> the alternatives to temp files is to try to get a URLClassloader to
> read from the partially written configuration archive file. However I
> think running a pre-configured geronimo instance off read only media
> ought to work.
>
> david jencks
>
> On Friday, April 2, 2004, at 02:11 PM, Jacek Laskowski wrote:
>
>> David Jencks wrote:
>>
>>> Why would we want to maintain the code for such a classloader?
>>
>> I agree with the arguments. There's a lot of work to do and maintain
>> afterwards. However, do we consider to run Geronimo on a read-only
>> media, e.g. CD-ROM? If so, the temp file solution won't work anymore.
>>
>>> david jencks
>>
>> Jacek
>>
>
Re: Problem with DeploymentContext
Posted by David Jencks <da...@coredevelopers.net>.
The deployment construction phase, of which this temp file usage is a
part, already won't work without file system write access -- one of the
alternatives to temp files is to try to get a URLClassloader to read
from the partially written configuration archive file. However I think
running a pre-configured geronimo instance off read only media ought to
work.
david jencks
On Friday, April 2, 2004, at 02:11 PM, Jacek Laskowski wrote:
> David Jencks wrote:
>
>> Why would we want to maintain the code for such a classloader?
>
> I agree with the arguments. There's a lot of work to do and maintain
> afterwards. However, do we consider to run Geronimo on a read-only
> media, e.g. CD-ROM? If so, the temp file solution won't work anymore.
>
>> david jencks
>
> Jacek
>
Re: Problem with DeploymentContext
Posted by Jacek Laskowski <jl...@apache.org>.
David Jencks wrote:
> Why would we want to maintain the code for such a classloader?
I agree with the arguments. There's a lot of work to do and maintain
afterwards. However, do we consider to run Geronimo on a read-only
media, e.g. CD-ROM? If so, the temp file solution won't work anymore.
> david jencks
Jacek
Re: Problem with DeploymentContext
Posted by David Jencks <da...@coredevelopers.net>.
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?
thanks
david jencks
>
> --
> Jeremy
>
Re: Problem with DeploymentContext
Posted by Jeremy Boynes <je...@coredevelopers.net>.
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.
--
Jeremy
Re: Problem with DeploymentContext
Posted by Jacek Laskowski <jl...@apache.org>.
Jeremy Boynes wrote:
> This is a symptom of 88-itis - the tool may only provide us with an
> input stream for the standard archive. We copy that to the output stream
> but that is not suitable for use as a classloader.
>
> I think David's solution of staging a temporary file somewhere and using
> it to build the classpath is probably the way to go, ugly as it seems.
Hi,
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?
p.s. Being very busy with WebLogic Server on HP-UX in a project it's a
fresh air to think about Geronimo at least a while ;)
> Jeremy
Jacek
Re: Problem with DeploymentContext
Posted by Jeremy Boynes <je...@coredevelopers.net>.
This is a symptom of 88-itis - the tool may only provide us with an
input stream for the standard archive. We copy that to the output stream
but that is not suitable for use as a classloader.
I think David's solution of staging a temporary file somewhere and using
it to build the classpath is probably the way to go, ugly as it seems.
--
Jeremy
David Jencks wrote:
> yes, I had this problem also. I wrote DeploymentContext.addStreamInclude
> to deal with it. I'd be happy if you found a better way, but I didn't.
>
> david jencks
>
> On Thursday, April 1, 2004, at 03:07 PM, Dain Sundstrom wrote:
>
>> Jeremy and David J,
>>
>> I think I might have run into a structural problem with
>> DeploymentContext while writing the EJB deployer. If you take a look
>> at EJBConfigBuilder in the openejb cvs, you will see it follows the
>> structure of the war deployer. I ran into a problem while attempting
>> to write a test for buildConfiguration(File, JarInputStream,
>> XmlObject) method. This method starts by coping the file contents
>> from the JarInputStream to the output file, and then builds the EJB
>> configuration. To build the EJB configuration I need to load and
>> inspect the EJB classes, and this is a problem because the output jar
>> file doesn't seem to be on the classpath of the DeploymentContext (we
>> get the classpath from the context on line 222).
>>
>> Any idea on how to get around this?
>>
>> -dain
>>
>> /*************************
>> * Dain Sundstrom
>> * Partner
>> * Core Developers Network
>> *************************/
>>
>
--
Jeremy
/*************************
* Jeremy Boynes
* Partner
* Core Developers Network
*************************/
Re: Problem with DeploymentContext
Posted by David Jencks <da...@coredevelopers.net>.
yes, I had this problem also. I wrote
DeploymentContext.addStreamInclude to deal with it. I'd be happy if
you found a better way, but I didn't.
david jencks
On Thursday, April 1, 2004, at 03:07 PM, Dain Sundstrom wrote:
> Jeremy and David J,
>
> I think I might have run into a structural problem with
> DeploymentContext while writing the EJB deployer. If you take a look
> at EJBConfigBuilder in the openejb cvs, you will see it follows the
> structure of the war deployer. I ran into a problem while attempting
> to write a test for buildConfiguration(File, JarInputStream,
> XmlObject) method. This method starts by coping the file contents
> from the JarInputStream to the output file, and then builds the EJB
> configuration. To build the EJB configuration I need to load and
> inspect the EJB classes, and this is a problem because the output jar
> file doesn't seem to be on the classpath of the DeploymentContext (we
> get the classpath from the context on line 222).
>
> Any idea on how to get around this?
>
> -dain
>
> /*************************
> * Dain Sundstrom
> * Partner
> * Core Developers Network
> *************************/
>