> From: Aaron Mulder [mailto:[EMAIL PROTECTED] > 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 is 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. -- Jeremy
