Framework for StAX-based model loading

[Jeremy Boynes <jb...@apache.org>]

I checked in a framework for a StAX-based configuration loader for the
SCA core. It is based on a set of element handlers that generate a model
object from a element in the XML stream; handlers for the core and
system schemas are in the core module, handlers for extensions can be
bundled in the extension module and are contributed as regular system
components.

I tested with the basic system and helloworld configurations and
discovered a problem with the way configured properties and references
are handled. This should be resolved once the FIXME in ComponentImpl is
addressed.

To get this working I had to modify the autowire resolver in the
SystemAggregateContextImpl. I hope this can be removed once Jim gets
references working. I also think we need to reexamine the autowire
algorithm but will open another thread for that.

--
Jeremy

Re: Framework for StAX-based model loading

[ant elder <an...@gmail.com>]

Does this mean the core will no longer require SDO and the depedency on EMF?


   ...ant

On 3/8/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> I checked in a framework for a StAX-based configuration loader for the
> SCA core. It is based on a set of element handlers that generate a model
> object from a element in the XML stream; handlers for the core and
> system schemas are in the core module, handlers for extensions can be
> bundled in the extension module and are contributed as regular system
> components.
>
> I tested with the basic system and helloworld configurations and
> discovered a problem with the way configured properties and references
> are handled. This should be resolved once the FIXME in ComponentImpl is
> addressed.
>
> To get this working I had to modify the autowire resolver in the
> SystemAggregateContextImpl. I hope this can be removed once Jim gets
> references working. I also think we need to reexamine the autowire
> algorithm but will open another thread for that.
>
> --
> Jeremy
>

Re: Framework for StAX-based model loading

[ant elder <an...@gmail.com>]

Definitely don't think we need two ways.

If most of the XML config is going to be simple 1 attribute type stuff then
StAX seems much simpler. If a reasonable amount of config XML is more
complicated then maybe we need a data binding.

I guess when trying to decide between these two approaches then given that
part of the Tuscany project is implementing this SDO data binding technology
we should probably err on the SDO choice...especially as the SDO guys say
they'll fix some of the problems that are making it harder.

   ...ant

On 3/23/06, Jim Marino <ji...@gmail.com> wrote:
>
> Hi Ant,
>
> I'm having trouble figuring out where you are coming down on this -
> maybe I'm just brain-dead this morning. You mention at the beginning
> that you are starting to be persuaded by the SDO approach but then
> you give the Axis example at the end which seems to say either "keep
> things simple" (i.e. StAX) or adopt a mixed approach and use StAX and
> SDO where appropriate. Am I reading this right?
>
> FWIW, I'd prefer to stick with one approach whatever it is, since
> multiple ones brings complexity and more maintenance in an area we
> probably don't need it (it's just configuration).
>
> Jim
>
>
> On Mar 23, 2006, at 7:13 AM, ant elder wrote:
>
> > On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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
> >
>
>

Re: Framework for StAX-based model loading

[Jim Marino <ji...@gmail.com>]

Hi Ant,

I'm having trouble figuring out where you are coming down on this -  
maybe I'm just brain-dead this morning. You mention at the beginning  
that you are starting to be persuaded by the SDO approach but then  
you give the Axis example at the end which seems to say either "keep  
things simple" (i.e. StAX) or adopt a mixed approach and use StAX and  
SDO where appropriate. Am I reading this right?

FWIW, I'd prefer to stick with one approach whatever it is, since  
multiple ones brings complexity and more maintenance in an area we  
probably don't need it (it's just configuration).

Jim


On Mar 23, 2006, at 7:13 AM, ant elder wrote:

> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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
>

Fwd: Framework for StAX-based model loading

[Jim Marino <jm...@bea.com>]

Resending since this didn't go through...

Begin forwarded message:

> From: Jim Marino <ji...@gmail.com>
> Date: March 23, 2006 11:53:12 AM PST
> To: tuscany-dev@ws.apache.org
> 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"  
>>>> <fr...@ca.ibm.com>
>>>> To: <tu...@ws.apache.org>
>>>> 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" <an...@gmail.com> wrote on 03/23/2006 10:13:24 AM:
>>>>>
>>>>>
>>>>>
>>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
>>>
>>>
>>
>>
>>
>>
>
>

Fwd: Framework for StAX-based model loading

[Jim Marino <jm...@bea.com>]

I'm forwarding this due to problems with my GMail setup...

Jim

Begin forwarded message:

> From: Jim Marino <ji...@gmail.com>
> Date: March 24, 2006 10:31:20 AM PST
> To: tuscany-dev@ws.apache.org
> Subject: Re: Framework for StAX-based model loading
>
>
> 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 <ji...@gmail.com>
>> 03/23/2006 02:53 PM
>> Please respond to
>> tuscany-dev
>>
>>
>> To
>> tuscany-dev@ws.apache.org
>> 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"
>>>>> <fr...@ca.ibm.com>
>>>>> To: <tu...@ws.apache.org>
>>>>> 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" <an...@gmail.com> wrote on 03/23/2006 10:13:24  
>>>>>> AM:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>

Fwd: Framework for StAX-based model loading

[Jim Marino <jm...@bea.com>]

Still can't get my Gmail right...sorry

Jim



Begin forwarded message:

> From: Jim Marino <ji...@gmail.com>
> Date: March 24, 2006 2:53:46 PM PST
> To: tuscany-dev@ws.apache.org
> Subject: Re: Framework for StAX-based model loading
>
>
> Thanks Frank for answering these questions.  I have a few more that  
> maybe you or others could offer opinions on.
>
> On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
>
>
>> 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.
>>
> I think option two is the more appealing one for applications  
> developers. I read option 1 to require a schema, which we may be  
> able to do for extensions, but is a bit much to ask application  
> developers to produce.  So, I'm curious as to how the conversion  
> methods you mentioned look like.  Assume I have the following Java  
> implementation and configuration class:
>
> public class MyComponent{
>
>     @Property
>     private Foo; myFoo;
>
> }
>
>
> public class Foo{
>
>     public Foo(){}
>
>     private String name;
>
>     public setName(String val){
>         name = val;
>     }
>
>     private Foo foo;
>
>     public void setFoo(Foo val){
>         foo = val;
>
>     }
>
>     private MyJaxBThing jaxBThing;
>
>     public void setMyJaxBThing(MyJaxBThing thing){
>         jaxBthing = thing;
>     }
> }
>
>
>
> And I want to use the following configuration:
>
>     <component name="myComp>
>         <implementation.java class="MyComponent/>
>         <properties>
>             <v:myFoo>
>                     <v:name>my name</v:name>
>                     <v:foo>
>                             <v:name>my sub name</v:name>
>                     </v:foo>
>                     <jaxb:jaxBThing>
>                             <!-- other configuration according to  
> JAX-B--->
>                     <jaxb:jaxBThing>
>             <v:myFoo>
>         </properties>
>     </component>
>
> I'm assuming I would have to register Foo and MyJaxBThing with  
> SDO?  Could someone walk through the steps I would need to do to  
> tell the runtime how to take the particular configuration and  
> deserialize it? Also, what would the string transformation methods  
> look like in this case? I'm also having difficulty pinning down how  
> the JAXB class is instantiated (I'm assuming something needs to  
> access a JAXB factory at some point).
>
> Another really common use case (sorry to keep harping on this one,  
> but I see it all of the time) is support for List and Map. I should  
> be able to specify some type of XML serialized form and have  
> property configuration injected on a component as a List or Map.   
> I'm assuming based on your comments below this can be done to the  
> SDO implementation and we could provide this to end-users without  
> them having to configure something?
>
> One final scenario, related to this, is support for factories for  
> property instantiation. IoC containers such as Spring have a way to  
> pass a factory in to the injection engine to delegate to for  
> creating property instances.  Could this be done with SDO?
>
>>
>>
>>
>>> - 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 have two concrete examples here where I have seen problems in  
> other projects:
>
>
> 1. Assume there are two nested components whose implementation  
> types are loaded by different classloaders. These two nested  
> components have a property that takes a "Foo". The configuration  
> schema is the same but the "Foo" classes are different because they  
> are loaded by different classloaders. Do you think we will run into  
> any issues here?
>
> 2. Another concern is around application reloadability. If I have a  
> registered type of "Foo" and the application it was registered by  
> needs to be reloaded, how is it flushed from SDO? Does the  
> container have to call a flush method somewhere?
>
>
>
>> 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.
>>
>
> I appreciate that and you taking the time to help explain this  
> stuff to me. I guess I'm going to be a typical example of someone  
> who wants to extend the container and has a bunch of questions :-)
>
>
>> 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 <ji...@gmail.com> 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 <ji...@gmail.com>
>>>> 03/23/2006 02:53 PM
>>>> Please respond to
>>>> tuscany-dev
>>>>
>>>>
>>>> To
>>>> tuscany-dev@ws.apache.org
>>>> 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"
>>>>>>> <fr...@ca.ibm.com>
>>>>>>> To: <tu...@ws.apache.org>
>>>>>>> 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" <an...@gmail.com> wrote on 03/23/2006  
>>>>>>>> 10:13:24 AM:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>

Re: How do we handle SCA properties

[Jim Marino <ji...@gmail.com>]

On Mar 28, 2006, at 7:20 AM, Jean-Sebastien Delfino wrote:

> Jim Marino wrote:
>
>>
>> On Mar 24, 2006, at 4:21 PM, Jean-Sebastien Delfino wrote:
>>
>>
>>> Jim Marino wrote:
>>>
>>> [snip]
>>>
>>>
>>>> Thanks Frank for answering these questions. I have a few more  
>>>> that maybe you or others could offer opinions on.
>>>>
>>>> On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
>>>>
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>>
>>>> I think option two is the more appealing one for applications  
>>>> developers. I read option 1 to require a schema, which we may be  
>>>> able to do for extensions, but is a bit much to ask application  
>>>> developers to produce.
>>>>
>>>>
>>>
>>> Jim, I'd like to initiate a new thread of discussion on property  
>>> types and property configuration, because I think that you're  
>>> bringing up very good and interesting points here and we're going  
>>> to have to explore that space, which is not really covered by the  
>>> SCA spec at the moment.
>>>
>>> I agree with you that option two is much more appealing to (Java)  
>>> application developers. If I'm a Java developer writing POJO  
>>> components I probably just want to write Java classes for my  
>>> complex properties, I don't want to write an XMLSchema at all. On  
>>> the other hand, if I'm a BPEL developer, or writing XSLT  
>>> components for example, chances are that I'll actually prefer to  
>>> write an XMLSchema. I think we need to support both use cases /  
>>> populations of developers, like we do for service interfaces with  
>>> Java interfaces and WSDL portTypes. I'm also starting to think  
>>> that this should even be more extensible. Let's say I'm writing a  
>>> Javascript component, a C++ component, or a Ruby component - just  
>>> using Ruby as an example here, I don't have a Ruby component  
>>> container in the back of my pocket :), will I want to define my  
>>> property types as Java classes? as XMLSchema types? I'm not  
>>> sure... I'd probably prefer to use the same programming language  
>>> I'm using to implement my component.
>>>
>>> So we have a lot to explore here, and I think that all these  
>>> questions are really about finding the right programming model  
>>> for defining and configuring properties of SCA components written  
>>> in various languages. We also need to add another dimension to  
>>> that. First we have to deal with the Java developer, the BPEL  
>>> developer, the XSLT developer, the JavaScript developer etc. then  
>>> we also have to deal with different data representations and  
>>> binding technologies. For some languages, like BPEL for example,  
>>> the data representation will probably be driven by what your BPEL  
>>> engine expects, or for JavaScript what your JavaScript runtime/VM  
>>> expects. For Java, we have multiple choices. Some people will  
>>> want to use plain JavaBeans, others JAXB, others SDO, others ADB  
>>> or XMLBeans etc. So again here, without even going into any  
>>> implementation details of how to glue all these technologies  
>>> together (and independent of whether or not we use our SDO  
>>> databinding to load our SCDL files), we need to define how an SCA  
>>> application developer, using Tuscany, will specify what form he  
>>> wants for his properties...
>>>
>>>
>> I'm wondering if now if the question isn't  a choice between  
>> Jeremy's approach and going with SDO ( or some other binding  
>> technology. Since we will need maximum extensibility to handle all  
>> of these different component types, It seems to me what we need is  
>> a "low-level" binding infrastructure that things like JAXB or SDO  
>> can plug into. Another way to view this would be the low-level  
>> infrastructure delegates to other binding technologies, which  
>> would allow us to support multiple binding solutions as opposed to  
>> just one at a time. This low-level infrastructure would be  
>> responsible for partially parsing the XML and delegating to a  
>> factories if necessary to instantiate property instances. I think  
>> this would allow for *multiple* binding frameworks as opposed to  
>> just one. Jeremy, do you think this is feesible and if so could  
>> you provide a sketch of how this would look in code?
>>
>>
> I was explicitly trying to create a different thread of discussion  
> here, on a different level. IMHO both the SDO based approach and  
> Jeremy's StAX approach can be made extensible and support pluggable  
> databindings and pluggable factories for properties. But again I  
> was trying to initiate a discussion of the actual scenarios for  
> using properties and requirements at the programming model level.  
> The SDO vs StAX discussion is an interesting discussion, but a  
> different one, and I'd prefer to continue it in its own thread, not  
> this one.
>
O.K. sorry I couldn't help myself. Can't we take the list of  
requirements last updated by Jeremy and fold the items you outlined  
here into them, changing the subject to the current?  I'm happy to do  
that if it works for you. I kind of think the two discussions are  
intertwined since the StAX vs. SDO is an issue related to how the  
requirements should be implemented.  I was trying to suggest the  
following:

- We must support a simple, easy bottom up extensibility story that  
feels natural in whatever implementation *major* language/programming  
model people are using.
- We also need to support a top-down approach. My opinion is the  
buttom up approach is more important given our user base but I don't  
think we should debate that.
- The most realistic way it seems to me that we can be successful in  
achieving support for such varied use cases is we have a "binding  
infrastructure" that is extremely open and not tied to a particular  
binding technology. I realize we need to go through the use cases in  
more detail before we arrive at this conclusion but I figured it  
would be useful to state prejudices up front
- Jeremy's StAX approach may provide this for us, with the ability to  
"layer" a variety of binding technologies on top. I definitely don't  
think we should conclude this yet. My intention was to point
out that we shouldn't necessarily presume it is StAX *vs.* SDO.

Anyway, do you want me to fold these into a requirements list?

>>
>>
>>> Now back to the reality of the SCA 0.9 spec :) It currently only  
>>> defines support for simple type properties and requires the type  
>>> of a property to be expressed as an XML schema type. The  
>>> <property> element is defined as follows: <property  
>>> name="xs:NCName" type="xs:QName" many="xs:boolean"?  
>>> default="xs:string"? required="xs:boolean"?/>* where xs:QName is  
>>> the qualified name of an XML schema simple type.
>>>
>>>
>> Yes, this was an area left for further work due to time constraints.
>>
>>> Obviously we need to improve this, and maybe we can even provide  
>>> some input into the spec with the work we are doing in Tuscany:
>>>
>>
>> Yea, we definitely need to improve since that level of support is  
>> kind of lame.
>>
>>
>>> - first define what it means to support complex type properties  
>>> (what types are allowed? what about special Java collection  
>>> types, can you have pointers between properties etc.)
>>> - decide if we want to use a type system that is independent of a  
>>> component implementation language, or tie the types of properties  
>>> to the component implementation language
>>>
>>
>> My opinion here is we want to go the language-specific route since  
>> we need to make working with properties natural to the  
>> implementation language. I think the most important goal of  
>> property configuration is to configuration points of variability  
>> on a specific implementation, not as a general representation of  
>> configuration data.
>>
> Yes, I agree with you for some use cases. If I'm going to write a  
> component in language X, I'd like to define my property types in  
> the same language X. On the other hand I can see other use cases  
> (e.g. top down scenarios) where I'm going to define a component  
> type without caring or even knowing about how it's going to be  
> implemented. I'm not sure which implementation neutral form/ 
> language I'll want to use to define the component properties. Will  
> I use XMLSchema? Any thoughts?
>
>
>>> cover the scenario you first brought up where you just want Java  
>>> classes and no schema at all
>>> - cover the scenarios where you just want to use XML schemas
>>> - define how an application developer chooses a databinding/ 
>>> representation
>>>
>> Jeremy, could you provide an outline of how the StAX work could  
>> enable this?
>>
>>> - define what happens when an application developer decides to  
>>> mix in a single application multiple databinding technologies (or  
>>> if that even makes sense at all...)
>>>
>>>
>> I think that makes sense based on the use case you brought up,  
>> e.g. a Java component that takes POJOs and a BPEL engine that only  
>> understands SDO.
>>
>>
>>> I'm probably missing many more questions/items here :) I just  
>>> wanted to initiate this discussion which I think is important.  
>>> Any thoughts?
>>>
>>>
>> This is good - I think we're hammering out some important things  
>> even if the discussion gets heated at times :-)
>>
>>> --Jean-Sebastien
>>>
>>>
>>>
>>
>>
>>
> -- 
> Jean-Sebastien
>
>

Re: How do we handle SCA properties

[Jean-Sebastien Delfino <js...@apache.org>]

Jim Marino wrote:
>
> On Mar 24, 2006, at 4:21 PM, Jean-Sebastien Delfino wrote:
>
>> Jim Marino wrote:
>>
>> [snip]
>>
>>> Thanks Frank for answering these questions. I have a few more that 
>>> maybe you or others could offer opinions on.
>>>
>>> On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
>>>
>>>
>>>> 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.
>>>>
>>> I think option two is the more appealing one for applications 
>>> developers. I read option 1 to require a schema, which we may be 
>>> able to do for extensions, but is a bit much to ask application 
>>> developers to produce.
>>>
>>
>> Jim, I'd like to initiate a new thread of discussion on property 
>> types and property configuration, because I think that you're 
>> bringing up very good and interesting points here and we're going to 
>> have to explore that space, which is not really covered by the SCA 
>> spec at the moment.
>>
>> I agree with you that option two is much more appealing to (Java) 
>> application developers. If I'm a Java developer writing POJO 
>> components I probably just want to write Java classes for my complex 
>> properties, I don't want to write an XMLSchema at all. On the other 
>> hand, if I'm a BPEL developer, or writing XSLT components for 
>> example, chances are that I'll actually prefer to write an XMLSchema. 
>> I think we need to support both use cases / populations of 
>> developers, like we do for service interfaces with Java interfaces 
>> and WSDL portTypes. I'm also starting to think that this should even 
>> be more extensible. Let's say I'm writing a Javascript component, a 
>> C++ component, or a Ruby component - just using Ruby as an example 
>> here, I don't have a Ruby component container in the back of my 
>> pocket :), will I want to define my property types as Java classes? 
>> as XMLSchema types? I'm not sure... I'd probably prefer to use the 
>> same programming language I'm using to implement my component.
>>
>> So we have a lot to explore here, and I think that all these 
>> questions are really about finding the right programming model for 
>> defining and configuring properties of SCA components written in 
>> various languages. We also need to add another dimension to that. 
>> First we have to deal with the Java developer, the BPEL developer, 
>> the XSLT developer, the JavaScript developer etc. then we also have 
>> to deal with different data representations and binding technologies. 
>> For some languages, like BPEL for example, the data representation 
>> will probably be driven by what your BPEL engine expects, or for 
>> JavaScript what your JavaScript runtime/VM expects. For Java, we have 
>> multiple choices. Some people will want to use plain JavaBeans, 
>> others JAXB, others SDO, others ADB or XMLBeans etc. So again here, 
>> without even going into any implementation details of how to glue all 
>> these technologies together (and independent of whether or not we use 
>> our SDO databinding to load our SCDL files), we need to define how an 
>> SCA application developer, using Tuscany, will specify what form he 
>> wants for his properties...
>>
> I'm wondering if now if the question isn't  a choice between Jeremy's 
> approach and going with SDO ( or some other binding technology. Since 
> we will need maximum extensibility to handle all of these different 
> component types, It seems to me what we need is a "low-level" binding 
> infrastructure that things like JAXB or SDO can plug into. Another way 
> to view this would be the low-level infrastructure delegates to other 
> binding technologies, which would allow us to support multiple binding 
> solutions as opposed to just one at a time. This low-level 
> infrastructure would be responsible for partially parsing the XML and 
> delegating to a factories if necessary to instantiate property 
> instances. I think this would allow for *multiple* binding frameworks 
> as opposed to just one. Jeremy, do you think this is feesible and if 
> so could you provide a sketch of how this would look in code?
>
I was explicitly trying to create a different thread of discussion here, 
on a different level. IMHO both the SDO based approach and Jeremy's StAX 
approach can be made extensible and support pluggable databindings and 
pluggable factories for properties. But again I was trying to initiate a 
discussion of the actual scenarios for using properties and requirements 
at the programming model level. The SDO vs StAX discussion is an 
interesting discussion, but a different one, and I'd prefer to continue 
it in its own thread, not this one.

>
>> Now back to the reality of the SCA 0.9 spec :) It currently only 
>> defines support for simple type properties and requires the type of a 
>> property to be expressed as an XML schema type. The <property> 
>> element is defined as follows: <property name="xs:NCName" 
>> type="xs:QName" many="xs:boolean"? default="xs:string"? 
>> required="xs:boolean"?/>* where xs:QName is the qualified name of an 
>> XML schema simple type.
>>
> Yes, this was an area left for further work due to time constraints.
>> Obviously we need to improve this, and maybe we can even provide some 
>> input into the spec with the work we are doing in Tuscany:
>
> Yea, we definitely need to improve since that level of support is kind 
> of lame.
>
>> - first define what it means to support complex type properties (what 
>> types are allowed? what about special Java collection types, can you 
>> have pointers between properties etc.)
>> - decide if we want to use a type system that is independent of a 
>> component implementation language, or tie the types of properties to 
>> the component implementation language
>
> My opinion here is we want to go the language-specific route since we 
> need to make working with properties natural to the implementation 
> language. I think the most important goal of property configuration is 
> to configuration points of variability on a specific implementation, 
> not as a general representation of configuration data.
Yes, I agree with you for some use cases. If I'm going to write a 
component in language X, I'd like to define my property types in the 
same language X. On the other hand I can see other use cases (e.g. top 
down scenarios) where I'm going to define a component type without 
caring or even knowing about how it's going to be implemented. I'm not 
sure which implementation neutral form/language I'll want to use to 
define the component properties. Will I use XMLSchema? Any thoughts?

>> cover the scenario you first brought up where you just want Java 
>> classes and no schema at all
>> - cover the scenarios where you just want to use XML schemas
>> - define how an application developer chooses a 
>> databinding/representation
> Jeremy, could you provide an outline of how the StAX work could enable 
> this?
>> - define what happens when an application developer decides to mix in 
>> a single application multiple databinding technologies (or if that 
>> even makes sense at all...)
>>
> I think that makes sense based on the use case you brought up, e.g. a 
> Java component that takes POJOs and a BPEL engine that only 
> understands SDO.
>
>> I'm probably missing many more questions/items here :) I just wanted 
>> to initiate this discussion which I think is important. Any thoughts?
>>
> This is good - I think we're hammering out some important things even 
> if the discussion gets heated at times :-)
>> --Jean-Sebastien
>>
>>
>
>
-- 
Jean-Sebastien

Re: How do we handle SCA properties (was: Framework for StAX-based model loading)

[Jim Marino <jm...@myromatours.com>]

On Mar 24, 2006, at 4:21 PM, Jean-Sebastien Delfino wrote:

> Jim Marino wrote:
>
> [snip]
>
>> Thanks Frank for answering these questions. I have a few more that  
>> maybe you or others could offer opinions on.
>>
>> On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
>>
>>
>>> 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.
>>>
>> I think option two is the more appealing one for applications  
>> developers. I read option 1 to require a schema, which we may be  
>> able to do for extensions, but is a bit much to ask application  
>> developers to produce.
>>
>
> Jim, I'd like to initiate a new thread of discussion on property  
> types and property configuration, because I think that you're  
> bringing up very good and interesting points here and we're going  
> to have to explore that space, which is not really covered by the  
> SCA spec at the moment.
>
> I agree with you that option two is much more appealing to (Java)  
> application developers. If I'm a Java developer writing POJO  
> components I probably just want to write Java classes for my  
> complex properties, I don't want to write an XMLSchema at all. On  
> the other hand, if I'm a BPEL developer, or writing XSLT components  
> for example, chances are that I'll actually prefer to write an  
> XMLSchema. I think we need to support both use cases / populations  
> of developers, like we do for service interfaces with Java  
> interfaces and WSDL portTypes. I'm also starting to think that this  
> should even be more extensible. Let's say I'm writing a Javascript  
> component, a C++ component, or a Ruby component - just using Ruby  
> as an example here, I don't have a Ruby component container in the  
> back of my pocket :), will I want to define my property types as  
> Java classes? as XMLSchema types? I'm not sure... I'd probably  
> prefer to use the same programming language I'm using to implement  
> my component.
>
> So we have a lot to explore here, and I think that all these  
> questions are really about finding the right programming model for  
> defining and configuring properties of SCA components written in  
> various languages. We also need to add another dimension to that.  
> First we have to deal with the Java developer, the BPEL developer,  
> the XSLT developer, the JavaScript developer etc. then we also have  
> to deal with different data representations and binding  
> technologies. For some languages, like BPEL for example, the data  
> representation will probably be driven by what your BPEL engine  
> expects, or for JavaScript what your JavaScript runtime/VM expects.  
> For Java, we have multiple choices. Some people will want to use  
> plain JavaBeans, others JAXB, others SDO, others ADB or XMLBeans  
> etc. So again here, without even going into any implementation  
> details of how to glue all these technologies together (and  
> independent of whether or not we use our SDO databinding to load  
> our SCDL files), we need to define how an SCA application  
> developer, using Tuscany, will specify what form he wants for his  
> properties...
>
I'm wondering if now if the question isn't  a choice between Jeremy's  
approach and going with SDO ( or some other binding technology. Since  
we will need maximum extensibility to handle all of these different  
component types, It seems to me what we need is a "low-level" binding  
infrastructure that things like JAXB or SDO can plug into. Another  
way to view this would be the low-level infrastructure delegates to  
other binding technologies, which would allow us to support multiple  
binding solutions as opposed to just one at a time. This low-level  
infrastructure would be responsible for partially parsing the XML and  
delegating to a factories if necessary to instantiate property  
instances. I think this would allow for *multiple* binding frameworks  
as opposed to just one. Jeremy, do you think this is feesible and if  
so could you provide a sketch of how this would look in code?


> Now back to the reality of the SCA 0.9 spec :) It currently only  
> defines support for simple type properties and requires the type of  
> a property to be expressed as an XML schema type. The <property>  
> element is defined as follows: <property name="xs:NCName"  
> type="xs:QName" many="xs:boolean"? default="xs:string"?  
> required="xs:boolean"?/>* where xs:QName is the qualified name of  
> an XML schema simple type.
>
Yes, this was an area left for further work due to time constraints.
> Obviously we need to improve this, and maybe we can even provide  
> some input into the spec with the work we are doing in Tuscany:

Yea, we definitely need to improve since that level of support is  
kind of lame.

> - first define what it means to support complex type properties  
> (what types are allowed? what about special Java collection types,  
> can you have pointers between properties etc.)
> - decide if we want to use a type system that is independent of a  
> component implementation language, or tie the types of properties  
> to the component implementation language

My opinion here is we want to go the language-specific route since we  
need to make working with properties natural to the implementation  
language. I think the most important goal of property configuration  
is to configuration points of variability on a specific  
implementation, not as a general representation of configuration data.
> - cover the scenario you first brought up where you just want Java  
> classes and no schema at all
> - cover the scenarios where you just want to use XML schemas
> - define how an application developer chooses a databinding/ 
> representation
Jeremy, could you provide an outline of how the StAX work could  
enable this?
> - define what happens when an application developer decides to mix  
> in a single application multiple databinding technologies (or if  
> that even makes sense at all...)
>
I think that makes sense based on the use case you brought up, e.g. a  
Java component that takes POJOs and a BPEL engine that only  
understands SDO.

> I'm probably missing many more questions/items here :) I just  
> wanted to initiate this discussion which I think is important. Any  
> thoughts?
>
This is good - I think we're hammering out some important things even  
if the discussion gets heated at times :-)
> -- 
> Jean-Sebastien
>
>

How do we handle SCA properties (was: Framework for StAX-based model loading)

[Jean-Sebastien Delfino <js...@apache.org>]

Jim Marino wrote:

[snip]
> Thanks Frank for answering these questions. I have a few more that 
> maybe you or others could offer opinions on.
>
> On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
>
>> 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.
> I think option two is the more appealing one for applications 
> developers. I read option 1 to require a schema, which we may be able 
> to do for extensions, but is a bit much to ask application developers 
> to produce.

Jim, I'd like to initiate a new thread of discussion on property types 
and property configuration, because I think that you're bringing up very 
good and interesting points here and we're going to have to explore that 
space, which is not really covered by the SCA spec at the moment.

I agree with you that option two is much more appealing to (Java) 
application developers. If I'm a Java developer writing POJO components 
I probably just want to write Java classes for my complex properties, I 
don't want to write an XMLSchema at all. On the other hand, if I'm a 
BPEL developer, or writing XSLT components for example, chances are that 
I'll actually prefer to write an XMLSchema. I think we need to support 
both use cases / populations of developers, like we do for service 
interfaces with Java interfaces and WSDL portTypes. I'm also starting to 
think that this should even be more extensible. Let's say I'm writing a 
Javascript component, a C++ component, or a Ruby component - just using 
Ruby as an example here, I don't have a Ruby component container in the 
back of my pocket :), will I want to define my property types as Java 
classes? as XMLSchema types? I'm not sure... I'd probably prefer to use 
the same programming language I'm using to implement my component.

