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
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 re
+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 Tu
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
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 differe
y 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,
Fran
ut time to just make a
decision
and run with it. If this much discussion went into every design
decision,
we'd still be sharpening our chisels and working on carving the
wheel :-)
Thanks,
Frank
Jim Marino <[EMAIL PROTECTED]>
03/23/2006 02:53 PM
Please respond to
tuscany-dev
To
tus
I'm still having delays from gmail...
Begin forwarded message:
From: Jim Marino <[EMAIL PROTECTED]>
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 u
e 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 chisel
tepping 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
g 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, wha
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 pro
> >>> - 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 e
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
>>>
a lot
I added support to the StAX version that allows you to specify a custom
parser for the content of
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 an
Still can't get my Gmail right...sorry
Jim
Begin forwarded message:
From: Jim Marino <[EMAIL PROTECTED]>
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
ur chisels and working on carving the
wheel :-)
Thanks,
Frank
Jim Marino <[EMAIL PROTECTED]>
03/23/2006 02:53 PM
Please respond to
tuscany-dev
To
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
bout 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
> >
> >
> &g
I'm forwarding this due to problems with my GMail setup...
Jim
Begin forwarded message:
From: Jim Marino <[EMAIL PROTECTED]>
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 unc
decision
and run with it. If this much discussion went into every design
decision,
we'd still be sharpening our chisels and working on carving the
wheel :-)
Thanks,
Frank
Jim Marino <[EMAIL PROTECTED]>
03/23/2006 02:53 PM
Please respond to
tuscany-dev
To
tuscany-dev@ws.apache.org
c
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 Ser
ing the wheel :-)
Thanks,
Frank
Jim Marino <[EMAIL PROTECTED]>
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
Original Message - From: "Frank Budinsky"
<[EMAIL PROTECTED]>
To:
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 ter
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: tuscany-dev@ws.apache.org
Subject: Re: Framework for StAX-based model loading
There has been a lot of discussion on this topic and Jer
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).
> >>
> >> Ra
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:
Sent: Thursday, March 23, 2006 9:37 AM
we'll take advantage of the benifits
advocated by both camps (Databinding vs. StAX).
Raymond
- Original Message - From: "Frank Budinsky" <[EMAIL PROTECTED]>
To:
Sent: Thursday, March 23, 2006 9:37 AM
Subject: Re: Framework for StAX-based model loading
I stand by my st
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
of the benifits advocated by
both camps (Databinding vs. StAX).
Raymond
- Original Message -
From: "Frank Budinsky" <[EMAIL PROTECTED]>
To:
Sent: Thursday, March 23, 2006 9:37 AM
Subject: Re: Framework for StAX-based model loading
I stand by my statement that the
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
g
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 s
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
On 3/23/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
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
hi Jeremy,
has somebody captured the current version of the logical model in UML.
thanks,
Michael
On 3/22/06, Jeremy Boynes <[EMAIL PROTECTED]> 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 J
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
Jeremy Boynes <[EMAIL PROTECTED]> 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
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 co
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 transf
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 diffe
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
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 3/21/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
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 c
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 th
Jean-Sebastien Delfino wrote:
>
> 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
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 XMLStreamRea
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 a
anyway and SDO should be a competitive Java binding
technology, as well as all the other things.
Frank.
Jeremy Boynes <[EMAIL PROTECTED]> 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-Se
need to get fixed
anyway and SDO should be a competitive Java binding technology, as well as
all the other things.
Frank.
Jeremy Boynes <[EMAIL PROTECTED]>
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 l
ay and SDO should be a competitive Java binding technology, as well as
all the other things.
Frank.
Jeremy Boynes <[EMAIL PROTECTED]>
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-S
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
>> cl
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
w
rick rineholt wrote:
> Before we jump the gun on this I'd like to see if more people could
> give some feedback on the pros and cons of this. I definitely some
> advantages in that it simplifies the code some and is based on
> technologies that more developers are more likely to be familiar
> wit
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.
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(SystemAggregateC
Before we jump the gun on this I'd like to see if more
people could give some
feedback on the pros and cons of this. I definitely
some advantages in that it
simplifies the code some and is based on technologies
that more developers are
more likely to be familiar with. I do think that
somethin
I like this a lot. Lets change everything over to it from SDO.
...ant
On 3/14/06, Jeremy Boynes <[EMAIL PROTECTED]> 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 opport
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 kee
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
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 useS
Does this mean the core will no longer require SDO and the depedency on EMF?
...ant
On 3/8/06, Jeremy Boynes <[EMAIL PROTECTED]> 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
> objec
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 ext
61 matches
Mail list logo
