2009/6/17 Daniel Kulp <dk...@apache.org> > On Tue June 16 2009 10:32:50 am Sanjiva Weerawarana wrote: > > The way Neethi works is that it basically uses Axiom only to implement > the > > policy-domain specific parser to create the policy-domain specific object > > model. That is, it is TOTALLY internal. > > Not entirely. The PolicyEngine object has public methods like: > Policy getPolicy(OMElement element) > that make it NOT totally internal.
That can be fixed easily ... that can be moved to a utility. That's a matter of opinion. I personally find dealing with StAX quite easy, > but I'm completely used to it by now. :-) > > That said, if you want to keep it a tree, I'm QUITE OK with using > org.w3c.dom.Element. That would make my life MUCH easier as all the CXF > builders are already using it. :-) I mostly suggested StAX since > the > writers are already using it. Kind of a mirror thing. I'm afraid DOM is not an option from an Axis2 point of view. We're trying to get away from it in order to achieve better performance - Rampart2 being one of those efforts. > That could could easily be factory'ed away but that would still require > CXF > > and Axis2 to have their own domain specific builders. Have you evaluated > > the pain level of going down to StAX to do the building? > > The main point of what I'm trying to do with 3.0 is to make it so CXF and > Axis2 don't need their own domain specific builders. We can share the > policy > model objects, the builders that go with them, etc.... For example, I > know > that several of the Rampart builders don't properly record some of the > attributes into the model. I know cause I fixed them in the CXF builders. > It would be good to have a single set of builders and models where we can > both > benefit from fixes such as that. Absolutely +1 if we can achieve that. However, that cannot happen until we agree on an API for the builders. > Using > Axiom is a non-starter for me. StAX or DOM Element is OK by me. Doesn't > matter which. You have a preference between those two? I'd be happy > either > way. If you're willing to rewrite all the current domain specific builders using straight StAX and not Axiom that's ok but there's a lot of those in security policy :). I'd rather not. PolicyEngine is really a policy builder class. That could be moved to a util package and devalued to what it is - a way to build a model. By doing that we can avoid a hard coded Axiom dependency and yet share the domain specific models etc, even if not the builders. > I'm not sure what MEX impacts here .. Axis2 has a MEX module and there's no > overlap/issue with Neethi's parsing model there. What am I missing? It mostly has to do if you get a Policy as an InputStream (MEX or from a > Policy repository via REST or similar), what is the most efficient way of > converting that stream into a usable Policy object. InputStream -> StAX > -> > builders is quite efficient requiring near 0 memory overhead during the > conversion. However, policy docs are "generally" fairly smallish (unless > you > are really nuts and LOVE policy docs ;-) so doing an InputStream -> some > infoset model like Axiom/DOM -> builders is really not THAT big of a deal. Yeah its usually not a big deal and often these are cached after first hit. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Director & Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/