So we have a lot to explore here, and I think that all these questions 
are really about finding the right programming model for defining and 
configuring properties of SCA components written in various languages. 
We also need to add another dimension to that. First we have to deal 
with the Java developer, the BPEL developer, the XSLT developer, the 
JavaScript developer etc. then we also have to deal with different data 
representations and binding technologies. For some languages, like BPEL 
for example, the data representation will probably be driven by what 
your BPEL engine expects, or for JavaScript what your JavaScript 
runtime/VM expects. For Java, we have multiple choices. Some people will 
want to use plain JavaBeans, others JAXB, others SDO, others ADB or 
XMLBeans etc. So again here, without even going into any implementation 
details of how to glue all these technologies together (and independent 
of whether or not we use our SDO databinding to load our SCDL files), we 
need to define how an SCA application developer, using Tuscany, will 
specify what form he wants for his properties...

Now back to the reality of the SCA 0.9 spec :) It currently only defines 
support for simple type properties and requires the type of a property 
to be expressed as an XML schema type. The <property> element is defined 
as follows: <property name="xs:NCName" type="xs:QName" 
many="xs:boolean"? default="xs:string"? required="xs:boolean"?/>* where 
xs:QName is the qualified name of an XML schema simple type.

Obviously we need to improve this, and maybe we can even provide some 
input into the spec with the work we are doing in Tuscany:
- first define what it means to support complex type properties (what 
types are allowed? what about special Java collection types, can you 
have pointers between properties etc.)
- decide if we want to use a type system that is independent of a 
component implementation language, or tie the types of properties to the 
component implementation language
- cover the scenario you first brought up where you just want Java 
classes and no schema at all
- cover the scenarios where you just want to use XML schemas
- define how an application developer chooses a databinding/representation
- define what happens when an application developer decides to mix in a 
single application multiple databinding technologies (or if that even 
makes sense at all...)

I'm probably missing many more questions/items here :) I just wanted to 
initiate this discussion which I think is important. Any thoughts?

-- 
Jean-Sebastien

Re: Framework for StAX-based model loading

[Jeremy Boynes <jb...@apache.org>]

Jim Marino wrote:
>>> - 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
>>>
<snip>a lot</snip>

I added support to the StAX version that allows you to specify a custom
parser for the content of any <v:name> element. It works by allowing you
to specify a "factory" attribute on the element which is the name of a
class to which we will pass the stax stream.

So if your XML contained:
  <properties>
    <propFoo factory='com.example.FooFactory'>
       <name>Hello</name>
    </propFoo>
  </properties>

we would create a new FooFactory, pass it the stream and use the result
to create the instance to inject into the component.

As a user, all you need to do is write the factory and include that with
your application. The implementation can use any XML binding technology
that can read from a StAX stream.

You can see an example in
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/core/src/test/java/org/apache/tuscany/core/loader/assembly/ComponentLoaderTestCase.java

I also added a factory that converts simple element text into a instance
of the Property's type as follows:
* if the property is a String, use the element text
* if the property type has a static valueOf(String) method,
  call that and use the result
* if the property type has a constructor taking a single
  String parameter, use that to instantiate a value
* if there is a PropertyEditor available for the type,
  use that to construct a value from the element text
* bail...

This gives support for most common Java types including primitives,
Numbers, String, URLs, Date (albeit in a funky form) etc.

I would have based this on the XML Schema simple type but that
information is not stored in the Property configuration model. Once we
get that in there then it would be simple to modify this for a xml->java
type conversion.

--
Jeremy

Fwd: Framework for StAX-based model loading

[Jim Marino <jm...@bea.com>]

I'm still having delays from gmail...

Begin forwarded message:

> From: Jim Marino <ji...@gmail.com>
> Date: April 5, 2006 9:10:14 AM PDT
> To: tuscany-dev@ws.apache.org
> Subject: Re: Framework for StAX-based model loading
>
>
> I think this this is a really good approach and will give us a  
> great binding/extension story for Tuscany. Two comments on the  
> statement that the model may look a little different than what we  
> have here. The first one is that in general, I'm o.k. with that as  
> long as it follows common Java idioms. I don't think this will be a  
> problem.  The second is I'm happy to help out porting the runtime  
> core to use the new model so just let me know when we have a cut of  
> the new model.
>
> Jim
>
> On Apr 4, 2006, at 3:16 PM, Frank Budinsky wrote:
>
>
>> Resending my previous post ... I see that the formatting I wrote  
>> it with
>> went away and it became impossible to read. Congratulations to  
>> anyone that
>> got anything out of it at all :-)
>>
>> Sorry about that,
>> Frank.
>>
>>
>> Here is a proposal for moving forward on this issue that I think (am
>> hoping :-) everyone can live with.
>>
>> 1. Remove the existing logical and physical models (and corresponding
>>    transformer code) and replace them with a single logical model
>>    created as follows:
>>   a. One-time generate a pure JavaBean model from the XMLSchema
>>      (sca-core.xsd) using a hacked up prototype of the SDO generator.
>>      This prototype suppresses SDO things (e.g., reflective methods,
>>      for example), so the generated classes are not SDOs - they're
>>      POJOs.
>>   b. Hand modify the generated classes to add additional methods  
>> needed
>>      for the logical model. The end result, will look very  
>> similar, but
>>      not identical, to the current logical model, so a small  
>> amount of
>>      work will be needed to port client code from the current logical
>>      model to this new combined "logical/physical" model.
>>
>> 2. Modify Jeremy's StAX handlers to work with this new model, and  
>> also
>>    use them as the prototypical example of the output for a new
>>    -generateLoader option for the SDO generator. The plan for the May
>>    release will be to use the modified hand written StAX handlers,  
>> but
>>    they will be marked as "to be generated", so that it's clear  
>> that in
>>    the future these handlers will be replaced with generated ones.
>>
>> 3. Start immediately on the SDO -generateLoader and -simpleBeans  
>> options.
>>    We will use -generateLoader for the core model, as soon as it's
>>    available (target 2-3 months?), but we will not plan to regen  
>> the core
>>    model using -simpleBeans. The model will remain hand coded
>>    indefinitely, but we can revisit the possibility of generating  
>> parts
>>    of it in the future (but this won't be a priority). The - 
>> simpleBeans
>>    option will be available for use by people adding extensions to  
>> the
>>    model, if they want to start with XSDs.
>>
>> 4. Also start immediately on a -generateSerializer option so that  
>> we will
>>    be able to use simple beans that need to be saved as well as  
>> loaded.
>>    Given that we support generation of POJOs, we need both generated
>>    loaders and serializers to use them. We also need to start work on
>>    defining the necessary Java annotations to support generating
>>    loaders/serializers from hand-written POJOs (or more generally  
>> to also
>>    generate SDOs from hand written Java interfaces.
>>
>> I think this approach is a win-win for both the SCA and SDO projects.
>>
>> Thoughts?
>>
>> Thanks,
>> Frank.
>>
>>
>>
>>> Frank Budinsky/Toronto/IBM@IBMCA wrote on 03/27/2006 01:26:46 PM:
>>>
>>>
>>>
>>>> Jim Marino <ji...@gmail.com> wrote on 03/24/2006 05:53:46 PM:
>>>>
>>>>
>>>>
>>>>> Thanks Frank for answering these questions.  I have a few more  
>>>>> that
>>>>> maybe you or others could offer opinions on.
>>>>>
>>>>> On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>> I think option two is the more appealing one for applications
>>>>> developers. I read option 1 to require a schema, which we may be
>>>>>
>>>>>
>> able
>>
>>
>>>>> to do for extensions, but is a bit much to ask application
>>>>>
>>>>>
>> developers
>>
>>
>>>>> to produce.  So, I'm curious as to how the conversion methods you
>>>>> mentioned look like.  Assume I have the following Java
>>>>>
>>>>>
>> implementation
>>
>>
>>>>> and configuration class:
>>>>>
>>>>>
>>>> I wouldn't write off option 1 so quickly. For your example, a  
>>>> schema
>>>>
>>>>
>> (or
>>
>>
>>>
>>>
>>>
>>>> equivalent SDO metadata) something like this is all that one needs:
>>>>
>>>> <element name="myFoo" type="Foo"/>
>>>>
>>>> <complexType name="Foo">
>>>>     <sequence>
>>>>         <element name="name" type="xsd:int"/>
>>>>         <element name="foo" type="Foo"/>
>>>>         <element name="myJaxBThing" type="jaxb:jaxBThing"/>
>>>>     </sequence>
>>>> </complexType>
>>>>
>>>> This schema could be deduced (under the covers) from the Java  
>>>> classes
>>>>
>>>>
>>> you
>>>
>>>
>>>> show below, so you wouldn't need to actually write it (once we  
>>>> get the
>>>>
>>>>
>>
>>
>>
>>>> Java import support working, of course).
>>>>
>>>>
>>>>
>>>>>
>>>>> public class MyComponent{
>>>>>
>>>>>      @Property
>>>>>      private Foo; myFoo;
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> public class Foo{
>>>>>
>>>>>      public Foo(){}
>>>>>
>>>>>      private String name;
>>>>>
>>>>>      public setName(String val){
>>>>>          name = val;
>>>>>      }
>>>>>
>>>>>      private Foo foo;
>>>>>
>>>>>      public void setFoo(Foo val){
>>>>>          foo = val;
>>>>>
>>>>>      }
>>>>>
>>>>>      private MyJaxBThing jaxBThing;
>>>>>
>>>>>      public void setMyJaxBThing(MyJaxBThing thing){
>>>>>          jaxBthing = thing;
>>>>>      }
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> And I want to use the following configuration:
>>>>>
>>>>>      <component name="myComp>
>>>>>          <implementation.java class="MyComponent/>
>>>>>          <properties>
>>>>>              <v:myFoo>
>>>>>                      <v:name>my name</v:name>
>>>>>                      <v:foo>
>>>>>                              <v:name>my sub name</v:name>
>>>>>                      </v:foo>
>>>>>                      <jaxb:jaxBThing>
>>>>>                              <!-- other configuration according
>>>>>
>>>>>
>>> to
>>>
>>>
>> JAX-B--->
>>
>>
>>>>>                      <jaxb:jaxBThing>
>>>>>              <v:myFoo>
>>>>>          </properties>
>>>>>      </component>
>>>>>
>>>>> I'm assuming I would have to register Foo and MyJaxBThing with  
>>>>> SDO?
>>>>> Could someone walk through the steps I would need to do to tell  
>>>>> the
>>>>> runtime how to take the particular configuration and  
>>>>> deserialize it?
>>>>>
>>>>>
>>
>>
>>
>>>> Assuming, however, that we don't have metadata, but just want to
>>>> deserialize by hand. I don't think the SDO approach is any  
>>>> easier or
>>>>
>>>>
>>> more
>>>
>>>
>>>> difficult than the StAX approach. By default the SDO  
>>>> deserializer will
>>>>
>>>>
>>
>>
>>
>>>> represent the "untyped" properties section of the model as a  
>>>> Sequence
>>>> (i.e., an unstructured representation of the "xsd:any" contents).
>>>>
>>>>
>> We'll
>>
>>
>>>> need some way to plug-in a converter, maybe something like a
>>>>
>>>>
>> FooFactory,
>>
>>
>>>
>>>
>>>
>>>> similar to what Jeremy described for the StAX approach. Btw, SDO  
>>>> has
>>>> createFromString methods for all the standard basic types plus a
>>>>
>>>>
>> generic
>>
>>
>>>
>>>
>>>
>>>> createFromString method that work like Jeremy described (i.e., try
>>>> valueOf, constructors, etc.).
>>>>
>>>>
>>>>
>>>>> Also, what would the string transformation methods look like in  
>>>>> this
>>>>>
>>>>>
>>
>>
>>
>>>>> case? I'm also having difficulty pinning down how the JAXB  
>>>>> class is
>>>>> instantiated (I'm assuming something needs to access a JAXB  
>>>>> factory
>>>>> at some point).
>>>>>
>>>>>
>>>> I don't know enough about JAXB to say. Maybe someone else knows?
>>>>
>>>>
>>>>
>>>>>
>>>>> Another really common use case (sorry to keep harping on this one,
>>>>> but I see it all of the time) is support for List and Map. I  
>>>>> should
>>>>> be able to specify some type of XML serialized form and have
>>>>>
>>>>>
>> property
>>
>>
>>>>> configuration injected on a component as a List or Map.  I'm
>>>>>
>>>>>
>> assuming
>>
>>
>>>>> based on your comments below this can be done to the SDO
>>>>> implementation and we could provide this to end-users without them
>>>>> having to configure something?
>>>>>
>>>>>
>>>> Yes ... the Sequence (DOM-like) view of the properties is there by
>>>> default.
>>>>
>>>>
>>>>
>>>>>
>>>>> One final scenario, related to this, is support for factories for
>>>>> property instantiation. IoC containers such as Spring have a  
>>>>> way to
>>>>> pass a factory in to the injection engine to delegate to for
>>>>>
>>>>>
>> creating
>>
>>
>>>>> property instances.  Could this be done with SDO?
>>>>>
>>>>>
>>>> I think we could provide something like this in Tuscany ... a
>>>> Tuscany-specific extension SPI.
>>>>
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> - 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 have two concrete examples here where I have seen problems in
>>>>>
>>>>>
>> other
>>
>>
>>>>> projects:
>>>>>
>>>>>
>>>>> 1. Assume there are two nested components whose implementation  
>>>>> types
>>>>>
>>>>>
>>
>>
>>
>>>>> are loaded by different classloaders. These two nested components
>>>>> have a property that takes a "Foo". The configuration schema is  
>>>>> the
>>>>> same but the "Foo" classes are different because they are  
>>>>> loaded by
>>>>> different classloaders. Do you think we will run into any issues
>>>>>
>>>>>
>> here?
>>
>>
>>>> Not unless the first Foo instance is passed to the second component
>>>> (that's expecting the second Foo). But this doesn't strike me as an
>>>>
>>>>
>> SDO
>>
>>
>>>> issue, it would be a problem even if the Foo class was hand coded,
>>>>
>>>>
>> don't
>>
>>
>>>
>>>
>>>
>>>> you think?
>>>>
>>>>
>>>>
>>>>>
>>>>> 2. Another concern is around application reloadability. If I  
>>>>> have a
>>>>> registered type of "Foo" and the application it was registered by
>>>>> needs to be reloaded, how is it flushed from SDO? Does the  
>>>>> container
>>>>>
>>>>>
>>
>>
>>
>>>>> have to call a flush method somewhere?
>>>>>
>>>>>
>>>> This depends on how we handle the scoping. If the TypeHelper that
>>>>
>>>>
>> knows
>>
>>
>>>> about Foo is in a private application scope then it should go away
>>>>
>>>>
>> with
>>
>>
>>>> the application.
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>
>>>>> I appreciate that and you taking the time to help explain this  
>>>>> stuff
>>>>>
>>>>>
>>
>>
>>
>>>>> to me. I guess I'm going to be a typical example of someone who
>>>>>
>>>>>
>> wants
>>
>>
>>>>> to extend the container and has a bunch of questions :-)
>>>>>
>>>>>
>>>> This is a good excersize for me as well. Regardless of the actual
>>>>
>>>>
>>> decision
>>>
>>>
>>>> of whether or not to use SDO for this particular purpose in SCA, it
>>>>
>>>>
>> will
>>
>>
>>>
>>>
>>>
>>>> help to clarify the issues and what parts of the SDO impl need
>>>>
>>>>
>>> attention.
>>>
>>>
>>>>
>>>> Thanks, Frank.
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 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 <ji...@gmail.com> 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 <ji...@gmail.com>
>>>>>>>> 03/23/2006 02:53 PM
>>>>>>>> Please respond to
>>>>>>>> tuscany-dev
>>>>>>>>
>>>>>>>>
>>>>>>>> To
>>>>>>>> tuscany-dev@ws.apache.org
>>>>>>>> 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"
>>>>>>>>>>> <fr...@ca.ibm.com>
>>>>>>>>>>> To: <tu...@ws.apache.org>
>>>>>>>>>>> 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" <an...@gmail.com> wrote on 03/23/2006
>>>>>>>>>>>> 10:13:24 AM:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>

Re: Assembly model changes

[Jim Marino <ji...@gmail.com>]

O.K. sorry if it gave you a conflict - let me know if you have an  
issue with the tests and I can try and help out if possible.

Jim

On Apr 12, 2006, at 8:25 AM, Jean-Sebastien Delfino wrote:

> Jim Marino wrote:
>
>> I just changed the event firing API. I don't think those will  
>> impact any of your stuff (I just checked them in). I think the  
>> refactorings around extension points may impact your stuff and  
>> vice versa.  Let's discuss tomorrow.
>>
>> Jim
>>
>>
>> On Apr 11, 2006, at 7:58 PM, Jean-Sebastien Delfino wrote:
>>
>>
>>> Jim Marino wrote:
>>>
>>>
>>>> I'm also in the process of making some changes to the eventing  
>>>> system (e.g. fireEvent) - Sebastien can we coordinate yours and  
>>>> mine?
>>>>
>>>>
>>>>
>>> Sure. Jim, can you tell us a little more about your changes, what  
>>> projects they impact? and when you're planning to check them in?  
>>> Then we can decide how best to proceed to minimize the merging  
>>> pain. Thanks.
>>>
>>> --Jean-Sebastien
>>>
>>>
>>>
>>
>>
>>
> Jim,
> I'm merging with your changes now, it doesn't look too bad there  
> are just a few conflicts. If all the tests pass after the merge  
> I'll check the changes in.
>
> -- 
> Jean-Sebastien
>
>

Re: Assembly model changes

[Jean-Sebastien Delfino <js...@apache.org>]

Jim Marino wrote:
> I just changed the event firing API. I don't think those will impact 
> any of your stuff (I just checked them in). I think the refactorings 
> around extension points may impact your stuff and vice versa.  Let's 
> discuss tomorrow.
>
> Jim
>
>
> On Apr 11, 2006, at 7:58 PM, Jean-Sebastien Delfino wrote:
>
>> Jim Marino wrote:
>>
>>> I'm also in the process of making some changes to the eventing 
>>> system (e.g. fireEvent) - Sebastien can we coordinate yours and mine?
>>>
>>>
>> Sure. Jim, can you tell us a little more about your changes, what 
>> projects they impact? and when you're planning to check them in? Then 
>> we can decide how best to proceed to minimize the merging pain. Thanks.
>>
>> --Jean-Sebastien
>>
>>
>
>
Jim,
I'm merging with your changes now, it doesn't look too bad there are 
just a few conflicts. If all the tests pass after the merge I'll check 
the changes in.

-- 
Jean-Sebastien

Re: Assembly model changes

[Jim Marino <jm...@myromatours.com>]

I just changed the event firing API. I don't think those will impact  
any of your stuff (I just checked them in). I think the refactorings  
around extension points may impact your stuff and vice versa.  Let's  
discuss tomorrow.

Jim


On Apr 11, 2006, at 7:58 PM, Jean-Sebastien Delfino wrote:

> Jim Marino wrote:
>
>> I'm also in the process of making some changes to the eventing  
>> system (e.g. fireEvent) - Sebastien can we coordinate yours and mine?
>>
>>
> Sure. Jim, can you tell us a little more about your changes, what  
> projects they impact? and when you're planning to check them in?  
> Then we can decide how best to proceed to minimize the merging  
> pain. Thanks.
>
> -- 
> Jean-Sebastien
>
>

Re: Assembly model changes

[Jean-Sebastien Delfino <js...@apache.org>]

Jim Marino wrote:
> I'm also in the process of making some changes to the eventing system 
> (e.g. fireEvent) - Sebastien can we coordinate yours and mine?
>
Sure. Jim, can you tell us a little more about your changes, what 
projects they impact? and when you're planning to check them in? Then we 
can decide how best to proceed to minimize the merging pain. Thanks.

-- 
Jean-Sebastien

Re: Assembly model changes

[Jim Marino <ji...@gmail.com>]

I'm also in the process of making some changes to the eventing system  
(e.g. fireEvent) - Sebastien can we coordinate yours and mine?


On Apr 11, 2006, at 12:52 PM, Jean-Sebastien Delfino wrote:

> Jeremy Boynes wrote:
>
>> A couple of questions inline
>>
>> Jean-Sebastien Delfino wrote:
>>
>>
>>> - A few renames, Aggregate to Composite, AggregatePart to Part,
>>> SimpleComponent to AtomicComponent, ComponentType to  
>>> ComponentInfo, more
>>> in line with the current spec discussions and Jim's latest  
>>> changes to
>>> the core runtime as well.
>>>
>>>
>>
>> Good stuff but ComponentInfo surprised me as I've not heard that -  
>> did
>> that come from Jim's changes?
>>
>>
> Ah for this one I guess I got confused between spec related  
> discussions, Jim's changes, and additional ideas I was playing  
> with. I was looking for a good name for the information describing  
> a component, and since we're always talking about how nice POJOs  
> and JavaBeans are these days, ComponentInfo sounded like BeanInfo  
> and seemed to get us closer to our ideal JavaBean based world :)  
> I'm happy to get back to ComponentType if people don't like  
> ComponentInfo.
>
>>
>>
>>> - Changed the handling of the maps of Components, EntryPoints,
>>> ExternalServices, ConfiguredReferences, etc.  now populated  
>>> immediately
>>> as you add objects to the model so that loaders can retrieve these
>>> objects by name.
>>>
>>>
>>
>> Do we still need list functionality or could we just use maps for  
>> these
>> things (with an add() helper method on the interface to simplify  
>> model
>> construction)?
>>
>>
>>
> I'd like to keep lists for now. Lists are easier to use than maps,  
> and this is how most models out there represent 0/1..n  
> relationships. I'll create a JIRA issue to evaluate what things  
> would look like if we changed to maps later maybe, but I don't  
> think we should do this now before our JavaOne release.
>
>>> - Simplified the logic in some of the initialize() and freeze()  
>>> methods.
>>>
>>> I am debating the usefulness of the freeze() methods, and would  
>>> like to
>>> get thoughts from the other people in the group. What do people  
>>> think
>>> about merging freeze and initialize()? or getting rid of this freeze
>>> capability altogether?
>>>
>>>
>>
>> initialize was there to support post-processing after load as the  
>> loader
>> could not add in extra stuff (e.g. by reading sidefiles). We can  
>> now do
>> that and have a couple of cases where we actually want the loader  
>> to do
>> extra work (e.g. importing WSDLs and SDO type definitions). I  
>> think we
>> may be able to remove initialize as well.
>>
>> We still have runtime code that can retieve model objects and  
>> freeze was
>> designed to prevent inadvertent changes to the model from messing up
>> that code. We have TODOs to get rid of this (e.g. removing
>> getAggregate()) so I would be OK removing freeze if we accelerate
>> removal of getAggregate() and similar model leaks.
>>
>>
>>
>>> I have not added Autowire to the model yet, I still need to get  
>>> my head
>>> around Autowire before I do that.
>>>
>>>
>>>
>>
>> I wouldn't rush on that just yet - I think we need to think a little
>> more about the mechanism for defining autowire constraints.
>>
>>
>>
> Agreed, I'm holding off on this for now.
>
>>> Next, I'm planning to add Java5 annotations to the model  
>>> interfaces to
>>> declare the mapping between the model classes and the  
>>> corresponding XSD
>>> artifacts from sca-core.xsd. I also have a little more cleanup to  
>>> do in
>>> some of the classes, but I think I've reached a stable enough  
>>> point now
>>> with the rest of the runtime working with this model.
>>>
>>> I had to catch up with changes in the main stream several times  
>>> while I
>>> was working in that branch and had a real hard time merging and
>>> resolving conflicts... so if there is no objection, I would like to
>>> merge this code back into the main code stream soon, tomorrow  
>>> ideally,
>>> before things get out of sync and I run into a nightmare of  
>>> conflicts
>>> again... Could people take a look and see if this updated model  
>>> looks
>>> reasonable before I do that? Thanks.
>>>
>>>
>>>
>> that's why
>> +1 for merging
>>
>>
>>
> Ok, thanks for reviewing, I'll wait until tomorrow to give others  
> an opportunity to take a look before I do the merge.
>
>
>> I did notice that many of the changes were just renames. These are
>> fairly simple changes which impact a lot of files and are prime
>> candidates for causing conflicts. However, the change itself it very
>> easy to review/test as it's just a rename. Perhaps some of the  
>> conflicts
>> could have been avoided if each one of these was done separately  
>> (little
>> and often).
>>   --
>> Jeremy
>>
>>
>>
> -- 
> Jean-Sebastien
>
>

Re: Assembly model changes

[Jean-Sebastien Delfino <js...@apache.org>]

Jeremy Boynes wrote:
> A couple of questions inline
>
> Jean-Sebastien Delfino wrote:
>   
>> - A few renames, Aggregate to Composite, AggregatePart to Part,
>> SimpleComponent to AtomicComponent, ComponentType to ComponentInfo, more
>> in line with the current spec discussions and Jim's latest changes to
>> the core runtime as well.
>>     
>
> Good stuff but ComponentInfo surprised me as I've not heard that - did
> that come from Jim's changes?
>   
Ah for this one I guess I got confused between spec related discussions, 
Jim's changes, and additional ideas I was playing with. I was looking 
for a good name for the information describing a component, and since 
we're always talking about how nice POJOs and JavaBeans are these days, 
ComponentInfo sounded like BeanInfo and seemed to get us closer to our 
ideal JavaBean based world :) I'm happy to get back to ComponentType if 
people don't like ComponentInfo.
>   
>> - Changed the handling of the maps of Components, EntryPoints,
>> ExternalServices, ConfiguredReferences, etc.  now populated immediately
>> as you add objects to the model so that loaders can retrieve these
>> objects by name.
>>     
>
> Do we still need list functionality or could we just use maps for these
> things (with an add() helper method on the interface to simplify model
> construction)?
>
>   
I'd like to keep lists for now. Lists are easier to use than maps, and 
this is how most models out there represent 0/1..n relationships. I'll 
create a JIRA issue to evaluate what things would look like if we 
changed to maps later maybe, but I don't think we should do this now 
before our JavaOne release.
>> - Simplified the logic in some of the initialize() and freeze() methods.
>>
>> I am debating the usefulness of the freeze() methods, and would like to
>> get thoughts from the other people in the group. What do people think
>> about merging freeze and initialize()? or getting rid of this freeze
>> capability altogether?
>>     
>
> initialize was there to support post-processing after load as the loader
> could not add in extra stuff (e.g. by reading sidefiles). We can now do
> that and have a couple of cases where we actually want the loader to do
> extra work (e.g. importing WSDLs and SDO type definitions). I think we
> may be able to remove initialize as well.
>
> We still have runtime code that can retieve model objects and freeze was
> designed to prevent inadvertent changes to the model from messing up
> that code. We have TODOs to get rid of this (e.g. removing
> getAggregate()) so I would be OK removing freeze if we accelerate
> removal of getAggregate() and similar model leaks.
>
>   
>> I have not added Autowire to the model yet, I still need to get my head
>> around Autowire before I do that.
>>
>>     
>
> I wouldn't rush on that just yet - I think we need to think a little
> more about the mechanism for defining autowire constraints.
>
>   
Agreed, I'm holding off on this for now.
>> Next, I'm planning to add Java5 annotations to the model interfaces to
>> declare the mapping between the model classes and the corresponding XSD
>> artifacts from sca-core.xsd. I also have a little more cleanup to do in
>> some of the classes, but I think I've reached a stable enough point now
>> with the rest of the runtime working with this model.
>>
>> I had to catch up with changes in the main stream several times while I
>> was working in that branch and had a real hard time merging and
>> resolving conflicts... so if there is no objection, I would like to
>> merge this code back into the main code stream soon, tomorrow ideally,
>> before things get out of sync and I run into a nightmare of conflicts
>> again... Could people take a look and see if this updated model looks
>> reasonable before I do that? Thanks.
>>
>>     
> that's why
> +1 for merging
>
>   
Ok, thanks for reviewing, I'll wait until tomorrow to give others an 
opportunity to take a look before I do the merge.

> I did notice that many of the changes were just renames. These are
> fairly simple changes which impact a lot of files and are prime
> candidates for causing conflicts. However, the change itself it very
> easy to review/test as it's just a rename. Perhaps some of the conflicts
> could have been avoided if each one of these was done separately (little
> and often).
>   
> --
> Jeremy
>
>   
-- 
Jean-Sebastien

Re: Assembly model changes, was: Framework for StAX-based model loading

[Jeremy Boynes <jb...@apache.org>]

A couple of questions inline

Jean-Sebastien Delfino wrote:
> - A few renames, Aggregate to Composite, AggregatePart to Part,
> SimpleComponent to AtomicComponent, ComponentType to ComponentInfo, more
> in line with the current spec discussions and Jim's latest changes to
> the core runtime as well.

Good stuff but ComponentInfo surprised me as I've not heard that - did
that come from Jim's changes?

> - Changed the handling of the maps of Components, EntryPoints,
> ExternalServices, ConfiguredReferences, etc.  now populated immediately
> as you add objects to the model so that loaders can retrieve these
> objects by name.

Do we still need list functionality or could we just use maps for these
things (with an add() helper method on the interface to simplify model
construction)?

> - Simplified the logic in some of the initialize() and freeze() methods.
> 
> I am debating the usefulness of the freeze() methods, and would like to
> get thoughts from the other people in the group. What do people think
> about merging freeze and initialize()? or getting rid of this freeze
> capability altogether?

initialize was there to support post-processing after load as the loader
could not add in extra stuff (e.g. by reading sidefiles). We can now do
that and have a couple of cases where we actually want the loader to do
extra work (e.g. importing WSDLs and SDO type definitions). I think we
may be able to remove initialize as well.

We still have runtime code that can retieve model objects and freeze was
designed to prevent inadvertent changes to the model from messing up
that code. We have TODOs to get rid of this (e.g. removing
getAggregate()) so I would be OK removing freeze if we accelerate
removal of getAggregate() and similar model leaks.

> I have not added Autowire to the model yet, I still need to get my head
> around Autowire before I do that.
> 

I wouldn't rush on that just yet - I think we need to think a little
more about the mechanism for defining autowire constraints.

> Next, I'm planning to add Java5 annotations to the model interfaces to
> declare the mapping between the model classes and the corresponding XSD
> artifacts from sca-core.xsd. I also have a little more cleanup to do in
> some of the classes, but I think I've reached a stable enough point now
> with the rest of the runtime working with this model.
> 
> I had to catch up with changes in the main stream several times while I
> was working in that branch and had a real hard time merging and
> resolving conflicts... so if there is no objection, I would like to
> merge this code back into the main code stream soon, tomorrow ideally,
> before things get out of sync and I run into a nightmare of conflicts
> again... Could people take a look and see if this updated model looks
> reasonable before I do that? Thanks.
> 

+1 for merging

I did notice that many of the changes were just renames. These are
fairly simple changes which impact a lot of files and are prime
candidates for causing conflicts. However, the change itself it very
easy to review/test as it's just a rename. Perhaps some of the conflicts
could have been avoided if each one of these was done separately (little
and often).

--
Jeremy

Assembly model changes, was: Framework for StAX-based model loading

[Jean-Sebastien Delfino <js...@apache.org>]

I checked in a first cut of some of the model changes discussed in this 
thread in our sandbox under 
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca 
(this is an SVN copy of the whole sca tree, including the changes to the 
model and the corresponding changes in the rest of the runtime). Here's 
a summary of the changes:

- Cleanup of the code to facilitate code generation, eventually.
- A few renames, Aggregate to Composite, AggregatePart to Part, 
SimpleComponent to AtomicComponent, ComponentType to ComponentInfo, more 
in line with the current spec discussions and Jim's latest changes to 
the core runtime as well.
- Changed the handling of the maps of Components, EntryPoints, 
ExternalServices, ConfiguredReferences, etc.  now populated immediately 
as you add objects to the model so that loaders can retrieve these 
objects by name.
- Adjusted some of the model classes to have both attributes from the 
physical model and attributes/relationships from the the logical model.
- Moved the contextFactory field from ConfiguredReference and 
ConfiguredService to Component, EntryPoint, ExternalService (which are 
the actual objects managed by the Contexts).
- Simplified the logic in some of the initialize() and freeze() methods.

I am debating the usefulness of the freeze() methods, and would like to 
get thoughts from the other people in the group. What do people think 
about merging freeze and initialize()? or getting rid of this freeze 
capability altogether?
I have not added Autowire to the model yet, I still need to get my head 
around Autowire before I do that.

Next, I'm planning to add Java5 annotations to the model interfaces to 
declare the mapping between the model classes and the corresponding XSD 
artifacts from sca-core.xsd. I also have a little more cleanup to do in 
some of the classes, but I think I've reached a stable enough point now 
with the rest of the runtime working with this model.

I had to catch up with changes in the main stream several times while I 
was working in that branch and had a real hard time merging and 
resolving conflicts... so if there is no objection, I would like to 
merge this code back into the main code stream soon, tomorrow ideally, 
before things get out of sync and I run into a nightmare of conflicts 
again... Could people take a look and see if this updated model looks 
reasonable before I do that? Thanks.

-- 
Jean-Sebastien

Re: Framework for StAX-based model loading

[Jim Marino <jm...@myromatours.com>]

+1 too
On Apr 5, 2006, at 11:17 AM, Jean-Sebastien Delfino wrote:

> Jeremy Boynes wrote:
>
>> Jim Marino wrote:
>>
>>
>>> On Apr 5, 2006, at 10:56 AM, Jean-Sebastien Delfino wrote:
>>>
>>>
>>>
>>>> Jim Marino wrote:
>>>>
>>>>
>>>>
>>>>> I think this this is a really good approach and will give us a   
>>>>> great
>>>>> binding/extension story for Tuscany. Two comments on the   
>>>>> statement
>>>>> that the model may look a little different than what we  have  
>>>>> here.
>>>>> The first one is that in general, I'm o.k. with that as  long  
>>>>> as it
>>>>> follows common Java idioms. I don't think this will be  a  
>>>>> problem. The second is I'm happy to help out porting the   
>>>>> runtime core to use
>>>>> the new model so just let me know when we have  a cut of the  
>>>>> new model.
>>>>>
>>>>> Jim
>>>>>
>>>>>
>>>>>
>>>>>
>>>> I like this approach too. I think that this compromise  
>>>> addresses  the
>>>> requirements that we discussed before, a simple handwritten  POJO
>>>> model, easy to extend, integration with StAX, and ability to   
>>>> generate
>>>> loaders at some point for people who would like to extend  Tuscany
>>>> without writing XML parsing code. I'm also very happy to  see the
>>>> introduction of new options to generate simpler SDOs and   
>>>> support SDOs
>>>> defined by Java interfaces in addition to XSD (which  is a very
>>>> important scenario that came up several times on this  list). With
>>>> some minor hacks to the SDO code generator, I was able  to generate
>>>> this morning the pure JavaBean model that Frank  describes in  
>>>> step (a)
>>>> and I'm now starting to look at step (b). I  should have a first  
>>>> cut
>>>> of the new model in about two days. It will  be very similar to the
>>>> current logical model, but I'm thinking  about checking it in the
>>>> sandbox first so that people can take a  look and help shape it  
>>>> - and
>>>> make sure it follows common Java  idioms :) before we port the  
>>>> runtime
>>>> core to it. Does that make sense?
>>>>
>>>>
>>> Works for me. Once we take a look at it, I'm happy to help out   
>>> porting
>>> the core over. Hopefully the changes won't be that  significant  
>>> and we
>>> can port it without breaking the build.
>>>
>>>
>>>
>>
>> In preparation for this, how about I switch over to the StAX  
>> loader with
>> the current model and check that everything is still working. We can
>> then remove the old physical model, transformers and SCDLModelLoader
>> registry in preparation for the new one?
>>
>> --
>> Jeremy
>>
>>
>>
> +1 from me. Good idea.
>
> -- 
> Jean-Sebastien
>
>

