[jira] Closed: (TUSCANY-86) Use a WSDL configured AxisService in the WS binding externalService impl
[ http://issues.apache.org/jira/browse/TUSCANY-86?page=all ] ant elder closed TUSCANY-86: Resolution: Fixed Fixed in 387177 > Use a WSDL configured AxisService in the WS binding externalService impl > > > Key: TUSCANY-86 > URL: http://issues.apache.org/jira/browse/TUSCANY-86 > Project: Tuscany > Type: Improvement > Components: Java SCA Axis Integration > Reporter: ant elder > Assignee: ant elder > Priority: Minor > > Axis2 now enables creating an AxisService client from a WSDL document which > means the client gets correctly configured for a service as specified in its > WSDL > This requires upgrading to Axis2 0.95 - TUSCANY-85 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-85) Upgrade to Axis2 0.95 release
[ http://issues.apache.org/jira/browse/TUSCANY-85?page=all ] ant elder closed TUSCANY-85: Resolution: Fixed Fixed in 386791. Thanks Rick! (Using a 0.95 SNAPSHOT build so we'll still have to pick up the final 0.95 when its done. But that should be straight forward now this and Tuscany-86 have been done) > Upgrade to Axis2 0.95 release > - > > Key: TUSCANY-85 > URL: http://issues.apache.org/jira/browse/TUSCANY-85 > Project: Tuscany > Type: Improvement > Components: Java SCA Axis Integration > Reporter: ant elder > Assignee: Rick Rineholt > Priority: Minor > > Tuscany currently uses Axis2 0.94. The next release has a number of fixes and > improvements such as Java2WSDL support, configuring AxisService automatically > from a WSDL, not requiring axis2.xml in clients, working ws-policy support > etc, and many bug fixes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: WRONG content @ http://people.apache.org/~jboynes/maven2/axis2/axis2-adb/0.95-SNAPSHOT/axis2-adb-0.95-SNAPSHOT.jar
My doing, already sent Jeremy an update. Raymond Feng wrote: > Hi, > > http://people.apache.org/~jboynes/maven2/axis2/axis2-adb/0.95-SNAPSHOT/axis2-adb-0.95-SNAPSHOT.jar is not pointing to the ADB jar. Please fix it. > > Thanks, > Raymond __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: WRONG content @ http://people.apache.org/~jboynes/maven2/axis2/axis2-adb/0.95-SNAPSHOT/axis2-adb-0.95-SNAPSHOT.jar
New files uploaded... rick rineholt wrote: > My doing, already sent Jeremy an update. > > Raymond Feng wrote: > >>Hi, >> >> > > http://people.apache.org/~jboynes/maven2/axis2/axis2-adb/0.95-SNAPSHOT/axis2-adb-0.95-SNAPSHOT.jar > is not pointing to the ADB jar. Please fix it. > >>Thanks, >>Raymond > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com
Re: Project structure
I would like to add optimally I'd prefer not to build/junit test SDO and DAS on every build (just use the snapshot). I might assume they may feel similar about the SCA parts. With Ant I could probably fix this up pretty quick, still wrapping my head around Maven especially 2.0. With regard to optional components going stale, if we could figure out how to optionally build items under Maven and not just comment them out, I wonder if we could not have our cake and eat it too, if we had a nightly build/test (GUMP?) we could build most of the time just what we needed/required and have the nightly run the whole build and test battery. ant elder wrote: > Whats not completely clear from this is the 'rules', specifically when must > the 'optional' stuff be built? If code isn't being built in the regular > build that everyone runs it quickly goes stale. Look at our old Axis1 > binding, been out of the regular build a couple of weeks and already it > fails to build. > > I'd like to see everything being included in the regular build. If some > extension makes building difficult vote it out, don't exclude every > extension by default. > > Is so much structure needed at this stage, or does it just makes things more > complicated and make an unnecessary decision now about how Tuscany must be > used. Maybe I just don't like the baseline vs extension distinction. > > I'd go for a more simple hierarchy and leave the structuring to the > distributions. More like the way Mule or DOJO do things with various > distributions designed for specific environments - minimal, SCA-SPEC, J2EE, > the kitchen sink, etc. Perhaps with distributions customizable with a fancy > build script to add/remove things - "minimal,+JavaScript". > >...ant > > On 3/18/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> One theme that came out of the recent project promotion thread was a >> need to establish what our project structure should be. Part of that >> also is the level of "support" between parts of that project structure. >> I'd like to propose a strawman, not only of the structure but also of >> the rules. >> >> A project "core" that: >> * is as small as possible with carefully controlled dependencies >> * provides the fabric for the runtime (Contexts) >> * provides APIs for providing plugin extensions >> * provides SPIs for embedding in host environments >> * can be built separately and used by extensions in binary form >> (implying versioning and stability on the extension APIs) >> * has a rule that incompatible changes to the API require the changer >> to upgrade and test all extensions in the Tuscany project and with >> a specific vote to accept them >> >> Baseline services that are distributed with the core that: >> * provide a deployment model for extensions (include loading, >> context building, package handling (classpath)) >> * provide critical system services (monitoring, admin enablement) >> * provide system services needed to support baseline extensions >> (security provider, transaction manager, work manager, ...) >> * has the same rule on API changes for those services as the core >> >> Baseline extensions that are distributed with the core: >> * programming models that are part of the specification >> (currently Java, futures being C++, Spring, J2EE, BPEL, ...) >> * transport bindings that are part of the specification >> (currently WS, futures being JMS, ...) >> * data bindings that are part of the specification >> (currently SDO, futures being JAXB, ...) >> * policy handlers that are part of the specification >> (futures being Security, Transaction, ...) >> >> Optional services that can be used to extend the runtime: >> * programming models that are not part of the specification >> (currently JavaScript, future being PHP, ???) >> * transport bindings that are not part of the specification >> (currently JSON-RPC, future being ???) >> * data bindings that are not part of the specification >> (currently JSON, future being ???) >> * services for use by applications >> (database access, DAS implementations, directory access, ...) >> * these would be released separately and could be deployed >> to a host environment by a user >> >> Host integrations that provide installable distributions: >> * provide implementations of the core's SPIs that allow >> Tuscany to run in different environments. >> (currently J2SE, J2EE WAR and Tomcat, >>future being full J2EE, Geronimo, OSGi(Eclipse), ...) >> * provide installable distributions that include all the >> baseline compoments applicable to that environment >> * provide "extended" distributions tailored to different >> user communities that include selected optional services >> >> Sample and demo applications that: >> * show key concepts from the SCA programming model >> (currently helloworld) >> * show how to build a large scale application >> (currently bigbank) >> * show how to use Tuscany in different environments >> >> Testing
[jira] Commented: (TUSCANY-118) Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration
[ http://issues.apache.org/jira/browse/TUSCANY-118?page=comments#action_12371103 ] Frank Budinsky commented on TUSCANY-118: Hi Raymond, I took a look at your patch and it looks good but I have a few questions. Let's assume that the plan is to add these two methods to the SDO project: 1) void SDOUtil.load(TypeHelper scope, XMLStreamReader reader, Object options) 2) XMLStreamReader SDOUtil.save(TypeHelper scope, XMLDocument document, Object options) Question 1: These two methods simply provide StAX-based load and save support for XML documents (ideally they would be added to XMLHelper in a future version of the SDO spec). Is that right ? Question 2: Your new classes, DataObjectStAXWrapper, StAXXMLResourceImpl/StaX2SAXAdapter, could be used, under the covers, to implement the above SDOUtil methods. Right ? Question 3: Your implementation, has dependencies on and uses classes from axis2 and ws. Does it need to, or is this just because it's lumped together with other function? Question 4: Are there any other new dependencies that this adds to the SDO project? Thanks, Frank. > Adding Serializer/Deserializer for DataObject using StAX for better Axis2 > AXIOM integration > --- > > Key: TUSCANY-118 > URL: http://issues.apache.org/jira/browse/TUSCANY-118 > Project: Tuscany > Type: Improvement > Components: Java SCA Axis Integration, Java SDO Implementation > Reporter: Raymond Feng > Attachments: rfeng_stax.diff, rfeng_stax_axis_095.diff > > Here are the key classes: > 1) DataObjectStAXWrapper > Implements "org.apache.axis2.databinding.ADBBean" interface by feeding > elements and attibutes to "org.apache.axis2.databinding.utils.ADBPullParser". > It can be used as > a Serializer for DataObject to be serialized as OMElement. > > 2) StAXXMLResourceImpl and StAX2SAXAdapter > StAXXMLResourceImpl extends "org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl" > to provide additional methods to load DataObject directly from > XMLStreamReader. StAX2SAXAdpter is responsible to pull StAX events from > XMLSreamReader and generate SAX events so that they can be consumed by > XMLResourceImpl. > 3) DataObjectStAXWrapperTestCase > It tests the round trip for "DataObject --> OMElment --> DataObject". Both > static SDO model (pre-generated) and dynamic SDO model (loaded from WSDL/XSD) > are covered. It also test the cost of the optimized roundtrip against the old > "quick and dirty" way (DataObject --> OutputStream --> InputStream --> > OMElement --> OutputStream --> InputStream --> DataObject). > It shows more that 400% performance gain. > > It seems that files in set 1 and 2 are more fit to be included in the SDO > sub-project. The following helper method is desirable. > void SDOUtil.load(TypeHelper scope, XMLStreamReader reader, Object options) > XMLStreamReader SDOUtil.save(TypeHelper scope, XMLDocument document, Object > options) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Project structure
On Monday 20 March 2006 10:44, rick rineholt wrote: > With regard to optional components going stale, if we > could figure out how to > optionally build items under Maven and not just > comment them out, I wonder if we > could not have our cake and eat it too, if we had a > nightly build/test (GUMP?) > we could build most of the time just what we > needed/required and have the > nightly run the whole build and test battery. With the use of profiles, you can "add" modules when a particular profile is selected. (In theory, haven't actually tried it yet) For example, by default, a top level pom.xml could just have submodules A, B, and C. If you run "mvn -Deverything" the "everything" profile could add D and E. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
Re: Framework for StAX-based model loading
rick rineholt wrote: > Before we jump the gun on this I'd like to see if more people could > give some feedback on the pros and cons of this. I definitely some > advantages in that it simplifies the code some and is based on > technologies that more developers are more likely to be familiar > with. I do think that something is lost in that SDO 's would provide > greater runtime referential checking with the specification. I'm not > in any what advocating not taking this route just hoping before we > make such a leap that a more livelier discussion would take place. > I've not seen anyone else chip in one way or another. I would like to wrap this up soon so as the response so far seems to be positive I plan to make the switch over tomorrow. Speak now ... -- Jeremy
Tuscany Java Architectural Wiki ?
I'd like to propose an Architectural Wiki page for the core Java SCA implementation. The purpose would to document the many conversations that describes the internal implementation of the Tuscany SCA runtime. It should stay extremely lose regarding format and appearance; quite literally if you have something that explains the core just possibly create a new section and either cut and paste or write it down. This is not to exclude someone from actually if so inclined to help out and format it, but not a requirement to add new content. The idea is to keep bar as almost as low as adding content to the mailing list but keep it 1) contained in one convenient place 2) ability to delete obsolete information. Does anyone else see this as a benefit ? Who knows maybe this time next year it could be the first Apache Wiki derived publication?... :-) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Tuscany Java Architectural Wiki ?
I like the idea. I'm willing to document if someone who knows how to set this stuff up can do it. Jim On 3/20/06, rick rineholt <[EMAIL PROTECTED]> wrote: > I'd like to propose an Architectural Wiki page for the > core Java SCA > implementation. The purpose would to document the > many conversations that > describes the internal implementation of the Tuscany > SCA runtime. It should stay > extremely lose regarding format and appearance; quite > literally if you have > something that explains the core just possibly create > a new section and either > cut and paste or write it down. This is not to > exclude someone from actually if > so inclined to help out and format it, but not a > requirement to add new content. > The idea is to keep bar as almost as low as adding > content to the mailing > list but keep it 1) contained in one convenient place > 2) ability to delete > obsolete information. > > Does anyone else see this as a benefit ? > > Who knows maybe this time next year it could be the > first Apache Wiki derived > publication?... :-) > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com >
[jira] Commented: (TUSCANY-118) Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration
[ http://issues.apache.org/jira/browse/TUSCANY-118?page=comments#action_12371115 ] Raymond Feng commented on TUSCANY-118: -- Hi, Frank. Thank you for looking into this. Please see my answers to your questions below. Raymond Question 1: These two methods simply provide StAX-based load and save support for XML documents (ideally they would be added to XMLHelper in a future version of the SDO spec). Is that right ? Yes. Question 2: Your new classes, DataObjectStAXWrapper, StAXXMLResourceImpl/StaX2SAXAdapter, could be used, under the covers, to implement the above SDOUtil methods. Right ? Yes. Question 3: Your implementation, has dependencies on and uses classes from axis2 and ws. Does it need to, or is this just because it's lumped together with other function? This is really a good question. I assume ideally SDO shouldn't depend on Axis2 for this utility. I need some inputs from folks like Jeremy to understand what's the best practice here. My naive view is to check if it's possible that we can get approval from original author to port the code into our code base. Antoher way is that we implement the utlity by ourselves. We can post this question to the dev list to get feedback from the open source veterans. Question 4: Are there any other new dependencies that this adds to the SDO project? I assume StAX API and impl should be good enough if the dependency in question 3 can be resovled. > Adding Serializer/Deserializer for DataObject using StAX for better Axis2 > AXIOM integration > --- > > Key: TUSCANY-118 > URL: http://issues.apache.org/jira/browse/TUSCANY-118 > Project: Tuscany > Type: Improvement > Components: Java SCA Axis Integration, Java SDO Implementation > Reporter: Raymond Feng > Attachments: rfeng_stax.diff, rfeng_stax_axis_095.diff > > Here are the key classes: > 1) DataObjectStAXWrapper > Implements "org.apache.axis2.databinding.ADBBean" interface by feeding > elements and attibutes to "org.apache.axis2.databinding.utils.ADBPullParser". > It can be used as > a Serializer for DataObject to be serialized as OMElement. > > 2) StAXXMLResourceImpl and StAX2SAXAdapter > StAXXMLResourceImpl extends "org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl" > to provide additional methods to load DataObject directly from > XMLStreamReader. StAX2SAXAdpter is responsible to pull StAX events from > XMLSreamReader and generate SAX events so that they can be consumed by > XMLResourceImpl. > 3) DataObjectStAXWrapperTestCase > It tests the round trip for "DataObject --> OMElment --> DataObject". Both > static SDO model (pre-generated) and dynamic SDO model (loaded from WSDL/XSD) > are covered. It also test the cost of the optimized roundtrip against the old > "quick and dirty" way (DataObject --> OutputStream --> InputStream --> > OMElement --> OutputStream --> InputStream --> DataObject). > It shows more that 400% performance gain. > > It seems that files in set 1 and 2 are more fit to be included in the SDO > sub-project. The following helper method is desirable. > void SDOUtil.load(TypeHelper scope, XMLStreamReader reader, Object options) > XMLStreamReader SDOUtil.save(TypeHelper scope, XMLDocument document, Object > options) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-118) Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration
[ http://issues.apache.org/jira/browse/TUSCANY-118?page=comments#action_12371116 ] Jeremy Boynes commented on TUSCANY-118: --- I assume having the SDO API depend on the StAX API would not be a problem? There should perhaps in a "StaxHelper" interface that would mean that the dependency was only triggered by people using StAX. Our SDO implementation should depend only on having an implementation of StAX available. Perhaps having the user pass the XMLStreamReader/XMLStreamWriter in the API would be sufficient. I think this is better than having a load(URL) type method that requires the implementation discover a StAX implementation. If the only dependency on AXIOM is for testing then we can just inlcude it as a depdency and it would never impact a distribution. If we are proving a helper for reading/writing an AXIOM model then it should be isolated to the AXIOM helper class itself so the only users that need to provide that dependency are the ones using AXIOM. > Adding Serializer/Deserializer for DataObject using StAX for better Axis2 > AXIOM integration > --- > > Key: TUSCANY-118 > URL: http://issues.apache.org/jira/browse/TUSCANY-118 > Project: Tuscany > Type: Improvement > Components: Java SCA Axis Integration, Java SDO Implementation > Reporter: Raymond Feng > Attachments: rfeng_stax.diff, rfeng_stax_axis_095.diff > > Here are the key classes: > 1) DataObjectStAXWrapper > Implements "org.apache.axis2.databinding.ADBBean" interface by feeding > elements and attibutes to "org.apache.axis2.databinding.utils.ADBPullParser". > It can be used as > a Serializer for DataObject to be serialized as OMElement. > > 2) StAXXMLResourceImpl and StAX2SAXAdapter > StAXXMLResourceImpl extends "org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl" > to provide additional methods to load DataObject directly from > XMLStreamReader. StAX2SAXAdpter is responsible to pull StAX events from > XMLSreamReader and generate SAX events so that they can be consumed by > XMLResourceImpl. > 3) DataObjectStAXWrapperTestCase > It tests the round trip for "DataObject --> OMElment --> DataObject". Both > static SDO model (pre-generated) and dynamic SDO model (loaded from WSDL/XSD) > are covered. It also test the cost of the optimized roundtrip against the old > "quick and dirty" way (DataObject --> OutputStream --> InputStream --> > OMElement --> OutputStream --> InputStream --> DataObject). > It shows more that 400% performance gain. > > It seems that files in set 1 and 2 are more fit to be included in the SDO > sub-project. The following helper method is desirable. > void SDOUtil.load(TypeHelper scope, XMLStreamReader reader, Object options) > XMLStreamReader SDOUtil.save(TypeHelper scope, XMLDocument document, Object > options) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Eclipse dependenices
I changed 3 POM files with EMF dependencies (sdo/impl/pom.xml, sdo/tools/pom.xml, and sca/tools/pom.xml) to use the new EMF maven repository at downloads.eclipse.org, instead of Jeremy's temporary repository. They seem to work for me, so I commited the changes. Frank.
Re: [jira] Commented: (TUSCANY-118) Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration
+1 to all of this (although it's test) Having an axis/axiom dependency on the "test" phase is possibly OK (although not ideal). Making the actual runtime depend on it is not OK. Just FYI, the JAXB 2.0 marshaller/unmarshaller has methods for the XMLStream* and XMLEvent* and such as well as those for InputSource, URL, InputStream, Source, etc I'm not sure if you care (since SDO is not JAXB), but I thought I'd mention it. Enjoy! Dan On Monday 20 March 2006 12:59, Jeremy Boynes (JIRA) wrote: > [ > http://issues.apache.org/jira/browse/TUSCANY-118?page=comments#action_1 >2371116 ] > > Jeremy Boynes commented on TUSCANY-118: > --- > > I assume having the SDO API depend on the StAX API would not be a > problem? There should perhaps in a "StaxHelper" interface that would > mean that the dependency was only triggered by people using StAX. > > Our SDO implementation should depend only on having an implementation > of StAX available. Perhaps having the user pass the > XMLStreamReader/XMLStreamWriter in the API would be sufficient. I think > this is better than having a load(URL) type method that requires the > implementation discover a StAX implementation. > > If the only dependency on AXIOM is for testing then we can just inlcude > it as a depdency and it would never impact a distribution. If we > are proving a helper for reading/writing an AXIOM model then it should > be isolated to the AXIOM helper class itself so the only users that > need to provide that dependency are the ones using AXIOM. > > > Adding Serializer/Deserializer for DataObject using StAX for better > > Axis2 AXIOM integration > > - > >-- > > > > Key: TUSCANY-118 > > URL: http://issues.apache.org/jira/browse/TUSCANY-118 > > Project: Tuscany > > Type: Improvement > > Components: Java SCA Axis Integration, Java SDO Implementation > > Reporter: Raymond Feng > > Attachments: rfeng_stax.diff, rfeng_stax_axis_095.diff > > > > Here are the key classes: > > 1) DataObjectStAXWrapper > > Implements "org.apache.axis2.databinding.ADBBean" interface by > > feeding elements and attibutes to > > "org.apache.axis2.databinding.utils.ADBPullParser". It can be used as > > a Serializer for DataObject to be serialized as OMElement. > > > > 2) StAXXMLResourceImpl and StAX2SAXAdapter > > StAXXMLResourceImpl extends > > "org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl" to provide > > additional methods to load DataObject directly from XMLStreamReader. > > StAX2SAXAdpter is responsible to pull StAX events from XMLSreamReader > > and generate SAX events so that they can be consumed by > > XMLResourceImpl. 3) DataObjectStAXWrapperTestCase > > It tests the round trip for "DataObject --> OMElment --> DataObject". > > Both static SDO model (pre-generated) and dynamic SDO model (loaded > > from WSDL/XSD) are covered. It also test the cost of the optimized > > roundtrip against the old "quick and dirty" way (DataObject --> > > OutputStream --> InputStream --> OMElement --> OutputStream --> > > InputStream --> DataObject). It shows more that 400% performance > > gain. > > > > It seems that files in set 1 and 2 are more fit to be included in the > > SDO sub-project. The following helper method is desirable. void > > SDOUtil.load(TypeHelper scope, XMLStreamReader reader, Object > > options) XMLStreamReader SDOUtil.save(TypeHelper scope, XMLDocument > > document, Object options) -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-118) Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration
Daniel Kulp wrote: > +1 to all of this (although it's test) > :-) > Having an axis/axiom dependency on the "test" phase is possibly OK > (although not ideal). Making the actual runtime depend on it is not OK. > We will need test dependencies on all technology implementations, otherwise we can't test them :-) I suppose the alternative is to make the SDO API and implementation extensible e.g. by completely externalizing serialization. > Just FYI, the JAXB 2.0 marshaller/unmarshaller has methods for the > XMLStream* and XMLEvent* and such as well as those for InputSource, URL, > InputStream, Source, etc I'm not sure if you care (since SDO is > not JAXB), but I thought I'd mention it. > This highlights the issue I was trying to avoid. As I read this (and I confess ignorance with JAXB) it sounds like there is *one* (un-)marshaller which has methods on it for different XML access APIs. This means that an implementation has to support *all* these different APIs - the "kitchen sink" approach that bloats the runtime footprint. I was hoping we would have an approach where the user only needed to ensure that the APIs *they* were using needed to be present. For example, if as a user I use StAX and SDO then I would just need a StAX implementation and an SDO implementation but would not need to worry about others (XMLBeans, Castor, JAXB, DOM, ...) -- Jeremy
Re: [jira] Commented: (TUSCANY-118) Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration
Jeremy, > > Just FYI, the JAXB 2.0 marshaller/unmarshaller has methods for the > > XMLStream* and XMLEvent* and such as well as those for InputSource, > > URL, InputStream, Source, etc I'm not sure if you care (since > > SDO is not JAXB), but I thought I'd mention it. > > This highlights the issue I was trying to avoid. As I read this (and I > confess ignorance with JAXB) it sounds like there is *one* > (un-)marshaller which has methods on it for different XML access APIs. > This means that an implementation has to support *all* these different > APIs - the "kitchen sink" approach that bloats the runtime footprint. Well, I'm not sure if it's really "kitchen sink". It's basically all the formats that are part of the JDK (JDK 1.5) which is all the source objects, the DOM, the InputSource, the URL, etc... with the addition of StAX.For the most part, I think internally, (not really sure, I haven't looked at the code) all they do is wrapper whatever comes in with a StAX Event thing so the engine itself just uses StAX.The marshaller/unmarshaller just "wraps" the incoming stuff with the appropriate wrapper. For the most part, the XMLInputFactory (part of StAX) contains all the methods for converting from all the other formats to the appropriate StAX type.Thus, the JAXB runtime doesn't need to do much. (puts the "kitchen sink" burden on the StAX runtime, not the JAXB one) Obviously, that makes the JAXB runtime directly depend on StAX in ALL cases. I'm not sure that's what you want or not, although I would vote +1 to allowing that dependency. :-) Enjoy! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-118) Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration
SDO 2 uses XMLHelper for marshalling/unmarshalling to XML. The fact that it's in a helper is the way that the spec has made it an optional part of SDO - only needed by SDO users that want to serialize/deserialize their objects as XML. An SDO user that doesn't need XML support, could work in a runtime that doesn't have the XMLHelper. Now, when using XML, the XML users typically expect all of these various input types to be supported. As Daniel puts it, they're just the list of things in the JDK. Talking to Steve Brodsky, an alternative is to add a single load(InputSource ...) API to the SDO spec ... which covers all the main ways of loading XML (Apparently StAXSource is coming in JDK 1.6) ... instead of having methods for all the different argument types. Thoughts? Frank Daniel Kulp <[EMAIL PROTECTED]> wrote on 03/20/2006 02:49:35 PM: > > Jeremy, > > > > Just FYI, the JAXB 2.0 marshaller/unmarshaller has methods for the > > > XMLStream* and XMLEvent* and such as well as those for InputSource, > > > URL, InputStream, Source, etc I'm not sure if you care (since > > > SDO is not JAXB), but I thought I'd mention it. > > > > This highlights the issue I was trying to avoid. As I read this (and I > > confess ignorance with JAXB) it sounds like there is *one* > > (un-)marshaller which has methods on it for different XML access APIs. > > This means that an implementation has to support *all* these different > > APIs - the "kitchen sink" approach that bloats the runtime footprint. > > Well, I'm not sure if it's really "kitchen sink". It's basically all > the formats that are part of the JDK (JDK 1.5) which is all the source > objects, the DOM, the InputSource, the URL, etc... with the addition of > StAX.For the most part, I think internally, (not really sure, I > haven't looked at the code) all they do is wrapper whatever comes in with > a StAX Event thing so the engine itself just uses StAX.The > marshaller/unmarshaller just "wraps" the incoming stuff with the > appropriate wrapper. For the most part, the XMLInputFactory (part of > StAX) contains all the methods for converting from all the other formats > to the appropriate StAX type.Thus, the JAXB runtime doesn't need to > do much. (puts the "kitchen sink" burden on the StAX runtime, not the > JAXB one) > > Obviously, that makes the JAXB runtime directly depend on StAX in ALL > cases. I'm not sure that's what you want or not, although I would vote > +1 to allowing that dependency. :-) > > Enjoy! > -- > J. Daniel Kulp > Principal Engineer > IONA > P: 781-902-8727 C: 508-380-7194 > [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-118) Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration
javax.xml.transform.Source and javax.xml.transform.Result seems to be the good cadidates. In JDK 1.4.x, there're three implementation classes for Source: DOMSource, SAXSource, StreamSource In JDK 1.6, there're more: DOMSource, JAXBSource, SAXSource, StAXSource, StreamSource Before we move the JDK 1.6, we can use our own version of StAXSource. Raymond - Original Message - From: "Frank Budinsky" <[EMAIL PROTECTED]> To: Sent: Monday, March 20, 2006 2:12 PM Subject: Re: [jira] Commented: (TUSCANY-118) Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration SDO 2 uses XMLHelper for marshalling/unmarshalling to XML. The fact that it's in a helper is the way that the spec has made it an optional part of SDO - only needed by SDO users that want to serialize/deserialize their objects as XML. An SDO user that doesn't need XML support, could work in a runtime that doesn't have the XMLHelper. Now, when using XML, the XML users typically expect all of these various input types to be supported. As Daniel puts it, they're just the list of things in the JDK. Talking to Steve Brodsky, an alternative is to add a single load(InputSource ...) API to the SDO spec ... which covers all the main ways of loading XML (Apparently StAXSource is coming in JDK 1.6) ... instead of having methods for all the different argument types. Thoughts? Frank Daniel Kulp <[EMAIL PROTECTED]> wrote on 03/20/2006 02:49:35 PM: Jeremy, > > Just FYI, the JAXB 2.0 marshaller/unmarshaller has methods for the > > XMLStream* and XMLEvent* and such as well as those for InputSource, > > URL, InputStream, Source, etc I'm not sure if you care (since > > SDO is not JAXB), but I thought I'd mention it. > > This highlights the issue I was trying to avoid. As I read this (and I > confess ignorance with JAXB) it sounds like there is *one* > (un-)marshaller which has methods on it for different XML access APIs. > This means that an implementation has to support *all* these different > APIs - the "kitchen sink" approach that bloats the runtime footprint. Well, I'm not sure if it's really "kitchen sink". It's basically all the formats that are part of the JDK (JDK 1.5) which is all the source objects, the DOM, the InputSource, the URL, etc... with the addition of StAX.For the most part, I think internally, (not really sure, I haven't looked at the code) all they do is wrapper whatever comes in with a StAX Event thing so the engine itself just uses StAX.The marshaller/unmarshaller just "wraps" the incoming stuff with the appropriate wrapper. For the most part, the XMLInputFactory (part of StAX) contains all the methods for converting from all the other formats to the appropriate StAX type.Thus, the JAXB runtime doesn't need to do much. (puts the "kitchen sink" burden on the StAX runtime, not the JAXB one) Obviously, that makes the JAXB runtime directly depend on StAX in ALL cases. I'm not sure that's what you want or not, although I would vote +1 to allowing that dependency. :-) Enjoy! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-107) get/setXMLVersion in XMLDocumentIMPL needs to be implemented
[ http://issues.apache.org/jira/browse/TUSCANY-107?page=comments#action_12371155 ] Frank Budinsky commented on TUSCANY-107: Thanks Hasan. I committed this, because it doesn't cause any of the existing tests to fail, but it would be good if you could provide another test case that tests the new methods. Thanks. > get/setXMLVersion in XMLDocumentIMPL needs to be implemented > > > Key: TUSCANY-107 > URL: http://issues.apache.org/jira/browse/TUSCANY-107 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Environment: All > Reporter: Hasan Muhammad > Priority: Minor > Attachments: xmlVersion_patch.txt > > The two methods in XMLDocumentImpl class, getXMLVersion() and setXMLVersion() > need to be implemented. This needs the following EMF build 2.2.0 I20060309 > This EMF build has the fix required to implemented these two methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Build breaks with new EMF clasesses ?
Hello, I'm seeing build breaks at svn rev: 387289 . org.apache.tuscany.container.java.assembly.tests.JavaAssemblyLoaderTestCase I've back tracked in svn and this started occurring I think with http://svn.apache.org/viewcvs?rev=387263&view=rev java.lang.NullPointerException at org.apache.tuscany.container.java.assembly.tests.JavaAssemblyLoaderTestCase.testLoader(JavaAssemblyLoaderTestCase.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [jira] Commented: (TUSCANY-118) Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration
Frank Budinsky wrote: > SDO 2 uses XMLHelper for marshalling/unmarshalling to XML. The fact > that it's in a helper is the way that the spec has made it an > optional part of SDO - only needed by SDO users that want to > serialize/deserialize their objects as XML. An SDO user that doesn't > need XML support, could work in a runtime that doesn't have the > XMLHelper. > Now, when using XML, the XML users typically expect all of these > various input types to be supported. I think this is the crux of the matter. I think a user will expect an implementation to support /any/ variation rather than /all/ variations. This reflects a typical usage pattern where an application uses a particular XML interface API (e.g. DOM) rather than all of them (DOM some places, SAX others, etc.). > As Daniel puts it, they're just the list of things in the JDK. > Talking to Steve Brodsky, an alternative is to add a single > load(InputSource ...) API to the SDO spec ... which covers all the > main ways of loading XML (Apparently StAXSource is coming in JDK 1.6) > ... instead of having methods for all the different argument types. I don't think users want a single method that does everything - I think they prefer something that integrates well with the API they are already using. I mean, the ultimate is flexibility is load(Object) but I would not consider that to be useful. The key realization here is that the API should not attempt to hide/abstract away the different interfaces to XML documents. Instead it should embrace each one and fully exploit its capabilities. Getting concrete, I would suggest that instead of a single XMLHelper there should be individual ones for each technology: DOMHelper, SAXHelper, StAXHelper, XMLBeansHelper, CastorHelper and so forth. -- Jeremy
Re: Project structure
I like the general proposal Jeremy made. I believe we need to make a distinction between things included in the core and baseline vs. contributions. Things in the distribution may go beyond the spec such as monitoring or some thing the community deems to have "wide" applicability to Tuscany users. I would add one extra package in core which is to separate out all of the public APIs related to extension into a separate project. Celtix has done this and this relates to a point below. In terms of build and process, my preference is to decide on an approach upfront that may be modified based on experience. Here's what I propose: 1. We focus on "clarifying" a public extension API. I don't believe we are going to be in a position to solidify this for some time, but we need to get to a more stable state than we are now since having an extension API is critical to growing the community. People writing contributions should use this API but expect change and the possibility of having to re-work their code. People working on core that introduce breaking changes will help contributors of these extensions make it "functionally whole". So, once we have the API in a "clarified" state, the build should work for extensions but people should not be upset if the API changes and while their extension may build, it may not function properly. In this case, the person responsible for introducing the change as the obligation to help get the extension working with others who are maintaining it. 2. Contributors of these new projects should be prepared to maintain them given changes in the core that are likely to arise. Hopefully this is a community process but people submitting new extension types should be prepared to maintain them. I believe this is part of the responsibility of being a committer but wanted to state it explicitly. 3. I would like to see a process where contributions first go into a sandbox and are worked on for some time prior to being put in extensions. It would be good to have a discussion (not a vote) before that move is made (i.e. to extensions). I think this is reasonably "lightweight" and offers a way to get people to contribute with no bar (the sandbox). 4. I think the project structure should reflect this. For example, I shouldn't need to download the kitchen sink to build and run the refrigerator ;-) More practically, having a project structure that represents distribution structures helps promote proper project hygiene and avoid nasty dependency issues. Thoughts? - Whats not completely clear from this is the 'rules', specifically when must the 'optional' stuff be built? If code isn't being built in the regular build that everyone runs it quickly goes stale. Look at our old Axis1 binding, been out of the regular build a couple of weeks and already it fails to build. I'd like to see everything being included in the regular build. If some extension makes building difficult vote it out, don't exclude every extension by default. Is so much structure needed at this stage, or does it just makes things more complicated and make an unnecessary decision now about how Tuscany must be used. Maybe I just don't like the baseline vs extension distinction. I'd go for a more simple hierarchy and leave the structuring to the distributions. More like the way Mule or DOJO do things with various distributions designed for specific environments - minimal, SCA-SPEC, J2EE, the kitchen sink, etc. Perhaps with distributions customizable with a fancy build script to add/remove things - "minimal,+JavaScript". ...ant On 3/18/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > One theme that came out of the recent project promotion thread was a > need to establish what our project structure should be. Part of that > also is the level of "support" between parts of that project structure. > I'd like to propose a strawman, not only of the structure but also of > the rules. > > A project "core" that: > * is as small as possible with carefully controlled dependencies > * provides the fabric for the runtime (Contexts) > * provides APIs for providing plugin extensions > * provides SPIs for embedding in host environments > * can be built separately and used by extensions in binary form > (implying versioning and stability on the extension APIs) > * has a rule that incompatible changes to the API require the changer > to upgrade and test all extensions in the Tuscany project and with > a specific vote to accept them > > Baseline services that are distributed with the core that: > * provide a deployment model for extensions (include loading, > context building, package handling (classpath)) > * provide critical system services (monitoring, admin enablement) > * provide system services needed to support baseline extensions > (security provider, transaction manager, work manager, ...) > * has the same rule on API changes for those services as the core > > Baseline extension
Re: Project structure
"kitchen sink to build and run the refrigerator" So, in your opinion, what's the kitchen sink? Please be extermely specific. Please do keep in mind that there needs to be a downloadable version on the apache web site / mirrors which people can download and run out-of-the-box. thanks, dims On 3/20/06, James F Marino <[EMAIL PROTECTED]> wrote: > I like the general proposal Jeremy made. I believe we need to make a > distinction between things included in the core and baseline vs. > contributions. Things in the distribution may go beyond the spec such > as monitoring or some thing the community deems to have "wide" > applicability to Tuscany users. I would add one extra package in core > which is to separate out all of the public APIs related to extension > into a separate project. Celtix has done this and this relates to a > point below. > > In terms of build and process, my preference is to decide on an > approach upfront that may be modified based on experience. Here's > what I propose: > > 1. We focus on "clarifying" a public extension API. I don't believe we > are going to be in a position to solidify this for some time, but we > need to get to a more stable state than we are now since having an > extension API is critical to growing the community. People writing > contributions should use this API but expect change and the > possibility of having to re-work their code. People working on core > that introduce breaking changes will help contributors of these > extensions make it "functionally whole". So, once we have the API in a > "clarified" state, the build should work for extensions but people > should not be upset if the API changes and while their extension may > build, it may not function properly. In this case, the person > responsible for introducing the change as the obligation to help get > the extension working with others who are maintaining it. > > 2. Contributors of these new projects should be prepared to maintain > them given changes in the core that are likely to arise. Hopefully > this is a community process but people submitting new extension types > should be prepared to maintain them. I believe this is part of the > responsibility of being a committer but wanted to state it explicitly. > > 3. I would like to see a process where contributions first go into a > sandbox and are worked on for some time prior to being put in > extensions. It would be good to have a discussion (not a vote) before > that move is made (i.e. to extensions). I think this is reasonably > "lightweight" and offers a way to get people to contribute with no bar > (the sandbox). > > 4. I think the project structure should reflect this. For example, I > shouldn't need to download the kitchen sink to build and run the > refrigerator ;-) More practically, having a project structure that > represents distribution structures helps promote proper project > hygiene and avoid nasty dependency issues. > > Thoughts? > > - > Whats not completely clear from this is the 'rules', specifically when must > the 'optional' stuff be built? If code isn't being built in the regular > build that everyone runs it quickly goes stale. Look at our old Axis1 > binding, been out of the regular build a couple of weeks and already it > fails to build. > > I'd like to see everything being included in the regular build. If some > extension makes building difficult vote it out, don't exclude every > extension by default. > > Is so much structure needed at this stage, or does it just makes things more > complicated and make an unnecessary decision now about how Tuscany must be > used. Maybe I just don't like the baseline vs extension distinction. > > I'd go for a more simple hierarchy and leave the structuring to the > distributions. More like the way Mule or DOJO do things with various > distributions designed for specific environments - minimal, SCA-SPEC, J2EE, > the kitchen sink, etc. Perhaps with distributions customizable with a fancy > build script to add/remove things - "minimal,+JavaScript". > >...ant > > On 3/18/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > > > One theme that came out of the recent project promotion thread was a > > need to establish what our project structure should be. Part of that > > also is the level of "support" between parts of that project structure. > > I'd like to propose a strawman, not only of the structure but also of > > the rules. > > > > A project "core" that: > > * is as small as possible with carefully controlled dependencies > > * provides the fabric for the runtime (Contexts) > > * provides APIs for providing plugin extensions > > * provides SPIs for embedding in host environments > > * can be built separately and used by extensions in binary form > > (implying versioning and stability on the extension APIs) > > * has a rule that incompatible changes to the API require the changer > > to upgrade and test all extensions in the Tuscany project
Re: Project structure
kitchen sink ~ contrib; refrigerator ~ core + baseline (maybe, although the baseline may not be necessary) On Mar 20, 2006, at 8:48 PM, Davanum Srinivas wrote: "kitchen sink to build and run the refrigerator" So, in your opinion, what's the kitchen sink? Please be extermely specific. Please do keep in mind that there needs to be a downloadable version on the apache web site / mirrors which people can download and run out-of-the-box. thanks, dims On 3/20/06, James F Marino <[EMAIL PROTECTED]> wrote: I like the general proposal Jeremy made. I believe we need to make a distinction between things included in the core and baseline vs. contributions. Things in the distribution may go beyond the spec such as monitoring or some thing the community deems to have "wide" applicability to Tuscany users. I would add one extra package in core which is to separate out all of the public APIs related to extension into a separate project. Celtix has done this and this relates to a point below. In terms of build and process, my preference is to decide on an approach upfront that may be modified based on experience. Here's what I propose: 1. We focus on "clarifying" a public extension API. I don't believe we are going to be in a position to solidify this for some time, but we need to get to a more stable state than we are now since having an extension API is critical to growing the community. People writing contributions should use this API but expect change and the possibility of having to re-work their code. People working on core that introduce breaking changes will help contributors of these extensions make it "functionally whole". So, once we have the API in a "clarified" state, the build should work for extensions but people should not be upset if the API changes and while their extension may build, it may not function properly. In this case, the person responsible for introducing the change as the obligation to help get the extension working with others who are maintaining it. 2. Contributors of these new projects should be prepared to maintain them given changes in the core that are likely to arise. Hopefully this is a community process but people submitting new extension types should be prepared to maintain them. I believe this is part of the responsibility of being a committer but wanted to state it explicitly. 3. I would like to see a process where contributions first go into a sandbox and are worked on for some time prior to being put in extensions. It would be good to have a discussion (not a vote) before that move is made (i.e. to extensions). I think this is reasonably "lightweight" and offers a way to get people to contribute with no bar (the sandbox). 4. I think the project structure should reflect this. For example, I shouldn't need to download the kitchen sink to build and run the refrigerator ;-) More practically, having a project structure that represents distribution structures helps promote proper project hygiene and avoid nasty dependency issues. Thoughts? - Whats not completely clear from this is the 'rules', specifically when must the 'optional' stuff be built? If code isn't being built in the regular build that everyone runs it quickly goes stale. Look at our old Axis1 binding, been out of the regular build a couple of weeks and already it fails to build. I'd like to see everything being included in the regular build. If some extension makes building difficult vote it out, don't exclude every extension by default. Is so much structure needed at this stage, or does it just makes things more complicated and make an unnecessary decision now about how Tuscany must be used. Maybe I just don't like the baseline vs extension distinction. I'd go for a more simple hierarchy and leave the structuring to the distributions. More like the way Mule or DOJO do things with various distributions designed for specific environments - minimal, SCA- SPEC, J2EE, the kitchen sink, etc. Perhaps with distributions customizable with a fancy build script to add/remove things - "minimal,+JavaScript". ...ant On 3/18/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: One theme that came out of the recent project promotion thread was a need to establish what our project structure should be. Part of that also is the level of "support" between parts of that project structure. I'd like to propose a strawman, not only of the structure but also of the rules. A project "core" that: * is as small as possible with carefully controlled dependencies * provides the fabric for the runtime (Contexts) * provides APIs for providing plugin extensions * provides SPIs for embedding in host environments * can be built separately and used by extensions in binary form (implying versioning and stability on the extension APIs) * has a rule that incompatible changes to the API require the changer to upgrade and test all extensions in the
Re: Framework for StAX-based model loading
Jeremy Boynes wrote: Jim Marino wrote: Hi Jeremy, Could you briefly enumerate what you see as the benefits to the StAX framework over alternatives? The final straw that prompted me to do this was the amount of classloader wrangling we ended up doing in the Tomcat code a couple of weeks ago. We need to keep track of context classloader switching between loading the model and loading any application code. There is plenty of room for subtle errors to creep in. The classloader issues we ran into with the current SDO implementation need to be solved. I am not sure that they are a sufficient reason for stopping to use SDO and moving to a different technology. I'm surprised to see that we have a databinding technology in Tuscany but we are running away from it when we encounter our first problems with it. I think we should spend a little more time trying to fix it instead of running away from it. By the way the classloader problems we ran into a couple weeks ago were not just caused by SDO, this was a combination of SDO, Axis2 and some of the factories used under the cover by Axis2, all having different requirements in terms of "current" class loader. The SDO solution (actually this would be true of any XML->POJO binding) was fine when the logical model was an exact replica of the XML files. However, to support more logical unit testing (and other uses) the model has now shifted back to being more of a true configuration model. This means we can't just slurp the XML into objects and use them directly, we need to read in the POJOs and then run a transformation on them. This adds an additional phase to the load process that needs maintenance. The logical model was never an exact replica of the XML files. Whatever technology you use you'll need to do the following: 1. handle the parsing/loading from XML 2. transform what you get from the XML into a logical model The current SDO based approach separated the two concerns. With this new StAX approach we do (1) and (2) together. I think this will create complexity over time. Having a container system there able to manage the loaders means extending the model is easy - an extension just needs to contribute its model elements and a XML handler. There is no need to codegen a separate XML model and write a transformer. There is also only one extension registry rather than two (the SDO type registry and the SCDL loader registry). I don't see why codegen is a problem. In general I'd rather get some code generated than write it myself. I agree that with the SDO approach you have to register the generated model and your handler/transformer. I don't really understand the difference you make between a handler and a transformer and why it's easier to write a handler than to codegen a model and write a transformer. With the SDO based approach you need to write code that gets data out of an SDO model with nice generated getter methods. With a StAX based approach (and it would be very similar with a DOM or SAX based approach) you get the data out of a more weakly typed model. Frankly I prefer to write: String name=component.getName(); than String name=reader.getAttributeValue(null, "name"); The XML handling is pluggable - it just uses the standard StAX APIs rather than internal hooks to our SDO implementation and/or EMF. A validating StAX parser can be used if required; semantic validation is still being performed in the model and builders. We have been working to remove the dependencies on EMF, so again I don't see how this can motivate moving to StAX. One of the goals of Tuscany is to provide a good SDO story anyway to people who want to load an XML document into an SDO model, without requiring any hooks into our SDO implementation or EMF. Again I think we should all work to improve our SDO story instead of using something else. For example I think that we should improve SDO to provide a good integration with StAX. Code footprint is better as there is no intermediate form. Performance and memory footprint are probably better too. However, I don't see that as a major factor as we are only reading config data here (i.e. it's once per deployment not once per request). I agree, code and memory footprint are better with the StAX approach. On the downside, StAX is a technology that may not be as familiar to people. However, I think it has enough similarity to DOM/SAX to be readily understood. It is also heavily used in Axis2 so we will be seeing it anyway. We will need to modify the parsing code if the XML changes whereas with SDO or another XML->POJO solution that would be handled by generation. However, the need to transform the model after load means that we have custom parsing code anyway just running on the POJOs (see SCDLModelContentHandler). This is the point that raises the biggest concern for me. I have been there before multiple times, implemented models and loaders for changing XML specificati
Re: Project structure
Assuming u are talking about the same set that Jeremy posted...+1 from me. sca/ # "core" system sca/system/common sca/system/model sca/system/core # "baseline" services and extensions sca/baseline/service/monitor sca/baseline/service/security sca/baseline/service/transaction sca/baseline/service/work sca/baseline/container/java sca/baseline/transport/axis2 sca/baseline/data/sdo sca/baseline/policy/security On 3/21/06, Jim Marino <[EMAIL PROTECTED]> wrote: > kitchen sink ~ contrib; refrigerator ~ core + baseline (maybe, > although the baseline may not be necessary) > > On Mar 20, 2006, at 8:48 PM, Davanum Srinivas wrote: > > > "kitchen sink to build and run the refrigerator" > > > > So, in your opinion, what's the kitchen sink? Please be extermely > > specific. Please do keep in mind that there needs to be a downloadable > > version on the apache web site / mirrors which people can download and > > run out-of-the-box. > > > > thanks, > > dims > > > > On 3/20/06, James F Marino <[EMAIL PROTECTED]> wrote: > > > >> I like the general proposal Jeremy made. I believe we need to make a > >> distinction between things included in the core and baseline vs. > >> contributions. Things in the distribution may go beyond the spec such > >> as monitoring or some thing the community deems to have "wide" > >> applicability to Tuscany users. I would add one extra package in core > >> which is to separate out all of the public APIs related to extension > >> into a separate project. Celtix has done this and this relates to a > >> point below. > >> > >> In terms of build and process, my preference is to decide on an > >> approach upfront that may be modified based on experience. Here's > >> what I propose: > >> > >> 1. We focus on "clarifying" a public extension API. I don't > >> believe we > >> are going to be in a position to solidify this for some time, but we > >> need to get to a more stable state than we are now since having an > >> extension API is critical to growing the community. People writing > >> contributions should use this API but expect change and the > >> possibility of having to re-work their code. People working on core > >> that introduce breaking changes will help contributors of these > >> extensions make it "functionally whole". So, once we have the API > >> in a > >> "clarified" state, the build should work for extensions but people > >> should not be upset if the API changes and while their extension may > >> build, it may not function properly. In this case, the person > >> responsible for introducing the change as the obligation to help get > >> the extension working with others who are maintaining it. > >> > >> 2. Contributors of these new projects should be prepared to maintain > >> them given changes in the core that are likely to arise. Hopefully > >> this is a community process but people submitting new extension types > >> should be prepared to maintain them. I believe this is part of the > >> responsibility of being a committer but wanted to state it > >> explicitly. > >> > >> 3. I would like to see a process where contributions first go into a > >> sandbox and are worked on for some time prior to being put in > >> extensions. It would be good to have a discussion (not a vote) before > >> that move is made (i.e. to extensions). I think this is reasonably > >> "lightweight" and offers a way to get people to contribute with no > >> bar > >> (the sandbox). > >> > >> 4. I think the project structure should reflect this. For example, I > >> shouldn't need to download the kitchen sink to build and run the > >> refrigerator ;-) More practically, having a project structure that > >> represents distribution structures helps promote proper project > >> hygiene and avoid nasty dependency issues. > >> > >> Thoughts? > >> > >> - > >> Whats not completely clear from this is the 'rules', specifically > >> when must > >> the 'optional' stuff be built? If code isn't being built in the > >> regular > >> build that everyone runs it quickly goes stale. Look at our old Axis1 > >> binding, been out of the regular build a couple of weeks and > >> already it > >> fails to build. > >> > >> I'd like to see everything being included in the regular build. If > >> some > >> extension makes building difficult vote it out, don't exclude every > >> extension by default. > >> > >> Is so much structure needed at this stage, or does it just makes > >> things more > >> complicated and make an unnecessary decision now about how Tuscany > >> must be > >> used. Maybe I just don't like the baseline vs extension distinction. > >> > >> I'd go for a more simple hierarchy and leave the structuring to the > >> distributions. More like the way Mule or DOJO do things with various > >> distributions designed for specific environments - minimal, SCA- > >> SPEC, J2EE, > >> the kitchen sink, etc. Perhaps with distributions customizable > >> with a fancy > >> build script to add/remove thing
Re: Project structure
On 3/21/06, James F Marino <[EMAIL PROTECTED]> wrote: 3. I would like to see a process where contributions first go into a > sandbox and are worked on for some time prior to being put in > extensions. It would be good to have a discussion (not a vote) before > that move is made ( i.e. to extensions). I think this is reasonably > "lightweight" and offers a way to get people to contribute with no bar > (the sandbox). I'm -1 on this, at least while its so vague. Exactly how long must things be in the sandbox and specifically what must be achieved before it can be promoted? I don't think this is workable right now as the code, APIs and SPIs are so volatile, just a few days can be enough for something that isn't part of the build to get broken in several places. Synapse had a similar discussion to this in its early stages and the outcome was for new contributions to go in HEAD, which I think is sensible. If you feel someones contributed something new and then loses interest and doesn't develop it and it becomes a burden to maintain then you can vote to get the code removed. ...ant
