Resending since this didn't go through...
Begin forwarded message:
From: Jim Marino <[EMAIL PROTECTED]>
Date: March 23, 2006 11:53:12 AM PST
To: [email protected]
Subject: Re: Framework for StAX-based model loading
There has been a lot of discussion on this topic and Jeremy's point
brings up an issue I think needs to be fleshed out. Specifically,
what are the requirements and priorities for loading configuration.
Could we perhaps take the following approach?
1. Agree on the requirements and their priorities without getting
into a technical discussion. I would suggest we rank requirements
by absolute priority, i.e. the most important first, the next
important, etc. rather than "requirements A and B are p1,
requirements X and Y p2"
2. Based on the requirements and priorities, compare the StAX and
SDO approaches for each
3. Agree on one approach moving forward for configuration
If this acceptable, my opinion on requirements in priority order are:
1. The configuration mechanism must be easy for end-users to use to
promote widespread adoption of Tuscany
- For example, basic types defined by the spec should be a
given, but it should also be easy for someone to add a custom type.
For instance, my Foo component may take a Bar type as
configuration. Based on past experience with IoC containers, I have
found this to be a very common situation.
-I assume this would have to involve describing the type and
registering some kind of custom handler with the runtime
2. The configuration mechanism must be easy for container extenders
to promote widespread adoption of Tuscany in the developer community
- Similar to point 1, although I think the requirements on ease-
of-use may be slightly different.
- One additional item here is the configuration mechanism
should follow Java idioms as closely as possible. Manipulating the
model should not be foreign to Java developers
- As a side note, I think items 1 and 2 are intimately related,
but 1 is slightly more important since Tuscany developers will have
a higher pain threshold than end-users
3. Operation in a variety of deployment environments. For example,
how does each approach handle different classloader hierarchy
scenarios?
4. Ability to handle serializations other than XML. This was one of
the reasons why we went to a separate logical model. It's also not
just related to testing although that is one use case. For example,
configuration may be pulled from sources other than XML such as a
registry.
5. Maintenance
- There are probably two considerations here. First, what we
use should be easily understood and used by Java developers wanting
to contribute to Tuscany. A second consideration is as the spec XML
changes, is it easy for us to evolve the code. Here, I would say we
concentrate on the first. The second use case has a lower priority
I have put to item 8.
6. Versioning
- We need a mechanism that easily supports versioning. In the
future, we will need to support multiple configuration format versions
7. Performance
- We need something that will be performant. On at least two
separate occasions, I have seen IoC container start-up brought to
its knees handling configuration processing. This may not seem
like a big deal but when there are 1,000s (or even a couple
hundred) of components, it rears its head.
8. Ease on "us", the commiters (the second maintenance consideration)
- This is where I would say how easy is it to accommodate spec
changes comes in. Either approach can handle changes so the
question becomes which alternative offers a better solution for
commiters.
Perhaps we could come up with a set of objective criteria to judge
by and then move to a technical discussion of each approach?
Jim
On Mar 23, 2006, at 11:02 AM, Jeremy Boynes wrote:
I think we need to be careful to distinguish the needs we have for
loading our configurations from the needs users have of SDO in
general. I think the SCA schemas have things in them that are
atypical: lots of extensibility, many namespaces, custom data
types, few attributes/properties and so forth. On the other hand,
our use case doesn't need things like change tracking or streaming
that SDO provides.
We need a good SDO implementation, we need a loading mechanism
that can handle our configurations; the two don't have to be the
same. If they are, that is good; if they aren't, that's not bad.
--
Jeremy
Jean-Sebastien Delfino wrote:
Raymond Feng wrote:
Hi, Frank.
I think I fully agree with you. An efficient databinding is what
we're looking for.
Ideally, if SDO later on supports lazy-loading (create the
DataObject skeleton first and pull in properties as they're
assessed) from XMLStreamReader, I assume we'll take advantage of
the benifits advocated by both camps (Databinding vs. StAX).
Raymond
----- Original Message ----- From: "Frank Budinsky"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, March 23, 2006 9:37 AM
Subject: Re: Framework for StAX-based model loading
I stand by my statement that the EMF problem is short term pain
for long
term gain :-) I think that in the long term using the SDO
generator will
be the best and easiest way to do this. Yes I am biased, but
I've seen it
before - avoiding reuse/dependencies works nicely at first, but
as things
grow/change and get more comlicated, the amount of reworking/
reinventing
becomes quite a nightmare. The opposite problem, which I think
we're
suffering from here, is that the reusable component that we are
trying to
leverage isn't as nice and clean and a perfect fit as we'd
like, so it
really looks undesirable. Since we have control of all the
pieces, in this
case, I think we have a great opportunity to make it a clean
fit. And like
I said in my reply to Jeremy, earlier, I really strongly feel
that the
problems that we're identifying here are not unique to SCA, so
fixing them
is really in our best interest.
Frank.
"ant elder" <[EMAIL PROTECTED]> wrote on 03/23/2006 10:13:24 AM:
On 3/23/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
<snip/>
As the binding itself uses JAXB2 (though it may change in
> the future), I have to include all eclipse dependencies and
SDO stuff,
> just to load the system configuration files :(
From the discussion I'm starting to be persuaded by some of the
arguments
for the SDO approach, but this EMF dependency seems a draw
back. If
we're
going to support alternate data bindings for the WS binding
its not
great to
still be dragging in EMF to run the thing. And I'd guess it
would be
much
easier to sell SDO to say the Axis2 guys to use instead of
XmlBeans if
there
was a pure Java SDO impl. Any Axis2 guys listening who'd
comment on
this?
As another comparison look at Axis2, they have their own very
simple
Axis
Data Binding (ADB) which supports simple XSDs, and they use
XmlBeans for
all
the complicated stuff. They don't use XmlBeans all the time
because lots
of
things don't need the complexity a full blown data binding
brings. And
as
Guillaume points out, the SCA binding schema are usually
pretty simple.
...ant
Raymond,
That's a very good point, I agree.
I think that this whole discussion thread is very useful as it
helps us identify requirements and areas of improvement for our
SDO databinding and codegen story. For example, Guillaume
mentioned that it would be great to have a Maven 1 SDO codegen
plugin, as ServiceMix is still built with Maven 1 at the moment
(and I guess a number of other projects out there still use Maven
1 as well). I can spend some time in the next few days and work
with anybody who would like to volunteer and try to wrap the code
generator in a Maven 1 plugin, if it helps. Guillaume, are you
using Ant at all? or just Maven 1?