Re: Framework for StAX-based model loading

[Jean-Sebastien Delfino <js...@apache.org>]

Jeremy Boynes wrote:
> Jim Marino wrote:
>   
>> On Apr 5, 2006, at 10:56 AM, Jean-Sebastien Delfino wrote:
>>
>>     
>>> Jim Marino wrote:
>>>
>>>       
>>>> I think this this is a really good approach and will give us a  great
>>>> binding/extension story for Tuscany. Two comments on the  statement
>>>> that the model may look a little different than what we  have here.
>>>> The first one is that in general, I'm o.k. with that as  long as it
>>>> follows common Java idioms. I don't think this will be  a problem. 
>>>> The second is I'm happy to help out porting the  runtime core to use
>>>> the new model so just let me know when we have  a cut of the new model.
>>>>
>>>> Jim
>>>>
>>>>
>>>>         
>>> I like this approach too. I think that this compromise addresses  the
>>> requirements that we discussed before, a simple handwritten  POJO
>>> model, easy to extend, integration with StAX, and ability to  generate
>>> loaders at some point for people who would like to extend  Tuscany
>>> without writing XML parsing code. I'm also very happy to  see the
>>> introduction of new options to generate simpler SDOs and  support SDOs
>>> defined by Java interfaces in addition to XSD (which  is a very
>>> important scenario that came up several times on this  list). With
>>> some minor hacks to the SDO code generator, I was able  to generate
>>> this morning the pure JavaBean model that Frank  describes in step (a)
>>> and I'm now starting to look at step (b). I  should have a first cut
>>> of the new model in about two days. It will  be very similar to the
>>> current logical model, but I'm thinking  about checking it in the
>>> sandbox first so that people can take a  look and help shape it - and
>>> make sure it follows common Java  idioms :) before we port the runtime
>>> core to it. Does that make sense?
>>>       
>> Works for me. Once we take a look at it, I'm happy to help out  porting
>> the core over. Hopefully the changes won't be that  significant and we
>> can port it without breaking the build.
>>
>>     
>
> In preparation for this, how about I switch over to the StAX loader with
> the current model and check that everything is still working. We can
> then remove the old physical model, transformers and SCDLModelLoader
> registry in preparation for the new one?
>
> --
> Jeremy
>
>   
+1 from me. Good idea.

-- 
Jean-Sebastien

Re: Framework for StAX-based model loading

[Jeremy Boynes <jb...@apache.org>]

Jim Marino wrote:
> 
> On Apr 5, 2006, at 10:56 AM, Jean-Sebastien Delfino wrote:
> 
>> Jim Marino wrote:
>>
>>> I think this this is a really good approach and will give us a  great
>>> binding/extension story for Tuscany. Two comments on the  statement
>>> that the model may look a little different than what we  have here.
>>> The first one is that in general, I'm o.k. with that as  long as it
>>> follows common Java idioms. I don't think this will be  a problem. 
>>> The second is I'm happy to help out porting the  runtime core to use
>>> the new model so just let me know when we have  a cut of the new model.
>>>
>>> Jim
>>>
>>>
>> I like this approach too. I think that this compromise addresses  the
>> requirements that we discussed before, a simple handwritten  POJO
>> model, easy to extend, integration with StAX, and ability to  generate
>> loaders at some point for people who would like to extend  Tuscany
>> without writing XML parsing code. I'm also very happy to  see the
>> introduction of new options to generate simpler SDOs and  support SDOs
>> defined by Java interfaces in addition to XSD (which  is a very
>> important scenario that came up several times on this  list). With
>> some minor hacks to the SDO code generator, I was able  to generate
>> this morning the pure JavaBean model that Frank  describes in step (a)
>> and I'm now starting to look at step (b). I  should have a first cut
>> of the new model in about two days. It will  be very similar to the
>> current logical model, but I'm thinking  about checking it in the
>> sandbox first so that people can take a  look and help shape it - and
>> make sure it follows common Java  idioms :) before we port the runtime
>> core to it. Does that make sense?
> 
> 
> Works for me. Once we take a look at it, I'm happy to help out  porting
> the core over. Hopefully the changes won't be that  significant and we
> can port it without breaking the build.
> 

In preparation for this, how about I switch over to the StAX loader with
the current model and check that everything is still working. We can
then remove the old physical model, transformers and SCDLModelLoader
registry in preparation for the new one?

--
Jeremy

Re: Framework for StAX-based model loading

[Jim Marino <jm...@bea.com>]

On Apr 5, 2006, at 10:56 AM, Jean-Sebastien Delfino wrote:

> Jim Marino wrote:
>
>> I think this this is a really good approach and will give us a  
>> great binding/extension story for Tuscany. Two comments on the  
>> statement that the model may look a little different than what we  
>> have here. The first one is that in general, I'm o.k. with that as  
>> long as it follows common Java idioms. I don't think this will be  
>> a problem.  The second is I'm happy to help out porting the  
>> runtime core to use the new model so just let me know when we have  
>> a cut of the new model.
>>
>> Jim
>>
>>
> I like this approach too. I think that this compromise addresses  
> the requirements that we discussed before, a simple handwritten  
> POJO model, easy to extend, integration with StAX, and ability to  
> generate loaders at some point for people who would like to extend  
> Tuscany without writing XML parsing code. I'm also very happy to  
> see the introduction of new options to generate simpler SDOs and  
> support SDOs defined by Java interfaces in addition to XSD (which  
> is a very important scenario that came up several times on this  
> list). With some minor hacks to the SDO code generator, I was able  
> to generate this morning the pure JavaBean model that Frank  
> describes in step (a) and I'm now starting to look at step (b). I  
> should have a first cut of the new model in about two days. It will  
> be very similar to the current logical model, but I'm thinking  
> about checking it in the sandbox first so that people can take a  
> look and help shape it - and make sure it follows common Java  
> idioms :) before we port the runtime core to it. Does that make sense?

Works for me. Once we take a look at it, I'm happy to help out  
porting the core over. Hopefully the changes won't be that  
significant and we can port it without breaking the build.

Jim


