I don't know much about how the sca properties are configured, but I'll try to answer your questions anyway.
> - As a user what steps do I need to take to provide custom data > values for config properties? In a previous post, I listed an example > of a concrete "Foo" class Option 1) Provide an XML schema completxType definition for the Type and let the generator gen the impl including the deserialization support. In the future, we plan to also let you provide a Java interface (with annotations, if necessary) to define the type, and then have the implementation class generated for you. The SDO generator will essentially generate the same Foo class that you showed in the other thread, just with the addition of a base class (DataObjectBase), and some get/set method overrides that implement efficient switch-based reflective accessors - used by the generic XML serializer/deserializer. If we also provide an option to generated a loader, in the future, we could also provide an option to supress the generation of the reflective accessors. The resulting class would no longer be an SDO object in this case - but it would be easy to do as a value-add feature in our generator (i.e., a -generateSimpleBean option). Option 2) Write the Foo implementation class yourself (or maybe generate it with some other technology - like JAXB) and then simply register it as a DataType with SDO. Remember that not all objects in an SDO model need to be DataObjects. If you want non-DataObjects, they're modeled as DataTypes, and you need to provide create from and convert to String methods for them. > - What steps do I need to extend the current model? What dependencies > are there? I'm not sure about this, it depends on the model. Is there a base type in the XSD for these properties. If so, then I suspect that you need to define the schema for your extension. If you go with option 1, above, that comes for free. If you want to do things by hand, then I think you could just treat your extension as unstructured XML (in the open content extension points in the model). Maybe someone else understands the model here better than I do? > - Can I use a custom binding technology to produce my model object? > I think I answered this in the option 2) section, above. > - Is it easy to support isolation between classloaders in managed > environments? My impression is that this is extremely problematic due > to required support of .INSTANCE. If that is the case, what is the > likelihood that the spec can be changed in a timely manner to improve > this? I don't think I understand where this problem will come up. In the static generated class scenarios that we're talking about, there really shouldn't be any access to .INSTANCE variables. Maybe someone can give a concrete example where this might be a problem, and we can try to figure out the solution from there. I think we need to be clear that any shortcomings in the SDO spec should not be a problem in generated scenarios. Other than saying that the generated interfaces for SDO types are bean-like, the SDO spec dictates very little about the nature of the generated code. We can fix whatever we need to. We really are just trying to leverage the Tuscany generator to do XML binding here ... our config loader does not need to be a fully compliant SDO application. Thanks, Frank. Jim Marino <[EMAIL PROTECTED]> wrote on 03/24/2006 01:31:20 PM: > I think there may be some issues uncovered with the requirements and > I'm not sure we all understand the advantages/disadvantages of each > approach. We may be over-analyzing this but the discussion was > getting very heated, there was a lot of disagreement over what the > actual (dis)advantages were, and I wanted to understand (at least for > myself) the broader implications. I thought stepping back a bit what > help clarify these things. For example, I am personally unclear on > how to do the following with SDO: > > - As a user what steps do I need to take to provide custom data > values for config properties? In a previous post, I listed an example > of a concrete "Foo" class > > - What steps do I need to extend the current model? What dependencies > are there? > > - Can I use a custom binding technology to produce my model object? > > - Is it easy to support isolation between classloaders in managed > environments? My impression is that this is extremely problematic due > to required support of .INSTANCE. If that is the case, what is the > likelihood that the spec can be changed in a timely manner to improve > this? > > I thought Jeremy's list was good and would provide a way to "weight" > answers to these and other questions. > > Jim > > On Mar 24, 2006, at 6:10 AM, Frank Budinsky wrote: > > > Jim, looking at your requirements (which I don't disagree with), I > > think > > that both approaches, if not already, can be made to meet them. > > > > Personally I think that we're over analyzing this. Both approaches > > have > > some advantages and disadvantages, but both will work. Whichever > > approach > > we take, I suspect that some people will like it and others won't . > > For > > example, people that know how to program with StAX will say it's > > easy to > > use ... people who don't will say the opposite. If we can get to > > the point > > that we effectively generate the logical model (so the user has to > > write > > no code), I think everyone will agree it's easy to use, since doing > > nothing is easy by definition :-) Of course we need to take a leap of > > faith that the current painful SDO codegen will evolve to that in > > the end. > > > > Having a vested interest to make the SDO binding technology as good as > > possible, I would support, and obviously love to see the decision > > go that > > way, That said, I think it's got to be about time to just make a > > decision > > and run with it. If this much discussion went into every design > > decision, > > we'd still be sharpening our chisels and working on carving the > > wheel :-) > > > > Thanks, > > Frank > > > > > > > > > > Jim Marino <[EMAIL PROTECTED]> > > 03/23/2006 02:53 PM > > Please respond to > > tuscany-dev > > > > > > To > > [email protected] > > cc > > > > Subject > > Re: Framework for StAX-based model loading > > > > > > > > > > > > > > There has been a lot of discussion on this topic and Jeremy's point > > brings up an issue I think needs to be fleshed out. Specifically, > > what are the requirements and priorities for loading configuration. > > Could we perhaps take the following approach? > > > > 1. Agree on the requirements and their priorities without getting > > into a technical discussion. I would suggest we rank requirements by > > absolute priority, i.e. the most important first, the next important, > > etc. rather than "requirements A and B are p1, requirements X and > > Y p2" > > > > 2. Based on the requirements and priorities, compare the StAX and SDO > > approaches for each > > > > 3. Agree on one approach moving forward for configuration > > > > If this acceptable, my opinion on requirements in priority order are: > > > > 1. The configuration mechanism must be easy for end-users to use to > > promote widespread adoption of Tuscany > > > > - For example, basic types defined by the spec should be a > > given, but it should also be easy for someone to add a custom type. > > For instance, my Foo component may take a Bar type as configuration. > > Based on past experience with IoC containers, I have found this to be > > a very common situation. > > > > -I assume this would have to involve describing the type and > > registering some kind of custom handler with the runtime > > > > 2. The configuration mechanism must be easy for container extenders > > to promote widespread adoption of Tuscany in the developer community > > > > - Similar to point 1, although I think the requirements on ease- > > of-use may be slightly different. > > - One additional item here is the configuration mechanism should > > follow Java idioms as closely as possible. Manipulating the model > > should not be foreign to Java developers > > - As a side note, I think items 1 and 2 are intimately related, > > but 1 is slightly more important since Tuscany developers will have a > > higher pain threshold than end-users > > > > 3. Operation in a variety of deployment environments. For example, > > how does each approach handle different classloader hierarchy > > scenarios? > > > > 4. Ability to handle serializations other than XML. This was one of > > the reasons why we went to a separate logical model. It's also not > > just related to testing although that is one use case. For example, > > configuration may be pulled from sources other than XML such as a > > registry. > > > > 5. Maintenance > > > > - There are probably two considerations here. First, what we use > > should be easily understood and used by Java developers wanting to > > contribute to Tuscany. A second consideration is as the spec XML > > changes, is it easy for us to evolve the code. Here, I would say we > > concentrate on the first. The second use case has a lower priority I > > have put to item 8. > > > > 6. Versioning > > > > - We need a mechanism that easily supports versioning. In the > > future, we will need to support multiple configuration format versions > > > > 7. Performance > > > > - We need something that will be performant. On at least two > > separate occasions, I have seen IoC container start-up brought to its > > knees handling configuration processing. This may not seem like a > > big deal but when there are 1,000s (or even a couple hundred) of > > components, it rears its head. > > > > 8. Ease on "us", the commiters (the second maintenance consideration) > > > > - This is where I would say how easy is it to accommodate spec > > changes comes in. Either approach can handle changes so the question > > becomes which alternative offers a better solution for commiters. > > > > Perhaps we could come up with a set of objective criteria to judge by > > and then move to a technical discussion of each approach? > > Jim > > > > On Mar 23, 2006, at 11:02 AM, Jeremy Boynes wrote: > > > > > >> I think we need to be careful to distinguish the needs we have for > >> loading our configurations from the needs users have of SDO in > >> general. I think the SCA schemas have things in them that are > >> atypical: lots of extensibility, many namespaces, custom data > >> types, few attributes/properties and so forth. On the other hand, > >> our use case doesn't need things like change tracking or streaming > >> that SDO provides. > >> > >> We need a good SDO implementation, we need a loading mechanism that > >> can handle our configurations; the two don't have to be the same. > >> If they are, that is good; if they aren't, that's not bad. > >> > >> -- > >> Jeremy > >> > >> Jean-Sebastien Delfino wrote: > >> > >> > >>> Raymond Feng wrote: > >>> > >>> > >>>> Hi, Frank. > >>>> > >>>> I think I fully agree with you. An efficient databinding is what > >>>> we're looking for. > >>>> > >>>> Ideally, if SDO later on supports lazy-loading (create the > >>>> DataObject skeleton first and pull in properties as they're > >>>> assessed) from XMLStreamReader, I assume we'll take advantage of > >>>> the benifits advocated by both camps (Databinding vs. StAX). > >>>> > >>>> Raymond > >>>> > >>>> ----- Original Message ----- From: "Frank Budinsky" > >>>> <[EMAIL PROTECTED]> > >>>> To: <[email protected]> > >>>> Sent: Thursday, March 23, 2006 9:37 AM > >>>> Subject: Re: Framework for StAX-based model loading > >>>> > >>>> > >>>> > >>>> > >>>>> I stand by my statement that the EMF problem is short term pain > >>>>> for long > >>>>> term gain :-) I think that in the long term using the SDO > >>>>> generator will > >>>>> be the best and easiest way to do this. Yes I am biased, but > >>>>> I've seen it > >>>>> before - avoiding reuse/dependencies works nicely at first, but > >>>>> as things > >>>>> grow/change and get more comlicated, the amount of reworking/ > >>>>> reinventing > >>>>> becomes quite a nightmare. The opposite problem, which I think > >>>>> we're > >>>>> suffering from here, is that the reusable component that we are > >>>>> trying to > >>>>> leverage isn't as nice and clean and a perfect fit as we'd like, > >>>>> so it > >>>>> really looks undesirable. Since we have control of all the > >>>>> pieces, in this > >>>>> case, I think we have a great opportunity to make it a clean > >>>>> fit. And like > >>>>> I said in my reply to Jeremy, earlier, I really strongly feel > >>>>> that the > >>>>> problems that we're identifying here are not unique to SCA, so > >>>>> fixing them > >>>>> is really in our best interest. > >>>>> > >>>>> Frank. > >>>>> > >>>>> "ant elder" <[EMAIL PROTECTED]> wrote on 03/23/2006 10:13:24 AM: > >>>>> > >>>>> > >>>>> > >>>>>> On 3/23/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > >>>>>> > >>>>>> <snip/> > >>>>>> > >>>>>> As the binding itself uses JAXB2 (though it may change in > >>>>>> > >>>>>>> the future), I have to include all eclipse dependencies and > >>>>>>> > >>>>>> SDO stuff, > >>>>>> > >>>>>>> just to load the system configuration files :( > >>>>>>> > >>>>>> > >>>>>> > >>>>>> From the discussion I'm starting to be persuaded by some of the > >>>>>> > >>>>>> > >>>>> arguments > >>>>> > >>>>> > >>>>>> for the SDO approach, but this EMF dependency seems a draw > >>>>>> back. If > >>>>>> > >>>>>> > >>>>> we're > >>>>> > >>>>> > >>>>>> going to support alternate data bindings for the WS binding its > >>>>>> not > >>>>>> > >>>>>> > >>>>> great to > >>>>> > >>>>> > >>>>>> still be dragging in EMF to run the thing. And I'd guess it > >>>>>> would be > >>>>>> > >>>>>> > >>>>> much > >>>>> > >>>>> > >>>>>> easier to sell SDO to say the Axis2 guys to use instead of > >>>>>> XmlBeans if > >>>>>> > >>>>>> > >>>>> there > >>>>> > >>>>> > >>>>>> was a pure Java SDO impl. Any Axis2 guys listening who'd > >>>>>> comment on > >>>>>> > >>>>>> > >>>>> this? > >>>>> > >>>>> > >>>>>> > >>>>>> As another comparison look at Axis2, they have their own very > >>>>>> simple > >>>>>> > >>>>>> > >>>>> Axis > >>>>> > >>>>> > >>>>>> Data Binding (ADB) which supports simple XSDs, and they use > >>>>>> XmlBeans for > >>>>>> > >>>>>> > >>>>> all > >>>>> > >>>>> > >>>>>> the complicated stuff. They don't use XmlBeans all the time > >>>>>> because lots > >>>>>> > >>>>>> > >>>>> of > >>>>> > >>>>> > >>>>>> things don't need the complexity a full blown data binding > >>>>>> brings. And > >>>>>> > >>>>>> > >>>>> as > >>>>> > >>>>> > >>>>>> Guillaume points out, the SCA binding schema are usually pretty > >>>>>> simple. > >>>>>> > >>>>>> ...ant > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>> Raymond, > >>> That's a very good point, I agree. > >>> I think that this whole discussion thread is very useful as it > >>> helps us identify requirements and areas of improvement for our > >>> SDO databinding and codegen story. For example, Guillaume > >>> mentioned that it would be great to have a Maven 1 SDO codegen > >>> plugin, as ServiceMix is still built with Maven 1 at the moment > >>> (and I guess a number of other projects out there still use Maven > >>> 1 as well). I can spend some time in the next few days and work > >>> with anybody who would like to volunteer and try to wrap the code > >>> generator in a Maven 1 plugin, if it helps. Guillaume, are you > >>> using Ant at all? or just Maven 1? > >>> > >>> > >> > >> > >> > >> > > > > > > > > >
