geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Boynes" <>
Subject RE: Geronimo Deployment Descriptors
Date Mon, 08 Sep 2003 00:23:00 GMT
> From: Aaron Mulder [] 
> 	I disagree - I don't think you should "win by default" 
> by putting 
> something in the repository first.

It is not a case of 'winning' - its about getting stuff to work. If
there had been something there I would have checked this into a
revolutionary branch; because there wasn't I checked it into HEAD. We
now get to discuss around something concrete and people depending on the
ENC (like Hiram and I who are trying to get IIOP working) can move on.

> > Applying that code would not get us to where we are now. It had 
> > loaders for the two different models, but nothing for 
> matching them up 
> > and getting the data into a form where something like the 
> > ComponentContextBuilder could work on it. It was trying to add that 
> > stuff that made change approach.
> 	Yeah, but the JSR-88 code doesn't work for the new approach.  
> You've just broken something *different*.  (Plus, as I point 
> out below, 
> you left the EJB POJOs working "the old way".)
> > If you want to pursue that as an alternative, perhaps in 
> conjunction 
> > with Greg's proposal for overlays, that would be cool.
> 	Well, are you going to fix the JSR-88 implementation?  
> I mean, right now if you try to save Geronimo-specific 
> customizations to an EJB JAR, it writes the Geronimo stuff 
> only, producing a tree of POJOs from 
> o.a.g.deployment.model.ejb, which if you look, doesn't even 
> include the stuff from ejb-jar.xml (i.e. an "Ejb" doesn't 
> have an "ejb-class" field, home & component interaces, etc.).
> 	Bottom line, it doesn't look to me like the "new 
> approach" is any more working than the old one!

I guess it depends on where your focus is. The stuff I was doing with
AppClient was stalled because I did not have a way to load the ENC from
the DD - now I can so I am happy :-)

Nothing in the code I checked in deals with writing XML. As I understand
it, that is going to be handled at some point using XMLBeans. I have no
idea where we are on that, except it is a different approach to what is
there right now.

> > But let's not stop dead in the water while we debate.
> 	Okay.  Well, I put my thoughts on it out in an e-mail this 
> morning (9:24), and I don't think you've replied to that yet...  In 
> particular, what if we keep the files separate, but keep your 
> proposed 
> changes to the POJO structure, and something yet to be 
> written does the 
> combining of multiple files into a single POJO tree, so the 
> file format 
> is transparent to the ComponentContextBuilder?

There are two aspects to this:
1) The POJO structure - I changed the geronimo ones to specialize the
   standard ones (as they add in additional information). I think that
   a useful change because it separates the in-memory form from the
   XML form.

2) The XML form. It was much easier to build an XML loader for a
   unified document as it does not need to worry about matching
   nodes. If we want to split into two and introduce the code
   for matching up the documents, we can.

These issues were discussed in both your and Greg's emails and I thought
my response covered both; sorry if I missed something.

I think an alternative XML form can be tried out without changing the
POJO structure. When it works, we have two solutions to compare side by
side and can have a vote on the approach.


View raw message