>
>
>> On Apr 4, 2006, at 3:16 PM, Frank Budinsky wrote:
>>
>>
>>> Resending my previous post ... I see that the formatting I wrote  
>>> it with
>>> went away and it became impossible to read. Congratulations to  
>>> anyone that
>>> got anything out of it at all :-)
>>>
>>> Sorry about that,
>>> Frank.
>>>
>>>
>>> Here is a proposal for moving forward on this issue that I think (am
>>> hoping :-) everyone can live with.
>>>
>>> 1. Remove the existing logical and physical models (and  
>>> corresponding
>>>    transformer code) and replace them with a single logical model
>>>    created as follows:
>>>   a. One-time generate a pure JavaBean model from the XMLSchema
>>>      (sca-core.xsd) using a hacked up prototype of the SDO  
>>> generator.
>>>      This prototype suppresses SDO things (e.g., reflective methods,
>>>      for example), so the generated classes are not SDOs - they're
>>>      POJOs.
>>>   b. Hand modify the generated classes to add additional methods  
>>> needed
>>>      for the logical model. The end result, will look very  
>>> similar, but
>>>      not identical, to the current logical model, so a small  
>>> amount of
>>>      work will be needed to port client code from the current  
>>> logical
>>>      model to this new combined "logical/physical" model.
>>>
>>> 2. Modify Jeremy's StAX handlers to work with this new model, and  
>>> also
>>>    use them as the prototypical example of the output for a new
>>>    -generateLoader option for the SDO generator. The plan for the  
>>> May
>>>    release will be to use the modified hand written StAX  
>>> handlers, but
>>>    they will be marked as "to be generated", so that it's clear  
>>> that in
>>>    the future these handlers will be replaced with generated ones.
>>>
>>> 3. Start immediately on the SDO -generateLoader and -simpleBeans  
>>> options.
>>>    We will use -generateLoader for the core model, as soon as it's
>>>    available (target 2-3 months?), but we will not plan to regen  
>>> the core
>>>    model using -simpleBeans. The model will remain hand coded
>>>    indefinitely, but we can revisit the possibility of generating  
>>> parts
>>>    of it in the future (but this won't be a priority). The - 
>>> simpleBeans
>>>    option will be available for use by people adding extensions  
>>> to the
>>>    model, if they want to start with XSDs.
>>>
>>> 4. Also start immediately on a -generateSerializer option so that  
>>> we will
>>>    be able to use simple beans that need to be saved as well as  
>>> loaded.
>>>    Given that we support generation of POJOs, we need both generated
>>>    loaders and serializers to use them. We also need to start  
>>> work on
>>>    defining the necessary Java annotations to support generating
>>>    loaders/serializers from hand-written POJOs (or more generally  
>>> to also
>>>    generate SDOs from hand written Java interfaces.
>>>
>>> I think this approach is a win-win for both the SCA and SDO  
>>> projects.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Frank.
>>>
>>>
>>>
>>>> Frank Budinsky/Toronto/IBM@IBMCA wrote on 03/27/2006 01:26:46 PM:
>>>>
>>>>
>>>>
>>>>> Jim Marino <ji...@gmail.com> wrote on 03/24/2006 05:53:46 PM:
>>>>>
>>>>>
>>>>>
>>>>>> Thanks Frank for answering these questions.  I have a few more  
>>>>>> that
>>>>>> maybe you or others could offer opinions on.
>>>>>>
>>>>>> On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>> I think option two is the more appealing one for applications
>>>>>> developers. I read option 1 to require a schema, which we may be
>>>>>>
>>>>>>
>>> able
>>>
>>>
>>>>>> to do for extensions, but is a bit much to ask application
>>>>>>
>>>>>>
>>> developers
>>>
>>>
>>>>>> to produce.  So, I'm curious as to how the conversion methods you
>>>>>> mentioned look like.  Assume I have the following Java
>>>>>>
>>>>>>
>>> implementation
>>>
>>>
>>>>>> and configuration class:
>>>>>>
>>>>>>
>>>>> I wouldn't write off option 1 so quickly. For your example, a  
>>>>> schema
>>>>>
>>>>>
>>> (or
>>>
>>>
>>>>
>>>>
>>>>
>>>>> equivalent SDO metadata) something like this is all that one  
>>>>> needs:
>>>>>
>>>>> <element name="myFoo" type="Foo"/>
>>>>>
>>>>> <complexType name="Foo">
>>>>>     <sequence>
>>>>>         <element name="name" type="xsd:int"/>
>>>>>         <element name="foo" type="Foo"/>
>>>>>         <element name="myJaxBThing" type="jaxb:jaxBThing"/>
>>>>>     </sequence>
>>>>> </complexType>
>>>>>
>>>>> This schema could be deduced (under the covers) from the Java  
>>>>> classes
>>>>>
>>>>>
>>>> you
>>>>
>>>>
>>>>> show below, so you wouldn't need to actually write it (once we  
>>>>> get the
>>>>>
>>>>>
>>>
>>>
>>>
>>>>> Java import support working, of course).
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> public class MyComponent{
>>>>>>
>>>>>>      @Property
>>>>>>      private Foo; myFoo;
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> public class Foo{
>>>>>>
>>>>>>      public Foo(){}
>>>>>>
>>>>>>      private String name;
>>>>>>
>>>>>>      public setName(String val){
>>>>>>          name = val;
>>>>>>      }
>>>>>>
>>>>>>      private Foo foo;
>>>>>>
>>>>>>      public void setFoo(Foo val){
>>>>>>          foo = val;
>>>>>>
>>>>>>      }
>>>>>>
>>>>>>      private MyJaxBThing jaxBThing;
>>>>>>
>>>>>>      public void setMyJaxBThing(MyJaxBThing thing){
>>>>>>          jaxBthing = thing;
>>>>>>      }
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>> And I want to use the following configuration:
>>>>>>
>>>>>>      <component name="myComp>
>>>>>>          <implementation.java class="MyComponent/>
>>>>>>          <properties>
>>>>>>              <v:myFoo>
>>>>>>                      <v:name>my name</v:name>
>>>>>>                      <v:foo>
>>>>>>                              <v:name>my sub name</v:name>
>>>>>>                      </v:foo>
>>>>>>                      <jaxb:jaxBThing>
>>>>>>                              <!-- other configuration according
>>>>>>
>>>>>>
>>>> to
>>>>
>>>>
>>> JAX-B--->
>>>
>>>
>>>>>>                      <jaxb:jaxBThing>
>>>>>>              <v:myFoo>
>>>>>>          </properties>
>>>>>>      </component>
>>>>>>
>>>>>> I'm assuming I would have to register Foo and MyJaxBThing with  
>>>>>> SDO?
>>>>>> Could someone walk through the steps I would need to do to  
>>>>>> tell the
>>>>>> runtime how to take the particular configuration and  
>>>>>> deserialize it?
>>>>>>
>>>>>>
>>>
>>>
>>>
>>>>> Assuming, however, that we don't have metadata, but just want to
>>>>> deserialize by hand. I don't think the SDO approach is any  
>>>>> easier or
>>>>>
>>>>>
>>>> more
>>>>
>>>>
>>>>> difficult than the StAX approach. By default the SDO  
>>>>> deserializer will
>>>>>
>>>>>
>>>
>>>
>>>
>>>>> represent the "untyped" properties section of the model as a  
>>>>> Sequence
>>>>> (i.e., an unstructured representation of the "xsd:any" contents).
>>>>>
>>>>>
>>> We'll
>>>
>>>
>>>>> need some way to plug-in a converter, maybe something like a
>>>>>
>>>>>
>>> FooFactory,
>>>
>>>
>>>>
>>>>
>>>>
>>>>> similar to what Jeremy described for the StAX approach. Btw,  
>>>>> SDO has
>>>>> createFromString methods for all the standard basic types plus a
>>>>>
>>>>>
>>> generic
>>>
>>>
>>>>
>>>>
>>>>
>>>>> createFromString method that work like Jeremy described (i.e., try
>>>>> valueOf, constructors, etc.).
>>>>>
>>>>>
>>>>>
>>>>>> Also, what would the string transformation methods look like  
>>>>>> in this
>>>>>>
>>>>>>
>>>
>>>
>>>
>>>>>> case? I'm also having difficulty pinning down how the JAXB  
>>>>>> class is
>>>>>> instantiated (I'm assuming something needs to access a JAXB  
>>>>>> factory
>>>>>> at some point).
>>>>>>
>>>>>>
>>>>> I don't know enough about JAXB to say. Maybe someone else knows?
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Another really common use case (sorry to keep harping on this  
>>>>>> one,
>>>>>> but I see it all of the time) is support for List and Map. I  
>>>>>> should
>>>>>> be able to specify some type of XML serialized form and have
>>>>>>
>>>>>>
>>> property
>>>
>>>
>>>>>> configuration injected on a component as a List or Map.  I'm
>>>>>>
>>>>>>
>>> assuming
>>>
>>>
>>>>>> based on your comments below this can be done to the SDO
>>>>>> implementation and we could provide this to end-users without  
>>>>>> them
>>>>>> having to configure something?
>>>>>>
>>>>>>
>>>>> Yes ... the Sequence (DOM-like) view of the properties is there by
>>>>> default.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> One final scenario, related to this, is support for factories for
>>>>>> property instantiation. IoC containers such as Spring have a  
>>>>>> way to
>>>>>> pass a factory in to the injection engine to delegate to for
>>>>>>
>>>>>>
>>> creating
>>>
>>>
>>>>>> property instances.  Could this be done with SDO?
>>>>>>
>>>>>>
>>>>> I think we could provide something like this in Tuscany ... a
>>>>> Tuscany-specific extension SPI.
>>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> - 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 have two concrete examples here where I have seen problems in
>>>>>>
>>>>>>
>>> other
>>>
>>>
>>>>>> projects:
>>>>>>
>>>>>>
>>>>>> 1. Assume there are two nested components whose implementation  
>>>>>> types
>>>>>>
>>>>>>
>>>
>>>
>>>
>>>>>> are loaded by different classloaders. These two nested components
>>>>>> have a property that takes a "Foo". The configuration schema  
>>>>>> is the
>>>>>> same but the "Foo" classes are different because they are  
>>>>>> loaded by
>>>>>> different classloaders. Do you think we will run into any issues
>>>>>>
>>>>>>
>>> here?
>>>
>>>
>>>>> Not unless the first Foo instance is passed to the second  
>>>>> component
>>>>> (that's expecting the second Foo). But this doesn't strike me  
>>>>> as an
>>>>>
>>>>>
>>> SDO
>>>
>>>
>>>>> issue, it would be a problem even if the Foo class was hand coded,
>>>>>
>>>>>
>>> don't
>>>
>>>
>>>>
>>>>
>>>>
>>>>> you think?
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> 2. Another concern is around application reloadability. If I  
>>>>>> have a
>>>>>> registered type of "Foo" and the application it was registered by
>>>>>> needs to be reloaded, how is it flushed from SDO? Does the  
>>>>>> container
>>>>>>
>>>>>>
>>>
>>>
>>>
>>>>>> have to call a flush method somewhere?
>>>>>>
>>>>>>
>>>>> This depends on how we handle the scoping. If the TypeHelper that
>>>>>
>>>>>
>>> knows
>>>
>>>
>>>>> about Foo is in a private application scope then it should go away
>>>>>
>>>>>
>>> with
>>>
>>>
>>>>> the application.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I appreciate that and you taking the time to help explain this  
>>>>>> stuff
>>>>>>
>>>>>>
>>>
>>>
>>>
>>>>>> to me. I guess I'm going to be a typical example of someone who
>>>>>>
>>>>>>
>>> wants
>>>
>>>
>>>>>> to extend the container and has a bunch of questions :-)
>>>>>>
>>>>>>
>>>>> This is a good excersize for me as well. Regardless of the actual
>>>>>
>>>>>
>>>> decision
>>>>
>>>>
>>>>> of whether or not to use SDO for this particular purpose in  
>>>>> SCA, it
>>>>>
>>>>>
>>> will
>>>
>>>
>>>>
>>>>
>>>>
>>>>> help to clarify the issues and what parts of the SDO impl need
>>>>>
>>>>>
>>>> attention.
>>>>
>>>>
>>>>>
>>>>> Thanks, Frank.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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 <ji...@gmail.com> 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 <ji...@gmail.com>
>>>>>>>>> 03/23/2006 02:53 PM
>>>>>>>>> Please respond to
>>>>>>>>> tuscany-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> To
>>>>>>>>> tuscany-dev@ws.apache.org
>>>>>>>>> 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"
>>>>>>>>>>>> <fr...@ca.ibm.com>
>>>>>>>>>>>> To: <tu...@ws.apache.org>
>>>>>>>>>>>> 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" <an...@gmail.com> wrote on 03/23/2006
>>>>>>>>>>>>> 10:13:24 AM:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
> -- 
> Jean-Sebastien
>
>

Re: Framework for StAX-based model loading

[Jean-Sebastien Delfino <js...@apache.org>]

Jim Marino wrote:
> I think this this is a really good approach and will give us a great 
> binding/extension story for Tuscany. Two comments on the statement 
> that the model may look a little different than what we have here. The 
> first one is that in general, I'm o.k. with that as long as it follows 
> common Java idioms. I don't think this will be a problem.  The second 
> is I'm happy to help out porting the runtime core to use the new model 
> so just let me know when we have a cut of the new model.
>
> Jim
>
I like this approach too. I think that this compromise addresses the 
requirements that we discussed before, a simple handwritten POJO model, 
easy to extend, integration with StAX, and ability to generate loaders 
at some point for people who would like to extend Tuscany without 
writing XML parsing code. I'm also very happy to see the introduction of 
new options to generate simpler SDOs and support SDOs defined by Java 
interfaces in addition to XSD (which is a very important scenario that 
came up several times on this list). With some minor hacks to the SDO 
code generator, I was able to generate this morning the pure JavaBean 
model that Frank describes in step (a) and I'm now starting to look at 
step (b). I should have a first cut of the new model in about two days. 
It will be very similar to the current logical model, but I'm thinking 
about checking it in the sandbox first so that people can take a look 
and help shape it - and make sure it follows common Java idioms :) 
before we port the runtime core to it. Does that make sense?

> On Apr 4, 2006, at 3:16 PM, Frank Budinsky wrote:
>
>> Resending my previous post ... I see that the formatting I wrote it with
>> went away and it became impossible to read. Congratulations to anyone 
>> that
>> got anything out of it at all :-)
>>
>> Sorry about that,
>> Frank.
>>
>>
>> Here is a proposal for moving forward on this issue that I think (am
>> hoping :-) everyone can live with.
>>
>> 1. Remove the existing logical and physical models (and corresponding
>>    transformer code) and replace them with a single logical model
>>    created as follows:
>>   a. One-time generate a pure JavaBean model from the XMLSchema
>>      (sca-core.xsd) using a hacked up prototype of the SDO generator.
>>      This prototype suppresses SDO things (e.g., reflective methods,
>>      for example), so the generated classes are not SDOs - they're
>>      POJOs.
>>   b. Hand modify the generated classes to add additional methods needed
>>      for the logical model. The end result, will look very similar, but
>>      not identical, to the current logical model, so a small amount of
>>      work will be needed to port client code from the current logical
>>      model to this new combined "logical/physical" model.
>>
>> 2. Modify Jeremy's StAX handlers to work with this new model, and also
>>    use them as the prototypical example of the output for a new
>>    -generateLoader option for the SDO generator. The plan for the May
>>    release will be to use the modified hand written StAX handlers, but
>>    they will be marked as "to be generated", so that it's clear that in
>>    the future these handlers will be replaced with generated ones.
>>
>> 3. Start immediately on the SDO -generateLoader and -simpleBeans 
>> options.
>>    We will use -generateLoader for the core model, as soon as it's
>>    available (target 2-3 months?), but we will not plan to regen the 
>> core
>>    model using -simpleBeans. The model will remain hand coded
>>    indefinitely, but we can revisit the possibility of generating parts
>>    of it in the future (but this won't be a priority). The -simpleBeans
>>    option will be available for use by people adding extensions to the
>>    model, if they want to start with XSDs.
>>
>> 4. Also start immediately on a -generateSerializer option so that we 
>> will
>>    be able to use simple beans that need to be saved as well as loaded.
>>    Given that we support generation of POJOs, we need both generated
>>    loaders and serializers to use them. We also need to start work on
>>    defining the necessary Java annotations to support generating
>>    loaders/serializers from hand-written POJOs (or more generally to 
>> also
>>    generate SDOs from hand written Java interfaces.
>>
>> I think this approach is a win-win for both the SCA and SDO projects.
>>
>> Thoughts?
>>
>> Thanks,
>> Frank.
>>
>>
>>> Frank Budinsky/Toronto/IBM@IBMCA wrote on 03/27/2006 01:26:46 PM:
>>>
>>>
>>>> Jim Marino <ji...@gmail.com> wrote on 03/24/2006 05:53:46 PM:
>>>>
>>>>
>>>>> Thanks Frank for answering these questions.  I have a few more that
>>>>> maybe you or others could offer opinions on.
>>>>>
>>>>> On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>> I think option two is the more appealing one for applications
>>>>> developers. I read option 1 to require a schema, which we may be
>>>>>
>> able
>>
>>>>> to do for extensions, but is a bit much to ask application
>>>>>
>> developers
>>
>>>>> to produce.  So, I'm curious as to how the conversion methods you
>>>>> mentioned look like.  Assume I have the following Java
>>>>>
>> implementation
>>
>>>>> and configuration class:
>>>>>
>>>> I wouldn't write off option 1 so quickly. For your example, a schema
>>>>
>> (or
>>
>>>
>>>
>>>> equivalent SDO metadata) something like this is all that one needs:
>>>>
>>>> <element name="myFoo" type="Foo"/>
>>>>
>>>> <complexType name="Foo">
>>>>     <sequence>
>>>>         <element name="name" type="xsd:int"/>
>>>>         <element name="foo" type="Foo"/>
>>>>         <element name="myJaxBThing" type="jaxb:jaxBThing"/>
>>>>     </sequence>
>>>> </complexType>
>>>>
>>>> This schema could be deduced (under the covers) from the Java classes
>>>>
>>> you
>>>
>>>> show below, so you wouldn't need to actually write it (once we get the
>>>>
>>
>>
>>>> Java import support working, of course).
>>>>
>>>>
>>>>>
>>>>> public class MyComponent{
>>>>>
>>>>>      @Property
>>>>>      private Foo; myFoo;
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> public class Foo{
>>>>>
>>>>>      public Foo(){}
>>>>>
>>>>>      private String name;
>>>>>
>>>>>      public setName(String val){
>>>>>          name = val;
>>>>>      }
>>>>>
>>>>>      private Foo foo;
>>>>>
>>>>>      public void setFoo(Foo val){
>>>>>          foo = val;
>>>>>
>>>>>      }
>>>>>
>>>>>      private MyJaxBThing jaxBThing;
>>>>>
>>>>>      public void setMyJaxBThing(MyJaxBThing thing){
>>>>>          jaxBthing = thing;
>>>>>      }
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> And I want to use the following configuration:
>>>>>
>>>>>      <component name="myComp>
>>>>>          <implementation.java class="MyComponent/>
>>>>>          <properties>
>>>>>              <v:myFoo>
>>>>>                      <v:name>my name</v:name>
>>>>>                      <v:foo>
>>>>>                              <v:name>my sub name</v:name>
>>>>>                      </v:foo>
>>>>>                      <jaxb:jaxBThing>
>>>>>                              <!-- other configuration according
>>>>>
>>> to
>>>
>> JAX-B--->
>>
>>>>>                      <jaxb:jaxBThing>
>>>>>              <v:myFoo>
>>>>>          </properties>
>>>>>      </component>
>>>>>
>>>>> I'm assuming I would have to register Foo and MyJaxBThing with SDO?
>>>>> Could someone walk through the steps I would need to do to tell the
>>>>> runtime how to take the particular configuration and deserialize it?
>>>>>
>>
>>
>>>> Assuming, however, that we don't have metadata, but just want to
>>>> deserialize by hand. I don't think the SDO approach is any easier or
>>>>
>>> more
>>>
>>>> difficult than the StAX approach. By default the SDO deserializer will
>>>>
>>
>>
>>>> represent the "untyped" properties section of the model as a Sequence
>>>> (i.e., an unstructured representation of the "xsd:any" contents).
>>>>
>> We'll
>>
>>>> need some way to plug-in a converter, maybe something like a
>>>>
>> FooFactory,
>>
>>>
>>>
>>>> similar to what Jeremy described for the StAX approach. Btw, SDO has
>>>> createFromString methods for all the standard basic types plus a
>>>>
>> generic
>>
>>>
>>>
>>>> createFromString method that work like Jeremy described (i.e., try
>>>> valueOf, constructors, etc.).
>>>>
>>>>
>>>>> Also, what would the string transformation methods look like in this
>>>>>
>>
>>
>>>>> case? I'm also having difficulty pinning down how the JAXB class is
>>>>> instantiated (I'm assuming something needs to access a JAXB factory
>>>>> at some point).
>>>>>
>>>> I don't know enough about JAXB to say. Maybe someone else knows?
>>>>
>>>>
>>>>>
>>>>> Another really common use case (sorry to keep harping on this one,
>>>>> but I see it all of the time) is support for List and Map. I should
>>>>> be able to specify some type of XML serialized form and have
>>>>>
>> property
>>
>>>>> configuration injected on a component as a List or Map.  I'm
>>>>>
>> assuming
>>
>>>>> based on your comments below this can be done to the SDO
>>>>> implementation and we could provide this to end-users without them
>>>>> having to configure something?
>>>>>
>>>> Yes ... the Sequence (DOM-like) view of the properties is there by
>>>> default.
>>>>
>>>>
>>>>>
>>>>> One final scenario, related to this, is support for factories for
>>>>> property instantiation. IoC containers such as Spring have a way to
>>>>> pass a factory in to the injection engine to delegate to for
>>>>>
>> creating
>>
>>>>> property instances.  Could this be done with SDO?
>>>>>
>>>> I think we could provide something like this in Tuscany ... a
>>>> Tuscany-specific extension SPI.
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> - 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 have two concrete examples here where I have seen problems in
>>>>>
>> other
>>
>>>>> projects:
>>>>>
>>>>>
>>>>> 1. Assume there are two nested components whose implementation types
>>>>>
>>
>>
>>>>> are loaded by different classloaders. These two nested components
>>>>> have a property that takes a "Foo". The configuration schema is the
>>>>> same but the "Foo" classes are different because they are loaded by
>>>>> different classloaders. Do you think we will run into any issues
>>>>>
>> here?
>>
>>>> Not unless the first Foo instance is passed to the second component
>>>> (that's expecting the second Foo). But this doesn't strike me as an
>>>>
>> SDO
>>
>>>> issue, it would be a problem even if the Foo class was hand coded,
>>>>
>> don't
>>
>>>
>>>
>>>> you think?
>>>>
>>>>
>>>>>
>>>>> 2. Another concern is around application reloadability. If I have a
>>>>> registered type of "Foo" and the application it was registered by
>>>>> needs to be reloaded, how is it flushed from SDO? Does the container
>>>>>
>>
>>
>>>>> have to call a flush method somewhere?
>>>>>
>>>> This depends on how we handle the scoping. If the TypeHelper that
>>>>
>> knows
>>
>>>> about Foo is in a private application scope then it should go away
>>>>
>> with
>>
>>>> the application.
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> I appreciate that and you taking the time to help explain this stuff
>>>>>
>>
>>
>>>>> to me. I guess I'm going to be a typical example of someone who
>>>>>
>> wants
>>
>>>>> to extend the container and has a bunch of questions :-)
>>>>>
>>>> This is a good excersize for me as well. Regardless of the actual
>>>>
>>> decision
>>>
>>>> of whether or not to use SDO for this particular purpose in SCA, it
>>>>
>> will
>>
>>>
>>>
>>>> help to clarify the issues and what parts of the SDO impl need
>>>>
>>> attention.
>>>
>>>>
>>>> Thanks, Frank.
>>>>
>>>>
>>>>>
>>>>>
>>>>>> 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 <ji...@gmail.com> 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 <ji...@gmail.com>
>>>>>>>> 03/23/2006 02:53 PM
>>>>>>>> Please respond to
>>>>>>>> tuscany-dev
>>>>>>>>
>>>>>>>>
>>>>>>>> To
>>>>>>>> tuscany-dev@ws.apache.org
>>>>>>>> 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"
>>>>>>>>>>> <fr...@ca.ibm.com>
>>>>>>>>>>> To: <tu...@ws.apache.org>
>>>>>>>>>>> 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" <an...@gmail.com> wrote on 03/23/2006
>>>>>>>>>>>> 10:13:24 AM:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-- 
Jean-Sebastien

Re: Framework for StAX-based model loading

[Jim Marino <ji...@gmail.com>]

I think this this is a really good approach and will give us a great  
binding/extension story for Tuscany. Two comments on the statement  
that the model may look a little different than what we have here.  
The first one is that in general, I'm o.k. with that as long as it  
follows common Java idioms. I don't think this will be a problem.   
The second is I'm happy to help out porting the runtime core to use  
the new model so just let me know when we have a cut of the new model.

Jim

On Apr 4, 2006, at 3:16 PM, Frank Budinsky wrote:

> Resending my previous post ... I see that the formatting I wrote it  
> with
> went away and it became impossible to read. Congratulations to  
> anyone that
> got anything out of it at all :-)
>
> Sorry about that,
> Frank.
>
>
> Here is a proposal for moving forward on this issue that I think (am
> hoping :-) everyone can live with.
>
> 1. Remove the existing logical and physical models (and corresponding
>    transformer code) and replace them with a single logical model
>    created as follows:
>   a. One-time generate a pure JavaBean model from the XMLSchema
>      (sca-core.xsd) using a hacked up prototype of the SDO generator.
>      This prototype suppresses SDO things (e.g., reflective methods,
>      for example), so the generated classes are not SDOs - they're
>      POJOs.
>   b. Hand modify the generated classes to add additional methods  
> needed
>      for the logical model. The end result, will look very similar,  
> but
>      not identical, to the current logical model, so a small amount of
>      work will be needed to port client code from the current logical
>      model to this new combined "logical/physical" model.
>
> 2. Modify Jeremy's StAX handlers to work with this new model, and also
>    use them as the prototypical example of the output for a new
>    -generateLoader option for the SDO generator. The plan for the May
>    release will be to use the modified hand written StAX handlers, but
>    they will be marked as "to be generated", so that it's clear  
> that in
>    the future these handlers will be replaced with generated ones.
>
> 3. Start immediately on the SDO -generateLoader and -simpleBeans  
> options.
>    We will use -generateLoader for the core model, as soon as it's
>    available (target 2-3 months?), but we will not plan to regen  
> the core
>    model using -simpleBeans. The model will remain hand coded
>    indefinitely, but we can revisit the possibility of generating  
> parts
>    of it in the future (but this won't be a priority). The - 
> simpleBeans
>    option will be available for use by people adding extensions to the
>    model, if they want to start with XSDs.
>
> 4. Also start immediately on a -generateSerializer option so that  
> we will
>    be able to use simple beans that need to be saved as well as  
> loaded.
>    Given that we support generation of POJOs, we need both generated
>    loaders and serializers to use them. We also need to start work on
>    defining the necessary Java annotations to support generating
>    loaders/serializers from hand-written POJOs (or more generally  
> to also
>    generate SDOs from hand written Java interfaces.
>
> I think this approach is a win-win for both the SCA and SDO projects.
>
> Thoughts?
>
> Thanks,
> Frank.
>
>
>> Frank Budinsky/Toronto/IBM@IBMCA wrote on 03/27/2006 01:26:46 PM:
>>
>>
>>> Jim Marino <ji...@gmail.com> wrote on 03/24/2006 05:53:46 PM:
>>>
>>>
>>>> Thanks Frank for answering these questions.  I have a few more that
>>>> maybe you or others could offer opinions on.
>>>>
>>>> On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
>>>>
>>>>
>>>>> 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.
>>>>>
>>>> I think option two is the more appealing one for applications
>>>> developers. I read option 1 to require a schema, which we may be
>>>>
> able
>
>>>> to do for extensions, but is a bit much to ask application
>>>>
> developers
>
>>>> to produce.  So, I'm curious as to how the conversion methods you
>>>> mentioned look like.  Assume I have the following Java
>>>>
> implementation
>
>>>> and configuration class:
>>>>
>>> I wouldn't write off option 1 so quickly. For your example, a schema
>>>
> (or
>
>>
>>
>>> equivalent SDO metadata) something like this is all that one needs:
>>>
>>> <element name="myFoo" type="Foo"/>
>>>
>>> <complexType name="Foo">
>>>     <sequence>
>>>         <element name="name" type="xsd:int"/>
>>>         <element name="foo" type="Foo"/>
>>>         <element name="myJaxBThing" type="jaxb:jaxBThing"/>
>>>     </sequence>
>>> </complexType>
>>>
>>> This schema could be deduced (under the covers) from the Java  
>>> classes
>>>
>> you
>>
>>> show below, so you wouldn't need to actually write it (once we  
>>> get the
>>>
>
>
>>> Java import support working, of course).
>>>
>>>
>>>>
>>>> public class MyComponent{
>>>>
>>>>      @Property
>>>>      private Foo; myFoo;
>>>>
>>>> }
>>>>
>>>>
>>>> public class Foo{
>>>>
>>>>      public Foo(){}
>>>>
>>>>      private String name;
>>>>
>>>>      public setName(String val){
>>>>          name = val;
>>>>      }
>>>>
>>>>      private Foo foo;
>>>>
>>>>      public void setFoo(Foo val){
>>>>          foo = val;
>>>>
>>>>      }
>>>>
>>>>      private MyJaxBThing jaxBThing;
>>>>
>>>>      public void setMyJaxBThing(MyJaxBThing thing){
>>>>          jaxBthing = thing;
>>>>      }
>>>> }
>>>>
>>>>
>>>>
>>>> And I want to use the following configuration:
>>>>
>>>>      <component name="myComp>
>>>>          <implementation.java class="MyComponent/>
>>>>          <properties>
>>>>              <v:myFoo>
>>>>                      <v:name>my name</v:name>
>>>>                      <v:foo>
>>>>                              <v:name>my sub name</v:name>
>>>>                      </v:foo>
>>>>                      <jaxb:jaxBThing>
>>>>                              <!-- other configuration according
>>>>
>> to
>>
> JAX-B--->
>
>>>>                      <jaxb:jaxBThing>
>>>>              <v:myFoo>
>>>>          </properties>
>>>>      </component>
>>>>
>>>> I'm assuming I would have to register Foo and MyJaxBThing with SDO?
>>>> Could someone walk through the steps I would need to do to tell the
>>>> runtime how to take the particular configuration and deserialize  
>>>> it?
>>>>
>
>
>>> Assuming, however, that we don't have metadata, but just want to
>>> deserialize by hand. I don't think the SDO approach is any easier or
>>>
>> more
>>
>>> difficult than the StAX approach. By default the SDO deserializer  
>>> will
>>>
>
>
>>> represent the "untyped" properties section of the model as a  
>>> Sequence
>>> (i.e., an unstructured representation of the "xsd:any" contents).
>>>
> We'll
>
>>> need some way to plug-in a converter, maybe something like a
>>>
> FooFactory,
>
>>
>>
>>> similar to what Jeremy described for the StAX approach. Btw, SDO has
>>> createFromString methods for all the standard basic types plus a
>>>
> generic
>
>>
>>
>>> createFromString method that work like Jeremy described (i.e., try
>>> valueOf, constructors, etc.).
>>>
>>>
>>>> Also, what would the string transformation methods look like in  
>>>> this
>>>>
>
>
>>>> case? I'm also having difficulty pinning down how the JAXB class is
>>>> instantiated (I'm assuming something needs to access a JAXB factory
>>>> at some point).
>>>>
>>> I don't know enough about JAXB to say. Maybe someone else knows?
>>>
>>>
>>>>
>>>> Another really common use case (sorry to keep harping on this one,
>>>> but I see it all of the time) is support for List and Map. I should
>>>> be able to specify some type of XML serialized form and have
>>>>
> property
>
>>>> configuration injected on a component as a List or Map.  I'm
>>>>
> assuming
>
>>>> based on your comments below this can be done to the SDO
>>>> implementation and we could provide this to end-users without them
>>>> having to configure something?
>>>>
>>> Yes ... the Sequence (DOM-like) view of the properties is there by
>>> default.
>>>
>>>
>>>>
>>>> One final scenario, related to this, is support for factories for
>>>> property instantiation. IoC containers such as Spring have a way to
>>>> pass a factory in to the injection engine to delegate to for
>>>>
> creating
>
>>>> property instances.  Could this be done with SDO?
>>>>
>>> I think we could provide something like this in Tuscany ... a
>>> Tuscany-specific extension SPI.
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>>> - 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 have two concrete examples here where I have seen problems in
>>>>
> other
>
>>>> projects:
>>>>
>>>>
>>>> 1. Assume there are two nested components whose implementation  
>>>> types
>>>>
>
>
>>>> are loaded by different classloaders. These two nested components
>>>> have a property that takes a "Foo". The configuration schema is the
>>>> same but the "Foo" classes are different because they are loaded by
>>>> different classloaders. Do you think we will run into any issues
>>>>
> here?
>
>>> Not unless the first Foo instance is passed to the second component
>>> (that's expecting the second Foo). But this doesn't strike me as an
>>>
> SDO
>
>>> issue, it would be a problem even if the Foo class was hand coded,
>>>
> don't
>
>>
>>
>>> you think?
>>>
>>>
>>>>
>>>> 2. Another concern is around application reloadability. If I have a
>>>> registered type of "Foo" and the application it was registered by
>>>> needs to be reloaded, how is it flushed from SDO? Does the  
>>>> container
>>>>
>
>
>>>> have to call a flush method somewhere?
>>>>
>>> This depends on how we handle the scoping. If the TypeHelper that
>>>
> knows
>
>>> about Foo is in a private application scope then it should go away
>>>
> with
>
>>> the application.
>>>
>>>
>>>>
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> I appreciate that and you taking the time to help explain this  
>>>> stuff
>>>>
>
>
>>>> to me. I guess I'm going to be a typical example of someone who
>>>>
> wants
>
>>>> to extend the container and has a bunch of questions :-)
>>>>
>>> This is a good excersize for me as well. Regardless of the actual
>>>
>> decision
>>
>>> of whether or not to use SDO for this particular purpose in SCA, it
>>>
> will
>
>>
>>
>>> help to clarify the issues and what parts of the SDO impl need
>>>
>> attention.
>>
>>>
>>> Thanks, Frank.
>>>
>>>
>>>>
>>>>
>>>>> 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 <ji...@gmail.com> 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 <ji...@gmail.com>
>>>>>>> 03/23/2006 02:53 PM
>>>>>>> Please respond to
>>>>>>> tuscany-dev
>>>>>>>
>>>>>>>
>>>>>>> To
>>>>>>> tuscany-dev@ws.apache.org
>>>>>>> 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"
>>>>>>>>>> <fr...@ca.ibm.com>
>>>>>>>>>> To: <tu...@ws.apache.org>
>>>>>>>>>> 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" <an...@gmail.com> wrote on 03/23/2006
>>>>>>>>>>> 10:13:24 AM:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Re: Framework for StAX-based model loading

[Frank Budinsky <fr...@ca.ibm.com>]

Resending my previous post ... I see that the formatting I wrote it with 
went away and it became impossible to read. Congratulations to anyone that 
got anything out of it at all :-)

Sorry about that,
Frank.


Here is a proposal for moving forward on this issue that I think (am 
hoping :-) everyone can live with.

1. Remove the existing logical and physical models (and corresponding 
   transformer code) and replace them with a single logical model 
   created as follows:
  a. One-time generate a pure JavaBean model from the XMLSchema 
     (sca-core.xsd) using a hacked up prototype of the SDO generator. 
     This prototype suppresses SDO things (e.g., reflective methods, 
     for example), so the generated classes are not SDOs - they're 
     POJOs.
  b. Hand modify the generated classes to add additional methods needed
     for the logical model. The end result, will look very similar, but
     not identical, to the current logical model, so a small amount of
     work will be needed to port client code from the current logical
     model to this new combined "logical/physical" model.

2. Modify Jeremy's StAX handlers to work with this new model, and also
   use them as the prototypical example of the output for a new
   -generateLoader option for the SDO generator. The plan for the May 
   release will be to use the modified hand written StAX handlers, but
   they will be marked as "to be generated", so that it's clear that in
   the future these handlers will be replaced with generated ones.

3. Start immediately on the SDO -generateLoader and -simpleBeans options.
   We will use -generateLoader for the core model, as soon as it's 
   available (target 2-3 months?), but we will not plan to regen the core
   model using -simpleBeans. The model will remain hand coded 
   indefinitely, but we can revisit the possibility of generating parts 
   of it in the future (but this won't be a priority). The -simpleBeans 
   option will be available for use by people adding extensions to the
   model, if they want to start with XSDs.

4. Also start immediately on a -generateSerializer option so that we will
   be able to use simple beans that need to be saved as well as loaded. 
   Given that we support generation of POJOs, we need both generated 
   loaders and serializers to use them. We also need to start work on
   defining the necessary Java annotations to support generating 
   loaders/serializers from hand-written POJOs (or more generally to also
   generate SDOs from hand written Java interfaces.

I think this approach is a win-win for both the SCA and SDO projects.

Thoughts?

Thanks,
Frank.

> Frank Budinsky/Toronto/IBM@IBMCA wrote on 03/27/2006 01:26:46 PM:
> 
> > Jim Marino <ji...@gmail.com> wrote on 03/24/2006 05:53:46 PM:
> > 
> > > Thanks Frank for answering these questions.  I have a few more that 
> > > maybe you or others could offer opinions on.
> > > 
> > > On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
> > > 
> > > > 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.
> > > I think option two is the more appealing one for applications 
> > > developers. I read option 1 to require a schema, which we may be 
able 
> > > to do for extensions, but is a bit much to ask application 
developers 
> > > to produce.  So, I'm curious as to how the conversion methods you 
> > > mentioned look like.  Assume I have the following Java 
implementation 
> > > and configuration class:
> > I wouldn't write off option 1 so quickly. For your example, a schema 
(or 
> 
> > equivalent SDO metadata) something like this is all that one needs:
> > 
> > <element name="myFoo" type="Foo"/>
> > 
> > <complexType name="Foo">
> >     <sequence>
> >         <element name="name" type="xsd:int"/>
> >         <element name="foo" type="Foo"/>
> >         <element name="myJaxBThing" type="jaxb:jaxBThing"/>
> >     </sequence>
> > </complexType>
> > 
> > This schema could be deduced (under the covers) from the Java classes 
> you 
> > show below, so you wouldn't need to actually write it (once we get the 

> > Java import support working, of course).
> > 
> > > 
> > > public class MyComponent{
> > > 
> > >      @Property
> > >      private Foo; myFoo;
> > > 
> > > }
> > > 
> > > 
> > > public class Foo{
> > > 
> > >      public Foo(){}
> > > 
> > >      private String name;
> > > 
> > >      public setName(String val){
> > >          name = val;
> > >      }
> > > 
> > >      private Foo foo;
> > > 
> > >      public void setFoo(Foo val){
> > >          foo = val;
> > > 
> > >      }
> > > 
> > >      private MyJaxBThing jaxBThing;
> > > 
> > >      public void setMyJaxBThing(MyJaxBThing thing){
> > >          jaxBthing = thing;
> > >      }
> > > }
> > > 
> > > 
> > > 
> > > And I want to use the following configuration:
> > > 
> > >      <component name="myComp>
> > >          <implementation.java class="MyComponent/>
> > >          <properties>
> > >              <v:myFoo>
> > >                      <v:name>my name</v:name>
> > >                      <v:foo>
> > >                              <v:name>my sub name</v:name>
> > >                      </v:foo>
> > >                      <jaxb:jaxBThing>
> > >                              <!-- other configuration according 
> to
JAX-B--->
> > >                      <jaxb:jaxBThing>
> > >              <v:myFoo>
> > >          </properties>
> > >      </component>
> > > 
> > > I'm assuming I would have to register Foo and MyJaxBThing with SDO? 
> > > Could someone walk through the steps I would need to do to tell the 
> > > runtime how to take the particular configuration and deserialize it? 

> > Assuming, however, that we don't have metadata, but just want to 
> > deserialize by hand. I don't think the SDO approach is any easier or 
> more 
> > difficult than the StAX approach. By default the SDO deserializer will 

> > represent the "untyped" properties section of the model as a Sequence 
> > (i.e., an unstructured representation of the "xsd:any" contents). 
We'll 
> > need some way to plug-in a converter, maybe something like a 
FooFactory, 
> 
> > similar to what Jeremy described for the StAX approach. Btw, SDO has 
> > createFromString methods for all the standard basic types plus a 
generic 
> 
> > createFromString method that work like Jeremy described (i.e., try 
> > valueOf, constructors, etc.). 
> > 
> > > Also, what would the string transformation methods look like in this 

> > > case? I'm also having difficulty pinning down how the JAXB class is 
> > > instantiated (I'm assuming something needs to access a JAXB factory 
> > > at some point).
> > I don't know enough about JAXB to say. Maybe someone else knows?
> > 
> > > 
> > > Another really common use case (sorry to keep harping on this one, 
> > > but I see it all of the time) is support for List and Map. I should 
> > > be able to specify some type of XML serialized form and have 
property 
> > > configuration injected on a component as a List or Map.  I'm 
assuming 
> > > based on your comments below this can be done to the SDO 
> > > implementation and we could provide this to end-users without them 
> > > having to configure something?
> > Yes ... the Sequence (DOM-like) view of the properties is there by 
> > default.
> > 
> > > 
> > > One final scenario, related to this, is support for factories for 
> > > property instantiation. IoC containers such as Spring have a way to 
> > > pass a factory in to the injection engine to delegate to for 
creating 
> > > property instances.  Could this be done with SDO?
> > I think we could provide something like this in Tuscany ... a 
> > Tuscany-specific extension SPI.
> > 
> > > >
> > > >
> > > >> - 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 have two concrete examples here where I have seen problems in 
other 
> > > projects:
> > > 
> > > 
> > > 1. Assume there are two nested components whose implementation types 

> > > are loaded by different classloaders. These two nested components 
> > > have a property that takes a "Foo". The configuration schema is the 
> > > same but the "Foo" classes are different because they are loaded by 
> > > different classloaders. Do you think we will run into any issues 
here?
> > Not unless the first Foo instance is passed to the second component 
> > (that's expecting the second Foo). But this doesn't strike me as an 
SDO 
> > issue, it would be a problem even if the Foo class was hand coded, 
don't 
> 
> > you think?
> > 
> > > 
> > > 2. Another concern is around application reloadability. If I have a 
> > > registered type of "Foo" and the application it was registered by 
> > > needs to be reloaded, how is it flushed from SDO? Does the container 

> > > have to call a flush method somewhere?
> > This depends on how we handle the scoping. If the TypeHelper that 
knows 
> > about Foo is in a private application scope then it should go away 
with 
> > the application.
> > 
> > > 
> > > 
> > > > 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.
> > > 
> > > I appreciate that and you taking the time to help explain this stuff 

> > > to me. I guess I'm going to be a typical example of someone who 
wants 
> > > to extend the container and has a bunch of questions :-)
> > This is a good excersize for me as well. Regardless of the actual 
> decision 
> > of whether or not to use SDO for this particular purpose in SCA, it 
will 
> 
> > help to clarify the issues and what parts of the SDO impl need 
> attention.
> > 
> > Thanks, Frank.
> > 
> > > 
> > > > 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 <ji...@gmail.com> 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 <ji...@gmail.com>
> > > >>> 03/23/2006 02:53 PM
> > > >>> Please respond to
> > > >>> tuscany-dev
> > > >>>
> > > >>>
> > > >>> To
> > > >>> tuscany-dev@ws.apache.org
> > > >>> 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"
> > > >>>>>> <fr...@ca.ibm.com>
> > > >>>>>> To: <tu...@ws.apache.org>
> > > >>>>>> 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" <an...@gmail.com> wrote on 03/23/2006 
> > > >>>>>>> 10:13:24 AM:
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >
> > > >
> > > 
> > 
> 

Re: Framework for StAX-based model loading

[Frank Budinsky <fr...@ca.ibm.com>]

Here is a proposal for moving forward on this issue that I think (am 
hoping :-) everyone can live with.

Remove the existing logical and physical models (and corresponding 
transformer code) and replace them with a single logical model created as 
follows:
One-time generate a pure JavaBean model from the XMLSchema (sca-core.xsd) 
using a hacked up prototype of the SDO generator. This prototype 
suppresses SDO things (e.g., reflective methods, for example), so the 
generated classes are not SDOs - they're POJOs.
Hand modify the generated classes to add additional methods needed for the 
logical model. The end result, will look very similar, but not identical, 
to the current logical model, so a small amount of work will be needed to 
port client code from the current logical model to this new combined 
"logical/physical" model.
Modify Jeremy's StAX handlers to work with this new model, and also use 
them as the prototypical example of the output for a new -generateLoader 
option for the SDO generator. The plan for the May release will be to use 
the modified hand written StAX handlers, but they will be marked as "to be 
generated", so that it's clear that in the future these handlers will be 
replaced with generated ones.
Start immediately on the SDO -generateLoader and -simpleBeans options. We 
will use -generateLoader for the core model, as soon as it's available 
(target 2-3 months?), but we will not plan to regen the core model using 
-simpleBeans. The model will remain hand coded indefinitely, but we can 
revisit the possibility of generating parts of it in the future (but this 
won't be a priority). The -simpleBeans option will be available for use by 
people adding extensions to the model, if they want to start with XSDs.
Also start immediately on a -generateSerializer option so that we will be 
able to use simple beans that need to be saved as well as loaded. Given 
that we support generation of POJOs, we need both generated loaders and 
serializers to use them. We also need to start work on defining the 
necessary Java annotations to support generating loaders/serializers from 
hand-written POJOs (or more generally to also generate SDOs from hand 
written Java interfaces.

I think this approach is a win-win for both the SCA and SDO projects.

Thoughts?

Thanks,
Frank.


Frank Budinsky/Toronto/IBM@IBMCA wrote on 03/27/2006 01:26:46 PM:

> Jim Marino <ji...@gmail.com> wrote on 03/24/2006 05:53:46 PM:
> 
> > Thanks Frank for answering these questions.  I have a few more that 
> > maybe you or others could offer opinions on.
> > 
> > On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
> > 
> > > 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.
> > I think option two is the more appealing one for applications 
> > developers. I read option 1 to require a schema, which we may be able 
> > to do for extensions, but is a bit much to ask application developers 
> > to produce.  So, I'm curious as to how the conversion methods you 
> > mentioned look like.  Assume I have the following Java implementation 
> > and configuration class:
> I wouldn't write off option 1 so quickly. For your example, a schema (or 

> equivalent SDO metadata) something like this is all that one needs:
> 
> <element name="myFoo" type="Foo"/>
> 
> <complexType name="Foo">
>     <sequence>
>         <element name="name" type="xsd:int"/>
>         <element name="foo" type="Foo"/>
>         <element name="myJaxBThing" type="jaxb:jaxBThing"/>
>     </sequence>
> </complexType>
> 
> This schema could be deduced (under the covers) from the Java classes 
you 
> show below, so you wouldn't need to actually write it (once we get the 
> Java import support working, of course).
> 
> > 
> > public class MyComponent{
> > 
> >      @Property
> >      private Foo; myFoo;
> > 
> > }
> > 
> > 
> > public class Foo{
> > 
> >      public Foo(){}
> > 
> >      private String name;
> > 
> >      public setName(String val){
> >          name = val;
> >      }
> > 
> >      private Foo foo;
> > 
> >      public void setFoo(Foo val){
> >          foo = val;
> > 
> >      }
> > 
> >      private MyJaxBThing jaxBThing;
> > 
> >      public void setMyJaxBThing(MyJaxBThing thing){
> >          jaxBthing = thing;
> >      }
> > }
> > 
> > 
> > 
> > And I want to use the following configuration:
> > 
> >      <component name="myComp>
> >          <implementation.java class="MyComponent/>
> >          <properties>
> >              <v:myFoo>
> >                      <v:name>my name</v:name>
> >                      <v:foo>
> >                              <v:name>my sub name</v:name>
> >                      </v:foo>
> >                      <jaxb:jaxBThing>
> >                              <!-- other configuration according to
JAX-B--->
> >                      <jaxb:jaxBThing>
> >              <v:myFoo>
> >          </properties>
> >      </component>
> > 
> > I'm assuming I would have to register Foo and MyJaxBThing with SDO? 
> > Could someone walk through the steps I would need to do to tell the 
> > runtime how to take the particular configuration and deserialize it? 
> Assuming, however, that we don't have metadata, but just want to 
> deserialize by hand. I don't think the SDO approach is any easier or 
more 
> difficult than the StAX approach. By default the SDO deserializer will 
> represent the "untyped" properties section of the model as a Sequence 
> (i.e., an unstructured representation of the "xsd:any" contents). We'll 
> need some way to plug-in a converter, maybe something like a FooFactory, 

> similar to what Jeremy described for the StAX approach. Btw, SDO has 
> createFromString methods for all the standard basic types plus a generic 

> createFromString method that work like Jeremy described (i.e., try 
> valueOf, constructors, etc.). 
> 
> > Also, what would the string transformation methods look like in this 
> > case? I'm also having difficulty pinning down how the JAXB class is 
> > instantiated (I'm assuming something needs to access a JAXB factory 
> > at some point).
> I don't know enough about JAXB to say. Maybe someone else knows?
> 
> > 
> > Another really common use case (sorry to keep harping on this one, 
> > but I see it all of the time) is support for List and Map. I should 
> > be able to specify some type of XML serialized form and have property 
> > configuration injected on a component as a List or Map.  I'm assuming 
> > based on your comments below this can be done to the SDO 
> > implementation and we could provide this to end-users without them 
> > having to configure something?
> Yes ... the Sequence (DOM-like) view of the properties is there by 
> default.
> 
> > 
> > One final scenario, related to this, is support for factories for 
> > property instantiation. IoC containers such as Spring have a way to 
> > pass a factory in to the injection engine to delegate to for creating 
> > property instances.  Could this be done with SDO?
> I think we could provide something like this in Tuscany ... a 
> Tuscany-specific extension SPI.
> 
> > >
> > >
> > >> - 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 have two concrete examples here where I have seen problems in other 
> > projects:
> > 
> > 
> > 1. Assume there are two nested components whose implementation types 
> > are loaded by different classloaders. These two nested components 
> > have a property that takes a "Foo". The configuration schema is the 
> > same but the "Foo" classes are different because they are loaded by 
> > different classloaders. Do you think we will run into any issues here?
> Not unless the first Foo instance is passed to the second component 
> (that's expecting the second Foo). But this doesn't strike me as an SDO 
> issue, it would be a problem even if the Foo class was hand coded, don't 

> you think?
> 
> > 
> > 2. Another concern is around application reloadability. If I have a 
> > registered type of "Foo" and the application it was registered by 
> > needs to be reloaded, how is it flushed from SDO? Does the container 
> > have to call a flush method somewhere?
> This depends on how we handle the scoping. If the TypeHelper that knows 
> about Foo is in a private application scope then it should go away with 
> the application.
> 
> > 
> > 
> > > 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.
> > 
> > I appreciate that and you taking the time to help explain this stuff 
> > to me. I guess I'm going to be a typical example of someone who wants 
> > to extend the container and has a bunch of questions :-)
> This is a good excersize for me as well. Regardless of the actual 
decision 
> of whether or not to use SDO for this particular purpose in SCA, it will 

> help to clarify the issues and what parts of the SDO impl need 
attention.
> 
> Thanks, Frank.
> 
> > 
> > > 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 <ji...@gmail.com> 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 <ji...@gmail.com>
> > >>> 03/23/2006 02:53 PM
> > >>> Please respond to
> > >>> tuscany-dev
> > >>>
> > >>>
> > >>> To
> > >>> tuscany-dev@ws.apache.org
> > >>> 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"
> > >>>>>> <fr...@ca.ibm.com>
> > >>>>>> To: <tu...@ws.apache.org>
> > >>>>>> 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" <an...@gmail.com> wrote on 03/23/2006 
> > >>>>>>> 10:13:24 AM:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
> > 
> 

Re: Framework for StAX-based model loading

[Frank Budinsky <fr...@ca.ibm.com>]

Jim Marino <ji...@gmail.com> wrote on 03/24/2006 05:53:46 PM:

> Thanks Frank for answering these questions.  I have a few more that 
> maybe you or others could offer opinions on.
> 
> On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
> 
> > 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.
> I think option two is the more appealing one for applications 
> developers. I read option 1 to require a schema, which we may be able 
> to do for extensions, but is a bit much to ask application developers 
> to produce.  So, I'm curious as to how the conversion methods you 
> mentioned look like.  Assume I have the following Java implementation 
> and configuration class:
I wouldn't write off option 1 so quickly. For your example, a schema (or 
equivalent SDO metadata) something like this is all that one needs:

<element name="myFoo" type="Foo"/>

<complexType name="Foo">
    <sequence>
        <element name="name" type="xsd:int"/>
        <element name="foo" type="Foo"/>
        <element name="myJaxBThing" type="jaxb:jaxBThing"/>
    </sequence>
</complexType>

This schema could be deduced (under the covers) from the Java classes you 
show below, so you wouldn't need to actually write it (once we get the 
Java import support working, of course).

> 
> public class MyComponent{
> 
>      @Property
>      private Foo; myFoo;
> 
> }
> 
> 
> public class Foo{
> 
>      public Foo(){}
> 
>      private String name;
> 
>      public setName(String val){
>          name = val;
>      }
> 
>      private Foo foo;
> 
>      public void setFoo(Foo val){
>          foo = val;
> 
>      }
> 
>      private MyJaxBThing jaxBThing;
> 
>      public void setMyJaxBThing(MyJaxBThing thing){
>          jaxBthing = thing;
>      }
> }
> 
> 
> 
> And I want to use the following configuration:
> 
>      <component name="myComp>
>          <implementation.java class="MyComponent/>
>          <properties>
>              <v:myFoo>
>                      <v:name>my name</v:name>
>                      <v:foo>
>                              <v:name>my sub name</v:name>
>                      </v:foo>
>                      <jaxb:jaxBThing>
>                              <!-- other configuration according to 
JAX-B--->
>                      <jaxb:jaxBThing>
>              <v:myFoo>
>          </properties>
>      </component>
> 
> I'm assuming I would have to register Foo and MyJaxBThing with SDO? 
> Could someone walk through the steps I would need to do to tell the 
> runtime how to take the particular configuration and deserialize it? 
Assuming, however, that we don't have metadata, but just want to 
deserialize by hand. I don't think the SDO approach is any easier or more 
difficult than the StAX approach. By default the SDO deserializer will 
represent the "untyped" properties section of the model as a Sequence 
(i.e., an unstructured representation of the "xsd:any" contents). We'll 
need some way to plug-in a converter, maybe something like a FooFactory, 
similar to what Jeremy described for the StAX approach. Btw, SDO has 
createFromString methods for all the standard basic types plus a generic 
createFromString method that work like Jeremy described (i.e., try 
valueOf, constructors, etc.). 

> Also, what would the string transformation methods look like in this 
> case? I'm also having difficulty pinning down how the JAXB class is 
> instantiated (I'm assuming something needs to access a JAXB factory 
> at some point).
I don't know enough about JAXB to say. Maybe someone else knows?

> 
> Another really common use case (sorry to keep harping on this one, 
> but I see it all of the time) is support for List and Map. I should 
> be able to specify some type of XML serialized form and have property 
> configuration injected on a component as a List or Map.  I'm assuming 
> based on your comments below this can be done to the SDO 
> implementation and we could provide this to end-users without them 
> having to configure something?
Yes ... the Sequence (DOM-like) view of the properties is there by 
default.

> 
> One final scenario, related to this, is support for factories for 
> property instantiation. IoC containers such as Spring have a way to 
> pass a factory in to the injection engine to delegate to for creating 
> property instances.  Could this be done with SDO?
I think we could provide something like this in Tuscany ... a 
Tuscany-specific extension SPI.

> >
> >
> >> - 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 have two concrete examples here where I have seen problems in other 
> projects:
> 
> 
> 1. Assume there are two nested components whose implementation types 
> are loaded by different classloaders. These two nested components 
> have a property that takes a "Foo". The configuration schema is the 
> same but the "Foo" classes are different because they are loaded by 
> different classloaders. Do you think we will run into any issues here?
Not unless the first Foo instance is passed to the second component 
(that's expecting the second Foo). But this doesn't strike me as an SDO 
issue, it would be a problem even if the Foo class was hand coded, don't 
you think?

> 
> 2. Another concern is around application reloadability. If I have a 
> registered type of "Foo" and the application it was registered by 
> needs to be reloaded, how is it flushed from SDO? Does the container 
> have to call a flush method somewhere?
This depends on how we handle the scoping. If the TypeHelper that knows 
about Foo is in a private application scope then it should go away with 
the application.

> 
> 
> > 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.
> 
> I appreciate that and you taking the time to help explain this stuff 
> to me. I guess I'm going to be a typical example of someone who wants 
> to extend the container and has a bunch of questions :-)
This is a good excersize for me as well. Regardless of the actual decision 
of whether or not to use SDO for this particular purpose in SCA, it will 
help to clarify the issues and what parts of the SDO impl need attention.

Thanks, Frank.

> 
> > 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 <ji...@gmail.com> 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 <ji...@gmail.com>
> >>> 03/23/2006 02:53 PM
> >>> Please respond to
> >>> tuscany-dev
> >>>
> >>>
> >>> To
> >>> tuscany-dev@ws.apache.org
> >>> 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"
> >>>>>> <fr...@ca.ibm.com>
> >>>>>> To: <tu...@ws.apache.org>
> >>>>>> 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" <an...@gmail.com> wrote on 03/23/2006 
> >>>>>>> 10:13:24 AM:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> 

Re: Framework for StAX-based model loading

[Jim Marino <ji...@gmail.com>]

Thanks Frank for answering these questions.  I have a few more that  
maybe you or others could offer opinions on.

On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:

> 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.
I think option two is the more appealing one for applications  
developers. I read option 1 to require a schema, which we may be able  
to do for extensions, but is a bit much to ask application developers  
to produce.  So, I'm curious as to how the conversion methods you  
mentioned look like.  Assume I have the following Java implementation  
and configuration class:

public class MyComponent{

     @Property
     private Foo; myFoo;

}


public class Foo{

     public Foo(){}

     private String name;

     public setName(String val){
         name = val;
     }

     private Foo foo;

     public void setFoo(Foo val){
         foo = val;

     }

     private MyJaxBThing jaxBThing;

     public void setMyJaxBThing(MyJaxBThing thing){
         jaxBthing = thing;
     }
}



And I want to use the following configuration:

     <component name="myComp>
         <implementation.java class="MyComponent/>
         <properties>
             <v:myFoo>
                     <v:name>my name</v:name>
                     <v:foo>
                             <v:name>my sub name</v:name>
                     </v:foo>
                     <jaxb:jaxBThing>
                             <!-- other configuration according to  
JAX-B--->
                     <jaxb:jaxBThing>
             <v:myFoo>
         </properties>
     </component>

I'm assuming I would have to register Foo and MyJaxBThing with SDO?   
Could someone walk through the steps I would need to do to tell the  
runtime how to take the particular configuration and deserialize it?  
Also, what would the string transformation methods look like in this  
case? I'm also having difficulty pinning down how the JAXB class is  
instantiated (I'm assuming something needs to access a JAXB factory  
at some point).

Another really common use case (sorry to keep harping on this one,  
but I see it all of the time) is support for List and Map. I should  
be able to specify some type of XML serialized form and have property  
configuration injected on a component as a List or Map.  I'm assuming  
based on your comments below this can be done to the SDO  
implementation and we could provide this to end-users without them  
having to configure something?

One final scenario, related to this, is support for factories for  
property instantiation. IoC containers such as Spring have a way to  
pass a factory in to the injection engine to delegate to for creating  
property instances.  Could this be done with SDO?
>
>
>> - 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 have two concrete examples here where I have seen problems in other  
projects:


1. Assume there are two nested components whose implementation types  
are loaded by different classloaders. These two nested components  
have a property that takes a "Foo". The configuration schema is the  
same but the "Foo" classes are different because they are loaded by  
different classloaders. Do you think we will run into any issues here?

2. Another concern is around application reloadability. If I have a  
registered type of "Foo" and the application it was registered by  
needs to be reloaded, how is it flushed from SDO? Does the container  
have to call a flush method somewhere?


> 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.

I appreciate that and you taking the time to help explain this stuff  
to me. I guess I'm going to be a typical example of someone who wants  
to extend the container and has a bunch of questions :-)

> 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 <ji...@gmail.com> 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 <ji...@gmail.com>
>>> 03/23/2006 02:53 PM
>>> Please respond to
>>> tuscany-dev
>>>
>>>
>>> To
>>> tuscany-dev@ws.apache.org
>>> 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"
>>>>>> <fr...@ca.ibm.com>
>>>>>> To: <tu...@ws.apache.org>
>>>>>> 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" <an...@gmail.com> wrote on 03/23/2006  
>>>>>>> 10:13:24 AM:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>

Re: Framework for StAX-based model loading

[Frank Budinsky <fr...@ca.ibm.com>]

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 <ji...@gmail.com> 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 <ji...@gmail.com>
> > 03/23/2006 02:53 PM
> > Please respond to
> > tuscany-dev
> >
> >
> > To
> > tuscany-dev@ws.apache.org
> > 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"
> >>>> <fr...@ca.ibm.com>
> >>>> To: <tu...@ws.apache.org>
> >>>> 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" <an...@gmail.com> wrote on 03/23/2006 10:13:24 AM:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> 

Re: Framework for StAX-based model loading

[Jim Marino <ji...@gmail.com>]

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 <ji...@gmail.com>
> 03/23/2006 02:53 PM
> Please respond to
> tuscany-dev
>
>
> To
> tuscany-dev@ws.apache.org
> 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"
>>>> <fr...@ca.ibm.com>
>>>> To: <tu...@ws.apache.org>
>>>> 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" <an...@gmail.com> wrote on 03/23/2006 10:13:24 AM:
>>>>>
>>>>>
>>>>>
>>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
>>>
>>>
>>
>>
>>
>>
>
>
>
>

Re: Framework for StAX-based model loading

[Frank Budinsky <fr...@ca.ibm.com>]

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 <ji...@gmail.com> 
03/23/2006 02:53 PM
Please respond to
tuscany-dev


To
tuscany-dev@ws.apache.org
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" 
>>> <fr...@ca.ibm.com>
>>> To: <tu...@ws.apache.org>
>>> 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" <an...@gmail.com> wrote on 03/23/2006 10:13:24 AM:
>>>>
>>>>
>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
>>
>
>
>

Re: Framework for StAX-based model loading

[Jim Marino <ji...@gmail.com>]

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"  
>>> <fr...@ca.ibm.com>
>>> To: <tu...@ws.apache.org>
>>> 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" <an...@gmail.com> wrote on 03/23/2006 10:13:24 AM:
>>>>
>>>>
>>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
>>
>
>
>

Re: Framework for StAX-based model loading

[Frank Budinsky <fr...@ca.ibm.com>]

Jeremy Boynes <jb...@apache.org> wrote on 03/23/2006 02:02:00 PM:

> 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. 
That's what I initially thought until Sebastien pointed me at the model - 
which I finally spent more than 2 minutes looking at :-) I think that 
aside from the wildcard extensibility hooks, the model is, itself, quite 
reasonably structured. 

> On the other hand, our use case 
> doesn't need things like change tracking or streaming that SDO provides.
My main point is that this IS a very common general use case. We need to 
support it well.

> 
> 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.
True ... but if we can make them the same, I think we should.

Frank.

> 
> --
> 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" 
<fr...@ca.ibm.com>
> >> To: <tu...@ws.apache.org>
> >> 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" <an...@gmail.com> wrote on 03/23/2006 10:13:24 AM:
> >>>
> >>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
> > 
> 
> 

Re: Framework for StAX-based model loading

[Jeremy Boynes <jb...@apache.org>]

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" <fr...@ca.ibm.com>
>> To: <tu...@ws.apache.org>
>> 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" <an...@gmail.com> wrote on 03/23/2006 10:13:24 AM:
>>>
>>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?
> 

Re: Framework for StAX-based model loading

[Guillaume Nodet <gn...@codehaus.org>]

Jean-Sebastien Delfino wrote:

> 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?
>
We are using maven 1 only, but ant tasks could be a start as they are 
easily integrated in maven.
A plugin is more a nice to have.

Cheers,
Guillaume Nodet

Re: Framework for StAX-based model loading

[Jean-Sebastien Delfino <js...@apache.org>]

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" <fr...@ca.ibm.com>
> To: <tu...@ws.apache.org>
> 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" <an...@gmail.com> wrote on 03/23/2006 10:13:24 AM:
>>
>>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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?

-- 
Jean-Sebastien

Re: Framework for StAX-based model loading

[Raymond Feng <en...@gmail.com>]

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" <fr...@ca.ibm.com>
To: <tu...@ws.apache.org>
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" <an...@gmail.com> wrote on 03/23/2006 10:13:24 AM:
>
>> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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
> 

Re: Framework for StAX-based model loading

[Frank Budinsky <fr...@ca.ibm.com>]

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" <an...@gmail.com> wrote on 03/23/2006 10:13:24 AM:

> On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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

Re: Framework for StAX-based model loading

[ant elder <an...@gmail.com>]

On 3/23/06, Guillaume Nodet <gn...@codehaus.org> 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

Re: Framework for StAX-based model loading

[Guillaume Nodet <gn...@codehaus.org>]

I do really like the StaX based loader for binding, which are really 
simple to write for simple
bindings.  The jbi binding is quite the same as the axis2 one, so that 
there is only one attribute on
the binding element.  Having to auto-generate a number of classes for 
that is quite painful.

If you are considering keeping the SDO model, it would be great to add 
support for maven 1
and ant, as not everyone is using maven 2.
As ServiceMix is still build with maven1, I decided to not implement the 
SDO based loader
at the moment and stay with StaX.  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 :(
I also had to rewrite the BootStrapHelper and TuscanyRuntime to be able 
to use StaX without
having to patch the sources (a setter for the stax attribute would be 
welcome ;) ).

... just my 2 cents.

Cheers,
Guillaume Nodet

Jeremy Boynes wrote:

>I checked in a framework for a StAX-based configuration loader for the
>SCA core. It is based on a set of element handlers that generate a model
>object from a element in the XML stream; handlers for the core and
>system schemas are in the core module, handlers for extensions can be
>bundled in the extension module and are contributed as regular system
>components.
>
>I tested with the basic system and helloworld configurations and
>discovered a problem with the way configured properties and references
>are handled. This should be resolved once the FIXME in ComponentImpl is
>addressed.
>
>To get this working I had to modify the autowire resolver in the
>SystemAggregateContextImpl. I hope this can be removed once Jim gets
>references working. I also think we need to reexamine the autowire
>algorithm but will open another thread for that.
>
>--
>Jeremy
>
>
>  
>

Re: Framework for StAX-based model loading

[ant elder <an...@gmail.com>]

I like this a lot. Lets change everything over to it from SDO.

   ...ant

On 3/14/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> I have got the StAX stuff to the point where I can run all the itests in
> the build and the tomcat/testing tests using the StAX framework. I think
> this is an opportune time to open discussion on whether we should switch
> over to this once and for all.
>
> You can enable the framework by setting the useStax boolean in
> BootstrapHelper to true and rebuilding the core module (and any others
> you wish to test).
>
> To see what is involved in adding an extension have a look at:
> JavaScriptImplementationLoader for the .js container
> JSONRPCBindingLoader for the .jsonrpc binding
>
> Comments welcome...
> --
> Jeremy
>
> Jeremy Boynes wrote:
> > I checked in a framework for a StAX-based configuration loader for the
> > SCA core. It is based on a set of element handlers that generate a model
> > object from a element in the XML stream; handlers for the core and
> > system schemas are in the core module, handlers for extensions can be
> > bundled in the extension module and are contributed as regular system
> > components.
> >
> > I tested with the basic system and helloworld configurations and
> > discovered a problem with the way configured properties and references
> > are handled. This should be resolved once the FIXME in ComponentImpl is
> > addressed.
> >
> > To get this working I had to modify the autowire resolver in the
> > SystemAggregateContextImpl. I hope this can be removed once Jim gets
> > references working. I also think we need to reexamine the autowire
> > algorithm but will open another thread for that.
> >
> > --
> > Jeremy
>
>

Re: Framework for StAX-based model loading

[Jeremy Boynes <jb...@apache.org>]

Guillaume Nodet wrote:
> I have just tested that with svn head and I have the following exception:
> org.apache.tuscany.core.context.DuplicateNameException:
> org.apache.tuscany.core.loader.assembly.ComponentLoader

This was a problem due to skew with Jim's changes yesterday - should be
fixed now.
--
Jeremy

Re: Framework for StAX-based model loading

[Guillaume Nodet <gn...@codehaus.org>]

I have just tested that with svn head and I have the following exception:
org.apache.tuscany.core.context.DuplicateNameException: 
org.apache.tuscany.core.loader.assembly.ComponentLoader
    at 
org.apache.tuscany.core.system.context.SystemAggregateContextImpl.registerConfiguration(SystemAggregateContextImpl.java:424)
    at 
org.apache.tuscany.core.system.context.SystemAggregateContextImpl.registerModelObject(SystemAggregateContextImpl.java:350)
    at 
org.apache.tuscany.core.client.BootstrapHelper.bootstrapStaxLoader(BootstrapHelper.java:117)
    at 
org.apache.tuscany.core.client.BootstrapHelper.getConfigurationLoader(BootstrapHelper.java:104)
    at 
org.apache.tuscany.core.client.TuscanyRuntime.<init>(TuscanyRuntime.java:93)
    at 
org.apache.tuscany.core.client.TuscanyRuntime.<init>(TuscanyRuntime.java:64)
    at 
org.apache.servicemix.sca.AssemblyLoaderTest.testStaxLoader(AssemblyLoaderTest.java:116)
    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)
    at junit.framework.TestResult.run(TestResult.java:109)
    at junit.framework.TestCase.run(TestCase.java:118)
    at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
    at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
    at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

Did I miss something ?

Guillaume Nodet

Jeremy Boynes wrote:

>I have got the StAX stuff to the point where I can run all the itests in
>the build and the tomcat/testing tests using the StAX framework. I think
>this is an opportune time to open discussion on whether we should switch
>over to this once and for all.
>
>You can enable the framework by setting the useStax boolean in
>BootstrapHelper to true and rebuilding the core module (and any others
>you wish to test).
>
>To see what is involved in adding an extension have a look at:
>JavaScriptImplementationLoader for the .js container
>JSONRPCBindingLoader for the .jsonrpc binding
>
>Comments welcome...
>--
>Jeremy
>
>Jeremy Boynes wrote:
>  
>
>>I checked in a framework for a StAX-based configuration loader for the
>>SCA core. It is based on a set of element handlers that generate a model
>>object from a element in the XML stream; handlers for the core and
>>system schemas are in the core module, handlers for extensions can be
>>bundled in the extension module and are contributed as regular system
>>components.
>>
>>I tested with the basic system and helloworld configurations and
>>discovered a problem with the way configured properties and references
>>are handled. This should be resolved once the FIXME in ComponentImpl is
>>addressed.
>>
>>To get this working I had to modify the autowire resolver in the
>>SystemAggregateContextImpl. I hope this can be removed once Jim gets
>>references working. I also think we need to reexamine the autowire
>>algorithm but will open another thread for that.
>>
>>--
>>Jeremy
>>    
>>
>
>
>
>  
>

Re: Framework for StAX-based model loading

[Jeremy Boynes <jb...@apache.org>]

Michael Beisiegel wrote:
> hi Jeremy,
> has somebody captured the current version of the logical model in UML.
> 

I don't think so - should be easy for someone with access to a reverse
engineering tool :-)

--
Jeremy

Re: Framework for StAX-based model loading

[Michael Beisiegel <mi...@gmail.com>]

hi Jeremy,
has somebody captured the current version of the logical model in UML.

thanks,
Michael

On 3/22/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> Frank Budinsky wrote:
> > Now back to the issue of whether or not to use SDO for the SCDL model.
> > Personally, I think that the main issue Jeremy is bringing up is that
> the
> > way SDO is currently being used for a Java binding of the physical
> model,
> > which then needs to be transformed into a different logical model,
> really
> > makes one question its value. You need to write similar code to create
> the
> > logical model, whether it's by reading from StAX or from the generated
> > physical model API. The generated API is a little nicer, but hardly
> enough
> > to warrant the added layer/complexity. I think I agree with that.
> >
> > But, if I step back, I really question the need for two models in the
> > first place. If I understand the history of this, the goal was to have a
> > logical model to hide the physical model, and specifically, the EMF
> > complexity it contained. If that's true, and given my comments above
> about
> > the EMF-less code that we're planning to generate, I would think that
> the
> > right end goal is to unifying the logical model with the generated
> model,
> > instead of eliminating it and writing all the model building code by
> hand.
> >
> > I think that we really should use the Tuscany code generator. It is
> > important that it be a competitive Java binding technology (as good or
> > better then JAXB, etc.), so what better way to make that happen then to
> > use it ourselves. The SDO spec is pretty vague on what an SDO generator
> > actually generates (other than the fact that the interfaces are
> > bean-like), so we have a lot of opportunity to provide options, etc., to
> > make it do exactly what we want.
> >
> > That's my admittedly biased 2 cents worth :-)
> >
>
> I would say that the goal for the logical model was to have a view of
> the configuration information that was easy to work with programatically.
>
> To support testing we wanted to be able to construct models easily that
> could be used to boot component containers. Although we would use that
> to test the containers themselves, the main goal was to allow users to
> test the logic in their components when some container interaction was
> required.
>
> With that in mind, I am not sure that any simple XML->Java binding
> approach is the right way to go. What we found before was that led to a
> model that mirrored the XML structure rather than the "logical"
> structure of the configuration.
>
> That is where the SDO/EMF issues crept in. To provide the model we
> wanted we needed to mix functionality into the generated code. This was
> hard to maintain so we attempted to factor it out into subclasses; that
> didn't really work which is why we ended up with a separate physical
> model. I think SDO/EMF is a perception victim here - I think we would
> have had the same issues with XMLBeans, JAXB or any other binding
> framework.
>
> If SDO could de-serialize directly into our logical model then that
> would be a simple option to use. However, if the price we need to pay to
> achieve that is a heavily annotated XML schema or a custom code
> generator I think we are back to where we are now.
>
> Finally, I want to be clear I don't think this is an SDO problem, I
> think it is an issue we have because the model does not map directly to
> XML and that we would have this problem with any technology - I have
> certainly seen the same issue in projects that used XMLBeans and Castor.
>
> We could enhance SDO to handle this mapping better (e.g. through a more
> sophisticated code generator). I think we would be better served though
> to direct that energy into improving the SDO-centric features of our
> implementation rather than doing something special for Tuscany's loading
> problem.
>
> One alternative we have is to make the logical model directly map to the
> XML. At one point we were there, but we moved away from that to simplify
> testing. I think that is the right strategic choice as it makes testing
> easier for our users - the price we pay for their convenience is a more
> complex configuration loader.
>
> --
> Jeremy
>

Re: Framework for StAX-based model loading

[Frank Budinsky <fr...@ca.ibm.com>]

Jeremy Boynes <jb...@apache.org> wrote on 03/22/2006 09:41:46 PM:

> Jean-Sebastien Delfino wrote:
> > 
> > The logical model is actually pretty close to the model generated from
> > the XMLSchema. If you take the model generated from the schema and add 
a
> > few derived /calculated relationships and derived attributes you get a
> > reasonable logical model for the runtime configuration.
> > 
> > We had this for some time - and contrary to what you're saying here
> > Jeremy - it worked. The issue at the time (and it's still an issue now
> > but Frank is working on fixing that) was that the generated model had
> > dependencies on EMF and some of the EMF aspects were shining through 
the
> > model. This made using this model and in particular writing test cases
> > difficult for people without EMF expertise. To workaround this problem
> > and shield people in the group from the EMFness of the generated 
model,
> > we created two separate hierarchies, a POJO based model (with no
> > dependencies on EMF or SDO), and a generated model (and obviously we 
had
> > to write the code to transform one into the other).
> > 
> > When we get from Frank a code generator that generates EMF-less model
> > classes then I think we'll be able to get back to what we had a few
> > weeks ago, which again worked...
> > - a generated model - always in line with the schema, without the 
burden
> > of writing, debugging and maintaining the parsing code
> > - derived logical relationships and attributes (when necessary) in
> > subclasses
> > - but this logical model will be a POJO model similar to what we have
> > now without any EMF dependencies.
> > 
> > When we get there, most component implementation types and binding 
types
> > should actually be able to work with just the generated model classes,
> > without writing any code at all (no loader, no parser).
> > 
> > I'll reiterate what I said before, I think that the right strategy 
here
> > is to use our databinding technology, and through that exercise help
> > make it better.
> > 
> 
> I actually said that "it never *really* worked" which is a different
> thing. Of course it "worked" as we were able to load configurations;
> however, for all of the reasons *you* describe above it was never an
> easy-to-use or easy-to-maintain implementation. That is still the case.
> 
> We now have a new level of complexity in that, due to changes to the SDO
> code generator *required to comply with the SDO spec* we now have a
> whole new set of SDO-specific annotations that had to be added to the
> schema files and which now need to be maintained. What next - a new
Jeremy, I think you're blowing this one way out of proportion. The issue 
is simply one of "." characters being used in names. I think the proper 
solution will be to have a generator option (or default) that will fix 
invalid Java names during codegen (not the SDO property names during 
XSDHelper.define - which is what the annotations do). To make the Tuscany 
SDO code generator competitive, we need to do that anyway. Regardless of 
what the spec says, a Java generator that generates Java that doesn't 
compile in some situations is just not going to fly. We will fix it.

> Maven plugin to run the schemas through an XSLT as the SDO spec suggests
> in order to mix in our annotations?
> 
> We still don't have a solution to SDO's classloader issues (again, spec
> related), we still don't have a solution for loading complex properties,
> and we are dependent on future changes to code generation to make it
> "really work" at all.
> 
> We've struggled for months with this type of solution, and pardon my
> frustration, but when is enough enough?
> 
> --
> Jeremy

Earlier in the thread you said this:

> We could enhance SDO to handle this mapping better (e.g. through a more
> sophisticated code generator). I think we would be better served though
> to direct that energy into improving the SDO-centric features of our
> implementation rather than doing something special for Tuscany's loading
> problem.
I'm absolutely convinced that the problems you're describing are not 
unique to the SCA use of SDO. From my experience with the SDO 1 
implementation at Eclipse, I can tell you that as many, or more, people 
are interested in using SDO as an "XML binding technology" than as a 
"unified API for accessing heterogeneous data, etc.", so we NEED to make 
it work well for this.

You also said this:

> If SDO could de-serialize directly into our logical model then that
> would be a simple option to use. However, if the price we need to pay to
> achieve that is a heavily annotated XML schema or a custom code
> generator I think we are back to where we are now.
This MUST BE the end goal, IMO. We just need to accept a few (not so 
small) bumps in the road on the way there :-) 

Frank.

Re: Framework for StAX-based model loading

[Jeremy Boynes <jb...@apache.org>]

Jean-Sebastien Delfino wrote:
> 
> The logical model is actually pretty close to the model generated from
> the XMLSchema. If you take the model generated from the schema and add a
> few derived /calculated relationships and derived attributes you get a
> reasonable logical model for the runtime configuration.
> 
> We had this for some time - and contrary to what you're saying here
> Jeremy - it worked. The issue at the time (and it's still an issue now
> but Frank is working on fixing that) was that the generated model had
> dependencies on EMF and some of the EMF aspects were shining through the
> model. This made using this model and in particular writing test cases
> difficult for people without EMF expertise. To workaround this problem
> and shield people in the group from the EMFness of the generated model,
> we created two separate hierarchies, a POJO based model (with no
> dependencies on EMF or SDO), and a generated model (and obviously we had
> to write the code to transform one into the other).
> 
> When we get from Frank a code generator that generates EMF-less model
> classes then I think we'll be able to get back to what we had a few
> weeks ago, which again worked...
> - a generated model - always in line with the schema, without the burden
> of writing, debugging and maintaining the parsing code
> - derived logical relationships and attributes (when necessary) in
> subclasses
> - but this logical model will be a POJO model similar to what we have
> now without any EMF dependencies.
> 
> When we get there, most component implementation types and binding types
> should actually be able to work with just the generated model classes,
> without writing any code at all (no loader, no parser).
> 
> I'll reiterate what I said before, I think that the right strategy here
> is to use our databinding technology, and through that exercise help
> make it better.
> 

I actually said that "it never *really* worked" which is a different
thing. Of course it "worked" as we were able to load configurations;
however, for all of the reasons *you* describe above it was never an
easy-to-use or easy-to-maintain implementation. That is still the case.

We now have a new level of complexity in that, due to changes to the SDO
code generator *required to comply with the SDO spec* we now have a
whole new set of SDO-specific annotations that had to be added to the
schema files and which now need to be maintained. What next - a new
Maven plugin to run the schemas through an XSLT as the SDO spec suggests
in order to mix in our annotations?

We still don't have a solution to SDO's classloader issues (again, spec
related), we still don't have a solution for loading complex properties,
and we are dependent on future changes to code generation to make it
"really work" at all.

We've struggled for months with this type of solution, and pardon my
frustration, but when is enough enough?

--
Jeremy

Re: Framework for StAX-based model loading

[Jean-Sebastien Delfino <js...@apache.org>]

Jeremy Boynes wrote:
> Frank Budinsky wrote:
>   
>> Now back to the issue of whether or not to use SDO for the SCDL model. 
>> Personally, I think that the main issue Jeremy is bringing up is that the 
>> way SDO is currently being used for a Java binding of the physical model, 
>> which then needs to be transformed into a different logical model, really 
>> makes one question its value. You need to write similar code to create the 
>> logical model, whether it's by reading from StAX or from the generated 
>> physical model API. The generated API is a little nicer, but hardly enough 
>> to warrant the added layer/complexity. I think I agree with that.
>>
>> But, if I step back, I really question the need for two models in the 
>> first place. If I understand the history of this, the goal was to have a 
>> logical model to hide the physical model, and specifically, the EMF 
>> complexity it contained. If that's true, and given my comments above about 
>> the EMF-less code that we're planning to generate, I would think that the 
>> right end goal is to unifying the logical model with the generated model, 
>> instead of eliminating it and writing all the model building code by hand.
>>
>> I think that we really should use the Tuscany code generator. It is 
>> important that it be a competitive Java binding technology (as good or 
>> better then JAXB, etc.), so what better way to make that happen then to 
>> use it ourselves. The SDO spec is pretty vague on what an SDO generator 
>> actually generates (other than the fact that the interfaces are 
>> bean-like), so we have a lot of opportunity to provide options, etc., to 
>> make it do exactly what we want.
>>
>> That's my admittedly biased 2 cents worth :-)
>>
>>     
>
> I would say that the goal for the logical model was to have a view of
> the configuration information that was easy to work with programatically.
>
> To support testing we wanted to be able to construct models easily that
> could be used to boot component containers. Although we would use that
> to test the containers themselves, the main goal was to allow users to
> test the logic in their components when some container interaction was
> required.
>
> With that in mind, I am not sure that any simple XML->Java binding
> approach is the right way to go. What we found before was that led to a
> model that mirrored the XML structure rather than the "logical"
> structure of the configuration.
>
> That is where the SDO/EMF issues crept in. To provide the model we
> wanted we needed to mix functionality into the generated code. This was
> hard to maintain so we attempted to factor it out into subclasses; that
> didn't really work which is why we ended up with a separate physical
> model. I think SDO/EMF is a perception victim here - I think we would
> have had the same issues with XMLBeans, JAXB or any other binding framework.
>
> If SDO could de-serialize directly into our logical model then that
> would be a simple option to use. However, if the price we need to pay to
> achieve that is a heavily annotated XML schema or a custom code
> generator I think we are back to where we are now.
>
> Finally, I want to be clear I don't think this is an SDO problem, I
> think it is an issue we have because the model does not map directly to
> XML and that we would have this problem with any technology - I have
> certainly seen the same issue in projects that used XMLBeans and Castor.
>
> We could enhance SDO to handle this mapping better (e.g. through a more
> sophisticated code generator). I think we would be better served though
> to direct that energy into improving the SDO-centric features of our
> implementation rather than doing something special for Tuscany's loading
> problem.
>
> One alternative we have is to make the logical model directly map to the
> XML. At one point we were there, but we moved away from that to simplify
> testing. I think that is the right strategic choice as it makes testing
> easier for our users - the price we pay for their convenience is a more
> complex configuration loader.
>
> --
> Jeremy
>
>   
The logical model is actually pretty close to the model generated from 
the XMLSchema. If you take the model generated from the schema and add a 
few derived /calculated relationships and derived attributes you get a 
reasonable logical model for the runtime configuration.

We had this for some time - and contrary to what you're saying here 
Jeremy - it worked. The issue at the time (and it's still an issue now 
but Frank is working on fixing that) was that the generated model had 
dependencies on EMF and some of the EMF aspects were shining through the 
model. This made using this model and in particular writing test cases 
difficult for people without EMF expertise. To workaround this problem 
and shield people in the group from the EMFness of the generated model, 
we created two separate hierarchies, a POJO based model (with no 
dependencies on EMF or SDO), and a generated model (and obviously we had 
to write the code to transform one into the other).

When we get from Frank a code generator that generates EMF-less model 
classes then I think we'll be able to get back to what we had a few 
weeks ago, which again worked...
- a generated model - always in line with the schema, without the burden 
of writing, debugging and maintaining the parsing code
- derived logical relationships and attributes (when necessary) in 
subclasses
- but this logical model will be a POJO model similar to what we have 
now without any EMF dependencies.

When we get there, most component implementation types and binding types 
should actually be able to work with just the generated model classes, 
without writing any code at all (no loader, no parser).

I'll reiterate what I said before, I think that the right strategy here 
is to use our databinding technology, and through that exercise help 
make it better.

-- 

Jean-Sebastien

Re: Framework for StAX-based model loading

[Jeremy Boynes <jb...@apache.org>]

Frank Budinsky wrote:
> Now back to the issue of whether or not to use SDO for the SCDL model. 
> Personally, I think that the main issue Jeremy is bringing up is that the 
> way SDO is currently being used for a Java binding of the physical model, 
> which then needs to be transformed into a different logical model, really 
> makes one question its value. You need to write similar code to create the 
> logical model, whether it's by reading from StAX or from the generated 
> physical model API. The generated API is a little nicer, but hardly enough 
> to warrant the added layer/complexity. I think I agree with that.
> 
> But, if I step back, I really question the need for two models in the 
> first place. If I understand the history of this, the goal was to have a 
> logical model to hide the physical model, and specifically, the EMF 
> complexity it contained. If that's true, and given my comments above about 
> the EMF-less code that we're planning to generate, I would think that the 
> right end goal is to unifying the logical model with the generated model, 
> instead of eliminating it and writing all the model building code by hand.
> 
> I think that we really should use the Tuscany code generator. It is 
> important that it be a competitive Java binding technology (as good or 
> better then JAXB, etc.), so what better way to make that happen then to 
> use it ourselves. The SDO spec is pretty vague on what an SDO generator 
> actually generates (other than the fact that the interfaces are 
> bean-like), so we have a lot of opportunity to provide options, etc., to 
> make it do exactly what we want.
> 
> That's my admittedly biased 2 cents worth :-)
> 

I would say that the goal for the logical model was to have a view of
the configuration information that was easy to work with programatically.

To support testing we wanted to be able to construct models easily that
could be used to boot component containers. Although we would use that
to test the containers themselves, the main goal was to allow users to
test the logic in their components when some container interaction was
required.

With that in mind, I am not sure that any simple XML->Java binding
approach is the right way to go. What we found before was that led to a
model that mirrored the XML structure rather than the "logical"
structure of the configuration.

That is where the SDO/EMF issues crept in. To provide the model we
wanted we needed to mix functionality into the generated code. This was
hard to maintain so we attempted to factor it out into subclasses; that
didn't really work which is why we ended up with a separate physical
model. I think SDO/EMF is a perception victim here - I think we would
have had the same issues with XMLBeans, JAXB or any other binding framework.

If SDO could de-serialize directly into our logical model then that
would be a simple option to use. However, if the price we need to pay to
achieve that is a heavily annotated XML schema or a custom code
generator I think we are back to where we are now.

Finally, I want to be clear I don't think this is an SDO problem, I
think it is an issue we have because the model does not map directly to
XML and that we would have this problem with any technology - I have
certainly seen the same issue in projects that used XMLBeans and Castor.

We could enhance SDO to handle this mapping better (e.g. through a more
sophisticated code generator). I think we would be better served though
to direct that energy into improving the SDO-centric features of our
implementation rather than doing something special for Tuscany's loading
problem.

One alternative we have is to make the logical model directly map to the
XML. At one point we were there, but we moved away from that to simplify
testing. I think that is the right strategic choice as it makes testing
easier for our users - the price we pay for their convenience is a more
complex configuration loader.

--
Jeremy

Re: Framework for StAX-based model loading

[Frank Budinsky <fr...@ca.ibm.com>]

Yes, you've got it right Jim. One thing that we did overlook, in terms of 
priority, was that generated classes can't use any EMF features, even in 
their impls. We initially put together a generator that generates EMF-less 
interfaces, but had EMF things in the implementation classes. That solves 
the problem of hiding EMF from clients, but we overlooked the fact that 
the generated classes are in the client's jar, so the client still needs 
direct access to EMF :-)

One of the things that we had planned to do as a longer term exercise was 
to decouple the generated classes from EMF, but now I've bumped it up to 
my personal #1 work item. I hope to get an initial version of this working 
in the next 2 to 3 weeks.

Now back to the issue of whether or not to use SDO for the SCDL model. 
Personally, I think that the main issue Jeremy is bringing up is that the 
way SDO is currently being used for a Java binding of the physical model, 
which then needs to be transformed into a different logical model, really 
makes one question its value. You need to write similar code to create the 
logical model, whether it's by reading from StAX or from the generated 
physical model API. The generated API is a little nicer, but hardly enough 
to warrant the added layer/complexity. I think I agree with that.

But, if I step back, I really question the need for two models in the 
first place. If I understand the history of this, the goal was to have a 
logical model to hide the physical model, and specifically, the EMF 
complexity it contained. If that's true, and given my comments above about 
the EMF-less code that we're planning to generate, I would think that the 
right end goal is to unifying the logical model with the generated model, 
instead of eliminating it and writing all the model building code by hand.

I think that we really should use the Tuscany code generator. It is 
important that it be a competitive Java binding technology (as good or 
better then JAXB, etc.), so what better way to make that happen then to 
use it ourselves. The SDO spec is pretty vague on what an SDO generator 
actually generates (other than the fact that the interfaces are 
bean-like), so we have a lot of opportunity to provide options, etc., to 
make it do exactly what we want.

That's my admittedly biased 2 cents worth :-)

Thanks,
Frank.


Jim Marino <ji...@gmail.com> wrote on 03/22/2006 02:53:53 PM:

> My recollection - Frank let me know if this is incorrect - was that 
> the SDO impl would not necessarily be "EMF-free" but that it would 
> hide implementation details. For the Java runtime, the goal was to be 
> "EMF-free" from the perspective that the runtime would not contain 
> direct dependencies on it.
> 
> Jim
> 
> 
> On Mar 22, 2006, at 1:15 AM, ant elder wrote:
> 
> > On 3/21/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > <snip/>
> >
> > We have been working to remove the dependencies on EMF
> >
> >
> > Is a goal to have an EMF free SDO impl? One of the reasons I liked 
> > this STaX
> > based approach is it makes the Tuscany core look more lightweight, but
> > removing the EMF dependency could also help there.
> >
> >    ...ant
> >
> 

Re: Framework for StAX-based model loading

[Jim Marino <ji...@gmail.com>]

My recollection - Frank let me know if this is incorrect - was that  
the SDO impl would not necessarily be "EMF-free" but that it would  
hide implementation details. For the Java runtime, the goal was to be  
"EMF-free" from the perspective that the runtime would not contain  
direct dependencies on it.

Jim


On Mar 22, 2006, at 1:15 AM, ant elder wrote:

> On 3/21/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> <snip/>
>
> We have been working to remove the dependencies on EMF
>
>
> Is a goal to have an EMF free SDO impl? One of the reasons I liked  
> this STaX
> based approach is it makes the Tuscany core look more lightweight, but
> removing the EMF dependency could also help there.
>
>    ...ant
>

Re: Framework for StAX-based model loading

[ant elder <an...@gmail.com>]

On 3/21/06, Jean-Sebastien Delfino <js...@apache.org> wrote:

<snip/>

We have been working to remove the dependencies on EMF


Is a goal to have an EMF free SDO impl? One of the reasons I liked this STaX
based approach is it makes the Tuscany core look more lightweight, but
removing the EMF dependency could also help there.

   ...ant

Re: Framework for StAX-based model loading

[Pete Robbins <ro...@googlemail.com>]

This is an interesting discussions. Not really relevant to your Java
discussion but...
in the C++ runtime we use SDO to load the contents of the scdl files to
build the logical model. Initially we kept the SDOs around in the runtime as
the model but this still required some extra classes to form the logical
model. We changed this so that now SDO is only used to load the scdl. The
reason I chose to use SDO is that I didn't have to write parser code for
each of the scdl files. Maybe StAX would prove to be as simple but loading
the scdl into a form I knew how to deal with was easy.

However the scdl is loaded there will always be a transformation from
physical to logical model as the logical model is composed from several
sources.

I guess we are just using SDO to parse the xml but it works nicely. Maybe
there could be some performance issues later. Of course, in the C++ case we
don't have your classloader problems or dragging in EMF ;-)

Re: Framework for StAX-based model loading

[Jeremy Boynes <jb...@apache.org>]

Jean-Sebastien Delfino wrote:
<snip/>
> 
> My main question remains: Is anybody volunteering to take
> responsibility for this code?
> 

Perhaps a more pertinent question is: which code do we as a community
choose to take responsibility for?

Seriously, you, I or anyone else may for many reasons be unable to
contribute to the project in the future. One of the primary goals of
incubation is to make sure there is enough diversity in the community
that the project will continue should any individual or bloc move on.

One of the implications here is that we all share responsibility for the
code. Individuals may have expertise in particular areas but the
responsibility belongs to all of us.

--
Jeremy

Re: Framework for StAX-based model loading

[Jim Marino <ji...@gmail.com>]

On Mar 21, 2006, at 7:26 PM, Jeremy Boynes wrote:

> The answer to that will depend on how the data for this will be
> represented in the XML and what binding technology you wish to use to
> deserialize it.
>
> With the StAX approach, it can be any deserialization approach that  
> can
> read a XMLStreamReader. That could be SDO (after Raymond's work),
> although as you are using a concrete class I think the SDO  
> configuration
> would be "interesting"; it could be ADB, JAXB, XMLBeans or Castor; or,
> as last resort, you could provide your own StAXElementLoader that was
> designed specifically to handle <jim:foo> elements.
>
> With the SDO approach, you could (somehow) register an XML schema with
> the SDO implementation which would result in an typed SDO being  
> created;

Is this done at development time or runtime?

> if not then the physical model would contain an ANY object. Given you
> have a class not an interface, you may also need to plug a  
> converter in
> (somehow) that could convert the SDO or the ANY into an instance of  
> your
> class (i.e. it would be "interesting").
>
So I purposely did this as a class since I think it is common for  
"data holder" types. Custom deserializers may wind up being something  
people commonly want to contribute.

> Neither approach supports complex types at the moment - StAX just
> supports String, SDO supports any simple type.

> This opens the bigger question of how do users contribute data  
> bindings
> into the runtime. I think that is worth discussing in a different  
> thread :-)
>
Yes that's another issue we need to tackle
> --
> Jeremy
>
> Jim Marino wrote:
>
>> I have an additional question. If I have a custom complex type,  
>> say  Foo
>> (:-)) what steps do I need to take to have that bound into a   
>> component
>> property for the StAX and SDO approaches e.g.:
>>
>> public class Foo{
>>
>>     private String bar;
>>
>>     public void setBar(String val){
>>         bar = val;
>>     }
>>
>>     public String getBar(){
>>         return bar;
>>     }
>>
>>     private Foo foo;
>>
>>     public void setFoo( Foo val){
>>         foo = val;
>>     }
>>
>>     public Foo getFoo(){
>>         return foo;
>>     }
>>
>> }
>>
>

Re: Framework for StAX-based model loading

[Jeremy Boynes <jb...@apache.org>]

The answer to that will depend on how the data for this will be
represented in the XML and what binding technology you wish to use to
deserialize it.

With the StAX approach, it can be any deserialization approach that can
read a XMLStreamReader. That could be SDO (after Raymond's work),
although as you are using a concrete class I think the SDO configuration
would be "interesting"; it could be ADB, JAXB, XMLBeans or Castor; or,
as last resort, you could provide your own StAXElementLoader that was
designed specifically to handle <jim:foo> elements.

With the SDO approach, you could (somehow) register an XML schema with
the SDO implementation which would result in an typed SDO being created;
if not then the physical model would contain an ANY object. Given you
have a class not an interface, you may also need to plug a converter in
(somehow) that could convert the SDO or the ANY into an instance of your
class (i.e. it would be "interesting").

Neither approach supports complex types at the moment - StAX just
supports String, SDO supports any simple type.

This opens the bigger question of how do users contribute data bindings
into the runtime. I think that is worth discussing in a different thread :-)

--
Jeremy

Jim Marino wrote:
> I have an additional question. If I have a custom complex type, say  Foo
> (:-)) what steps do I need to take to have that bound into a  component
> property for the StAX and SDO approaches e.g.:
> 
> public class Foo{
> 
>     private String bar;
> 
>     public void setBar(String val){
>         bar = val;
>     }
> 
>     public String getBar(){
>         return bar;
>     }
> 
>     private Foo foo;
> 
>     public void setFoo( Foo val){
>         foo = val;
>     }
> 
>     public Foo getFoo(){
>         return foo;
>     }
> 
> }
> 

Re: Framework for StAX-based model loading

[Jim Marino <ji...@gmail.com>]

I have an additional question. If I have a custom complex type, say  
Foo (:-)) what steps do I need to take to have that bound into a  
component property for the StAX and SDO approaches e.g.:

public class Foo{

     private String bar;

     public void setBar(String val){
         bar = val;
     }

     public String getBar(){
         return bar;
     }

     private Foo foo;

     public void setFoo( Foo val){
         foo = val;
     }

     public Foo getFoo(){
         return foo;
     }

}


Jim


On Mar 21, 2006, at 6:22 PM, Jean-Sebastien Delfino wrote:

> Frank Budinsky wrote:
>
>> I think Jeremy's point that this might  be an example of using the  
>> "wrong hammer on the screw" depends on how structured (vs. open)  
>> the physical model actually is. More generally than just whether  
>> SDO is the right approach for this particular application, I think  
>> it's a question of whether it's worth using any Java binding  
>> technology on a model that is full of open and mixed content - and  
>> even worse, the open content is not described by a schema (i.e.,  
>> lax). Whether it's SDO, JAXB, or some other XML binding  
>> technology, the programming model that results is more DOM-like  
>> then a nice static model that we'd like. In the SDO case you end  
>> up doing a lot of DOM-like access using Sequence's (accessing  
>> "mixed", "any", and "anyAttribute" properties) - hardly a clean  
>> and beautiful Java binding. I'm not sure if the threshold of where  
>> the physical model is too loosely defined to map to a clean Java  
>> binding has been crossed or not in this case, but it looks close  
>> anyway. If it wasn't, we wouldn't need a logical model.
>>
>> I think the other problems that Jeremy points out, need to get  
>> fixed anyway and SDO should be a competitive Java binding  
>> technology, as well as all the other things.
>>
>> Frank.
>>
>>
>>
>>
>> Jeremy Boynes <jb...@apache.org> 03/21/2006 02:44 PM
>> Please respond to
>> tuscany-dev
>>
>>
>> To
>> tuscany-dev@ws.apache.org
>> cc
>>
>> Subject
>> Re: Framework for StAX-based model loading
>>
>>
>>
>>
>>
>>
>> Jean-Sebastien Delfino wrote:
>>
>>
>>> 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.
>>>
>>>
>>>
>>
>> I wouldn't say "running away" (that's a little dramatic) but I do  
>> think
>> it is fair to say that we ran into problems due to the way our SDO
>> implementation couples the type system to the thread's classloader.
>>
>> The goal of SDO is not to be just another XML data binding  
>> technology,
>> its purpose is to "simplify data programming so developers can  
>> focus on
>> business logic instead of the underlying technology." It does this
>> through abstraction of that technology, by providing a data-graph
>> oriented API and capabilities like containment and change tracking.
>>
>> We are not using those capabilities. We're actually only using a tiny
>> fraction of its capabilites. I think it is reasonable to evaluate
>> whether it is the right hammer to use on this screw.
>>
>>
>>
>>>> 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.
>>>
>>>
>>>
>>
>> I would describe our problem slightly differently saying we need:
>> 1) to parse the incoming bytestream
>> 2) to use the parse results to build the logical model
>> The first of these is being handled by StAX, the second the code we
>> provide that reacts to parse events and builds the model. This seems
>> like a fairly clear separation of concerns.
>>
>> I would also break down the SDO-based solution differently:
>> 1) SDO parses the incoming bytestream
>> 2) SDO builds its physical model to represent the XML
>> 3) the SCDLModelContentHandler parses the physical model
>>    and generates a partial logical model
>> 4) linkers generated in 3) run to complete the logical model
>>
>> I think this is less separated. The implementation of
>> SCDLContentModelHandler is tightly coupled to the physical model
>> generated by SDO. The linkers are also coupled to the element  
>> handlers
>> (the caseXXXX methods) that parse each physical model object.
>>
>> I'd also point out that the implementation of the content handler for
>> the core assembly model is different from other extensions: the  
>> former
>> uses a (code-generated) case dispatcher, the others tend to use a  
>> single
>> method with manually coded instanceof tests.
>>
>>
>>
>>>> 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");
>>>
>>>
>>>
>>
>> I wouldn't have such a big issue with codegen if it generated the  
>> code
>> that we wanted. However, the codegen here is generating objects that
>> represent the physical structure of the XML rather than ones that  
>> map to
>> the logical model. This leads to the need for another parser/ 
>> transform
>> (the SCDLModelContentHandler) to convert from the physical
>> representation to the logical one.
>>
>> The result is we have both the complexity of code generation *and*  
>> the
>> complexity of a manually coded parser/transformer.
>>
>>
>>
>>>> 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.
>>>
>>>
>>>
>>
>> The point I was making here is that there are multiple  
>> implementations
>> of StAX available that can be used and that the loader is not tied to
>> one of them. This may be useful for people embedding Tuscany in other
>> environments where they have some preference over which  
>> implementation
>> should be used.
>>
>> We are already working to integrate StAX support with SDO to allow  
>> SDO's
>> to be (de)-serialized from/to StAX event streams. We are already  
>> using
>> this for better AXIOM integration in the web-services stack.
>>
>> Having a good SDO implementation is a primary objective for the  
>> project.
>> However, as I pointed out at the start, SDO is more than just an XML
>> binding technology and we need to make sure its SDO-ness excels.  
>> We also
>> need to realize that it is not the universal solution for data  
>> binding
>> and that other technologies may work better in specific scenarios. I
>> think we have one of those scenarios.
>>
>>
>>
>>>> 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 specifications. Usually the kind of approach demonstrated by  
>>> this
>>> StAX loader looks very simple and very tempting at the beginning  
>>> of the
>>> project, but ends up in a mess and maintenance nightmare in the  
>>> longer
>>> term.
>>>
>>>
>>>
>>
>> Unfortunately I think that just an aspect of this problem. I have  
>> seen
>> XML-binding based solutions used in other projects and they have also
>> proved to be very fragile even in the face of static schemas. If  
>> we had
>> a pure SDO solution I would be less concerned; my concern here is  
>> about
>> the parse/transform code that we have to maintain to convert the
>> physical to the logical model.
>>
>>
>>
>>> If we want to avoid that we need the following:
>>> - more work on this StAX loader to clearly separate the pure
>>> loading/de-serialization aspect from the physical -> logical
>>> transformation aspects, if you mix the two aspects it will be a  
>>> recipe
>>> for disaster after a year of maintenance adjusting to changes in  
>>> the XML
>>>
>>>
>>
>> See above - I think the same applies to the SCDLModelContentHandler
>>
>>
>>
>>> - define intermediate data structures (close to the physical  
>>> model) to
>>> avoid polluting the logical model with XML specific info (I'm  
>>> thinking
>>> of all the cases where we're going to have to store  
>>> intermedaite / half
>>> loaded data and complete/resolve things in a second pass,  
>>> properties and
>>> wires are two examples that come to mind); if we don't do that  
>>> and start
>>> adding stuff to the logical model to facilitate the loading phase we
>>> will make a mess of the logical model
>>>
>>>
>>
>> I don't think we have needed to populate the logical model with  
>> physical
>> artifacts. I did make some changes to support the StAX loader such as
>> storing reference targets as pointers rather than using a Reference
>> object directly. I would contend that is a normalization that better
>> represents the logical model - it certainly cut out a couple of bugs
>> that were the result of inconsistent updates to the denormalized  
>> References.
>>
>>
>>
>>> - make the StAX loader approach more complete before we jump to  
>>> switch
>>> to it, to really understand the impact, for example  the StAX  
>>> loaders do
>>> not handle subsystems or property types at the moment, I think  
>>> that the
>>> support for properties in particular is going to be interesting  
>>> and will
>>> generate some work to integrate between StAX and SDO if we want to
>>> support SDO properties.
>>>
>>>
>>
>> Given subsystems are changing and not really supported yet by the
>> runtime this does not seem like a major issue. In fact, looking at  
>> the
>> how subsystems are handled in the SCDLModelContentHandler, adding  
>> StAX
>> loader support form them would be trivial. How about you have a go at
>> doing it and see how hard/easy adding things to the StAX framework
>> actually is?
>>
>> For properties, I don't think either solution is fully fleshed out  
>> yet
>> so using that as a basis for comparison is a little unfair. For  
>> example,
>> I would ask how user-defined types are loaded into the SDO type  
>> system,
>> or how non-SDO property type support would be added (e.g. to load
>> properties as JAXB objects)?
>>
>> With the StAX solution we have the advantage that by using a standard
>> technology it will be easier to add in other binding frameworks.  
>> We are
>> already working on a StAX->SDO deserializer that would give us a
>> solution when the user was using an SDO; further JAXB, XMLBeans  
>> and (I
>> believe) Castor all support StAX sources so it should be trival to
>> integrate those.
>>
>>
>>
>>> - come up with brand new solution for serializing/saving models,  
>>> I am
>>> sure we will run into use cases where we want to save an  
>>> assembly, a set
>>> of wires, a module component configuration etc; StAX only handles  
>>> the
>>> loading part, so if we're not using SDO here again we'll have to  
>>> invent
>>> something else to handle serialization/saving of the models...
>>>
>>>
>>>
>>
>> We need to do that anyway. If the logical model was an SDO then we  
>> could
>> just write it out, but it isn't. We would need to develop and  
>> maintain a
>> serializer equivalent to the SCDLModelContentHandler and that is  
>> likely
>> to be just as much manual code to maintain as a StAX serializer.
>>
>>
>>
>>> My main concern is about the complexity of maintaining all this  
>>> code.
>>> Just the (incomplete) support for the core SCDL is already about 750
>>> lines of code, mixing parsing logic and mapping/construction of the
>>> logical model, using dynamic APIs like reader.getAttribute(null,  
>>> "name")
>>> compared to the 550 lines of model transformation code using  
>>> strongly
>>> typed APIs generated from the SCDL XSD in the  
>>> SCDLModelContentHandler
>>> (with more complete support for the core SCDL). I anticipate many
>>> changes in the SCDL XSD and the logical model during the course  
>>> of this
>>> year, the StAX based loader approach may look appealing now at the
>>> beginning of the project, but we will only succeed with it if we  
>>> have
>>> committed contributors and committers ready to maintain this  
>>> code, make
>>> it complete, and adjust it each time we change the SCDL XSD (and  
>>> it's
>>> going to be pretty painful, compared to just rebuild to regen the  
>>> code
>>> from XSD and adjust the transformer where it's broken by the  
>>> changes).
>>>
>>>
>>>
>>
>> I think the "adjust the transformer" part here is the key phrase.  
>> This
>> is going to be just as much work as maintaining any StAX handler (as
>> they are essentially doing the same thing).
>>
>> If you're going to compare lines of code, the honest metric here  
>> would
>> be to compare the number of lines related to parsing and  
>> transformation
>> and to exclude the code used to create the logical model. But  
>> lines of
>> code alone are not the only metric; when I compare blocks out of
>> SCDLModelContentHandlerImpl with the StAX equivalent the latter seems
>> less complex (at least to me).
>>
>> For example, the <service> code in SCDLModelContentHanlderImpl is:
>>
>>     public Object caseService(Service object) {
>>         final org.apache.tuscany.model.assembly.Service
>> service=factory.createService();
>>         service.setName(object.getName());
>>
>>         linkers.add(new Runnable() {
>>             public void run() {
>>                 currentComponentType.getServices().add(service);
>>             };
>>         });
>>
>>         currentService=service;
>>         return service;
>>     }
>>
>> and for the contained <interface.java>
>>
>>     public Object caseJavaInterface(JavaInterface object) {
>>         final JavaServiceContract
>> serviceContract=factory.createJavaServiceContract();
>>         serviceContract.setScope(Scope.INSTANCE);
>>
>>         serviceContract.setInterfaceName(object.getInterface());
>>
>> serviceContract.setCallbackInterfaceName 
>> (object.getCallbackInterface());
>>
>>         linkServiceContract(object, serviceContract);
>>
>>         return serviceContract;
>>     }
>>
>> and
>>
>>     private void linkServiceContract(Object object, final
>> ServiceContract serviceContract) {
>>         Object container=((DataObject)object).getContainer();
>>         if (container instanceof Service) {
>>
>>             // Set a service contract on a service
>>             final org.apache.tuscany.model.assembly.Service
>> service=currentService;
>>             linkers.add(new Runnable() {
>>                 public void run() {
>>                     service.setServiceContract(serviceContract);
>>                 }
>>             });
>>         }
>>         else if (container instanceof Reference) {
>>
>>             // Set a service contract on a reference
>>             final org.apache.tuscany.model.assembly.Reference
>> reference=currentReference;
>>             linkers.add(new Runnable() {
>>                 public void run() {
>>                     reference.setServiceContract(serviceContract);
>>                 }
>>             });
>>         } else if (container instanceof ExternalService) {
>>
>>             // Set a service contract on an external service
>>             final org.apache.tuscany.model.assembly.ExternalService
>> externalService=currentExternalService;
>>             linkers.add(new Runnable() {
>>                 public void run() {
>>
>> externalService.getConfiguredService().getService 
>> ().setServiceContract(serviceContract);
>>                 }
>>             });
>>         } else if (container instanceof EntryPoint) {
>>
>>             // Set a service contract on an entry point
>>             final org.apache.tuscany.model.assembly.EntryPoint
>> entryPoint=currentEntryPoint;
>>             linkers.add(new Runnable() {
>>                 public void run() {
>>
>> entryPoint.getConfiguredService().getService().setServiceContract 
>> (serviceContract);
>>
>> entryPoint.getConfiguredReference().getReference 
>> ().setServiceContract(serviceContract);
>>                 }
>>             });
>>         }
>>     }
>>
>> whereas in the StAX framework the <service> handler is:
>>
>>     public Service load(XMLStreamReader reader, ResourceLoader
>> resourceLoader) throws XMLStreamException,  
>> ConfigurationLoadException {
>>         assert SERVICE.equals(reader.getName());
>>         Service service = factory.createService();
>>         service.setName(reader.getAttributeValue(null, "name"));
>>
>>         while (true) {
>>             switch (reader.next()) {
>>             case START_ELEMENT:
>>                 AssemblyModelObject o = registry.load(reader,
>> resourceLoader);
>>                 if (o instanceof ServiceContract) {
>>                     service.setServiceContract((ServiceContract) o);
>>                 }
>>                 reader.next();
>>                 break;
>>             case END_ELEMENT:
>>                 return service;
>>             }
>>         }
>>     }
>>
>> and the <interface.java> handler is
>>
>>     public JavaServiceContract load(XMLStreamReader reader,
>> ResourceLoader resourceLoader) throws XMLStreamException,
>> ConfigurationLoadException {
>>         assert AssemblyConstants.INTERFACE_JAVA.equals 
>> (reader.getName());
>>         JavaServiceContract serviceContract =
>> factory.createJavaServiceContract();
>>         serviceContract.setScope(Scope.INSTANCE);
>>         serviceContract.setInterfaceName(reader.getAttributeValue 
>> (null,
>> "interface"));
>>
>> serviceContract.setCallbackInterfaceName(reader.getAttributeValue 
>> (null,
>> "callbackInterface"));
>>         return serviceContract;
>>     }
>>
>>
>>
>>> I am not completely opposed to a StAX based loader approach. I  
>>> can even
>>> see some benefits:
>>> - smaller code and memory footprint compared to a solution based on
>>> generated code
>>> - faster loading (I'm actually not sure how much we'll gain on  
>>> typical
>>> SCA module file, but I'm guessing that it'll be faster)
>>> - and more important IMO... more flexible parsing (for example we  
>>> could
>>> relax a little the requirement for some of the namespaces to be
>>> specified in SCDL, this could help simplify SCDL files a little)
>>>
>>> But I'm concerned that we're going to have to spent a lot of  
>>> energy to
>>> make it really work well in the long term (energy which could be  
>>> spent
>>> on many other aspects we need to cover in Tuscany). Basically I  
>>> will be
>>> OK with this StAX loader approach only if we have enough people  
>>> in the
>>> group really volunteering to take responsiblity for it, maintain  
>>> it, and
>>> adjust it to all the upcoming changes to the XSD or the logical  
>>> model.
>>> People just need to think about it and realize that it's going to  
>>> be a
>>> lot of work.
>>>
>>>
>>>
>>
>> I think we need to take responsibility for whichever option we  
>> choose.
>> Maintaining the loading code in the face of an evolving spec is  
>> going to
>> require work from all of us. The choice here comes down to what  
>> are we
>> willing to look after:
>>
>> A) an SDO model, code generation, a SCDLContentModelHandler and its
>>    linker blocks, a set of SCDLModelLoader impls,
>>    and Thread classloader management code, or
>>
>> B) a set of StAXElementLoader's
>>
>> As I said at the start, I wasn't even looking at this until we ran  
>> into
>> the Thread classloader problems during the Tomcat integration. I  
>> still
>> don't think we have resolved all of them and think we are going to  
>> run
>> into a new set of challenges with other property binding frameworks.
>>
>> I would like to put this to rest soon. Both versions are out there  
>> for
>> folk to look at and they are both complete enough to run our current
>> examples.
>>
>> I think the StAX version is simpler yet just as flexible, avoids  
>> some of
>> the problems seen to date, and provides an easy integration path with
>> other frameworks (including SDO) and unless there is a strong  
>> technical
>> argument against I'd like to switch over.
>>
>> --
>> Jeremy
>>
>>
>>
>>
>>
> The SCDL schemas are there: http://svn.apache.org/repos/asf/ 
> incubator/tuscany/java/spec/sca/src/main/resources/schemas. Most of  
> the base elements have an xsd:any or anyAttribute in addition to  
> their structured content. This is typical when you define a  
> language like SCDL to allow for extensions of the language without  
> making changes to the base schema. Besides that, SCDL looks pretty  
> structured to me.
>
> I think that the (A) vs (B) comparison above is unfair. We don't  
> need to maintain an SDO model, it is generated from the SCDL XSDs,  
> we are not adding maintenance requirements on the code generation,  
> it is already part of the SDO sub-project, and I don't think that  
> the classloader related issues are relevant here (again the  
> classloader issues we ran into were caused by different libraries  
> having different requirements on the "current" classloader, this  
> will need to be fixed in SDO but is not only an SDO issue).
>
> I am not convinced at all that the StAXElementLoaders are going to  
> remain as simple and flexible as Jeremy thinks. My main question  
> remains: Is anybody volunteering to take responsibility for this code?
>
> -- 
> Jean-Sebastien
>
>

Re: Framework for StAX-based model loading

[Jean-Sebastien Delfino <js...@apache.org>]

Frank Budinsky wrote:
> I think Jeremy's point that this might  be an example of using the "wrong 
> hammer on the screw" depends on how structured (vs. open) the physical 
> model actually is. More generally than just whether SDO is the right 
> approach for this particular application, I think it's a question of 
> whether it's worth using any Java binding technology on a model that is 
> full of open and mixed content - and even worse, the open content is not 
> described by a schema (i.e., lax). Whether it's SDO, JAXB, or some other 
> XML binding technology, the programming model that results is more 
> DOM-like then a nice static model that we'd like. In the SDO case you end 
> up doing a lot of DOM-like access using Sequence's (accessing "mixed", 
> "any", and "anyAttribute" properties) - hardly a clean and beautiful Java 
> binding. I'm not sure if the threshold of where the physical model is too 
> loosely defined to map to a clean Java binding has been crossed or not in 
> this case, but it looks close anyway. If it wasn't, we wouldn't need a 
> logical model.
>
> I think the other problems that Jeremy points out, need to get fixed 
> anyway and SDO should be a competitive Java binding technology, as well as 
> all the other things.
>
> Frank.
>
>
>
>
> Jeremy Boynes <jb...@apache.org> 
> 03/21/2006 02:44 PM
> Please respond to
> tuscany-dev
>
>
> To
> tuscany-dev@ws.apache.org
> cc
>
> Subject
> Re: Framework for StAX-based model loading
>
>
>
>
>
>
> Jean-Sebastien Delfino wrote:
>   
>> 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.
>>
>>     
>
> I wouldn't say "running away" (that's a little dramatic) but I do think
> it is fair to say that we ran into problems due to the way our SDO
> implementation couples the type system to the thread's classloader.
>
> The goal of SDO is not to be just another XML data binding technology,
> its purpose is to "simplify data programming so developers can focus on
> business logic instead of the underlying technology." It does this
> through abstraction of that technology, by providing a data-graph
> oriented API and capabilities like containment and change tracking.
>
> We are not using those capabilities. We're actually only using a tiny
> fraction of its capabilites. I think it is reasonable to evaluate
> whether it is the right hammer to use on this screw.
>
>   
>>> 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.
>>
>>     
>
> I would describe our problem slightly differently saying we need:
> 1) to parse the incoming bytestream
> 2) to use the parse results to build the logical model
> The first of these is being handled by StAX, the second the code we
> provide that reacts to parse events and builds the model. This seems
> like a fairly clear separation of concerns.
>
> I would also break down the SDO-based solution differently:
> 1) SDO parses the incoming bytestream
> 2) SDO builds its physical model to represent the XML
> 3) the SCDLModelContentHandler parses the physical model
>    and generates a partial logical model
> 4) linkers generated in 3) run to complete the logical model
>
> I think this is less separated. The implementation of
> SCDLContentModelHandler is tightly coupled to the physical model
> generated by SDO. The linkers are also coupled to the element handlers
> (the caseXXXX methods) that parse each physical model object.
>
> I'd also point out that the implementation of the content handler for
> the core assembly model is different from other extensions: the former
> uses a (code-generated) case dispatcher, the others tend to use a single
> method with manually coded instanceof tests.
>
>   
>>> 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");
>>
>>     
>
> I wouldn't have such a big issue with codegen if it generated the code
> that we wanted. However, the codegen here is generating objects that
> represent the physical structure of the XML rather than ones that map to
> the logical model. This leads to the need for another parser/transform
> (the SCDLModelContentHandler) to convert from the physical
> representation to the logical one.
>
> The result is we have both the complexity of code generation *and* the
> complexity of a manually coded parser/transformer.
>
>   
>>> 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.
>>
>>     
>
> The point I was making here is that there are multiple implementations
> of StAX available that can be used and that the loader is not tied to
> one of them. This may be useful for people embedding Tuscany in other
> environments where they have some preference over which implementation
> should be used.
>
> We are already working to integrate StAX support with SDO to allow SDO's
> to be (de)-serialized from/to StAX event streams. We are already using
> this for better AXIOM integration in the web-services stack.
>
> Having a good SDO implementation is a primary objective for the project.
> However, as I pointed out at the start, SDO is more than just an XML
> binding technology and we need to make sure its SDO-ness excels. We also
> need to realize that it is not the universal solution for data binding
> and that other technologies may work better in specific scenarios. I
> think we have one of those scenarios.
>
>   
>>> 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 specifications. Usually the kind of approach demonstrated by this
>> StAX loader looks very simple and very tempting at the beginning of the
>> project, but ends up in a mess and maintenance nightmare in the longer
>> term.
>>
>>     
>
> Unfortunately I think that just an aspect of this problem. I have seen
> XML-binding based solutions used in other projects and they have also
> proved to be very fragile even in the face of static schemas. If we had
> a pure SDO solution I would be less concerned; my concern here is about
> the parse/transform code that we have to maintain to convert the
> physical to the logical model.
>
>   
>> If we want to avoid that we need the following:
>> - more work on this StAX loader to clearly separate the pure
>> loading/de-serialization aspect from the physical -> logical
>> transformation aspects, if you mix the two aspects it will be a recipe
>> for disaster after a year of maintenance adjusting to changes in the XML
>>     
>
> See above - I think the same applies to the SCDLModelContentHandler
>
>   
>> - define intermediate data structures (close to the physical model) to
>> avoid polluting the logical model with XML specific info (I'm thinking
>> of all the cases where we're going to have to store intermedaite / half
>> loaded data and complete/resolve things in a second pass, properties and
>> wires are two examples that come to mind); if we don't do that and start
>> adding stuff to the logical model to facilitate the loading phase we
>> will make a mess of the logical model
>>     
>
> I don't think we have needed to populate the logical model with physical
> artifacts. I did make some changes to support the StAX loader such as
> storing reference targets as pointers rather than using a Reference
> object directly. I would contend that is a normalization that better
> represents the logical model - it certainly cut out a couple of bugs
> that were the result of inconsistent updates to the denormalized 
> References.
>
>   
>> - make the StAX loader approach more complete before we jump to switch
>> to it, to really understand the impact, for example  the StAX loaders do
>> not handle subsystems or property types at the moment, I think that the
>> support for properties in particular is going to be interesting and will
>> generate some work to integrate between StAX and SDO if we want to
>> support SDO properties.
>>     
>
> Given subsystems are changing and not really supported yet by the
> runtime this does not seem like a major issue. In fact, looking at the
> how subsystems are handled in the SCDLModelContentHandler, adding StAX
> loader support form them would be trivial. How about you have a go at
> doing it and see how hard/easy adding things to the StAX framework
> actually is?
>
> For properties, I don't think either solution is fully fleshed out yet
> so using that as a basis for comparison is a little unfair. For example,
> I would ask how user-defined types are loaded into the SDO type system,
> or how non-SDO property type support would be added (e.g. to load
> properties as JAXB objects)?
>
> With the StAX solution we have the advantage that by using a standard
> technology it will be easier to add in other binding frameworks. We are
> already working on a StAX->SDO deserializer that would give us a
> solution when the user was using an SDO; further JAXB, XMLBeans and (I
> believe) Castor all support StAX sources so it should be trival to
> integrate those.
>
>   
>> - come up with brand new solution for serializing/saving models, I am
>> sure we will run into use cases where we want to save an assembly, a set
>> of wires, a module component configuration etc; StAX only handles the
>> loading part, so if we're not using SDO here again we'll have to invent
>> something else to handle serialization/saving of the models...
>>
>>     
>
> We need to do that anyway. If the logical model was an SDO then we could
> just write it out, but it isn't. We would need to develop and maintain a
> serializer equivalent to the SCDLModelContentHandler and that is likely
> to be just as much manual code to maintain as a StAX serializer.
>
>   
>> My main concern is about the complexity of maintaining all this code.
>> Just the (incomplete) support for the core SCDL is already about 750
>> lines of code, mixing parsing logic and mapping/construction of the
>> logical model, using dynamic APIs like reader.getAttribute(null, "name")
>> compared to the 550 lines of model transformation code using strongly
>> typed APIs generated from the SCDL XSD in the SCDLModelContentHandler
>> (with more complete support for the core SCDL). I anticipate many
>> changes in the SCDL XSD and the logical model during the course of this
>> year, the StAX based loader approach may look appealing now at the
>> beginning of the project, but we will only succeed with it if we have
>> committed contributors and committers ready to maintain this code, make
>> it complete, and adjust it each time we change the SCDL XSD (and it's
>> going to be pretty painful, compared to just rebuild to regen the code
>> from XSD and adjust the transformer where it's broken by the changes).
>>
>>     
>
> I think the "adjust the transformer" part here is the key phrase. This
> is going to be just as much work as maintaining any StAX handler (as
> they are essentially doing the same thing).
>
> If you're going to compare lines of code, the honest metric here would
> be to compare the number of lines related to parsing and transformation
> and to exclude the code used to create the logical model. But lines of
> code alone are not the only metric; when I compare blocks out of
> SCDLModelContentHandlerImpl with the StAX equivalent the latter seems
> less complex (at least to me).
>
> For example, the <service> code in SCDLModelContentHanlderImpl is:
>
>     public Object caseService(Service object) {
>         final org.apache.tuscany.model.assembly.Service
> service=factory.createService();
>         service.setName(object.getName());
>
>         linkers.add(new Runnable() {
>             public void run() {
>                 currentComponentType.getServices().add(service);
>             };
>         });
>
>         currentService=service;
>         return service;
>     }
>
> and for the contained <interface.java>
>
>     public Object caseJavaInterface(JavaInterface object) {
>         final JavaServiceContract
> serviceContract=factory.createJavaServiceContract();
>         serviceContract.setScope(Scope.INSTANCE);
>
>         serviceContract.setInterfaceName(object.getInterface());
>
> serviceContract.setCallbackInterfaceName(object.getCallbackInterface());
>
>         linkServiceContract(object, serviceContract);
>
>         return serviceContract;
>     }
>
> and
>
>     private void linkServiceContract(Object object, final
> ServiceContract serviceContract) {
>         Object container=((DataObject)object).getContainer();
>         if (container instanceof Service) {
>
>             // Set a service contract on a service
>             final org.apache.tuscany.model.assembly.Service
> service=currentService;
>             linkers.add(new Runnable() {
>                 public void run() {
>                     service.setServiceContract(serviceContract);
>                 }
>             });
>         }
>         else if (container instanceof Reference) {
>
>             // Set a service contract on a reference
>             final org.apache.tuscany.model.assembly.Reference
> reference=currentReference;
>             linkers.add(new Runnable() {
>                 public void run() {
>                     reference.setServiceContract(serviceContract);
>                 }
>             });
>         } else if (container instanceof ExternalService) {
>
>             // Set a service contract on an external service
>             final org.apache.tuscany.model.assembly.ExternalService
> externalService=currentExternalService;
>             linkers.add(new Runnable() {
>                 public void run() {
>
> externalService.getConfiguredService().getService().setServiceContract(serviceContract);
>                 }
>             });
>         } else if (container instanceof EntryPoint) {
>
>             // Set a service contract on an entry point
>             final org.apache.tuscany.model.assembly.EntryPoint
> entryPoint=currentEntryPoint;
>             linkers.add(new Runnable() {
>                 public void run() {
>
> entryPoint.getConfiguredService().getService().setServiceContract(serviceContract);
>
> entryPoint.getConfiguredReference().getReference().setServiceContract(serviceContract);
>                 }
>             });
>         }
>     }
>
> whereas in the StAX framework the <service> handler is:
>
>     public Service load(XMLStreamReader reader, ResourceLoader
> resourceLoader) throws XMLStreamException, ConfigurationLoadException {
>         assert SERVICE.equals(reader.getName());
>         Service service = factory.createService();
>         service.setName(reader.getAttributeValue(null, "name"));
>
>         while (true) {
>             switch (reader.next()) {
>             case START_ELEMENT:
>                 AssemblyModelObject o = registry.load(reader,
> resourceLoader);
>                 if (o instanceof ServiceContract) {
>                     service.setServiceContract((ServiceContract) o);
>                 }
>                 reader.next();
>                 break;
>             case END_ELEMENT:
>                 return service;
>             }
>         }
>     }
>
> and the <interface.java> handler is
>
>     public JavaServiceContract load(XMLStreamReader reader,
> ResourceLoader resourceLoader) throws XMLStreamException,
> ConfigurationLoadException {
>         assert AssemblyConstants.INTERFACE_JAVA.equals(reader.getName());
>         JavaServiceContract serviceContract =
> factory.createJavaServiceContract();
>         serviceContract.setScope(Scope.INSTANCE);
>         serviceContract.setInterfaceName(reader.getAttributeValue(null,
> "interface"));
>
> serviceContract.setCallbackInterfaceName(reader.getAttributeValue(null,
> "callbackInterface"));
>         return serviceContract;
>     }
>
>   
>> I am not completely opposed to a StAX based loader approach. I can even
>> see some benefits:
>> - smaller code and memory footprint compared to a solution based on
>> generated code
>> - faster loading (I'm actually not sure how much we'll gain on typical
>> SCA module file, but I'm guessing that it'll be faster)
>> - and more important IMO... more flexible parsing (for example we could
>> relax a little the requirement for some of the namespaces to be
>> specified in SCDL, this could help simplify SCDL files a little)
>>
>> But I'm concerned that we're going to have to spent a lot of energy to
>> make it really work well in the long term (energy which could be spent
>> on many other aspects we need to cover in Tuscany). Basically I will be
>> OK with this StAX loader approach only if we have enough people in the
>> group really volunteering to take responsiblity for it, maintain it, and
>> adjust it to all the upcoming changes to the XSD or the logical model.
>> People just need to think about it and realize that it's going to be a
>> lot of work.
>>
>>     
>
> I think we need to take responsibility for whichever option we choose.
> Maintaining the loading code in the face of an evolving spec is going to
> require work from all of us. The choice here comes down to what are we
> willing to look after:
>
> A) an SDO model, code generation, a SCDLContentModelHandler and its
>    linker blocks, a set of SCDLModelLoader impls,
>    and Thread classloader management code, or
>
> B) a set of StAXElementLoader's
>
> As I said at the start, I wasn't even looking at this until we ran into
> the Thread classloader problems during the Tomcat integration. I still
> don't think we have resolved all of them and think we are going to run
> into a new set of challenges with other property binding frameworks.
>
> I would like to put this to rest soon. Both versions are out there for
> folk to look at and they are both complete enough to run our current
> examples.
>
> I think the StAX version is simpler yet just as flexible, avoids some of
> the problems seen to date, and provides an easy integration path with
> other frameworks (including SDO) and unless there is a strong technical
> argument against I'd like to switch over.
>
> --
> Jeremy
>
>
>
>   
The SCDL schemas are there: 
http://svn.apache.org/repos/asf/incubator/tuscany/java/spec/sca/src/main/resources/schemas. 
Most of the base elements have an xsd:any or anyAttribute in addition to 
their structured content. This is typical when you define a language 
like SCDL to allow for extensions of the language without making changes 
to the base schema. Besides that, SCDL looks pretty structured to me.

I think that the (A) vs (B) comparison above is unfair. We don't need to 
maintain an SDO model, it is generated from the SCDL XSDs, we are not 
adding maintenance requirements on the code generation, it is already 
part of the SDO sub-project, and I don't think that the classloader 
related issues are relevant here (again the classloader issues we ran 
into were caused by different libraries having different requirements on 
the "current" classloader, this will need to be fixed in SDO but is not 
only an SDO issue).

I am not convinced at all that the StAXElementLoaders are going to 
remain as simple and flexible as Jeremy thinks. My main question 
remains: Is anybody volunteering to take responsibility for this code?

-- 
Jean-Sebastien

Re: Framework for StAX-based model loading

[Frank Budinsky <fr...@ca.ibm.com>]

I think Jeremy's point that this might  be an example of using the "wrong 
hammer on the screw" depends on how structured (vs. open) the physical 
model actually is. More generally than just whether SDO is the right 
approach for this particular application, I think it's a question of 
whether it's worth using any Java binding technology on a model that is 
full of open and mixed content - and even worse, the open content is not 
described by a schema (i.e., lax). Whether it's SDO, JAXB, or some other 
XML binding technology, the programming model that results is more 
DOM-like then a nice static model that we'd like. In the SDO case you end 
up doing a lot of DOM-like access using Sequence's (accessing "mixed", 
"any", and "anyAttribute" properties) - hardly a clean and beautiful Java 
binding. I'm not sure if the threshold of where the physical model is too 
loosely defined to map to a clean Java binding has been crossed or not in 
this case, but it looks close anyway. If it wasn't, we wouldn't need a 
logical model.

I think the other problems that Jeremy points out, need to get fixed 
anyway and SDO should be a competitive Java binding technology, as well as 
all the other things.

Frank.




Jeremy Boynes <jb...@apache.org> 
03/21/2006 02:44 PM
Please respond to
tuscany-dev


To
tuscany-dev@ws.apache.org
cc

Subject
Re: Framework for StAX-based model loading






Jean-Sebastien Delfino wrote:
> 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.
> 

I wouldn't say "running away" (that's a little dramatic) but I do think
it is fair to say that we ran into problems due to the way our SDO
implementation couples the type system to the thread's classloader.

The goal of SDO is not to be just another XML data binding technology,
its purpose is to "simplify data programming so developers can focus on
business logic instead of the underlying technology." It does this
through abstraction of that technology, by providing a data-graph
oriented API and capabilities like containment and change tracking.

We are not using those capabilities. We're actually only using a tiny
fraction of its capabilites. I think it is reasonable to evaluate
whether it is the right hammer to use on this screw.

>> 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.
> 

I would describe our problem slightly differently saying we need:
1) to parse the incoming bytestream
2) to use the parse results to build the logical model
The first of these is being handled by StAX, the second the code we
provide that reacts to parse events and builds the model. This seems
like a fairly clear separation of concerns.

I would also break down the SDO-based solution differently:
1) SDO parses the incoming bytestream
2) SDO builds its physical model to represent the XML
3) the SCDLModelContentHandler parses the physical model
   and generates a partial logical model
4) linkers generated in 3) run to complete the logical model

I think this is less separated. The implementation of
SCDLContentModelHandler is tightly coupled to the physical model
generated by SDO. The linkers are also coupled to the element handlers
(the caseXXXX methods) that parse each physical model object.

I'd also point out that the implementation of the content handler for
the core assembly model is different from other extensions: the former
uses a (code-generated) case dispatcher, the others tend to use a single
method with manually coded instanceof tests.

>> 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");
> 

I wouldn't have such a big issue with codegen if it generated the code
that we wanted. However, the codegen here is generating objects that
represent the physical structure of the XML rather than ones that map to
the logical model. This leads to the need for another parser/transform
(the SCDLModelContentHandler) to convert from the physical
representation to the logical one.

The result is we have both the complexity of code generation *and* the
complexity of a manually coded parser/transformer.

>> 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.
> 

The point I was making here is that there are multiple implementations
of StAX available that can be used and that the loader is not tied to
one of them. This may be useful for people embedding Tuscany in other
environments where they have some preference over which implementation
should be used.

We are already working to integrate StAX support with SDO to allow SDO's
to be (de)-serialized from/to StAX event streams. We are already using
this for better AXIOM integration in the web-services stack.

Having a good SDO implementation is a primary objective for the project.
However, as I pointed out at the start, SDO is more than just an XML
binding technology and we need to make sure its SDO-ness excels. We also
need to realize that it is not the universal solution for data binding
and that other technologies may work better in specific scenarios. I
think we have one of those scenarios.

>> 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 specifications. Usually the kind of approach demonstrated by this
> StAX loader looks very simple and very tempting at the beginning of the
> project, but ends up in a mess and maintenance nightmare in the longer
> term.
> 

Unfortunately I think that just an aspect of this problem. I have seen
XML-binding based solutions used in other projects and they have also
proved to be very fragile even in the face of static schemas. If we had
a pure SDO solution I would be less concerned; my concern here is about
the parse/transform code that we have to maintain to convert the
physical to the logical model.

> If we want to avoid that we need the following:
> - more work on this StAX loader to clearly separate the pure
> loading/de-serialization aspect from the physical -> logical
> transformation aspects, if you mix the two aspects it will be a recipe
> for disaster after a year of maintenance adjusting to changes in the XML

See above - I think the same applies to the SCDLModelContentHandler

> - define intermediate data structures (close to the physical model) to
> avoid polluting the logical model with XML specific info (I'm thinking
> of all the cases where we're going to have to store intermedaite / half
> loaded data and complete/resolve things in a second pass, properties and
> wires are two examples that come to mind); if we don't do that and start
> adding stuff to the logical model to facilitate the loading phase we
> will make a mess of the logical model

I don't think we have needed to populate the logical model with physical
artifacts. I did make some changes to support the StAX loader such as
storing reference targets as pointers rather than using a Reference
object directly. I would contend that is a normalization that better
represents the logical model - it certainly cut out a couple of bugs
that were the result of inconsistent updates to the denormalized 
References.

> - make the StAX loader approach more complete before we jump to switch
> to it, to really understand the impact, for example  the StAX loaders do
> not handle subsystems or property types at the moment, I think that the
> support for properties in particular is going to be interesting and will
> generate some work to integrate between StAX and SDO if we want to
> support SDO properties.

Given subsystems are changing and not really supported yet by the
runtime this does not seem like a major issue. In fact, looking at the
how subsystems are handled in the SCDLModelContentHandler, adding StAX
loader support form them would be trivial. How about you have a go at
doing it and see how hard/easy adding things to the StAX framework
actually is?

For properties, I don't think either solution is fully fleshed out yet
so using that as a basis for comparison is a little unfair. For example,
I would ask how user-defined types are loaded into the SDO type system,
or how non-SDO property type support would be added (e.g. to load
properties as JAXB objects)?

With the StAX solution we have the advantage that by using a standard
technology it will be easier to add in other binding frameworks. We are
already working on a StAX->SDO deserializer that would give us a
solution when the user was using an SDO; further JAXB, XMLBeans and (I
believe) Castor all support StAX sources so it should be trival to
integrate those.

> - come up with brand new solution for serializing/saving models, I am
> sure we will run into use cases where we want to save an assembly, a set
> of wires, a module component configuration etc; StAX only handles the
> loading part, so if we're not using SDO here again we'll have to invent
> something else to handle serialization/saving of the models...
> 

We need to do that anyway. If the logical model was an SDO then we could
just write it out, but it isn't. We would need to develop and maintain a
serializer equivalent to the SCDLModelContentHandler and that is likely
to be just as much manual code to maintain as a StAX serializer.

> My main concern is about the complexity of maintaining all this code.
> Just the (incomplete) support for the core SCDL is already about 750
> lines of code, mixing parsing logic and mapping/construction of the
> logical model, using dynamic APIs like reader.getAttribute(null, "name")
> compared to the 550 lines of model transformation code using strongly
> typed APIs generated from the SCDL XSD in the SCDLModelContentHandler
> (with more complete support for the core SCDL). I anticipate many
> changes in the SCDL XSD and the logical model during the course of this
> year, the StAX based loader approach may look appealing now at the
> beginning of the project, but we will only succeed with it if we have
> committed contributors and committers ready to maintain this code, make
> it complete, and adjust it each time we change the SCDL XSD (and it's
> going to be pretty painful, compared to just rebuild to regen the code
> from XSD and adjust the transformer where it's broken by the changes).
> 

I think the "adjust the transformer" part here is the key phrase. This
is going to be just as much work as maintaining any StAX handler (as
they are essentially doing the same thing).

If you're going to compare lines of code, the honest metric here would
be to compare the number of lines related to parsing and transformation
and to exclude the code used to create the logical model. But lines of
code alone are not the only metric; when I compare blocks out of
SCDLModelContentHandlerImpl with the StAX equivalent the latter seems
less complex (at least to me).

For example, the <service> code in SCDLModelContentHanlderImpl is:

    public Object caseService(Service object) {
        final org.apache.tuscany.model.assembly.Service
service=factory.createService();
        service.setName(object.getName());

        linkers.add(new Runnable() {
            public void run() {
                currentComponentType.getServices().add(service);
            };
        });

        currentService=service;
        return service;
    }

and for the contained <interface.java>

    public Object caseJavaInterface(JavaInterface object) {
        final JavaServiceContract
serviceContract=factory.createJavaServiceContract();
        serviceContract.setScope(Scope.INSTANCE);

        serviceContract.setInterfaceName(object.getInterface());

serviceContract.setCallbackInterfaceName(object.getCallbackInterface());

        linkServiceContract(object, serviceContract);

        return serviceContract;
    }

and

    private void linkServiceContract(Object object, final
ServiceContract serviceContract) {
        Object container=((DataObject)object).getContainer();
        if (container instanceof Service) {

            // Set a service contract on a service
            final org.apache.tuscany.model.assembly.Service
service=currentService;
            linkers.add(new Runnable() {
                public void run() {
                    service.setServiceContract(serviceContract);
                }
            });
        }
        else if (container instanceof Reference) {

            // Set a service contract on a reference
            final org.apache.tuscany.model.assembly.Reference
reference=currentReference;
            linkers.add(new Runnable() {
                public void run() {
                    reference.setServiceContract(serviceContract);
                }
            });
        } else if (container instanceof ExternalService) {

            // Set a service contract on an external service
            final org.apache.tuscany.model.assembly.ExternalService
externalService=currentExternalService;
            linkers.add(new Runnable() {
                public void run() {

externalService.getConfiguredService().getService().setServiceContract(serviceContract);
                }
            });
        } else if (container instanceof EntryPoint) {

            // Set a service contract on an entry point
            final org.apache.tuscany.model.assembly.EntryPoint
entryPoint=currentEntryPoint;
            linkers.add(new Runnable() {
                public void run() {

entryPoint.getConfiguredService().getService().setServiceContract(serviceContract);

entryPoint.getConfiguredReference().getReference().setServiceContract(serviceContract);
                }
            });
        }
    }

whereas in the StAX framework the <service> handler is:

    public Service load(XMLStreamReader reader, ResourceLoader
resourceLoader) throws XMLStreamException, ConfigurationLoadException {
        assert SERVICE.equals(reader.getName());
        Service service = factory.createService();
        service.setName(reader.getAttributeValue(null, "name"));

        while (true) {
            switch (reader.next()) {
            case START_ELEMENT:
                AssemblyModelObject o = registry.load(reader,
resourceLoader);
                if (o instanceof ServiceContract) {
                    service.setServiceContract((ServiceContract) o);
                }
                reader.next();
                break;
            case END_ELEMENT:
                return service;
            }
        }
    }

and the <interface.java> handler is

    public JavaServiceContract load(XMLStreamReader reader,
ResourceLoader resourceLoader) throws XMLStreamException,
ConfigurationLoadException {
        assert AssemblyConstants.INTERFACE_JAVA.equals(reader.getName());
        JavaServiceContract serviceContract =
factory.createJavaServiceContract();
        serviceContract.setScope(Scope.INSTANCE);
        serviceContract.setInterfaceName(reader.getAttributeValue(null,
"interface"));

serviceContract.setCallbackInterfaceName(reader.getAttributeValue(null,
"callbackInterface"));
        return serviceContract;
    }

> I am not completely opposed to a StAX based loader approach. I can even
> see some benefits:
> - smaller code and memory footprint compared to a solution based on
> generated code
> - faster loading (I'm actually not sure how much we'll gain on typical
> SCA module file, but I'm guessing that it'll be faster)
> - and more important IMO... more flexible parsing (for example we could
> relax a little the requirement for some of the namespaces to be
> specified in SCDL, this could help simplify SCDL files a little)
> 
> But I'm concerned that we're going to have to spent a lot of energy to
> make it really work well in the long term (energy which could be spent
> on many other aspects we need to cover in Tuscany). Basically I will be
> OK with this StAX loader approach only if we have enough people in the
> group really volunteering to take responsiblity for it, maintain it, and
> adjust it to all the upcoming changes to the XSD or the logical model.
> People just need to think about it and realize that it's going to be a
> lot of work.
> 

I think we need to take responsibility for whichever option we choose.
Maintaining the loading code in the face of an evolving spec is going to
require work from all of us. The choice here comes down to what are we
willing to look after:

A) an SDO model, code generation, a SCDLContentModelHandler and its
   linker blocks, a set of SCDLModelLoader impls,
   and Thread classloader management code, or

B) a set of StAXElementLoader's

As I said at the start, I wasn't even looking at this until we ran into
the Thread classloader problems during the Tomcat integration. I still
don't think we have resolved all of them and think we are going to run
into a new set of challenges with other property binding frameworks.

I would like to put this to rest soon. Both versions are out there for
folk to look at and they are both complete enough to run our current
examples.

I think the StAX version is simpler yet just as flexible, avoids some of
the problems seen to date, and provides an easy integration path with
other frameworks (including SDO) and unless there is a strong technical
argument against I'd like to switch over.

--
Jeremy

Re: Framework for StAX-based model loading

[Jeremy Boynes <jb...@apache.org>]

Jean-Sebastien Delfino wrote:
> 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.
> 

I wouldn't say "running away" (that's a little dramatic) but I do think
it is fair to say that we ran into problems due to the way our SDO
implementation couples the type system to the thread's classloader.

The goal of SDO is not to be just another XML data binding technology,
its purpose is to "simplify data programming so developers can focus on
business logic instead of the underlying technology." It does this
through abstraction of that technology, by providing a data-graph
oriented API and capabilities like containment and change tracking.

We are not using those capabilities. We're actually only using a tiny
fraction of its capabilites. I think it is reasonable to evaluate
whether it is the right hammer to use on this screw.

>> 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.
> 

I would describe our problem slightly differently saying we need:
1) to parse the incoming bytestream
2) to use the parse results to build the logical model
The first of these is being handled by StAX, the second the code we
provide that reacts to parse events and builds the model. This seems
like a fairly clear separation of concerns.

I would also break down the SDO-based solution differently:
1) SDO parses the incoming bytestream
2) SDO builds its physical model to represent the XML
3) the SCDLModelContentHandler parses the physical model
   and generates a partial logical model
4) linkers generated in 3) run to complete the logical model

I think this is less separated. The implementation of
SCDLContentModelHandler is tightly coupled to the physical model
generated by SDO. The linkers are also coupled to the element handlers
(the caseXXXX methods) that parse each physical model object.

I'd also point out that the implementation of the content handler for
the core assembly model is different from other extensions: the former
uses a (code-generated) case dispatcher, the others tend to use a single
method with manually coded instanceof tests.

>> 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");
> 

I wouldn't have such a big issue with codegen if it generated the code
that we wanted. However, the codegen here is generating objects that
represent the physical structure of the XML rather than ones that map to
the logical model. This leads to the need for another parser/transform
(the SCDLModelContentHandler) to convert from the physical
representation to the logical one.

The result is we have both the complexity of code generation *and* the
complexity of a manually coded parser/transformer.

>> 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.
> 

The point I was making here is that there are multiple implementations
of StAX available that can be used and that the loader is not tied to
one of them. This may be useful for people embedding Tuscany in other
environments where they have some preference over which implementation
should be used.

We are already working to integrate StAX support with SDO to allow SDO's
to be (de)-serialized from/to StAX event streams. We are already using
this for better AXIOM integration in the web-services stack.

Having a good SDO implementation is a primary objective for the project.
However, as I pointed out at the start, SDO is more than just an XML
binding technology and we need to make sure its SDO-ness excels. We also
need to realize that it is not the universal solution for data binding
and that other technologies may work better in specific scenarios. I
think we have one of those scenarios.

>> 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 specifications. Usually the kind of approach demonstrated by this
> StAX loader looks very simple and very tempting at the beginning of the
> project, but ends up in a mess and maintenance nightmare in the longer
> term.
> 

Unfortunately I think that just an aspect of this problem. I have seen
XML-binding based solutions used in other projects and they have also
proved to be very fragile even in the face of static schemas. If we had
a pure SDO solution I would be less concerned; my concern here is about
the parse/transform code that we have to maintain to convert the
physical to the logical model.

> If we want to avoid that we need the following:
> - more work on this StAX loader to clearly separate the pure
> loading/de-serialization aspect from the physical -> logical
> transformation aspects, if you mix the two aspects it will be a recipe
> for disaster after a year of maintenance adjusting to changes in the XML

See above - I think the same applies to the SCDLModelContentHandler

> - define intermediate data structures (close to the physical model) to
> avoid polluting the logical model with XML specific info (I'm thinking
> of all the cases where we're going to have to store intermedaite / half
> loaded data and complete/resolve things in a second pass, properties and
> wires are two examples that come to mind); if we don't do that and start
> adding stuff to the logical model to facilitate the loading phase we
> will make a mess of the logical model

I don't think we have needed to populate the logical model with physical
artifacts. I did make some changes to support the StAX loader such as
storing reference targets as pointers rather than using a Reference
object directly. I would contend that is a normalization that better
represents the logical model - it certainly cut out a couple of bugs
that were the result of inconsistent updates to the denormalized References.

> - make the StAX loader approach more complete before we jump to switch
> to it, to really understand the impact, for example  the StAX loaders do
> not handle subsystems or property types at the moment, I think that the
> support for properties in particular is going to be interesting and will
> generate some work to integrate between StAX and SDO if we want to
> support SDO properties.

Given subsystems are changing and not really supported yet by the
runtime this does not seem like a major issue. In fact, looking at the
how subsystems are handled in the SCDLModelContentHandler, adding StAX
loader support form them would be trivial. How about you have a go at
doing it and see how hard/easy adding things to the StAX framework
actually is?

For properties, I don't think either solution is fully fleshed out yet
so using that as a basis for comparison is a little unfair. For example,
I would ask how user-defined types are loaded into the SDO type system,
or how non-SDO property type support would be added (e.g. to load
properties as JAXB objects)?

With the StAX solution we have the advantage that by using a standard
technology it will be easier to add in other binding frameworks. We are
already working on a StAX->SDO deserializer that would give us a
solution when the user was using an SDO; further JAXB, XMLBeans and (I
believe) Castor all support StAX sources so it should be trival to
integrate those.

> - come up with brand new solution for serializing/saving models, I am
> sure we will run into use cases where we want to save an assembly, a set
> of wires, a module component configuration etc; StAX only handles the
> loading part, so if we're not using SDO here again we'll have to invent
> something else to handle serialization/saving of the models...
> 

We need to do that anyway. If the logical model was an SDO then we could
just write it out, but it isn't. We would need to develop and maintain a
serializer equivalent to the SCDLModelContentHandler and that is likely
to be just as much manual code to maintain as a StAX serializer.

> My main concern is about the complexity of maintaining all this code.
> Just the (incomplete) support for the core SCDL is already about 750
> lines of code, mixing parsing logic and mapping/construction of the
> logical model, using dynamic APIs like reader.getAttribute(null, "name")
> compared to the 550 lines of model transformation code using strongly
> typed APIs generated from the SCDL XSD in the SCDLModelContentHandler
> (with more complete support for the core SCDL). I anticipate many
> changes in the SCDL XSD and the logical model during the course of this
> year, the StAX based loader approach may look appealing now at the
> beginning of the project, but we will only succeed with it if we have
> committed contributors and committers ready to maintain this code, make
> it complete, and adjust it each time we change the SCDL XSD (and it's
> going to be pretty painful, compared to just rebuild to regen the code
> from XSD and adjust the transformer where it's broken by the changes).
> 

I think the "adjust the transformer" part here is the key phrase. This
is going to be just as much work as maintaining any StAX handler (as
they are essentially doing the same thing).

If you're going to compare lines of code, the honest metric here would
be to compare the number of lines related to parsing and transformation
and to exclude the code used to create the logical model. But lines of
code alone are not the only metric; when I compare blocks out of
SCDLModelContentHandlerImpl with the StAX equivalent the latter seems
less complex (at least to me).

For example, the <service> code in SCDLModelContentHanlderImpl is:

    public Object caseService(Service object) {
        final org.apache.tuscany.model.assembly.Service
service=factory.createService();
        service.setName(object.getName());

        linkers.add(new Runnable() {
            public void run() {
                currentComponentType.getServices().add(service);
            };
        });

        currentService=service;
        return service;
    }

and for the contained <interface.java>

    public Object caseJavaInterface(JavaInterface object) {
        final JavaServiceContract
serviceContract=factory.createJavaServiceContract();
        serviceContract.setScope(Scope.INSTANCE);

        serviceContract.setInterfaceName(object.getInterface());

serviceContract.setCallbackInterfaceName(object.getCallbackInterface());

        linkServiceContract(object, serviceContract);

        return serviceContract;
    }

and

    private void linkServiceContract(Object object, final
ServiceContract serviceContract) {
        Object container=((DataObject)object).getContainer();
        if (container instanceof Service) {

            // Set a service contract on a service
            final org.apache.tuscany.model.assembly.Service
service=currentService;
            linkers.add(new Runnable() {
                public void run() {
                    service.setServiceContract(serviceContract);
                }
            });
        }
        else if (container instanceof Reference) {

            // Set a service contract on a reference
            final org.apache.tuscany.model.assembly.Reference
reference=currentReference;
            linkers.add(new Runnable() {
                public void run() {
                    reference.setServiceContract(serviceContract);
                }
            });
        } else if (container instanceof ExternalService) {

            // Set a service contract on an external service
            final org.apache.tuscany.model.assembly.ExternalService
externalService=currentExternalService;
            linkers.add(new Runnable() {
                public void run() {

externalService.getConfiguredService().getService().setServiceContract(serviceContract);
                }
            });
        } else if (container instanceof EntryPoint) {

            // Set a service contract on an entry point
            final org.apache.tuscany.model.assembly.EntryPoint
entryPoint=currentEntryPoint;
            linkers.add(new Runnable() {
                public void run() {

entryPoint.getConfiguredService().getService().setServiceContract(serviceContract);

entryPoint.getConfiguredReference().getReference().setServiceContract(serviceContract);
                }
            });
        }
    }

whereas in the StAX framework the <service> handler is:

    public Service load(XMLStreamReader reader, ResourceLoader
resourceLoader) throws XMLStreamException, ConfigurationLoadException {
        assert SERVICE.equals(reader.getName());
        Service service = factory.createService();
        service.setName(reader.getAttributeValue(null, "name"));

        while (true) {
            switch (reader.next()) {
            case START_ELEMENT:
                AssemblyModelObject o = registry.load(reader,
resourceLoader);
                if (o instanceof ServiceContract) {
                    service.setServiceContract((ServiceContract) o);
                }
                reader.next();
                break;
            case END_ELEMENT:
                return service;
            }
        }
    }

and the <interface.java> handler is

    public JavaServiceContract load(XMLStreamReader reader,
ResourceLoader resourceLoader) throws XMLStreamException,
ConfigurationLoadException {
        assert AssemblyConstants.INTERFACE_JAVA.equals(reader.getName());
        JavaServiceContract serviceContract =
factory.createJavaServiceContract();
        serviceContract.setScope(Scope.INSTANCE);
        serviceContract.setInterfaceName(reader.getAttributeValue(null,
"interface"));

serviceContract.setCallbackInterfaceName(reader.getAttributeValue(null,
"callbackInterface"));
        return serviceContract;
    }

> I am not completely opposed to a StAX based loader approach. I can even
> see some benefits:
> - smaller code and memory footprint compared to a solution based on
> generated code
> - faster loading (I'm actually not sure how much we'll gain on typical
> SCA module file, but I'm guessing that it'll be faster)
> - and more important IMO... more flexible parsing (for example we could
> relax a little the requirement for some of the namespaces to be
> specified in SCDL, this could help simplify SCDL files a little)
> 
> But I'm concerned that we're going to have to spent a lot of energy to
> make it really work well in the long term (energy which could be spent
> on many other aspects we need to cover in Tuscany). Basically I will be
> OK with this StAX loader approach only if we have enough people in the
> group really volunteering to take responsiblity for it, maintain it, and
> adjust it to all the upcoming changes to the XSD or the logical model.
> People just need to think about it and realize that it's going to be a
> lot of work.
> 

I think we need to take responsibility for whichever option we choose.
Maintaining the loading code in the face of an evolving spec is going to
require work from all of us. The choice here comes down to what are we
willing to look after:

A) an SDO model, code generation, a SCDLContentModelHandler and its
   linker blocks, a set of SCDLModelLoader impls,
   and Thread classloader management code, or

B) a set of StAXElementLoader's

As I said at the start, I wasn't even looking at this until we ran into
the Thread classloader problems during the Tomcat integration. I still
don't think we have resolved all of them and think we are going to run
into a new set of challenges with other property binding frameworks.

I would like to put this to rest soon. Both versions are out there for
folk to look at and they are both complete enough to run our current
examples.

I think the StAX version is simpler yet just as flexible, avoids some of
the problems seen to date, and provides an easy integration path with
other frameworks (including SDO) and unless there is a strong technical
argument against I'd like to switch over.

--
Jeremy

Re: Framework for StAX-based model loading

[Jean-Sebastien Delfino <js...@apache.org>]

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 specifications. Usually the kind of approach demonstrated by this 
StAX loader looks very simple and very tempting at the beginning of the 
project, but ends up in a mess and maintenance nightmare in the longer term.

If we want to avoid that we need the following:
- more work on this StAX loader to clearly separate the pure 
loading/de-serialization aspect from the physical -> logical 
transformation aspects, if you mix the two aspects it will be a recipe 
for disaster after a year of maintenance adjusting to changes in the XML
- define intermediate data structures (close to the physical model) to 
avoid polluting the logical model with XML specific info (I'm thinking 
of all the cases where we're going to have to store intermedaite / half 
loaded data and complete/resolve things in a second pass, properties and 
wires are two examples that come to mind); if we don't do that and start 
adding stuff to the logical model to facilitate the loading phase we 
will make a mess of the logical model
- make the StAX loader approach more complete before we jump to switch 
to it, to really understand the impact, for example  the StAX loaders do 
not handle subsystems or property types at the moment, I think that the 
support for properties in particular is going to be interesting and will 
generate some work to integrate between StAX and SDO if we want to 
support SDO properties.
- come up with brand new solution for serializing/saving models, I am 
sure we will run into use cases where we want to save an assembly, a set 
of wires, a module component configuration etc; StAX only handles the 
loading part, so if we're not using SDO here again we'll have to invent 
something else to handle serialization/saving of the models...

My main concern is about the complexity of maintaining all this code. 
Just the (incomplete) support for the core SCDL is already about 750 
lines of code, mixing parsing logic and mapping/construction of the 
logical model, using dynamic APIs like reader.getAttribute(null, "name") 
compared to the 550 lines of model transformation code using strongly 
typed APIs generated from the SCDL XSD in the SCDLModelContentHandler 
(with more complete support for the core SCDL). I anticipate many 
changes in the SCDL XSD and the logical model during the course of this 
year, the StAX based loader approach may look appealing now at the 
beginning of the project, but we will only succeed with it if we have 
committed contributors and committers ready to maintain this code, make 
it complete, and adjust it each time we change the SCDL XSD (and it's 
going to be pretty painful, compared to just rebuild to regen the code 
from XSD and adjust the transformer where it's broken by the changes).

I am not completely opposed to a StAX based loader approach. I can even 
see some benefits:
- smaller code and memory footprint compared to a solution based on 
generated code
- faster loading (I'm actually not sure how much we'll gain on typical 
SCA module file, but I'm guessing that it'll be faster)
- and more important IMO... more flexible parsing (for example we could 
relax a little the requirement for some of the namespaces to be 
specified in SCDL, this could help simplify SCDL files a little)

But I'm concerned that we're going to have to spent a lot of energy to 
make it really work well in the long term (energy which could be spent 
on many other aspects we need to cover in Tuscany). Basically I will be 
OK with this StAX loader approach only if we have enough people in the 
group really volunteering to take responsiblity for it, maintain it, and 
adjust it to all the upcoming changes to the XSD or the logical model. 
People just need to think about it and realize that it's going to be a 
lot of work.

>  what comes to mind - if anyone else can see any issues please let
> me know.
>
> --
> Jeremy
>
>   


-- 
Jean-Sebastien

Re: Framework for StAX-based model loading

[Jeremy Boynes <jb...@apache.org>]

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 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.

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).

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.

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).

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).

That's what comes to mind - if anyone else can see any issues please let
me know.

--
Jeremy

Re: Framework for StAX-based model loading

[Jim Marino <jm...@myroma.net>]

Hi Jeremy,

Could you briefly enumerate what you see as the benefits to the StAX  
framework over alternatives?

Thanks,
Jim

On Mar 14, 2006, at 1:47 PM, Jeremy Boynes wrote:

> I have got the StAX stuff to the point where I can run all the  
> itests in
> the build and the tomcat/testing tests using the StAX framework. I  
> think
> this is an opportune time to open discussion on whether we should  
> switch
> over to this once and for all.
>
> You can enable the framework by setting the useStax boolean in
> BootstrapHelper to true and rebuilding the core module (and any others
> you wish to test).
>
> To see what is involved in adding an extension have a look at:
> JavaScriptImplementationLoader for the .js container
> JSONRPCBindingLoader for the .jsonrpc binding
>
> Comments welcome...
> --
> Jeremy
>
> Jeremy Boynes wrote:
>
>> I checked in a framework for a StAX-based configuration loader for  
>> the
>> SCA core. It is based on a set of element handlers that generate a  
>> model
>> object from a element in the XML stream; handlers for the core and
>> system schemas are in the core module, handlers for extensions can be
>> bundled in the extension module and are contributed as regular system
>> components.
>>
>> I tested with the basic system and helloworld configurations and
>> discovered a problem with the way configured properties and  
>> references
>> are handled. This should be resolved once the FIXME in  
>> ComponentImpl is
>> addressed.
>>
>> To get this working I had to modify the autowire resolver in the
>> SystemAggregateContextImpl. I hope this can be removed once Jim gets
>> references working. I also think we need to reexamine the autowire
>> algorithm but will open another thread for that.
>>
>> --
>> Jeremy
>

Re: Framework for StAX-based model loading

[Jeremy Boynes <jb...@apache.org>]

I have got the StAX stuff to the point where I can run all the itests in
the build and the tomcat/testing tests using the StAX framework. I think
this is an opportune time to open discussion on whether we should switch
over to this once and for all.

You can enable the framework by setting the useStax boolean in
BootstrapHelper to true and rebuilding the core module (and any others
you wish to test).

To see what is involved in adding an extension have a look at:
JavaScriptImplementationLoader for the .js container
JSONRPCBindingLoader for the .jsonrpc binding

Comments welcome...
--
Jeremy

Jeremy Boynes wrote:
> I checked in a framework for a StAX-based configuration loader for the
> SCA core. It is based on a set of element handlers that generate a model
> object from a element in the XML stream; handlers for the core and
> system schemas are in the core module, handlers for extensions can be
> bundled in the extension module and are contributed as regular system
> components.
> 
> I tested with the basic system and helloworld configurations and
> discovered a problem with the way configured properties and references
> are handled. This should be resolved once the FIXME in ComponentImpl is
> addressed.
> 
> To get this working I had to modify the autowire resolver in the
> SystemAggregateContextImpl. I hope this can be removed once Jim gets
> references working. I also think we need to reexamine the autowire
> algorithm but will open another thread for that.
> 
> --
> Jeremy