date:20060706


Venkat,

I know I said on IRC this morning I would try an post some comments  
on migrating this but I am afraid that things today have kept me  
distracted. I will be on IRC early tomorrow morning, I hope that is  
not too late for you.


--
Jeremy

On Jul 6, 2006, at 11:51 AM, Jeremy Boynes wrote:

As discussed on IRC this morning, I have checked Venkat's RMI  
binding code from TUSCANY-467 into the sandbox. This is still based  
on the M1 implementation but we wanted to have something in SVN to  
act as a baseline for discussion. It will not compile at this time  
so I have not incorporated it into the build.


--
Jeremy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DAS named parameters

2006-07-06 Thread Kevin Williams

I am in the middle of removing the "named parameter" feature of DAS 
command and notice that we currently allow a special convenience name to 
allow a client to retrieve a database generated ID from a low-level 
insert command like this:


   DAS das = DAS.FACTORY.createDAS(getConnection());
   Command insert = das.createCommand("insert into COMPANY (NAME) 
values (?)"); 
   insert.setParameter(1, "AAA Rental");

   insert.execute();
   Integer key = (Integer) insert.getParameter("generated_key");

I expect that clients will typically not execute a low level insert like 
this.  Instead, I expect them to pass a modified graph to the DAS and 
the DAS will generate and execute a set of insert statements.  Any 
database-generated IDs will be propagated back to the provided data 
graph and the client can access them there.


That said, I think this is a nice low-level feature so I hate to get rid 
of it.  But, I am removing named parameter access.  I suppose I could 
provide a special convenience parameter index to serve the same 
purpose.  Something like:


   Integer key = (Integer) insert.getParameter(DAS.GENERATED_KEY);

That would work but seems a bit cheesy ... maybe no cheesier than the 
special name.   Any other ideas?


Thanks,

--Kevin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposed approach for M2


Comments inline
On Jul 6, 2006, at 6:17 PM, Jean-Sebastien Delfino wrote:


Jeremy,

I won't comment on your attacks at the bottom of this email. I was  
hoping for a more constructive technical discussion. I added my  
answers and comments on the specific technical issues inline.


Jeremy Boynes wrote:

On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:


My proposal is not to merge M1 and the core2 sandbox. I am  
proposing to start a new fresh code stream and build the runtime  
through baby steps. We may be able to reuse some pieces of  
existing code, but more important is to engage our community in  
this exercise and integrate the new ideas that will emerge from  
this.




I don't believe the two issues are necessarily coupled. Quite a  
few members of the community are engaged on the sandbox code  
already and we could work with you to improve that rather having  
to throw everything out and start over with all new ideas.




Here's an example where I'm struggling with both M1 and the core2  
sandbox and thinking that we can do better if we start with a new  
fresh stream: our (recursive) assembly metadata model.


- M1 does not implement the recursive composition model and would  
require significant changes to support it. Core2 is an attempt to  
implement it but I'm not sure it's quite right, and also think  
that it can be simplified.


It would really help if you could come up with concrete areas  
where it is not right or where it could be simplified - for  
example, end user scenarios that are not supported.




- M1 used Lists to represent relationships, Core2 uses Maps, I  
think M1 was better since it allowed to keep the order in the  
relationships.


There's nothing I remember in the assembly spec where order  
matters. On the other hand there are many areas where things are  
keyed by a name which has to be unique. This seems like a natural  
mapping (sorry) to a Map. In M1 I started to move toward simple  
map structures but you replaced it with what seemed like a fairly  
complicated specialized List implementation that sent  
notifications that updated a Map anyway. Given the desire for  
simplification, are there any end-user scenarios that require  
ordering to be preserved and that can't be supported with a basic  
HashMap or LinkedHashMap?


As an administrator I'll want my administration tool to display  
components displayed in the order I declared them in SCDL.
SCDL isn't the only form assembly can be serialized to/from. Also, if  
I were an admin, I'd probably want to sort the components according  
to some useful criteria, not how they are listed in a SCDL as most  
admins will never look at XML.  One could always use LikedHashMap  
though.


I'll also want a configuration or admin tool loading/saving  
modified SCDL to write things in the order that they were  
initially, not in a random order. As an application developer I'd  
like to have an SCA debugging tool showing me my components in a  
list in the right order as well. Also if I want to implement the  
model defined by the XML schemas in the spec using any of the  
DataBinding technologies out there, I'll end up with Lists, not Maps.


We have  been using StAX just fine for this and it accommodates a  
number of databinding solutions for extensions. Are you proposing we  
revisit this decision made back before the M1 release to go with STaX  
loading? If so, for what reasons? BTW, not all databinding solutions  
will have problems - XStream will work just fine with what we have.  
Also, are you sure about XMLBeans and JAXB or are you just speaking  
about a current implementation of SDO?


Finally even if we decided to use Maps in some cases to provide  
keyed access to some elements of the model, we'd have to do it  
differently. For example a single Map containing all components,  
references and services in a composite (according to the spec they  
cannot have the same names) instead of three Maps like you have in  
Core2.




- Core2 only defines implementation classes for the model, I  
think we should have interfaces + default implementation classes  
instead, like we had in M1, to allow for alternate  
implementations of the model.


One of the most complex things with the M1 model was all the  
interfaces involved, the need to pass factory implementations  
around, the number of different factories involved (one per  
extension implementation) and the potential issues with code  
assuming its implementation of the factory was the one used.


The core2 model uses concrete classes which are really just data  
holders - there's no behaviour in them to be abstracted through  
the interface. This gives a much simpler programming model for  
extensions using the model.


Do you have any scenarios that would require different  
implementations of the model? Are they so different that they  
might as well just use different classes?




I don't think that having just implementation classes is much  
simple

Re: Proposed approach for M2

2006-07-06 Thread Jean-Sebastien Delfino


Jeremy,

I won't comment on your attacks at the bottom of this email. I was 
hoping for a more constructive technical discussion. I added my answers 
and comments on the specific technical issues inline.


Jeremy Boynes wrote:

On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:


My proposal is not to merge M1 and the core2 sandbox. I am proposing 
to start a new fresh code stream and build the runtime through baby 
steps. We may be able to reuse some pieces of existing code, but more 
important is to engage our community in this exercise and integrate 
the new ideas that will emerge from this.




I don't believe the two issues are necessarily coupled. Quite a few 
members of the community are engaged on the sandbox code already and 
we could work with you to improve that rather having to throw 
everything out and start over with all new ideas.




Here's an example where I'm struggling with both M1 and the core2 
sandbox and thinking that we can do better if we start with a new 
fresh stream: our (recursive) assembly metadata model.


- M1 does not implement the recursive composition model and would 
require significant changes to support it. Core2 is an attempt to 
implement it but I'm not sure it's quite right, and also think that 
it can be simplified.


It would really help if you could come up with concrete areas where it 
is not right or where it could be simplified - for example, end user 
scenarios that are not supported.




- M1 used Lists to represent relationships, Core2 uses Maps, I think 
M1 was better since it allowed to keep the order in the relationships.


There's nothing I remember in the assembly spec where order matters. 
On the other hand there are many areas where things are keyed by a 
name which has to be unique. This seems like a natural mapping (sorry) 
to a Map. In M1 I started to move toward simple map structures but you 
replaced it with what seemed like a fairly complicated specialized 
List implementation that sent notifications that updated a Map anyway. 
Given the desire for simplification, are there any end-user scenarios 
that require ordering to be preserved and that can't be supported with 
a basic HashMap or LinkedHashMap?


As an administrator I'll want my administration tool to display 
components displayed in the order I declared them in SCDL. I'll also 
want a configuration or admin tool loading/saving modified SCDL to write 
things in the order that they were initially, not in a random order. As 
an application developer I'd like to have an SCA debugging tool showing 
me my components in a list in the right order as well. Also if I want to 
implement the model defined by the XML schemas in the spec using any of 
the DataBinding technologies out there, I'll end up with Lists, not Maps.


Finally even if we decided to use Maps in some cases to provide keyed 
access to some elements of the model, we'd have to do it differently. 
For example a single Map containing all components, references and 
services in a composite (according to the spec they cannot have the same 
names) instead of three Maps like you have in Core2.




- Core2 only defines implementation classes for the model, I think we 
should have interfaces + default implementation classes instead, like 
we had in M1, to allow for alternate implementations of the model.


One of the most complex things with the M1 model was all the 
interfaces involved, the need to pass factory implementations around, 
the number of different factories involved (one per extension 
implementation) and the potential issues with code assuming its 
implementation of the factory was the one used.


The core2 model uses concrete classes which are really just data 
holders - there's no behaviour in them to be abstracted through the 
interface. This gives a much simpler programming model for extensions 
using the model.


Do you have any scenarios that would require different implementations 
of the model? Are they so different that they might as well just use 
different classes?




I don't think that having just implementation classes is much simpler. 
If you interact with the model SPI, reading interfaces is simpler IMO 
and more suitable for inclusion in a specification document... allowing 
multiple implementations of these interfaces. Also we have to support 
the whole lifecycle of an SCA application (development, deploy/install, 
runtime, admin etc.) and I'd like to allow some flexibility for 
different tools, running at different times to use different 
implementations of the assembly model interfaces.




- Over usage of Java Generics breaks flexibility in some cases, for 
example Component will force you to 
recreate an instance of Component to swap its implementation with an 
implementation of a different type (and lose all the wires going 
in/out of the component).


There may be cases where generics may be overkill but I don't think 
that really requires us to throw out the model. There are other cases 
wher

Re: C++ M1 Release Candidate

2006-07-06 Thread Luciano Resende

Hi Pete

I took sometime to look
at the C++ M1 Release candidate and I have the following feedback...
Please keep in mind that
my C++ skills is not one of my biggest strengths as of today, so, some
feedback might be due to lack of involvement with C++ for couple of years...

Also note that I didn't
have a C++ DEV environment, so I was just running things from the binaries
you posted.

- In Tuscany Java, we have
some sample script files to boot the Tuscany environment (http://incubator.apache.org/tuscany/projectjava.html#Enviroment%20scripts).
Should we have something similar for C++ environment ? I have created a
sample one just to using for C++ M1 and could be used as a sample if people
think this is a good idea.

- Instructions
on how to install Tuscany SCA CPP posted here (http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/INSTALL)
says:
-
5.a. Unzip the supplied zip file. set the TUSCANY_SCACPP variable to point
to the 'deploy' directory in the unzipped directory tree.

I
can find the deploy directory in the c++ svn repository, but it's not available
in the M1 release candidate. Is this just the directory the files were
extracted ? If so, documentation needs clarification, otherwise M1 zip
need to be checked.
Trying
to go a step ahead, I set this to the place i unzipped the files and looks
like it accepted that :)

- In order to start getting
better results from the SCA Calculator sample program, I had to figure
out the following items that were not mentioned in the INSTALL instructions

-
Need to add axis2c\lib directory to path as well... instructions only mention
bin directory
-
Need the following runtime env dlls : msvcp60d.dll, msvcrtd.dll (my system
only had the regular ones without the d)

- After fixing the DLL
issues, i found that the calculator sample app was expecting the following
environment variable to be set :
SystemConfigurationException
TUSCANY_SCACPP_SYSTEM_ROOT
environment variable not set

I
set that to the same value of TUSCANY_SCACPP
Do
we need these 2 env variables ? What is the difference between TUSCANY_SCACPP
and TUSCANY_SCACPP_SYSTEM_ROOT

- Now I'm at the point
I'm getting the following exception
SystemConfigurationException
Duplicate
wire for reference: CalculatorDivideService

Any
workaround here ?

Other minor things

- Couple files like : LICENSE,
NOTICE, README all have no extensions, are these the way they are supposed
to be ? The Java M1 had some of these files with the txt extension...
- The SDO package have
two readme with different contents on it (README and README.txt)

-- Luciano

"Pete Robbins"
<[EMAIL PROTECTED]>
07/05/2006 08:02 PM

Please respond to
tuscany-dev@ws.apache.org

To
tuscany-dev@ws.apache.org

Subject
C++ M1 Release Candidate

I have posted a candidate for the first C++ release
here.

http://people.apache.org/~robbinspg/RC1

Would all interested parties take some time to review this so that we can
either re-spin the release or vote on it asap.

The website documentation is out of date and will be re-written to sync
with
what is in the release. Hopefully this will be done tomorrow.

A Calculator sample is included which demonstrates deploying an SCA module,
component wiring, locating and invoking C++ service from
C++ component, invoking from a C++ client, and exposing a service
as a web
service using ws binding.

Release Summary
=

Tuscany SCA C++ provides a runtime implementation for the Service Component
Architecture 0.9 specification, written in C++ and will currently support
C++
component implementation types. This is not yet a complete implementation
and
known restrictions are described below.

Supported SCA Assembly Model features
* All features are supported unless listed under the known
restrictions
below. See SCA Assembly Model specification.

Supported language bindings
* Component implementations written in C++. See SCA Client and
Implementation Model specification.
* Component interfaces described by C++ classes. See SCA Client
and
Implementation Model specification.

Supported external service and entry point bindings
* The web service binding is supported. This implementation will
support
web services which using document literal SOAP bindings conforming
to
the
WS-I basic profile (rpc/encoded is not yet supported).

Known restrictions
* Subsystem: wiring, entry points and external services are not
supported.
* Local service interfaces cannot use overloaded operations (the
SCA
specification limits remote service interfaces to not using
overloaded operations).
* Each WSDL definition for a web service binding must be in a single
WSDL
document.
* No load time validation of the deployed SCA application (run time
validation only).
* No metadata API.
--
Pete

Re: Email versus IRC

yea that's cool. I just thought if a decision was made on IRC it  
couldn't be "undone" by a vote on the list. I like the idea of using  
quick chats to clear out lingering things and then have them ratified  
on the list.


Jim

On Jul 6, 2006, at 4:02 PM, Jeremy Boynes wrote:



On Jul 6, 2006, at 3:04 PM, Jim Marino wrote:



On Jul 6, 2006, at 2:22 PM, Jeremy Boynes wrote:



We will also hold pre-announced chats at other times so try and  
bring closure to issues that seem to be dragging on in email  
threads. The point of these is to come to a decision and such  
outcomes must be posted to the list for all to review. It is the  
discussion on the list that is binding.
I like all of this except the above. I thought decisions of  
substance cannot be made on IRC? It sounds unfair since people  
oftentimes cannot attend. I have no problems with discussions but  
decision making should be on the list. I hate to be a contrarian  
on this point but I feel it is important.


The intention here was to provide a mechanism to handle discussions  
from the list that were just going on and on. Critical is that the  
discussion started on the list and would conclude on the list. I  
was trying to capture that the point of the chat would be to tackle  
a specific issue rather than just have your typical rambling IRC  
thread :-)


Would it work for you to say that the point of the chat would be to  
have a focused discussion?


--
Jeremy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposed approach for M2

2006-07-06 Thread Kenneth Tam


On 7/6/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

On Jul 6, 2006, at 12:05 PM, Simon Nash wrote:

All ideas that Sebastien has proposed are being considered - we had a
long discussion on these very things on IRC this morning. The main
questions being asked about his proposal are "what is the benefit of
starting over?" and "why can we not start with what we already have
in the sandbox?" One of the problems here is that there are no clear
answers to them.

...

We made a start this morning with a fairly long discussion on IRC
about which code to use. Several people said that they had found the
sandbox code clearer than M1 and wanted to know from Sebastien why he
thought we had to start over (I paraphrase). It's a reasonable
question to ask; it's unreasonable for it to continue to go unanswered.


.. not having been on IRC, you can add me to the list of folks who
found the sandbox code more manageable and easier to get involved
with.  I'm not fundamentally opposed to the idea that we might "start
over", but I certainly don't see a documented/well-discussed technical
case justifying that at this point.

k

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Email versus IRC

2006-07-06 Thread Kenneth Tam

On 7/6/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

On Jul 6, 2006, at 3:04 PM, Jim Marino wrote:

>
> On Jul 6, 2006, at 2:22 PM, Jeremy Boynes wrote:
>
>>
>> We will also hold pre-announced chats at other times so try and
>> bring closure to issues that seem to be dragging on in email
>> threads. The point of these is to come to a decision and such
>> outcomes must be posted to the list for all to review. It is the
>> discussion on the list that is binding.
> I like all of this except the above. I thought decisions of
> substance cannot be made on IRC? It sounds unfair since people
> oftentimes cannot attend. I have no problems with discussions but
> decision making should be on the list. I hate to be a contrarian on
> this point but I feel it is important.

The intention here was to provide a mechanism to handle discussions
from the list that were just going on and on. Critical is that the
discussion started on the list and would conclude on the list. I was
trying to capture that the point of the chat would be to tackle a
specific issue rather than just have your typical rambling IRC
thread :-)

Would it work for you to say that the point of the chat would be to
have a focused discussion?

+1 -- I think we should consider IRC a great venue for arbitrary sets
of folks to come to consensus amongst themselves, which will
ultimately help build consensus amongst everyone on the email list.

I for one tend to avoid IRC because of frequent firewall issues.
Plus, I have enough scheduled/realtime meetings/appointments that I
really don't need one more :)

thanks,
k

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Email versus IRC



On Jul 6, 2006, at 3:04 PM, Jim Marino wrote:



On Jul 6, 2006, at 2:22 PM, Jeremy Boynes wrote:



We will also hold pre-announced chats at other times so try and  
bring closure to issues that seem to be dragging on in email  
threads. The point of these is to come to a decision and such  
outcomes must be posted to the list for all to review. It is the  
discussion on the list that is binding.
I like all of this except the above. I thought decisions of  
substance cannot be made on IRC? It sounds unfair since people  
oftentimes cannot attend. I have no problems with discussions but  
decision making should be on the list. I hate to be a contrarian on  
this point but I feel it is important.


The intention here was to provide a mechanism to handle discussions  
from the list that were just going on and on. Critical is that the  
discussion started on the list and would conclude on the list. I was  
trying to capture that the point of the chat would be to tackle a  
specific issue rather than just have your typical rambling IRC  
thread :-)


Would it work for you to say that the point of the chat would be to  
have a focused discussion?


--
Jeremy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Steps twords graduations

2006-07-06 Thread William A. Rowe, Jr.


FYI

I'm very satisfied with the overall progress of stdcxx, but see two
obstacles to graduation;

 * the bug tracking system is being well utilized to discuss patches,
   but the dev list is still a bit quiet on the design-decision front.
   It's important that decisions are open and not made in the conference
   room amoung a closed circle of individuals.

   I believe adding tuscany folks to this effort, having a more diverse
   group of committers, will go a long ways to alleviating this quiet :)

 * the diversity remains an issue.  Here again, having multiple groups of
   users who submit patches, become committers will go a long way in solving
   this issue as well.

Although open source is ready when it's ready, I'd really like to look ahead
to the end of September to attempt to graduate stdcxx.  I know the current
PMC understands the ASF concept, meritocracy etc, and is doing a noble job
maintaining the codebase.  Let's all watch these two areas so that we can
retitle this effort as the Apache stdcxx Library [graduated].

Bill

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: using stdcxx in tuscany/C++

2006-07-06 Thread William A. Rowe, Jr.


Great news!  Thanks for keeping us in the loop.

Martin Sebor wrote:

Hi,

We have heard that the Tuscany developers have been exploring
the option of using Apache stdcxx as the common implementation
of the C++ Standard Library for Tuscany/C++. We are wondering
whether this is in fact the case and, if so, what the stdcxx
team can do in order to make it as smooth as possible.

Martin

.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: using stdcxx in tuscany/C++


Hi Martin.

Using stdcxx is certainly on our list of things to investigate. There are 2
ways in which we can use a C++ standard library:
1) Internally withing our own implementation code
2) Exposed on user APIs

We currently use stl within our implementation and the use of stl classes on
our interfaces is currently under discussion in the SCA C++ Specification
group.

Ed Slattery took a look at using stdcxx but I have to admit I have had
little time to follw this up.
I need to take a look at your project and see what the benefits are. I will
set aside some time tomorrow to do this.

Thanks for your interest.

On 06/07/06, Martin Sebor <[EMAIL PROTECTED]> wrote:


Hi,

We have heard that the Tuscany developers have been exploring
the option of using Apache stdcxx as the common implementation
of the C++ Standard Library for Tuscany/C++. We are wondering
whether this is in fact the case and, if so, what the stdcxx
team can do in order to make it as smooth as possible.

Martin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Pete

using stdcxx in tuscany/C++

2006-07-06 Thread Martin Sebor


Hi,

We have heard that the Tuscany developers have been exploring
the option of using Apache stdcxx as the common implementation
of the C++ Standard Library for Tuscany/C++. We are wondering
whether this is in fact the case and, if so, what the stdcxx
team can do in order to make it as smooth as possible.

Martin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Email versus IRC



On Jul 6, 2006, at 2:22 PM, Jeremy Boynes wrote:

I'd like to see if I can recap where this thread went. There seem  
to be two sets of opinion:


1) that regular scheduled chats are helpful
2) that impromptu, unscheduled chats are helpful

In light of this, I'd like to propose the following IRC policy for  
the project:


==
We will hold a regular scheduled chat at the current time (15:30GMT  
every Monday) to discuss non-urgent things that people may be  
interested in. Subjects should be posted to the list in advance so  
that people can make a decision on whether to attend; attendance is  
encouraged but optional. The folk that show up get to choose what  
is discussed.


We will also hold pre-announced chats at other times so try and  
bring closure to issues that seem to be dragging on in email  
threads. The point of these is to come to a decision and such  
outcomes must be posted to the list for all to review. It is the  
discussion on the list that is binding.
I like all of this except the above. I thought decisions of substance  
cannot be made on IRC? It sounds unfair since people oftentimes  
cannot attend. I have no problems with discussions but decision  
making should be on the list. I hate to be a contrarian on this point  
but I feel it is important.


In general we will encourage community members to hang out on the  
IRC channel so that anyone can hold an impromptu discussion with  
folk that happen to be around. We especially encourage committers  
to be available so that new users have a way to reach someone. Any  
decisions should be summarized to the list.

==

I hope that captures everyone's thoughts and if so I'd suggest we  
put it on the website.

If not, how about meeting on IRC to close this out?


No :-) Let's close it out on this list.

--
Jeremy

On Jul 5, 2006, at 3:04 AM, ant elder wrote:

There's a thread going on over on incubator-general about the use  
of IRC:

http://marc.theaimsgroup.com/?t=11511128601&r=1&w=2

Are people happy with having our current weekly hour long IRC  
chat? I find
the chat a useful way to find whats going on and gauge peoples  
opinions. A 1

hour chat isn't so long that its hard to read the chat log, we could
probably do better at providing a summary of what was said, and  
maybe post

the log and summary on the wiki so its easier to find. So I think the
current chat is useful and works ok but we can change this if  
others don't

like it.

Currently the chat focus has been primarily Java SCA, should we  
try and
include C++ or SDO or DAS more? Or have separate extra chats for  
those?
Often the chat is one long rambling conversation, should we try to  
be more
structured and have a set 10 minutes for this, 10 minutes for that  
type of
thing to just get a regular status and have any followup  
discussion on the

mailing list?

Is the 15:30GMT on Monday time slot ok?

What do you think?

  ...ant



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Raymond's data transformation framework checked in for core2


Hi Raymond,

I now you posted a while back but people may have forgotten: could  
you explain or point us to the shortest-path algorithm you used  
(there was a picture) and describe the architectural approach you  
took with this?  Thanks a bunch.


Also, Ant, I see E4X listed.  Are you interested in providing input  
for that?


Jim

P.S. I'll post the patch tomorrow when I'm rested or if someone else  
gets to it before then, go for it.


On Jul 6, 2006, at 2:49 PM, Raymond Feng wrote:


Hi,

Here's the projects for the data transformation prototype:

1) databinding-framework: It contains the base interfaces and  
classes for the framework as well as transformer implementations  
for different XML parsing technologies such as DOM, StAX, and SAX.


2) databinding-axiom: Apache ws-common Axiom databinding
3) databinding-castor: Castor 1.0 databinding
4) databinding-jaxb: JAXB 2.0 databinding
5) databinding-sdo: SDO 2.0.1 databinding
6) databinding-xmlbeans: Apache XMLBeans 2.1
7) databinding-test: Integration test for transformation accross  
data bindings


The prototype has the following features:

1) Experimental interfaces:

DataBinding (represent metadata for a given databinding such as  
)


Transformer (performs object to object transformation, the  
sourceType and resultType is now represented by java classes, I'm  
thinking of using unique QNames)
TransformerRegistry (registers transformers and decide which path  
to use for given source/result databinding peers),


Mediator (provides the data mediation system service)

PushStyleTransformer (pushes events into the receiver handler)
DataPipe (receives events from the push-style transformer to  
populate the result object).
PushStyleTransformer connects to DataPipe to form a regular  
Transformer.


2) A directed and weighted graph with the shortest path algorithm.

3) Experimental Transformer implementations for various data  
bindings, including SDO, JAXB, XmlObjects, Axiom, Castor, StAX,  
DOM, Stream and String.


4) Maven build will automatically generates related classes for  
SDO, XmlObjects, JAXB and Castor based on ipo.xsd


5) Test cases demonstrate the usage

Here are some TODOs in my mind.

1) Define how to describe a data binding for SCA artifacts (for  
example, references and services), something like  
 (Potentially

a proposal for the spec?) as well as annotations
2) Finalize the contract interfaces and extensibility for the  
framework
3) Align the property story with the framework which may be able to  
present the property value in the specified databinding type to the  
component implementations

4) Add more data bindings such as E4X

Thanks,
Raymond

- Original Message - From: "Jim Marino"  
<[EMAIL PROTECTED]>

To: 
Sent: Thursday, July 06, 2006 8:17 AM
Subject: Raymond's data transformation framework checked in for core2


Thanks to Raymond, we have the start of an extensible data   
transformation framework for core2. I've checked it in for him  
but  have not added it to the build since I couldn't get the  
plugins to  download properly (it may just be the maven repo at  
Sun was down).  Raymond, could you take a look and since it is  
checked in, we can  work from patches now on?


I'll let Raymond describe what he did but it looks like it handles  
a number of databinding frameworks, including SDO, JAXB, Castor,  
Axiom  and XMLBeans.


I think it would also be interesting to see if we could add E4X   
support. Ant, are you interested in this, since you have been  
active  with JavaScript and have mentioned using E4X in  
transformation  scenarios in the past?


Thanks Raymond!

Jim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposed approach for M2



On Jul 6, 2006, at 12:05 PM, Simon Nash wrote:


Jeremy,

Jeremy Boynes wrote:

On Jul 6, 2006, at 2:17 AM, Simon Nash wrote:


The point here is not how large someone's code is but whether  
they  are working with others in the community. As you point out,  
there has  been quite a bit of discussion over the last few days  
on how we  should move forward, discussion in which many people  
have engaged but  in which Sebastien has remained silent. Rather  
than work with others  to improve the model we already have, he  
chose to start over on his  own with a completely new architecture  
titled "m2-design." This isn't  asking for constructive  
discussion, it's throwing gasoline on the fire.
I don't see Sebastien's actions as implying the motives that you  
suggest.

Anyone can be offline for a couple of days, especially over a holiday
time, without this meaning that they are not engaging with the  
community.
And I can see no justification for your statement that putting  
forward a

new idea in the form of some prototype interface code, with a covering
note asking for community reaction and feedback, is in any sense  
failing
to work with the community but an act of throwing gasoline on the  
fire.


As Jim says, we all need to work together constructively on this.
I believe this means being open to new ideas, even if they involve  
some

rework of code that already exists.  To simply dismiss such ideas out
of hand does not move us forward technically and does not help with
community building either.
Simon, I've have to say I am shocked or maybe just not understanding  
what you mean...hopefully it is the latter. When has anyone dismissed  
Sebastien's ideas "out of hand"? I'm completely frustrated that not a  
single one of my questions have been answered, vacations not  
withstanding (no excuse in my book as I'm on vacation too). Moreover,  
this is a pattern that has repeated itself time and again. Both  
Jeremy and I spent significant time preparing the core2  
presentation...some people responded but, perhaps not surprisingly,  
none of the vocal proponents of starting afresh. We've asked numerous  
times in emails to the list, IRC, at ApacheCon, on the phone, etc.  
for those people to offer concrete suggestions for improving core2.  
No response. I replied to several emails on the list that spoke of  
the "starting over" in very broad terms. No response. I started the  
wiki page on scenarios. Again, no response from the proponents of  
starting afresh.


What needs to be done to elicit a response? It was even suggested  
that Sebastien present his ideas, as Jeremy and I did.  I'm willing  
to block out however much time it takes, I assume at least four hours  
one day, perhaps up to eight. Again, no response. If you'd like to  
see a microcosm of this, please read the IRC log for today.


This is hardly the type of positive community building I imagined  
when starting this project. To me, it sounds like a group of  
individuals talking in generalizations who have no interest in  
community building and just want their way without doing any of the  
leg work to earn it.




In terms of open-mindedness, Jim and I have already engaged on  
the  technical issues Sebastien brought up in his mail, just like  
we and  other community members did on the scenario thread. As  
these things  usually go, on some issues there's agreement, on  
some there are  differences of opinion, and others need more  
clarification. I look  forward to others joining this kind of  
constructive discussion so  that we can come to consensus.  
However, all the technical issues he  raised can be addressed by  
the incremental improvement approach and  none seem to warrant  
starting over; using something like using a List  vs. Map to  
justify a re-write is simply hyperbole.
Your statement here that Sebastien is justifying a rewrite based on  
this

one issue is a hyperbole that does not reflect the post that he sent.
He listed a number of suggestions of which this was only one.  If  
these
are each taken separately, then each of them can be reduced to  
something
that could potentially be added incrementally to core2.  If they  
are all

taken together, then it is valid to ask the question (as Sebastien has
done) whether core2 is the best starting point or whether a different
approach is preferable.
All of them taken as a whole, even assuming they are correct (which I  
do not believe they are) would hardly amount to a rewrite. In fact,  
none of the criticisms would even affect the core2 runtime as the  
model is decoupled from it (one of the things we fixed w.r.t. to M1).  
Do you believe otherwise? If so, let's get down and talk specifics,  
instead of dancing around this issues.


Far from being negative, I am glad that we finally have these  
social  issues out of smoke-filled rooms and onto the table. This  
kind of  thing is never a pleasant discussion but is one that must  
be had if  we are to function as a commu

Re: Email versus IRC

2006-07-06 Thread Kevin Williams


This sounds good to me. +1

Jeremy Boynes wrote:

I'd like to see if I can recap where this thread went. There seem to  
be two sets of opinion:


1) that regular scheduled chats are helpful
2) that impromptu, unscheduled chats are helpful

In light of this, I'd like to propose the following IRC policy for  
the project:


==
We will hold a regular scheduled chat at the current time (15:30GMT  
every Monday) to discuss non-urgent things that people may be  
interested in. Subjects should be posted to the list in advance so  
that people can make a decision on whether to attend; attendance is  
encouraged but optional. The folk that show up get to choose what is  
discussed.


We will also hold pre-announced chats at other times so try and bring  
closure to issues that seem to be dragging on in email threads. The  
point of these is to come to a decision and such outcomes must be  
posted to the list for all to review. It is the discussion on the  
list that is binding.


In general we will encourage community members to hang out on the IRC  
channel so that anyone can hold an impromptu discussion with folk  
that happen to be around. We especially encourage committers to be  
available so that new users have a way to reach someone. Any  
decisions should be summarized to the list.

==

I hope that captures everyone's thoughts and if so I'd suggest we put  
it on the website.

If not, how about meeting on IRC to close this out?

--
Jeremy

On Jul 5, 2006, at 3:04 AM, ant elder wrote:

There's a thread going on over on incubator-general about the use  of 
IRC:

http://marc.theaimsgroup.com/?t=11511128601&r=1&w=2

Are people happy with having our current weekly hour long IRC chat?  
I find
the chat a useful way to find whats going on and gauge peoples  
opinions. A 1

hour chat isn't so long that its hard to read the chat log, we could
probably do better at providing a summary of what was said, and  
maybe post

the log and summary on the wiki so its easier to find. So I think the
current chat is useful and works ok but we can change this if  others 
don't

like it.

Currently the chat focus has been primarily Java SCA, should we try  and
include C++ or SDO or DAS more? Or have separate extra chats for  those?
Often the chat is one long rambling conversation, should we try to  
be more
structured and have a set 10 minutes for this, 10 minutes for that  
type of
thing to just get a regular status and have any followup discussion  
on the

mailing list?

Is the 15:30GMT on Monday time slot ok?

What do you think?

  ...ant




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]








-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Raymond's data transformation framework checked in for core2

2006-07-06 Thread Raymond Feng


Hi,

Here's the projects for the data transformation prototype:

1) databinding-framework: It contains the base interfaces and classes for 
the framework as well as transformer implementations for different XML 
parsing technologies such as DOM, StAX, and SAX.


2) databinding-axiom: Apache ws-common Axiom databinding
3) databinding-castor: Castor 1.0 databinding
4) databinding-jaxb: JAXB 2.0 databinding
5) databinding-sdo: SDO 2.0.1 databinding
6) databinding-xmlbeans: Apache XMLBeans 2.1
7) databinding-test: Integration test for transformation accross data 
bindings


The prototype has the following features:

1) Experimental interfaces:

DataBinding (represent metadata for a given databinding such as 
)


Transformer (performs object to object transformation, the sourceType and 
resultType is now represented by java classes, I'm thinking of using unique 
QNames)
TransformerRegistry (registers transformers and decide which path to use for 
given source/result databinding peers),


Mediator (provides the data mediation system service)

PushStyleTransformer (pushes events into the receiver handler)
DataPipe (receives events from the push-style transformer to populate the 
result object).

PushStyleTransformer connects to DataPipe to form a regular Transformer.

2) A directed and weighted graph with the shortest path algorithm.

3) Experimental Transformer implementations for various data bindings, 
including SDO, JAXB, XmlObjects, Axiom, Castor, StAX, DOM, Stream and 
String.


4) Maven build will automatically generates related classes for SDO, 
XmlObjects, JAXB and Castor based on ipo.xsd


5) Test cases demonstrate the usage

Here are some TODOs in my mind.

1) Define how to describe a data binding for SCA artifacts (for example, 
references and services), something like  (Potentially

a proposal for the spec?) as well as annotations
2) Finalize the contract interfaces and extensibility for the framework
3) Align the property story with the framework which may be able to present 
the property value in the specified databinding type to the component 
implementations

4) Add more data bindings such as E4X

Thanks,
Raymond

- Original Message - 
From: "Jim Marino" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, July 06, 2006 8:17 AM
Subject: Raymond's data transformation framework checked in for core2


Thanks to Raymond, we have the start of an extensible data  transformation 
framework for core2. I've checked it in for him but  have not added it to 
the build since I couldn't get the plugins to  download properly (it may 
just be the maven repo at Sun was down).  Raymond, could you take a look 
and since it is checked in, we can  work from patches now on?


I'll let Raymond describe what he did but it looks like it handles a 
number of databinding frameworks, including SDO, JAXB, Castor, Axiom  and 
XMLBeans.


I think it would also be interesting to see if we could add E4X  support. 
Ant, are you interested in this, since you have been active  with 
JavaScript and have mentioned using E4X in transformation  scenarios in 
the past?


Thanks Raymond!

Jim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Email versus IRC

+1

that just about covers it from my point of view. I'd also be interested in
experimenting with a 1hr email session. Email is pretty fast nowadays and
refreshing and responding via the mailing list could also work. It would
also remove the really annoying thing about IRC which is the loss of context
on the msgs. For example:

Fred: I propose X as the best solution
Joe: Y is better
Bill: I agree

Of course Bill was actually agreeing with Fred but the pathetically slow IRC
response (at least on my system) combined with many people "talking" at once
causes confusion.

I guess I just don't like IRC ;-)

I will attend when I can tho...

On 06/07/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

I'd like to see if I can recap where this thread went. There seem to
be two sets of opinion:

1) that regular scheduled chats are helpful
2) that impromptu, unscheduled chats are helpful

In light of this, I'd like to propose the following IRC policy for
the project:

==
We will hold a regular scheduled chat at the current time (15:30GMT
every Monday) to discuss non-urgent things that people may be
interested in. Subjects should be posted to the list in advance so
that people can make a decision on whether to attend; attendance is
encouraged but optional. The folk that show up get to choose what is
discussed.

We will also hold pre-announced chats at other times so try and bring
closure to issues that seem to be dragging on in email threads. The
point of these is to come to a decision and such outcomes must be
posted to the list for all to review. It is the discussion on the
list that is binding.

In general we will encourage community members to hang out on the IRC
channel so that anyone can hold an impromptu discussion with folk
that happen to be around. We especially encourage committers to be
available so that new users have a way to reach someone. Any
decisions should be summarized to the list.
==

I hope that captures everyone's thoughts and if so I'd suggest we put
it on the website.
If not, how about meeting on IRC to close this out?

--
Jeremy

On Jul 5, 2006, at 3:04 AM, ant elder wrote:

> There's a thread going on over on incubator-general about the use
> of IRC:
> http://marc.theaimsgroup.com/?t=11511128601&r=1&w=2
>
> Are people happy with having our current weekly hour long IRC chat?
> I find
> the chat a useful way to find whats going on and gauge peoples
> opinions. A 1
> hour chat isn't so long that its hard to read the chat log, we could
> probably do better at providing a summary of what was said, and
> maybe post
> the log and summary on the wiki so its easier to find. So I think the
> current chat is useful and works ok but we can change this if
> others don't
> like it.
>
> Currently the chat focus has been primarily Java SCA, should we try
> and
> include C++ or SDO or DAS more? Or have separate extra chats for
> those?
> Often the chat is one long rambling conversation, should we try to
> be more
> structured and have a set 10 minutes for this, 10 minutes for that
> type of
> thing to just get a regular status and have any followup discussion
> on the
> mailing list?
>
> Is the 15:30GMT on Monday time slot ok?
>
> What do you think?
>
>   ...ant

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Pete

Re: Raymond's data transformation framework checked in for core2

2006-07-06 Thread Raymond Feng


Hi, Jim.

Thank you for checking them into the sandbox.

Here's a patch enabling the build and test for all the projects. I found out 
the Sun's jaxb-impl 2.0.1 has an incorrect dependency to jaxb-api 2.0.1 
which doesn't exist. I downgraded it to jaxb-impl 2.0.


I'll post a list of features and todos to the mailling list later.

Thanks,
Raymond


- Original Message - 
From: "Jim Marino" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, July 06, 2006 8:17 AM
Subject: Raymond's data transformation framework checked in for core2


Thanks to Raymond, we have the start of an extensible data  transformation 
framework for core2. I've checked it in for him but  have not added it to 
the build since I couldn't get the plugins to  download properly (it may 
just be the maven repo at Sun was down).  Raymond, could you take a look 
and since it is checked in, we can  work from patches now on?


I'll let Raymond describe what he did but it looks like it handles a 
number of databinding frameworks, including SDO, JAXB, Castor, Axiom  and 
XMLBeans.


I think it would also be interesting to see if we could add E4X  support. 
Ant, are you interested in this, since you have been active  with 
JavaScript and have mentioned using E4X in transformation  scenarios in 
the past?


Thanks Raymond!

Jim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Index: databinding-test/pom.xml
===
--- databinding-test/pom.xml(revision 419645)
+++ databinding-test/pom.xml(working copy)
@@ -43,6 +43,12 @@
compile


+   com.sun.xml.bind
+   jaxb-impl
+   2.0
+   test
+   
+   
org.apache.tuscany.databinding
databinding-xmlbeans
${pom.version}
Index: databinding-jaxb/pom.xml
===
--- databinding-jaxb/pom.xml(revision 419645)
+++ databinding-jaxb/pom.xml(working copy)
@@ -40,7 +40,9 @@

com.sun.xml.bind
jaxb-impl
-   2.0.1
+   
+   2.0
test


Index: pom.xml
===
--- pom.xml (revision 419645)
+++ pom.xml (working copy)
@@ -29,7 +29,6 @@
Tuscany SCA Data Bindings


-


+   

+   
+   junit
+   junit
+   
+
+   
+   jmock
+   jmock
+   
+
+   
+


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Email versus IRC

I'd like to see if I can recap where this thread went. There seem to  
be two sets of opinion:


1) that regular scheduled chats are helpful
2) that impromptu, unscheduled chats are helpful

In light of this, I'd like to propose the following IRC policy for  
the project:


==
We will hold a regular scheduled chat at the current time (15:30GMT  
every Monday) to discuss non-urgent things that people may be  
interested in. Subjects should be posted to the list in advance so  
that people can make a decision on whether to attend; attendance is  
encouraged but optional. The folk that show up get to choose what is  
discussed.


We will also hold pre-announced chats at other times so try and bring  
closure to issues that seem to be dragging on in email threads. The  
point of these is to come to a decision and such outcomes must be  
posted to the list for all to review. It is the discussion on the  
list that is binding.


In general we will encourage community members to hang out on the IRC  
channel so that anyone can hold an impromptu discussion with folk  
that happen to be around. We especially encourage committers to be  
available so that new users have a way to reach someone. Any  
decisions should be summarized to the list.

==

I hope that captures everyone's thoughts and if so I'd suggest we put  
it on the website.

If not, how about meeting on IRC to close this out?

--
Jeremy

On Jul 5, 2006, at 3:04 AM, ant elder wrote:

There's a thread going on over on incubator-general about the use  
of IRC:

http://marc.theaimsgroup.com/?t=11511128601&r=1&w=2

Are people happy with having our current weekly hour long IRC chat?  
I find
the chat a useful way to find whats going on and gauge peoples  
opinions. A 1

hour chat isn't so long that its hard to read the chat log, we could
probably do better at providing a summary of what was said, and  
maybe post

the log and summary on the wiki so its easier to find. So I think the
current chat is useful and works ok but we can change this if  
others don't

like it.

Currently the chat focus has been primarily Java SCA, should we try  
and
include C++ or SDO or DAS more? Or have separate extra chats for  
those?
Often the chat is one long rambling conversation, should we try to  
be more
structured and have a set 10 minutes for this, 10 minutes for that  
type of
thing to just get a regular status and have any followup discussion  
on the

mailing list?

Is the 15:30GMT on Monday time slot ok?

What do you think?

  ...ant



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Publish Tuscany C++ M1 release


I have posted a candidate for the first C++ release here:

http://people.apache.org/~robbinspg/RC1

The code is tagged in svn:
http://svn.apache.org/repos/asf/incubator/tuscany/tags/cpp-0.1.incubating-M1/



Please vote to publish the Milestone 1 release distributions. Please
take some time to download the distributions, review them and test them
in your environment before voting.

The vote is open for the next 72 hours, please vote by July 9th,
23:00 BST. At least three +1 votes are required, and only the votes from
Tuscany committers are binding. If the majority of all votes is
positive, I will send a summary of that vote to the Incubator's general
list to formally request the Incubator PMC to approve the Tuscany C++
Milestone 1 release. For your reference the Incubator release policy
guidelines are available at
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases.


Release Summary
=

Tuscany SCA C++ provides a runtime implementation for the Service Component
Architecture 0.9 specification, written in C++ and will currently support
C++
component implementation types. This is not yet a complete implementation
and
known restrictions are described below.

Supported SCA Assembly Model features
 *  All features are supported unless listed under the known restrictions
below. See SCA Assembly Model specification.

Supported language bindings
 * Component implementations written in C++. See SCA Client and
   Implementation Model specification.
 * Component interfaces described by C++ classes. See SCA Client and
   Implementation Model specification.

Supported external service and entry point bindings
 * The web service binding is supported. This implementation will support
   web services which using document literal SOAP bindings conforming to
the
   WS-I basic profile (rpc/encoded is not yet supported).

Known restrictions
 * Subsystem: wiring, entry points and external services are not supported.
 * Local service interfaces cannot use overloaded operations (the SCA
   specification limits remote service interfaces to not using
overloaded operations).
 * Each WSDL definition for a web service binding must be in a single WSDL
document.
 * No load time validation of the deployed SCA application (run time
validation only).
 * No metadata API.

A sample is included which demonstrates deploying an SCA module, component
wiring, locating and invoking C++ service from C++ component,  invoking from
a C++ client, and exposing a service as a web service using ws binding.


Cheers,

--
Pete

Re: Proposed approach for M2


On Jul 6, 2006, at 12:05 PM, Simon Nash wrote:


Jeremy,

Jeremy Boynes wrote:

On Jul 6, 2006, at 2:17 AM, Simon Nash wrote:


The point here is not how large someone's code is but whether  
they  are working with others in the community. As you point out,  
there has  been quite a bit of discussion over the last few days  
on how we  should move forward, discussion in which many people  
have engaged but  in which Sebastien has remained silent. Rather  
than work with others  to improve the model we already have, he  
chose to start over on his  own with a completely new architecture  
titled "m2-design." This isn't  asking for constructive  
discussion, it's throwing gasoline on the fire.
I don't see Sebastien's actions as implying the motives that you  
suggest.

Anyone can be offline for a couple of days, especially over a holiday
time, without this meaning that they are not engaging with the  
community.


Of course. It's not the time factor that's the issue here but the way  
in which Sebastien ignored all the discussion that other people had  
been doing during that time. We all take time off, although perhaps  
going dark just after launching what was bound to be a controversial  
thread was not such a good idea. However, if you do take time away,  
it is only common courtesy to catch up on discussions that have taken  
place before jumping back in.


And I can see no justification for your statement that putting  
forward a

new idea in the form of some prototype interface code, with a covering
note asking for community reaction and feedback, is in any sense  
failing
to work with the community but an act of throwing gasoline on the  
fire.


That is unfortunate.


As Jim says, we all need to work together constructively on this.
I believe this means being open to new ideas, even if they involve  
some

rework of code that already exists.  To simply dismiss such ideas out
of hand does not move us forward technically and does not help with
community building either.


What you are not saying here is that both Jim and I posted  
constructive, technical comments in our replies to Sebastien's email;  
you actually cut mine out of your first response. That omission,  
combined with phrases such as "dismiss such ideas out out hand" is  
disingenuous, if not downright misleading.


All ideas that Sebastien has proposed are being considered - we had a  
long discussion on these very things on IRC this morning. The main  
questions being asked about his proposal are "what is the benefit of  
starting over?" and "why can we not start with what we already have  
in the sandbox?" One of the problems here is that there are no clear  
answers to them.


In terms of open-mindedness, Jim and I have already engaged on  
the  technical issues Sebastien brought up in his mail, just like  
we and  other community members did on the scenario thread. As  
these things  usually go, on some issues there's agreement, on  
some there are  differences of opinion, and others need more  
clarification. I look  forward to others joining this kind of  
constructive discussion so  that we can come to consensus.  
However, all the technical issues he  raised can be addressed by  
the incremental improvement approach and  none seem to warrant  
starting over; using something like using a List  vs. Map to  
justify a re-write is simply hyperbole.
Your statement here that Sebastien is justifying a rewrite based on  
this

one issue is a hyperbole that does not reflect the post that he sent.
He listed a number of suggestions of which this was only one.  If  
these
are each taken separately, then each of them can be reduced to  
something
that could potentially be added incrementally to core2.  If they  
are all

taken together, then it is valid to ask the question (as Sebastien has
done) whether core2 is the best starting point or whether a different
approach is preferable.


It is, of course, a valid question to ask. So, looking at the whole  
set of questions and the responses so far, let me ask you - in your  
technical opinion, is there enough of a problem here to warrant  
throwing out what we have and starting over with a new architecture  
vs. taking an approach of incremental improvement? Or if we are not  
doing it for technical reasons, why are we doing it?




Far from being negative, I am glad that we finally have these  
social  issues out of smoke-filled rooms and onto the table. This  
kind of  thing is never a pleasant discussion but is one that must  
be had if  we are to function as a community.

I am fine with technical debate and I think this is very healthy and
should be happening in the open on this list.  However, when people
express technical opinions or put forward technical proposals, I don't
think it is appropriate to respond with a personal attack implying  
that

some anti-community motive lies behind a technical proposal or idea.


It wasn't meant as a personal attack and at no time did I intend to  
s

Re: Proposed approach for M2

2006-07-06 Thread Simon Nash


Jim Marino wrote:






We will only reach the right conclusion on
this important debate if we all engage constructively at a technical
level and evaluate new contributions and ideas in an open-minded way.
Your apparent characterization of Sebastien's constructive engagement
in this discussion as an attempt to "forge his own path" is unfair and
offensive, and not at all how I interpret Sebastien's recent posts.

Simon, I don't think that is fair and labeling it as offensive is  
unnecessarily caustic. Perhaps Jeremy could have worded some of his  
response better but I think *everyone* has been guilty of this over  the 
past several weeks so I'd prefer to make a general statement that  we 
all remain constructive since we are not doing a very good job of  
community building.



I have responded to Jeremy directly (on the list) so I won't repeat
my comments here.  I certainly agree that we all need to remain
constructive and I believe the best way to do this is to focus on
technical matters and give all ideas, suggestions, and proposals
a fair hearing.

My second point is that the desire for constructive discussion comes  
from *all* of us, not just Sebastien. For example, Jeremy spent a  
significant amount of time on the core2 architecture presentation a  
month back, numerous posts to the list, proposals (e.g. constructor  
injection), and scenarios, etc. - all of which were attempts to  
constructively engage the community.



Yes, I agree.  I was reacting to this particular post, and I was
not intending to imply that Jeremy's overall contribution to Tuscany
has been anything other than constructive.  I think it is a good
principle to assume that everyone's desire is to participate
constructively and to regard all technical proposals and contributions
as attempts to be constructive.

As I mentioned in a previous post, moving the community forward  starts 
with positive individual acts. Perhaps you could engage by  positing 
scenarios to the wiki you are interested in, or respond to  my response 
to Sebastien asking why any of the changes he mentioned  could not be 
incrementally accommodated by core2? This approach  sounds to me like a 
nice way to accommodate the interests of many and  move things forward.



I'm on vacation this week and I have very limited time available for
work-related activity.  I should be able to get more involved in the
constructive ways that you suggest when I return to work next week.

  Simon
--
Simon C Nash   IBM Distinguished Engineer
Hursley Park, Winchester, UK   [EMAIL PROTECTED]
Tel. +44-1962-815156   Fax +44-1962-818999


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposed approach for M2

2006-07-06 Thread Simon Nash


Jeremy,

Jeremy Boynes wrote:

On Jul 6, 2006, at 2:17 AM, Simon Nash wrote:



The point here is not how large someone's code is but whether they  are 
working with others in the community. As you point out, there has  been 
quite a bit of discussion over the last few days on how we  should move 
forward, discussion in which many people have engaged but  in which 
Sebastien has remained silent. Rather than work with others  to improve 
the model we already have, he chose to start over on his  own with a 
completely new architecture titled "m2-design." This isn't  asking for 
constructive discussion, it's throwing gasoline on the fire.



I don't see Sebastien's actions as implying the motives that you suggest.
Anyone can be offline for a couple of days, especially over a holiday
time, without this meaning that they are not engaging with the community.
And I can see no justification for your statement that putting forward a
new idea in the form of some prototype interface code, with a covering
note asking for community reaction and feedback, is in any sense failing
to work with the community but an act of throwing gasoline on the fire.

As Jim says, we all need to work together constructively on this.
I believe this means being open to new ideas, even if they involve some
rework of code that already exists.  To simply dismiss such ideas out
of hand does not move us forward technically and does not help with
community building either.

In terms of open-mindedness, Jim and I have already engaged on the  
technical issues Sebastien brought up in his mail, just like we and  
other community members did on the scenario thread. As these things  
usually go, on some issues there's agreement, on some there are  
differences of opinion, and others need more clarification. I look  
forward to others joining this kind of constructive discussion so  that 
we can come to consensus. However, all the technical issues he  raised 
can be addressed by the incremental improvement approach and  none seem 
to warrant starting over; using something like using a List  vs. Map to 
justify a re-write is simply hyperbole.



Your statement here that Sebastien is justifying a rewrite based on this
one issue is a hyperbole that does not reflect the post that he sent.
He listed a number of suggestions of which this was only one.  If these
are each taken separately, then each of them can be reduced to something
that could potentially be added incrementally to core2.  If they are all
taken together, then it is valid to ask the question (as Sebastien has
done) whether core2 is the best starting point or whether a different
approach is preferable.

Far from being negative, I am glad that we finally have these social  
issues out of smoke-filled rooms and onto the table. This kind of  thing 
is never a pleasant discussion but is one that must be had if  we are to 
function as a community.



I am fine with technical debate and I think this is very healthy and
should be happening in the open on this list.  However, when people
express technical opinions or put forward technical proposals, I don't
think it is appropriate to respond with a personal attack implying that
some anti-community motive lies behind a technical proposal or idea.

I hope we can agree to keep these discussions technical from now on.

Simon

--
Simon C Nash   IBM Distinguished Engineer
Hursley Park, Winchester, UK   [EMAIL PROTECTED]
Tel. +44-1962-815156   Fax +44-1962-818999


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RMI Binding

As discussed on IRC this morning, I have checked Venkat's RMI binding  
code from TUSCANY-467 into the sandbox. This is still based on the M1  
implementation but we wanted to have something in SVN to act as a  
baseline for discussion. It will not compile at this time so I have  
not incorporated it into the build.


--
Jeremy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposed approach for M2

2006-07-06 Thread Kenneth Tam

On 7/5/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
>
> My proposal is not to merge M1 and the core2 sandbox. I am
> proposing to start a new fresh code stream and build the runtime
> through baby steps. We may be able to reuse some pieces of existing
> code, but more important is to engage our community in this
> exercise and integrate the new ideas that will emerge from this.
>

I don't believe the two issues are necessarily coupled. Quite a few
members of the community are engaged on the sandbox code already and
we could work with you to improve that rather having to throw
everything out and start over with all new ideas.

+1 on improving the sandbox code -- it seems to me that there's a
certain mininum amount of code that needs to exist to really kickstart
a community-based solution to a problem of this scope, and I have a
hard time envisioning how starting a fresh code stream at this point
would result in anything noticeably smaller/simpler/more
comprehensible than what's already there in Core2.

> Here's an example where I'm struggling with both M1 and the core2
> sandbox and thinking that we can do better if we start with a new
> fresh stream.

I don't know the Core2 code well enough to mount a cogent technical
reply to these concerns off the top of my head -- my perspective is
simply that the best way to address such issues is to raise them here
in the community and discuss/prototype possible approaches in the
context of the existing code streams.

My experience has been that such discussions work much better in the
context of something functioning -- so before deciding to start (yet)
again, I'm hoping we can work to evolve what's already in svn.  I'm
able to regularly spend time on this project, but not near the
full-time level of some folks here.  For me, the Core2 code base has
been much more accessible and maps more naturally to my understanding
of the spec so far.. on that basis, if there's a desire to do
something differently, I'd very much like to see it made obvious how
that couldn't be accomodated in the context of Core2 before we hit the
reset button.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: C++ M1 Release Candidate


OK... there are a couple of fixes for VC7 compilation plus some
copyright/licence issues that will be resolved. I will respin the distro in
the next few hours and put up the candidate for a vote.

On 06/07/06, Edward Slattery <[EMAIL PROTECTED]> wrote:


Ive downloaded and built the src distro on Windows using the command line,
devstudio6 and devstudio7. The builds all work fine, but the calculator
sample on studio7 only half works as the project descriptions are missing
some of the proxies/wrappers. Add works but Div doesnt.
Im just going to fix that 

Ed.


On 06/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> The problem appears to be that WinXP expanding of a compressed folder
can
> not expand the tuscany_sca_cpp-0.1.incubating-M1-src.zip (despite the
fact
> that it was used to create the zip in the first place!). This zip can be
> successfully extracted using WinZip or even jar -xf so I am not going to
> update the zip.
>
> Any ideas on why WinXP zip expand has a problem?? I'm fairly sure that
it
> is
> to do with a long path name.
>
> Cheers,
>
>
> On 06/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >
> > There is a problem with the Windows src zip for sca to do with
filename
> > lengths. I will fix it and re-post a new zip.
> >
> >
> > On 06/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > >
> > >  I have posted a candidate for the first C++ release here.
> > >
> > > http://people.apache.org/~robbinspg/RC1
> > >
> > > Would all interested parties take some time to review this so that
we
> > > can either re-spin the release or vote on it asap.
> > >
> > > The website documentation is out of date and will be re-written to
> sync
> > > with what is in the release. Hopefully this will be done tomorrow.
> > >
> > > A Calculator sample is included which demonstrates deploying an SCA
> > > module, component wiring, locating and invoking C++ service from
> > > C++ component,  invoking from a C++ client, and exposing a service
as
> a web
> > > service using ws binding.
> > >
> > >
> > > Release Summary
> > > =
> > >
> > > Tuscany SCA C++ provides a runtime implementation for the Service
> > > Component
> > > Architecture 0.9 specification, written in C++ and will currently
> > > support C++
> > > component implementation types. This is not yet a complete
> > > implementation and
> > > known restrictions are described below.
> > >
> > > Supported SCA Assembly Model features
> > >   *  All features are supported unless listed under the known
> > > restrictions
> > >  below. See SCA Assembly Model specification.
> > >
> > > Supported language bindings
> > >   * Component implementations written in C++. See SCA Client and
> > > Implementation Model specification.
> > >   * Component interfaces described by C++ classes. See SCA Client
and
> > > Implementation Model specification.
> > >
> > > Supported external service and entry point bindings
> > >   * The web service binding is supported. This implementation will
> > > support
> > > web services which using document literal SOAP bindings
conforming
> > > to the
> > > WS-I basic profile (rpc/encoded is not yet supported).
> > >
> > > Known restrictions
> > >   * Subsystem: wiring, entry points and external services are not
> > > supported.
> > >   * Local service interfaces cannot use overloaded operations (the
SCA
> > > specification limits remote service interfaces to not using
> > > overloaded operations).
> > >   * Each WSDL definition for a web service binding must be in a
single
> > > WSDL document.
> > >   * No load time validation of the deployed SCA application (run
time
> > > validation only).
> > >   * No metadata API.
> > > --
> > > Pete
> > >
> >
> >
> >
> > --
> >
> > Pete
> >
>
>
>
> --
> Pete
>
>





--
Pete

Re: Proposed approach for M2

2006-07-06 Thread ant elder

Jeremy, as you know, its been holidays in the US this week and that will be
why Sebastien was quiet over the weekend and Monday and Tuesday. I've found
all his past posts on this sandbox topic most constructive and helpful.

  ...ant

On 7/6/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

On Jul 6, 2006, at 2:17 AM, Simon Nash wrote:

> Jeremy,
>
> Jeremy Boynes wrote:
>
>> On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
> 
>>> I just checked in sandbox/sebastien/m2-design/model.spi a set of
>>> new interfaces. This is just an initial strawman to trigger a
>>> constructive discussion and ideas on how to best represent the
>>> recursive model. I also need help to define a scenario (not unit
>>> test cases, but an end to end sample application) to help put
>>> the  recursive composition model in perspective and make sure we
>>> all  understand it the same way.
>>>
>> I am troubled that you have chosen to start on your own codebase
>> at a  time when most of us have been trying to have constructive
>> discussion  on this list. Based on the approach you proposed in
>> your original  email I would have hoped that we could have started
>> with your end- user scenarios and had a chance to explore how they
>> could be  supported by M1, the sandbox, or some other code before
>> starting  another codebase. I'm disappointed that, having started
>> this very  thread nearly a week ago with the premise of community,
>> your first  response on it was to commit a large chunk of
>> independent code rather  than follow up with any of the other
>> people who have already  contributed to the discussion.
>> I think discussion led to compromise and consensus on the
>> scenario- driven approach that you proposed. As shown above and in
>> other recent  threads, there's plenty of room for improvements and/
>> or new features  in our current code and a willingness to discuss
>> them, albeit in  terms of technical merit rather than personal
>> opinion. I hope you can  find a way to join in rather than forge
>> your own path.
> This can by no stretch of the imagination be described as a "large
> chunk
> of independent code".  It consists of around 20 interfaces with no
> implementation.  Quite a bit of the discussion on this topic over the
> last few days has focused on what could be the advantages of starting
> a new code stream rather than continuing with either M1 or core2.  As
> Sebastien said in his post, the purpose of this code (as well as other
> suggestions he made in his latest post) is to trigger contructive
> discussion on new ideas that are not incrementally derived from either
> of the existing codebases.  When presenting such ideas, it is often
> helpful to see sample code rather that just a textual description.
>
> I am very disppointed at your negative reaction to this, which is
> about
> as far away as I can imagine from the constructive technical
> discussion
> that Sebastien asked for.  We will only reach the right conclusion on
> this important debate if we all engage constructively at a technical
> level and evaluate new contributions and ideas in an open-minded way.
> Your apparent characterization of Sebastien's constructive engagement
> in this discussion as an attempt to "forge his own path" is unfair and
> offensive, and not at all how I interpret Sebastien's recent posts.
>
>   Simon
>
> --
> Simon C Nash   IBM Distinguished Engineer
> Hursley Park, Winchester, UK   [EMAIL PROTECTED]
> Tel. +44-1962-815156   Fax +44-1962-818999

Simon,

The point here is not how large someone's code is but whether they
are working with others in the community. As you point out, there has
been quite a bit of discussion over the last few days on how we
should move forward, discussion in which many people have engaged but
in which Sebastien has remained silent. Rather than work with others
to improve the model we already have, he chose to start over on his
own with a completely new architecture titled "m2-design." This isn't
asking for constructive discussion, it's throwing gasoline on the fire.

In terms of open-mindedness, Jim and I have already engaged on the
technical issues Sebastien brought up in his mail, just like we and
other community members did on the scenario thread. As these things
usually go, on some issues there's agreement, on some there are
differences of opinion, and others need more clarification. I look
forward to others joining this kind of constructive discussion so
that we can come to consensus. However, all the technical issues he
raised can be addressed by the incremental improvement approach and
none seem to warrant starting over; using something like using a List
vs. Map to justify a re-write is simply hyperbole.

Far from being negative, I am glad that we finally have these social
issues out of smoke-filled rooms and onto the table. This kind of
thing is never a pleasant discussion but is one that must be had if
we are to function as a community.

--
Jeremy

---

RE: Support for callbacks

2006-07-06 Thread Meeraj Kunnumpurath

I have got an implementation based on Doug Lea's concurrent utilities
(JDK 1.4), I think this can be ported to use Java 5 concurrent
libraries. If you don't mind, I can start looking at this. 

-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED] 
Sent: 06 July 2006 16:12
To: tuscany-dev@ws.apache.org
Subject: Re: Support for callbacks


On Jul 6, 2006, at 8:04 AM, Meeraj Kunnumpurath wrote:

>>> Good point. I think a similar mechanism may be o.k. as long as we
> clean up properly when the request ends or the thread is reclaimed 
> (e.g.
> in case of failure where the callback never hapens). Perhaps we could 
> use the WorkArea API for this? Were you thinking of something in 
> particular?
>
> Have you looked at any commonj work manager (JSR-237) implementations?
>
Yep that's what I was thinking of with the WorkArea stuff. Right now we
reused Geronimo's WorkManager impl for the async dispatching but it
drags in a lot of dependencies for what it does. I was thinking we could
just write a thin implementation of WorkManager using the JDK 5
concurrency libraries and eliminate the dependencies. When we run in a
managed environment, we could swap implementations since the WorkManager
is set up as a system service.

I haven't had time to look at doing this so if anyone is interested (as
well as joining in on the callback work), it would be great.

Jim

> M
>
> -Original Message-
> From: Jim Marino [mailto:[EMAIL PROTECTED]
> Sent: 06 July 2006 16:01
> To: tuscany-dev@ws.apache.org
> Subject: Re: Support for callbacks
>
> Hi Ignacio,
>
> Sorry about the delay...Comments inline. I've also added some 
> scenarios to the wiki so feel free to add your thoughts to them.
>
> Jim
>
>
> On Jul 5, 2006, at 2:07 PM, Ignacio Silva-Lepe wrote:
>
>> Hi Jim,
>>
>> Sorry about the disconnect, I was out Monday and yesterday. I'll be 
>> sure to attend the IRC chat tomorrow. In the meantime, some more 
>> quick
>
>> comments.
>>
>> - Original Message - 
>>
 If I understand correctly, would a system service transport use a 
 low level communication mechanism, like a socket for instance? This

 does not  seem like an appropriate approach for a local scenario,
>>> Right, for the local scenario, I was thinking the callback instance 
>>> would be put on the thread local context and the proxy would access 
>>> it from there as opposed to going out over a socket and back in 
>>> through a listener. Basically, it would be an optimization of the 
>>> remote case. I think we can further optimize things depending on 
>>> scopes, e.g. if the callback scope is "module", we could possibly 
>>> avoid threadlocal storage and have the proxy hold on to an instance 
>>> directly.
>>
>> Pointing at the callback instance directly from the proxy would 
>> eliminate invocation chains and the ability to add interceptors to 
>> them, wouldn't it?
>
> Yea the proxy should probably point back to the Component and not the 
> instance directly unless there is an optimized case where no 
> interceptors were present. Once the proxy points to Component, it can 
> call getInboundWire(String serviceName) which will return the 
> invocation chain that will dispatch to the correct instance. In the 
> case of an AtomicComponent, when the end of the chain is reached, the 
> target invoker will delegate to the scope container which will return 
> the right instance.
>
>
>> Also, I'm not sure using a thread local in the core is a good idea if

>> an intention is to allow the core to be embeddable in, for instance, 
>> a
>
>> managed environment, as thread local does not necessarily mix well 
>> with thread pools.
>>
> Good point. I think a similar mechanism may be o.k. as long as we 
> clean up properly when the request ends or the thread is reclaimed 
> (e.g. in case of failure where the callback never hapens). Perhaps we 
> could use the WorkArea API for this? Were you thinking of something in

> particular?
>
> Jim
>
>> 
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> This message has been checked for all email viruses by MessageLabs.
>
>
>
>
> *
>
> You can find us at www.voca.com
>
> *
> This communication is confidential and intended for the exclusive use 
> of the addressee only. You should not disclose its contents to any 
> other person.
> If you are not the intended recipient please notify the sender named 
> above immediately.
>
> Registered in England, No 1023742,
> Registered Office: Voca Limited
> Drake House, Three Rivers Court,
> Homestead Road, Rickmansworth,
> Hertfordshire, WD3 1FX
>
>
> This me

RE: Raymond's data transformation framework checked in for core2

2006-07-06 Thread Liu, Jervis

Hi, this is a good news. I will try to use this in Celtix binding. 

Thanks,
Jervis

-Original Message- 
From: Jim Marino [mailto:[EMAIL PROTECTED] 
Sent: 7/6/2006 (星期四) 11:17 下午 
To: tuscany-dev@ws.apache.org 
Cc: 
Subject: Raymond's data transformation framework checked in for core2 

Thanks to Raymond, we have the start of an extensible data 
transformation framework for core2. I've checked it in for him but 
have not added it to the build since I couldn't get the plugins to 
download properly (it may just be the maven repo at Sun was down). 
Raymond, could you take a look and since it is checked in, we can 
work from patches now on?

I'll let Raymond describe what he did but it looks like it handles a 
number of databinding frameworks, including SDO, JAXB, Castor, Axiom 
and XMLBeans.

I think it would also be interesting to see if we could add E4X 
support. Ant, are you interested in this, since you have been active 
with JavaScript and have mentioned using E4X in transformation 
scenarios in the past?

Thanks Raymond!

Jim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposed approach for M2


On Jul 6, 2006, at 2:17 AM, Simon Nash wrote:


Jeremy,

Jeremy Boynes wrote:


On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:


I just checked in sandbox/sebastien/m2-design/model.spi a set of   
new interfaces. This is just an initial strawman to trigger a   
constructive discussion and ideas on how to best represent the   
recursive model. I also need help to define a scenario (not unit   
test cases, but an end to end sample application) to help put  
the  recursive composition model in perspective and make sure we  
all  understand it the same way.


I am troubled that you have chosen to start on your own codebase  
at a  time when most of us have been trying to have constructive  
discussion  on this list. Based on the approach you proposed in  
your original  email I would have hoped that we could have started  
with your end- user scenarios and had a chance to explore how they  
could be  supported by M1, the sandbox, or some other code before  
starting  another codebase. I'm disappointed that, having started  
this very  thread nearly a week ago with the premise of community,  
your first  response on it was to commit a large chunk of  
independent code rather  than follow up with any of the other  
people who have already  contributed to the discussion.
I think discussion led to compromise and consensus on the  
scenario- driven approach that you proposed. As shown above and in  
other recent  threads, there's plenty of room for improvements and/ 
or new features  in our current code and a willingness to discuss  
them, albeit in  terms of technical merit rather than personal  
opinion. I hope you can  find a way to join in rather than forge  
your own path.
This can by no stretch of the imagination be described as a "large  
chunk

of independent code".  It consists of around 20 interfaces with no
implementation.  Quite a bit of the discussion on this topic over the
last few days has focused on what could be the advantages of starting
a new code stream rather than continuing with either M1 or core2.  As
Sebastien said in his post, the purpose of this code (as well as other
suggestions he made in his latest post) is to trigger contructive
discussion on new ideas that are not incrementally derived from either
of the existing codebases.  When presenting such ideas, it is often
helpful to see sample code rather that just a textual description.

I am very disppointed at your negative reaction to this, which is  
about
as far away as I can imagine from the constructive technical  
discussion

that Sebastien asked for.  We will only reach the right conclusion on
this important debate if we all engage constructively at a technical
level and evaluate new contributions and ideas in an open-minded way.
Your apparent characterization of Sebastien's constructive engagement
in this discussion as an attempt to "forge his own path" is unfair and
offensive, and not at all how I interpret Sebastien's recent posts.

  Simon

--
Simon C Nash   IBM Distinguished Engineer
Hursley Park, Winchester, UK   [EMAIL PROTECTED]
Tel. +44-1962-815156   Fax +44-1962-818999


Simon,

The point here is not how large someone's code is but whether they  
are working with others in the community. As you point out, there has  
been quite a bit of discussion over the last few days on how we  
should move forward, discussion in which many people have engaged but  
in which Sebastien has remained silent. Rather than work with others  
to improve the model we already have, he chose to start over on his  
own with a completely new architecture titled "m2-design." This isn't  
asking for constructive discussion, it's throwing gasoline on the fire.


In terms of open-mindedness, Jim and I have already engaged on the  
technical issues Sebastien brought up in his mail, just like we and  
other community members did on the scenario thread. As these things  
usually go, on some issues there's agreement, on some there are  
differences of opinion, and others need more clarification. I look  
forward to others joining this kind of constructive discussion so  
that we can come to consensus. However, all the technical issues he  
raised can be addressed by the incremental improvement approach and  
none seem to warrant starting over; using something like using a List  
vs. Map to justify a re-write is simply hyperbole.


Far from being negative, I am glad that we finally have these social  
issues out of smoke-filled rooms and onto the table. This kind of  
thing is never a pleasant discussion but is one that must be had if  
we are to function as a community.


--
Jeremy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Raymond's data transformation framework checked in for core2

Thanks to Raymond, we have the start of an extensible data  
transformation framework for core2. I've checked it in for him but  
have not added it to the build since I couldn't get the plugins to  
download properly (it may just be the maven repo at Sun was down).  
Raymond, could you take a look and since it is checked in, we can  
work from patches now on?


I'll let Raymond describe what he did but it looks like it handles a  
number of databinding frameworks, including SDO, JAXB, Castor, Axiom  
and XMLBeans.


I think it would also be interesting to see if we could add E4X  
support. Ant, are you interested in this, since you have been active  
with JavaScript and have mentioned using E4X in transformation  
scenarios in the past?


Thanks Raymond!

Jim
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support for callbacks



On Jul 6, 2006, at 8:04 AM, Meeraj Kunnumpurath wrote:


Good point. I think a similar mechanism may be o.k. as long as we
clean up properly when the request ends or the thread is reclaimed  
(e.g.

in case of failure where the callback never hapens). Perhaps we could
use the WorkArea API for this? Were you thinking of something in
particular?

Have you looked at any commonj work manager (JSR-237) implementations?

Yep that's what I was thinking of with the WorkArea stuff. Right now  
we reused Geronimo's WorkManager impl for the async dispatching but  
it drags in a lot of dependencies for what it does. I was thinking we  
could just write a thin implementation of WorkManager using the JDK 5  
concurrency libraries and eliminate the dependencies. When we run in  
a managed environment, we could swap implementations since the  
WorkManager is set up as a system service.


I haven't had time to look at doing this so if anyone is interested  
(as well as joining in on the callback work), it would be great.


Jim


M

-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 06 July 2006 16:01
To: tuscany-dev@ws.apache.org
Subject: Re: Support for callbacks

Hi Ignacio,

Sorry about the delay...Comments inline. I've also added some  
scenarios

to the wiki so feel free to add your thoughts to them.

Jim


On Jul 5, 2006, at 2:07 PM, Ignacio Silva-Lepe wrote:


Hi Jim,

Sorry about the disconnect, I was out Monday and yesterday. I'll be
sure to attend the IRC chat tomorrow. In the meantime, some more  
quick



comments.

- Original Message - 


If I understand correctly, would a system service transport use a
low level communication mechanism, like a socket for instance? This
does not  seem like an appropriate approach for a local scenario,

Right, for the local scenario, I was thinking the callback instance
would be put on the thread local context and the proxy would access
it from there as opposed to going out over a socket and back in
through a listener. Basically, it would be an optimization of the
remote case. I think we can further optimize things depending on
scopes, e.g. if the callback scope is "module", we could possibly
avoid threadlocal storage and have the proxy hold on to an instance
directly.


Pointing at the callback instance directly from the proxy would
eliminate invocation chains and the ability to add interceptors to
them, wouldn't it?


Yea the proxy should probably point back to the Component and not the
instance directly unless there is an optimized case where no
interceptors were present. Once the proxy points to Component, it can
call getInboundWire(String serviceName) which will return the  
invocation

chain that will dispatch to the correct instance. In the case of an
AtomicComponent, when the end of the chain is reached, the target
invoker will delegate to the scope container which will return the  
right

instance.



Also, I'm not sure using a thread local in the core is a good idea if
an intention is to allow the core to be embeddable in, for  
instance, a



managed environment, as thread local does not necessarily mix well
with thread pools.

Good point. I think a similar mechanism may be o.k. as long as we  
clean

up properly when the request ends or the thread is reclaimed (e.g. in
case of failure where the callback never hapens). Perhaps we could use
the WorkArea API for this? Were you thinking of something in  
particular?


Jim





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


This message has been checked for all email viruses by MessageLabs.




*

You can find us at www.voca.com

*
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX


This message has been checked for all email viruses by MessageLabs.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Support for callbacks

2006-07-06 Thread Meeraj Kunnumpurath

>>Good point. I think a similar mechanism may be o.k. as long as we
clean up properly when the request ends or the thread is reclaimed (e.g.
in case of failure where the callback never hapens). Perhaps we could
use the WorkArea API for this? Were you thinking of something in
particular?

Have you looked at any commonj work manager (JSR-237) implementations?

M

-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED] 
Sent: 06 July 2006 16:01
To: tuscany-dev@ws.apache.org
Subject: Re: Support for callbacks

Hi Ignacio,

Sorry about the delay...Comments inline. I've also added some scenarios
to the wiki so feel free to add your thoughts to them.

Jim

On Jul 5, 2006, at 2:07 PM, Ignacio Silva-Lepe wrote:

> Hi Jim,
>
> Sorry about the disconnect, I was out Monday and yesterday. I'll be 
> sure to attend the IRC chat tomorrow. In the meantime, some more quick

> comments.
>
> - Original Message - 
>
>>> If I understand correctly, would a system service transport use a  
>>> low level communication mechanism, like a socket for instance? This 
>>> does not  seem like an appropriate approach for a local scenario,
>> Right, for the local scenario, I was thinking the callback instance  
>> would be put on the thread local context and the proxy would access  
>> it from there as opposed to going out over a socket and back in  
>> through a listener. Basically, it would be an optimization of the  
>> remote case. I think we can further optimize things depending on  
>> scopes, e.g. if the callback scope is "module", we could possibly  
>> avoid threadlocal storage and have the proxy hold on to an instance  
>> directly.
>
> Pointing at the callback instance directly from the proxy would 
> eliminate invocation chains and the ability to add interceptors to 
> them, wouldn't it?

Yea the proxy should probably point back to the Component and not the
instance directly unless there is an optimized case where no
interceptors were present. Once the proxy points to Component, it can
call getInboundWire(String serviceName) which will return the invocation
chain that will dispatch to the correct instance. In the case of an
AtomicComponent, when the end of the chain is reached, the target
invoker will delegate to the scope container which will return the right
instance.

> Also, I'm not sure using a thread local in the core is a good idea if 
> an intention is to allow the core to be embeddable in, for instance, a

> managed environment, as thread local does not necessarily mix well 
> with thread pools.
>
Good point. I think a similar mechanism may be o.k. as long as we clean
up properly when the request ends or the thread is reclaimed (e.g. in
case of failure where the callback never hapens). Perhaps we could use
the WorkArea API for this? Were you thinking of something in particular?

Jim

> 
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

This message has been checked for all email viruses by MessageLabs.

*

You can find us at www.voca.com

*
This communication is confidential and intended for 
the exclusive use of the addressee only. You should 
not disclose its contents to any other person.
If you are not the intended recipient please notify 
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX

This message has been checked for all email viruses by MessageLabs.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tuscany Icon



On Jul 6, 2006, at 6:35 AM, Hawkins, Joel wrote:


That's the one! Couldn't remember where I'd seen it. Just change the
size|font|color of 'sca' in the middle of the ring to make it 'pop' a
bit more.

Then everyone can make their own with a sharpie and a glass of  
Chianti.

I plan on getting started right away. ;-)
I like the idea of a sharpie and Chianti - maybe we can even get T.O.  
to draw one in the endzone when he scores a touchdown ;-)


-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 06, 2006 7:50 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany Icon

Actually, I had a half-baked wine-stain one on the slides at:

http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ 
doc/


Kelvin's looked kind of cool but it is a bit colorful. I think we
should also see how it scales down too.

Jim


On Jul 6, 2006, at 4:37 AM, Davanum Srinivas wrote:


missing a bottle of wine? :)

On 7/6/06, kelvin goodson <[EMAIL PROTECTED]> wrote:

I'm like this,

http://wiki.apache.org/ws-data/attachments/Tuscany(2f)
LogoCandidates/attachments/tuscanylogo_candidate1.jpg
but I think it might be too colourful and I like the idea of
bringing out
the "sca" in Tuscany  as shown in
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)
LogoCandidates/attachments/tusc_h.jpg

I also like
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)
LogoCandidates/attachments/tuscanylogo_candidate2.jpgbut
I think that may be because I'd like to buy a lawnmower from  
them :-)



On 7/6/06, Andrew Borley <[EMAIL PROTECTED]> wrote:


My favourite so far is one of Ed's:

http://wiki.apache.org/ws-data/attachments/Tuscany(2f)

LogoCandidates/attachments/tusc_mod9.jpg




On 7/6/06, haleh mahbod <[EMAIL PROTECTED]> wrote:


What Ed posted in black and brown looks good. Maybe we can get

rid of

some

of the trees and make it simpler. I'll take a stab at it.


On 7/5/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote:


Cheers!

-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 05, 2006 5:45 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany Icon

On 05/07/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote:


I really liked the wine stain on the white background.

That was

pretty

clever, simple, evocative, etc.

Plus it'd look really cool on a white tee shirt, and it makes

branding

of cocktail napkin-based design documents really easy.

:-)



I always thought that a single cypress tree with no writing

was the

best...
but now I really like the wine stain. I can supply custom

stained

shirts

;-)

--
Pete
The contents of this e-mail are intended for the named

addressee only.

It

contains information that may be confidential. Unless you

are the

named

addressee or an authorized designee, you may not copy or use

it, or

disclose

it to anyone else. If you received it in error please notify us

immediately

and then destroy it.


 
-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]








--

Cheers,

Andrew Borley





--
Best Regards
Kelvin Goodson





--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service
Developers)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

The contents of this e-mail are intended for the named addressee  
only. It contains information that may be confidential. Unless you  
are the named addressee or an authorized designee, you may not copy  
or use it, or disclose it to anyone else. If you received it in  
error please notify us immediately and then destroy it.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support for callbacks


Hi Ignacio,

Sorry about the delay...Comments inline. I've also added some  
scenarios to the wiki so feel free to add your thoughts to them.


Jim


On Jul 5, 2006, at 2:07 PM, Ignacio Silva-Lepe wrote:


Hi Jim,

Sorry about the disconnect, I was out Monday and yesterday. I'll be  
sure to
attend the IRC chat tomorrow. In the meantime, some more quick  
comments.


- Original Message - 

If I understand correctly, would a system service transport use  
a  low level
communication mechanism, like a socket for instance? This does  
not  seem like

an appropriate approach for a local scenario,
Right, for the local scenario, I was thinking the callback  
instance  would be put on the thread local context and the proxy  
would access  it from there as opposed to going out over a socket  
and back in  through a listener. Basically, it would be an  
optimization of the  remote case. I think we can further optimize  
things depending on  scopes, e.g. if the callback scope is  
"module", we could possibly  avoid threadlocal storage and have  
the proxy hold on to an instance  directly.


Pointing at the callback instance directly from the proxy would  
eliminate
invocation chains and the ability to add interceptors to them,  
wouldn't it?


Yea the proxy should probably point back to the Component and not the  
instance directly unless there is an optimized case where no  
interceptors were present. Once the proxy points to Component, it can  
call getInboundWire(String serviceName) which will return the  
invocation chain that will dispatch to the correct instance. In the  
case of an AtomicComponent, when the end of the chain is reached, the  
target invoker will delegate to the scope container which will return  
the right instance.



Also, I'm not sure using a thread local in the core is a good idea  
if an
intention is to allow the core to be embeddable in, for instance, a  
managed

environment, as thread local does not necessarily mix well with thread
pools.

Good point. I think a similar mechanism may be o.k. as long as we  
clean up properly when the request ends or the thread is reclaimed  
(e.g. in case of failure where the callback never hapens). Perhaps we  
could use the WorkArea API for this? Were you thinking of something  
in particular?


Jim





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Do we plan to move to JUnit 4.1?

2006-07-06 Thread Kevin Williams

I would much rather wait for the Surefire/JUnit 4 integration (  
http://jira.codehaus.org/browse/SUREFIRE-31  ) than switch to another 
testing framework.

--Kevin


Daniel Kulp wrote:

Actually, Maven supports TestNG natively in the Surefire plugin.   I've tried 
it before and it does work.

Maven does NOT support JUnit 4.0 yet.   Thus, if you want to go with something 
other than junit 3.8.1, TestNG is the only option right now.

The problem with TestNG is that the "integrated support in eclipse" stuff is 
no where near as good as the JUnit support.   Debugging JUnit tests in 
eclipse is very pleasant.   Debugging TestNG stuff is less so (but doable).   
I don't know about IDEA plugins.


Dan


On Thursday July 06 2006 4:06 am, Meeraj Kunnumpurath wrote:
 


I have been looking at TestNG lately. It is lot better than Junit 3.8.1.
However, I think lot of those features are incorporated in Junit 4.0. I
am not sure about the Maven support for TestNG.

-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: 06 July 2006 02:10
To: tuscany-dev@ws.apache.org
Subject: Re: Do we plan to move to JUnit 4.1?

On Jul 5, 2006, at 5:05 PM, Raymond Feng wrote:
   


I'm wondering if we plan to move to JUnit 4.1? I see more
flexibilities and simplicities offered by JUnit 4.x. Now I can also
use the wizards from Eclipse 3.2 to take advantage of it.

Do we see any issues? I understand Junit 4.x requires JDK 5. I'm not
sure if maven 2.0.4 supports it.
 


We had a look at junit 4 back in Sep but stayed with 3.8.1 due to the
lack of maven support. Can you find out if that has changed? If it has
it might be worth upgrading.

--
Jeremy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


This message has been checked for all email viruses by MessageLabs.




*

   You can find us at www.voca.com

*
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX


This message has been checked for all email viruses by MessageLabs.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   



 





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Do we plan to move to JUnit 4.1?

2006-07-06 Thread Daniel Kulp


Actually, Maven supports TestNG natively in the Surefire plugin.   I've tried 
it before and it does work.

Maven does NOT support JUnit 4.0 yet.   Thus, if you want to go with something 
other than junit 3.8.1, TestNG is the only option right now.

The problem with TestNG is that the "integrated support in eclipse" stuff is 
no where near as good as the JUnit support.   Debugging JUnit tests in 
eclipse is very pleasant.   Debugging TestNG stuff is less so (but doable).   
I don't know about IDEA plugins.

Dan


On Thursday July 06 2006 4:06 am, Meeraj Kunnumpurath wrote:
> I have been looking at TestNG lately. It is lot better than Junit 3.8.1.
> However, I think lot of those features are incorporated in Junit 4.0. I
> am not sure about the Maven support for TestNG.
>
> -Original Message-
> From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
> Sent: 06 July 2006 02:10
> To: tuscany-dev@ws.apache.org
> Subject: Re: Do we plan to move to JUnit 4.1?
>
> On Jul 5, 2006, at 5:05 PM, Raymond Feng wrote:
> > I'm wondering if we plan to move to JUnit 4.1? I see more
> > flexibilities and simplicities offered by JUnit 4.x. Now I can also
> > use the wizards from Eclipse 3.2 to take advantage of it.
> >
> > Do we see any issues? I understand Junit 4.x requires JDK 5. I'm not
> > sure if maven 2.0.4 supports it.
>
> We had a look at junit 4 back in Sep but stayed with 3.8.1 due to the
> lack of maven support. Can you find out if that has changed? If it has
> it might be worth upgrading.
>
> --
> Jeremy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> This message has been checked for all email viruses by MessageLabs.
>
>
>
>
> *
>
> You can find us at www.voca.com
>
> *
> This communication is confidential and intended for
> the exclusive use of the addressee only. You should
> not disclose its contents to any other person.
> If you are not the intended recipient please notify
> the sender named above immediately.
>
> Registered in England, No 1023742,
> Registered Office: Voca Limited
> Drake House, Three Rivers Court,
> Homestead Road, Rickmansworth,
> Hertfordshire, WD3 1FX
>
>
> This message has been checked for all email viruses by MessageLabs.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194   F:781-902-8001
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tuscany Icon

2006-07-06 Thread Hawkins, Joel

That's the one! Couldn't remember where I'd seen it. Just change the
size|font|color of 'sca' in the middle of the ring to make it 'pop' a
bit more. 

Then everyone can make their own with a sharpie and a glass of Chianti.
I plan on getting started right away. ;-)

-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 06, 2006 7:50 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany Icon

Actually, I had a half-baked wine-stain one on the slides at:

http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/doc/

Kelvin's looked kind of cool but it is a bit colorful. I think we  
should also see how it scales down too.

Jim


On Jul 6, 2006, at 4:37 AM, Davanum Srinivas wrote:

> missing a bottle of wine? :)
>
> On 7/6/06, kelvin goodson <[EMAIL PROTECTED]> wrote:
>> I'm like this,
>>
>> http://wiki.apache.org/ws-data/attachments/Tuscany(2f) 
>> LogoCandidates/attachments/tuscanylogo_candidate1.jpg
>> but I think it might be too colourful and I like the idea of  
>> bringing out
>> the "sca" in Tuscany  as shown in
>> http://wiki.apache.org/ws-data/attachments/Tuscany(2f) 
>> LogoCandidates/attachments/tusc_h.jpg
>>
>> I also like
>> http://wiki.apache.org/ws-data/attachments/Tuscany(2f) 
>> LogoCandidates/attachments/tuscanylogo_candidate2.jpgbut
>> I think that may be because I'd like to buy a lawnmower from them :-)
>>
>>
>> On 7/6/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
>> >
>> > My favourite so far is one of Ed's:
>> >
>> > http://wiki.apache.org/ws-data/attachments/Tuscany(2f) 
>> LogoCandidates/attachments/tusc_mod9.jpg
>> >
>> >
>> >
>> > On 7/6/06, haleh mahbod <[EMAIL PROTECTED]> wrote:
>> > >
>> > > What Ed posted in black and brown looks good. Maybe we can get  
>> rid of
>> > some
>> > > of the trees and make it simpler. I'll take a stab at it.
>> > >
>> > >
>> > > On 7/5/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote:
>> > > >
>> > > > Cheers!
>> > > >
>> > > > -Original Message-
>> > > > From: Pete Robbins [mailto:[EMAIL PROTECTED]
>> > > > Sent: Wednesday, July 05, 2006 5:45 PM
>> > > > To: tuscany-dev@ws.apache.org
>> > > > Subject: Re: Tuscany Icon
>> > > >
>> > > > On 05/07/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote:
>> > > > >
>> > > > > I really liked the wine stain on the white background.  
>> That was
>> > pretty
>> > > > > clever, simple, evocative, etc.
>> > > > >
>> > > > > Plus it'd look really cool on a white tee shirt, and it makes
>> > branding
>> > > > > of cocktail napkin-based design documents really easy.
>> > > > >
>> > > > > :-)
>> > > >
>> > > >
>> > > > I always thought that a single cypress tree with no writing  
>> was the
>> > > > best...
>> > > > but now I really like the wine stain. I can supply custom  
>> stained
>> > shirts
>> > > > ;-)
>> > > >
>> > > > --
>> > > > Pete
>> > > > The contents of this e-mail are intended for the named  
>> addressee only.
>> > > It
>> > > > contains information that may be confidential. Unless you  
>> are the
>> > named
>> > > > addressee or an authorized designee, you may not copy or use  
>> it, or
>> > > disclose
>> > > > it to anyone else. If you received it in error please notify us
>> > > immediately
>> > > > and then destroy it.
>> > > >
>> > > >  
>> -
>> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > > For additional commands, e-mail: [EMAIL PROTECTED]
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> > --
>> >
>> > Cheers,
>> >
>> > Andrew Borley
>> >
>> >
>>
>>
>> --
>> Best Regards
>> Kelvin Goodson
>>
>>
>
>
> -- 
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service  
> Developers)
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (TUSCANY-153) ChangeSummary on root data object not supported

2006-07-06 Thread Frank Budinsky

Brent,

The JavaDoc for the -noNotification generator option says it all:

 * -noNotification
 * This option eliminates all change notification overhead in the 
generated classes. Changes to
 * DataObjects generated using this option cannot be recorded, and 
consequently the classes cannot
 * be used with an SDO ChangeSummary or DataGraph.

You should definitely not be using it.

Thanks,
Frank.

"Brent Daniel" <[EMAIL PROTECTED]> wrote on 07/06/2006 07:48:05 AM:

> Kelvin,
> 
>   It looks like the difference between your generated code and mine is
> that mine is being generated with the "noNotificationRequired" option.
> I'm not sure why our test cases started using this for generated
> classes, but it seems to work for all normal cases, but not for this
> one. Regardless, we should be able to make progress without this issue
> blocking us given that we can generate the models with notification
> turned on.
> 
> Thanks,
> Brent
> 
> 
> On 7/6/06, Kelvin Goodson (JIRA)  wrote:
> >[ http://issues.apache.org/jira/browse/TUSCANY-153?
> page=comments#action_12419452 ]
> >
> > Kelvin Goodson commented on TUSCANY-153:
> > 
> >
> > When I run XSD2JavaGenerator against the test.xsd in the supplied 
> jar I get very different generated code from that found in the jar, 
> e.g. CustomerImpl's setID method in the jar is ...
> >
> >  public void setID(int newID)
> >  {
> >id = newID;
> >  }
> >
> > and my generated code has ...
> >
> >  public void setID(int newID)
> >  {
> >int oldID = id;
> >id = newID;
> >boolean oldIDESet = idESet;
> >idESet = true;
> >if (eNotificationRequired())
> >  eNotify(new ENotificationImpl(this, Notification.SET, 
> DasPackageImpl.CUSTOMER__ID, oldID, id, !oldIDESet));
> >  }
> >
> >
> > running the test against the new generated code gives ...
> >
> > [EMAIL PROTECTED] (ID: , Product: null, Quantity: 
> 5, Customer_ID: )
> > [EMAIL PROTECTED] (ID: 5, lastName: null, address: null)
> > [EMAIL PROTECTED] (ID: 10, Product: null, Quantity: 
> , Customer_ID: )
> > [EMAIL PROTECTED] (eClass:
> [EMAIL PROTECTED] (name: DataGraphRoot) 
> (instanceClassName: null) (abstract: false, interface: false))
> >
> >
> > > ChangeSummary on root data object not supported
> > > ---
> > >
> > >  Key: TUSCANY-153
> > >  URL: http://issues.apache.org/jira/browse/TUSCANY-153
> > >  Project: Tuscany
> > > Type: Bug
> >
> > >   Components: Java SDO Implementation
> > > Versions: Java-Mx
> > > Reporter: Kevin Williams
> > >  Fix For: Java-Mx
> > >  Attachments: tuscany153.jar
> > >
> > > The RDB DAS intends to produce data graphs without using a 
> DataGraph instance and this requires us to attach a change history 
> to the root DataObject.  It seems that this capability is not yet 
implemented.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > If you think it was sent incorrectly contact one of the 
administrators:
> >   http://issues.apache.org/jira/secure/Administrators.jspa
> > -
> > For more information on JIRA, see:
> >   http://www.atlassian.com/software/jira
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tuscany Icon


Actually, I had a half-baked wine-stain one on the slides at:

http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/doc/

Kelvin's looked kind of cool but it is a bit colorful. I think we  
should also see how it scales down too.


Jim


On Jul 6, 2006, at 4:37 AM, Davanum Srinivas wrote:


missing a bottle of wine? :)

On 7/6/06, kelvin goodson <[EMAIL PROTECTED]> wrote:

I'm like this,

http://wiki.apache.org/ws-data/attachments/Tuscany(2f) 
LogoCandidates/attachments/tuscanylogo_candidate1.jpg
but I think it might be too colourful and I like the idea of  
bringing out

the "sca" in Tuscany  as shown in
http://wiki.apache.org/ws-data/attachments/Tuscany(2f) 
LogoCandidates/attachments/tusc_h.jpg


I also like
http://wiki.apache.org/ws-data/attachments/Tuscany(2f) 
LogoCandidates/attachments/tuscanylogo_candidate2.jpgbut

I think that may be because I'd like to buy a lawnmower from them :-)


On 7/6/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> My favourite so far is one of Ed's:
>
> http://wiki.apache.org/ws-data/attachments/Tuscany(2f) 
LogoCandidates/attachments/tusc_mod9.jpg

>
>
>
> On 7/6/06, haleh mahbod <[EMAIL PROTECTED]> wrote:
> >
> > What Ed posted in black and brown looks good. Maybe we can get  
rid of

> some
> > of the trees and make it simpler. I'll take a stab at it.
> >
> >
> > On 7/5/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote:
> > >
> > > Cheers!
> > >
> > > -Original Message-
> > > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, July 05, 2006 5:45 PM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: Tuscany Icon
> > >
> > > On 05/07/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I really liked the wine stain on the white background.  
That was

> pretty
> > > > clever, simple, evocative, etc.
> > > >
> > > > Plus it'd look really cool on a white tee shirt, and it makes
> branding
> > > > of cocktail napkin-based design documents really easy.
> > > >
> > > > :-)
> > >
> > >
> > > I always thought that a single cypress tree with no writing  
was the

> > > best...
> > > but now I really like the wine stain. I can supply custom  
stained

> shirts
> > > ;-)
> > >
> > > --
> > > Pete
> > > The contents of this e-mail are intended for the named  
addressee only.

> > It
> > > contains information that may be confidential. Unless you  
are the

> named
> > > addressee or an authorized designee, you may not copy or use  
it, or

> > disclose
> > > it to anyone else. If you received it in error please notify us
> > immediately
> > > and then destroy it.
> > >
> > >  
-

> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
>
>
> --
>
> Cheers,
>
> Andrew Borley
>
>


--
Best Regards
Kelvin Goodson





--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service  
Developers)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (TUSCANY-153) ChangeSummary on root data object not supported

2006-07-06 Thread Brent Daniel

Kelvin,

 It looks like the difference between your generated code and mine is
that mine is being generated with the "noNotificationRequired" option.
I'm not sure why our test cases started using this for generated
classes, but it seems to work for all normal cases, but not for this
one. Regardless, we should be able to make progress without this issue
blocking us given that we can generate the models with notification
turned on.

Thanks,
Brent

On 7/6/06, Kelvin Goodson (JIRA)  wrote:

   [ 
http://issues.apache.org/jira/browse/TUSCANY-153?page=comments#action_12419452 ]

Kelvin Goodson commented on TUSCANY-153:

When I run XSD2JavaGenerator against the test.xsd in the supplied jar I get 
very different generated code from that found in the jar,  e.g. CustomerImpl's 
setID method in the jar is ...

 public void setID(int newID)
 {
   id = newID;
 }

and my generated code has ...

 public void setID(int newID)
 {
   int oldID = id;
   id = newID;
   boolean oldIDESet = idESet;
   idESet = true;
   if (eNotificationRequired())
 eNotify(new ENotificationImpl(this, Notification.SET, 
DasPackageImpl.CUSTOMER__ID, oldID, id, !oldIDESet));
 }

running the test against the new generated code gives ...

[EMAIL PROTECTED] (ID: , Product: null, Quantity: 5, Customer_ID: 
)
[EMAIL PROTECTED] (ID: 5, lastName: null, address: null)
[EMAIL PROTECTED] (ID: 10, Product: null, Quantity: , Customer_ID: 
)
[EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: DataGraphRoot) 
(instanceClassName: null) (abstract: false, interface: false))

> ChangeSummary on root data object not supported
> ---
>
>  Key: TUSCANY-153
>  URL: http://issues.apache.org/jira/browse/TUSCANY-153
>  Project: Tuscany
> Type: Bug

>   Components: Java SDO Implementation
> Versions: Java-Mx
> Reporter: Kevin Williams
>  Fix For: Java-Mx
>  Attachments: tuscany153.jar
>
> The RDB DAS intends to produce data graphs without using a DataGraph instance 
and this requires us to attach a change history to the root DataObject.  It seems 
that this capability is not yet implemented.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
  http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
  http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tuscany Icon

2006-07-06 Thread Davanum Srinivas


missing a bottle of wine? :)

On 7/6/06, kelvin goodson <[EMAIL PROTECTED]> wrote:

I'm like this,

http://wiki.apache.org/ws-data/attachments/Tuscany(2f)LogoCandidates/attachments/tuscanylogo_candidate1.jpg
but I think it might be too colourful and I like the idea of bringing out
the "sca" in Tuscany  as shown in
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)LogoCandidates/attachments/tusc_h.jpg

I also like
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)LogoCandidates/attachments/tuscanylogo_candidate2.jpgbut
I think that may be because I'd like to buy a lawnmower from them :-)


On 7/6/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> My favourite so far is one of Ed's:
>
> 
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)LogoCandidates/attachments/tusc_mod9.jpg
>
>
>
> On 7/6/06, haleh mahbod <[EMAIL PROTECTED]> wrote:
> >
> > What Ed posted in black and brown looks good. Maybe we can get rid of
> some
> > of the trees and make it simpler. I'll take a stab at it.
> >
> >
> > On 7/5/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote:
> > >
> > > Cheers!
> > >
> > > -Original Message-
> > > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, July 05, 2006 5:45 PM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: Tuscany Icon
> > >
> > > On 05/07/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I really liked the wine stain on the white background. That was
> pretty
> > > > clever, simple, evocative, etc.
> > > >
> > > > Plus it'd look really cool on a white tee shirt, and it makes
> branding
> > > > of cocktail napkin-based design documents really easy.
> > > >
> > > > :-)
> > >
> > >
> > > I always thought that a single cypress tree with no writing was the
> > > best...
> > > but now I really like the wine stain. I can supply custom stained
> shirts
> > > ;-)
> > >
> > > --
> > > Pete
> > > The contents of this e-mail are intended for the named addressee only.
> > It
> > > contains information that may be confidential. Unless you are the
> named
> > > addressee or an authorized designee, you may not copy or use it, or
> > disclose
> > > it to anyone else. If you received it in error please notify us
> > immediately
> > > and then destroy it.
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
>
>
> --
>
> Cheers,
>
> Andrew Borley
>
>


--
Best Regards
Kelvin Goodson





--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tuscany Icon

2006-07-06 Thread kelvin goodson


I'm like this,

http://wiki.apache.org/ws-data/attachments/Tuscany(2f)LogoCandidates/attachments/tuscanylogo_candidate1.jpg
but I think it might be too colourful and I like the idea of bringing out
the "sca" in Tuscany  as shown in
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)LogoCandidates/attachments/tusc_h.jpg

I also like
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)LogoCandidates/attachments/tuscanylogo_candidate2.jpgbut
I think that may be because I'd like to buy a lawnmower from them :-)


On 7/6/06, Andrew Borley <[EMAIL PROTECTED]> wrote:


My favourite so far is one of Ed's:

http://wiki.apache.org/ws-data/attachments/Tuscany(2f)LogoCandidates/attachments/tusc_mod9.jpg



On 7/6/06, haleh mahbod <[EMAIL PROTECTED]> wrote:
>
> What Ed posted in black and brown looks good. Maybe we can get rid of
some
> of the trees and make it simpler. I'll take a stab at it.
>
>
> On 7/5/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote:
> >
> > Cheers!
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 05, 2006 5:45 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: Tuscany Icon
> >
> > On 05/07/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote:
> > >
> > > I really liked the wine stain on the white background. That was
pretty
> > > clever, simple, evocative, etc.
> > >
> > > Plus it'd look really cool on a white tee shirt, and it makes
branding
> > > of cocktail napkin-based design documents really easy.
> > >
> > > :-)
> >
> >
> > I always thought that a single cypress tree with no writing was the
> > best...
> > but now I really like the wine stain. I can supply custom stained
shirts
> > ;-)
> >
> > --
> > Pete
> > The contents of this e-mail are intended for the named addressee only.
> It
> > contains information that may be confidential. Unless you are the
named
> > addressee or an authorized designee, you may not copy or use it, or
> disclose
> > it to anyone else. If you received it in error please notify us
> immediately
> > and then destroy it.
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>


--

Cheers,

Andrew Borley





--
Best Regards
Kelvin Goodson

Re: Email versus IRC

You'll get a rise of this: I'm in Rome now and the other day I was  
out doing my run, all sweaty, in terrible heat, and I run past this  
women and she asks if I have a lighter for her cigarette :-) Classic  
Italy.


Jim

On Jul 6, 2006, at 2:10 AM, Andrew Borley wrote:


On 7/6/06, Jim Marino <[EMAIL PROTECTED]> wrote:


at the squash courts ;-)



That's for the healthy, athletic guys - us cooler types hang out  
behind the

bike sheds, smoking woodbines and cracking jokes ;-)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: C++ M1 Release Candidate

2006-07-06 Thread Edward Slattery


Ive downloaded and built the src distro on Windows using the command line,
devstudio6 and devstudio7. The builds all work fine, but the calculator
sample on studio7 only half works as the project descriptions are missing
some of the proxies/wrappers. Add works but Div doesnt.
Im just going to fix that 

Ed.


On 06/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote:


The problem appears to be that WinXP expanding of a compressed folder can
not expand the tuscany_sca_cpp-0.1.incubating-M1-src.zip (despite the fact
that it was used to create the zip in the first place!). This zip can be
successfully extracted using WinZip or even jar -xf so I am not going to
update the zip.

Any ideas on why WinXP zip expand has a problem?? I'm fairly sure that it
is
to do with a long path name.

Cheers,


On 06/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> There is a problem with the Windows src zip for sca to do with filename
> lengths. I will fix it and re-post a new zip.
>
>
> On 06/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >
> >  I have posted a candidate for the first C++ release here.
> >
> > http://people.apache.org/~robbinspg/RC1
> >
> > Would all interested parties take some time to review this so that we
> > can either re-spin the release or vote on it asap.
> >
> > The website documentation is out of date and will be re-written to
sync
> > with what is in the release. Hopefully this will be done tomorrow.
> >
> > A Calculator sample is included which demonstrates deploying an SCA
> > module, component wiring, locating and invoking C++ service from
> > C++ component,  invoking from a C++ client, and exposing a service as
a web
> > service using ws binding.
> >
> >
> > Release Summary
> > =
> >
> > Tuscany SCA C++ provides a runtime implementation for the Service
> > Component
> > Architecture 0.9 specification, written in C++ and will currently
> > support C++
> > component implementation types. This is not yet a complete
> > implementation and
> > known restrictions are described below.
> >
> > Supported SCA Assembly Model features
> >   *  All features are supported unless listed under the known
> > restrictions
> >  below. See SCA Assembly Model specification.
> >
> > Supported language bindings
> >   * Component implementations written in C++. See SCA Client and
> > Implementation Model specification.
> >   * Component interfaces described by C++ classes. See SCA Client and
> > Implementation Model specification.
> >
> > Supported external service and entry point bindings
> >   * The web service binding is supported. This implementation will
> > support
> > web services which using document literal SOAP bindings conforming
> > to the
> > WS-I basic profile (rpc/encoded is not yet supported).
> >
> > Known restrictions
> >   * Subsystem: wiring, entry points and external services are not
> > supported.
> >   * Local service interfaces cannot use overloaded operations (the SCA
> > specification limits remote service interfaces to not using
> > overloaded operations).
> >   * Each WSDL definition for a web service binding must be in a single
> > WSDL document.
> >   * No load time validation of the deployed SCA application (run time
> > validation only).
> >   * No metadata API.
> > --
> > Pete
> >
>
>
>
> --
>
> Pete
>



--
Pete

Re: Proposed approach for M2



On Jul 6, 2006, at 2:17 AM, Simon Nash wrote:


Jeremy,

Jeremy Boynes wrote:


On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:


I just checked in sandbox/sebastien/m2-design/model.spi a set of   
new interfaces. This is just an initial strawman to trigger a   
constructive discussion and ideas on how to best represent the   
recursive model. I also need help to define a scenario (not unit   
test cases, but an end to end sample application) to help put  
the  recursive composition model in perspective and make sure we  
all  understand it the same way.


I am troubled that you have chosen to start on your own codebase  
at a  time when most of us have been trying to have constructive  
discussion  on this list. Based on the approach you proposed in  
your original  email I would have hoped that we could have started  
with your end- user scenarios and had a chance to explore how they  
could be  supported by M1, the sandbox, or some other code before  
starting  another codebase. I'm disappointed that, having started  
this very  thread nearly a week ago with the premise of community,  
your first  response on it was to commit a large chunk of  
independent code rather  than follow up with any of the other  
people who have already  contributed to the discussion.
I think discussion led to compromise and consensus on the  
scenario- driven approach that you proposed. As shown above and in  
other recent  threads, there's plenty of room for improvements and/ 
or new features  in our current code and a willingness to discuss  
them, albeit in  terms of technical merit rather than personal  
opinion. I hope you can  find a way to join in rather than forge  
your own path.
This can by no stretch of the imagination be described as a "large  
chunk

of independent code".  It consists of around 20 interfaces with no
implementation.  Quite a bit of the discussion on this topic over the
last few days has focused on what could be the advantages of starting
a new code stream rather than continuing with either M1 or core2.  As
Sebastien said in his post, the purpose of this code (as well as other
suggestions he made in his latest post) is to trigger contructive
discussion on new ideas that are not incrementally derived from either
of the existing codebases.  When presenting such ideas, it is often
helpful to see sample code rather that just a textual description.

I am very disppointed at your negative reaction to this, which is  
about
as far away as I can imagine from the constructive technical  
discussion

that Sebastien asked for.



We will only reach the right conclusion on
this important debate if we all engage constructively at a technical
level and evaluate new contributions and ideas in an open-minded way.
Your apparent characterization of Sebastien's constructive engagement
in this discussion as an attempt to "forge his own path" is unfair and
offensive, and not at all how I interpret Sebastien's recent posts.

Simon, I don't think that is fair and labeling it as offensive is  
unnecessarily caustic. Perhaps Jeremy could have worded some of his  
response better but I think *everyone* has been guilty of this over  
the past several weeks so I'd prefer to make a general statement that  
we all remain constructive since we are not doing a very good job of  
community building.


My second point is that the desire for constructive discussion comes  
from *all* of us, not just Sebastien. For example, Jeremy spent a  
significant amount of time on the core2 architecture presentation a  
month back, numerous posts to the list, proposals (e.g. constructor  
injection), and scenarios, etc. - all of which were attempts to  
constructively engage the community.


As I mentioned in a previous post, moving the community forward  
starts with positive individual acts. Perhaps you could engage by  
positing scenarios to the wiki you are interested in, or respond to  
my response to Sebastien asking why any of the changes he mentioned  
could not be incrementally accommodated by core2? This approach  
sounds to me like a nice way to accommodate the interests of many and  
move things forward.


Jim


  Simon

--
Simon C Nash   IBM Distinguished Engineer
Hursley Park, Winchester, UK   [EMAIL PROTECTED]
Tel. +44-1962-815156   Fax +44-1962-818999


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: C++ M1 Release Candidate


The problem appears to be that WinXP expanding of a compressed folder can
not expand the tuscany_sca_cpp-0.1.incubating-M1-src.zip (despite the fact
that it was used to create the zip in the first place!). This zip can be
successfully extracted using WinZip or even jar -xf so I am not going to
update the zip.

Any ideas on why WinXP zip expand has a problem?? I'm fairly sure that it is
to do with a long path name.

Cheers,


On 06/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote:


There is a problem with the Windows src zip for sca to do with filename
lengths. I will fix it and re-post a new zip.


On 06/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
>  I have posted a candidate for the first C++ release here.
>
> http://people.apache.org/~robbinspg/RC1
>
> Would all interested parties take some time to review this so that we
> can either re-spin the release or vote on it asap.
>
> The website documentation is out of date and will be re-written to sync
> with what is in the release. Hopefully this will be done tomorrow.
>
> A Calculator sample is included which demonstrates deploying an SCA
> module, component wiring, locating and invoking C++ service from
> C++ component,  invoking from a C++ client, and exposing a service as a web
> service using ws binding.
>
>
> Release Summary
> =
>
> Tuscany SCA C++ provides a runtime implementation for the Service
> Component
> Architecture 0.9 specification, written in C++ and will currently
> support C++
> component implementation types. This is not yet a complete
> implementation and
> known restrictions are described below.
>
> Supported SCA Assembly Model features
>   *  All features are supported unless listed under the known
> restrictions
>  below. See SCA Assembly Model specification.
>
> Supported language bindings
>   * Component implementations written in C++. See SCA Client and
> Implementation Model specification.
>   * Component interfaces described by C++ classes. See SCA Client and
> Implementation Model specification.
>
> Supported external service and entry point bindings
>   * The web service binding is supported. This implementation will
> support
> web services which using document literal SOAP bindings conforming
> to the
> WS-I basic profile (rpc/encoded is not yet supported).
>
> Known restrictions
>   * Subsystem: wiring, entry points and external services are not
> supported.
>   * Local service interfaces cannot use overloaded operations (the SCA
> specification limits remote service interfaces to not using
> overloaded operations).
>   * Each WSDL definition for a web service binding must be in a single
> WSDL document.
>   * No load time validation of the deployed SCA application (run time
> validation only).
>   * No metadata API.
> --
> Pete
>



--

Pete





--
Pete

[jira] Commented: (TUSCANY-153) ChangeSummary on root data object not supported

2006-07-06 Thread Kelvin Goodson (JIRA)

[ 
http://issues.apache.org/jira/browse/TUSCANY-153?page=comments#action_12419452 
] 

Kelvin Goodson commented on TUSCANY-153:


When I run XSD2JavaGenerator against the test.xsd in the supplied jar I get 
very different generated code from that found in the jar,  e.g. CustomerImpl's 
setID method in the jar is ...

  public void setID(int newID)
  {
id = newID;
  }

and my generated code has ...

  public void setID(int newID)
  {
int oldID = id;
id = newID;
boolean oldIDESet = idESet;
idESet = true;
if (eNotificationRequired())
  eNotify(new ENotificationImpl(this, Notification.SET, 
DasPackageImpl.CUSTOMER__ID, oldID, id, !oldIDESet));
  }


running the test against the new generated code gives ...

[EMAIL PROTECTED] (ID: , Product: null, Quantity: 5, Customer_ID: 
)
[EMAIL PROTECTED] (ID: 5, lastName: null, address: null)
[EMAIL PROTECTED] (ID: 10, Product: null, Quantity: , Customer_ID: 
)
[EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: DataGraphRoot) 
(instanceClassName: null) (abstract: false, interface: false))


> ChangeSummary on root data object not supported
> ---
>
>  Key: TUSCANY-153
>  URL: http://issues.apache.org/jira/browse/TUSCANY-153
>  Project: Tuscany
> Type: Bug

>   Components: Java SDO Implementation
> Versions: Java-Mx
> Reporter: Kevin Williams
>  Fix For: Java-Mx
>  Attachments: tuscany153.jar
>
> The RDB DAS intends to produce data graphs without using a DataGraph instance 
> and this requires us to attach a change history to the root DataObject.  It 
> seems that this capability is not yet implemented.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposed approach for M2

2006-07-06 Thread Simon Nash


Jeremy,

Jeremy Boynes wrote:


On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:



I just checked in sandbox/sebastien/m2-design/model.spi a set of  new 
interfaces. This is just an initial strawman to trigger a  
constructive discussion and ideas on how to best represent the  
recursive model. I also need help to define a scenario (not unit  test 
cases, but an end to end sample application) to help put the  
recursive composition model in perspective and make sure we all  
understand it the same way.




I am troubled that you have chosen to start on your own codebase at a  
time when most of us have been trying to have constructive discussion  
on this list. Based on the approach you proposed in your original  email 
I would have hoped that we could have started with your end- user 
scenarios and had a chance to explore how they could be  supported by 
M1, the sandbox, or some other code before starting  another codebase. 
I'm disappointed that, having started this very  thread nearly a week 
ago with the premise of community, your first  response on it was to 
commit a large chunk of independent code rather  than follow up with any 
of the other people who have already  contributed to the discussion.


I think discussion led to compromise and consensus on the scenario- 
driven approach that you proposed. As shown above and in other recent  
threads, there's plenty of room for improvements and/or new features  in 
our current code and a willingness to discuss them, albeit in  terms of 
technical merit rather than personal opinion. I hope you can  find a way 
to join in rather than forge your own path.



This can by no stretch of the imagination be described as a "large chunk
of independent code".  It consists of around 20 interfaces with no
implementation.  Quite a bit of the discussion on this topic over the
last few days has focused on what could be the advantages of starting
a new code stream rather than continuing with either M1 or core2.  As
Sebastien said in his post, the purpose of this code (as well as other
suggestions he made in his latest post) is to trigger contructive
discussion on new ideas that are not incrementally derived from either
of the existing codebases.  When presenting such ideas, it is often
helpful to see sample code rather that just a textual description.

I am very disppointed at your negative reaction to this, which is about
as far away as I can imagine from the constructive technical discussion
that Sebastien asked for.  We will only reach the right conclusion on
this important debate if we all engage constructively at a technical
level and evaluate new contributions and ideas in an open-minded way.
Your apparent characterization of Sebastien's constructive engagement
in this discussion as an attempt to "forge his own path" is unfair and
offensive, and not at all how I interpret Sebastien's recent posts.

  Simon

--
Simon C Nash   IBM Distinguished Engineer
Hursley Park, Winchester, UK   [EMAIL PROTECTED]
Tel. +44-1962-815156   Fax +44-1962-818999


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Email versus IRC

2006-07-06 Thread Andrew Borley


On 7/6/06, Jim Marino <[EMAIL PROTECTED]> wrote:


at the squash courts ;-)



That's for the healthy, athletic guys - us cooler types hang out behind the
bike sheds, smoking woodbines and cracking jokes ;-)

[jira] Commented: (TUSCANY-516) Annotating generated SDO Types for the associated 'Factory' and 'Package' generated classes

2006-07-06 Thread Venkatakrishnan (JIRA)

[ 
http://issues.apache.org/jira/browse/TUSCANY-516?page=comments#action_12419444 
] 

Venkatakrishnan commented on TUSCANY-516:
-

In the approach that I am following to map SDOs to XSDs, I instantiate the SDO 
in order to be able to access it 'Type' field and then ofcourse work with the 
'Type' instance such as type.is Sequenced(), or type.isDataType()... and so on.

But then how do I instantiate the SDO?  I would ideally need information about 
the associated DataFactory to be used isn' t it.   All that a user might input 
is the name of the SDO Type such as com.examples.sequences.MixedQuote".  Using 
this I must have to instantiate this SDO class.  For this I need to know which 
is the Factory class over which I can execute 'createMixedQuote' method.  i.e. 
I need to know com.example.sequences.SequencesFactory

An alternate method of instantiating the SDO is to call its 'protected' 
constructor, using Java Reflection APIs.  This breaks encapsulation as we break 
the 'protected' access.  Also if the input SDO Type name is actually the name 
of the Interface and not the implementation i.e. if it is MixedQuote and not 
MixedQuoteImpl, then this will not work.

On the other hand, if the generated SDO type also had information about the 
Factory class that can instantiate it, it can be picked up and used.  I am 
wondering if we could have annotations in the generated code for this.  

Since the code generation cycle for generating SDOs also includes the 
generation of the associated Package and Factory classes, I was wondering if we 
could capture this information as part of the generated SDOs.

Presently, my requirement is only for information about the Factory but then I 
hope that there will be other tools that might need the 'Package' information 
as well.

Example use case
-
//the SDO class name is given by the user
Class sdoClass = Class.forName("com.examples.sequences.MixedQuote");

// I would like to obtain the Factory class name without user intervention
Class sdoFactoryClass = 
Class.forName("com.examples.sequences.MixedQuoteFactory");

String factoryMethodName = "create" + sdoClass.getSimpleName();

Method initMethod = sdoFactoryClass.getDeclaredMethod(INIT_METHOD, new 
Class[0]);
Object sdoFactory = initMethod.invoke(null, new Object[0]);

// here is how I instantiate the SDO
Method factoryMethod =  factoryClass   
.getDeclaredMethod(getFactoryMethodName(factoryMethodName, new Class[0]);
dataObject  = (DataObject)factoryMethod.invoke(sdoFactory, new Object[0])

Thanks.

> Annotating generated SDO Types for the associated 'Factory' and 'Package' 
> generated classes
> ---
>
>  Key: TUSCANY-516
>  URL: http://issues.apache.org/jira/browse/TUSCANY-516
>  Project: Tuscany
> Type: Sub-task

>   Components: Java SDO Tools
> Versions: Java-Mx
> Reporter: Venkatakrishnan

>
>  The SDO needs to be instantiated to obtain a more reliable information about 
> it type using the 'getType' method. To minimize user inputs in aid of this 
> instantiation, it would be good to have an annotation added to the generated 
> SDO, pointing to the Factory class for the SDO.  
> Work Around : Currently, the protected constructor of the input SDO class is 
> invoked using Java Reflection APIs.  This is not an ok approach as we break 
> the access and then invoke the constructor.  Also, if the input is the SDO 
> Type Interface then this work around will fail.
> If having the Factory class information sound ok, then we could also have the 
> Package class information.  I am sure we are going to need this somewhere 
> down the line.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Do we plan to move to JUnit 4.1?

My big thing with JUnit4 is that it finally allows initializer  
methods to be called at instantiation, although I haven't had much  
need for this in Tuacany. One thing we should be careful of in  
deciding to use JUnit4 is integration with mock object frameworks.  
Currently, in core2 and in the Celtix binding, we use JMock and  
EasyMock. IMO having a mock object framework far outweighs the  
benefits of JUnit4 if the two prove to be incompatible.


I've taken a quick look at TestNG a while back and think it has some  
really cool features (e.g. concurrency, test groups, etc.) and do  
believe it is a more complete testing framework in that it has  
features for integration testing built in. One big benefit for JUnit  
is ubiquity, although I think it would be useful to look at TestNG  
more closely when we tackle the issue of getting an integration build.


Also, Cedric (one of the TestNG guys) is a really good squash player  
so TestNG must be good as well ;-)


Jim


On Jul 6, 2006, at 1:06 AM, Meeraj Kunnumpurath wrote:

I have been looking at TestNG lately. It is lot better than Junit  
3.8.1.
However, I think lot of those features are incorporated in Junit  
4.0. I

am not sure about the Maven support for TestNG.

-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: 06 July 2006 02:10
To: tuscany-dev@ws.apache.org
Subject: Re: Do we plan to move to JUnit 4.1?

On Jul 5, 2006, at 5:05 PM, Raymond Feng wrote:


I'm wondering if we plan to move to JUnit 4.1? I see more
flexibilities and simplicities offered by JUnit 4.x. Now I can also
use the wizards from Eclipse 3.2 to take advantage of it.

Do we see any issues? I understand Junit 4.x requires JDK 5. I'm not
sure if maven 2.0.4 supports it.


We had a look at junit 4 back in Sep but stayed with 3.8.1 due to the
lack of maven support. Can you find out if that has changed? If it has
it might be worth upgrading.

--
Jeremy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


This message has been checked for all email viruses by MessageLabs.




*

You can find us at www.voca.com

*
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX


This message has been checked for all email viruses by MessageLabs.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Email versus IRC


at the squash courts ;-)

On Jul 5, 2006, at 6:14 PM, Jeremy Boynes wrote:


On Jul 5, 2006, at 11:37 AM, Jeremy Boynes wrote:


On Jul 5, 2006, at 11:10 AM, haleh mahbod wrote:

IRC has been a useful tool for timely community brainstorming to  
handle

issues that need quick attention.



Right. That was the basis for saying IRC should be an impromptu,  
consensus building mechanism - there's no need to wait for a  
scheduled time to have these types of discussions.


Of course, this kind of approach only works if people can be  
contacted on IRC - very few people were on the channel today and I  
have the impression that is fairly typical. Where do Tuscany folk  
hang out?


--
Jeremy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposed approach for M2


Comments inline, thanks for some of the clarifications...

On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:


Jim Marino wrote:


On Jul 3, 2006, at 5:34 AM, ant elder wrote:

One of the big reasons for me is summed up well in Sebastien's  
proposal:


"This will get our community members involved in building the  
runtime
together and will lead to a wider knowledge base that makes it  
possible to
quickly implement new functionality in the future. It will also  
build a
community knowledge base that is ready to help new community  
members come on

board quickly."

I struggle with understanding the what and why of parts of the  
sandbox code
and hope bringing small bits over one step at a time will help  
with this.


Could you outline specifically what you don't understand. Perhaps  
we could do another code walkthrough like we did about a month ago?


Why don't you like this approach? Sure it may take a bit more  
time but if in
the long run we end up with more people understanding the runtime  
that seems
like time well spent even if we end up with most of the trunk  
being just

whats in the sandbox today.

The key point is I like Jeremy's approach better. The thought of  
merging M1 with the sandbox code (Sebastien's proposal) doesn't  
seem to fit based on my technical knowledge of both code bases.  
More importantly, Jeremy's approach strike me as better.  Since I  
have outlined my reasoning in previous posts (not just technical)  
why I think it is better,I won't repeat them here, as it will just  
confuse the ongoing threads.





My proposal is not to merge M1 and the core2 sandbox. I am  
proposing to start a new fresh code stream and build the runtime  
through baby steps. We may be able to reuse some pieces of existing  
code, but more important is to engage our community in this  
exercise and integrate the new ideas that will emerge from this.



Here's an example where I'm struggling with both M1 and the core2  
sandbox and thinking that we can do better if we start with a new  
fresh stream: our (recursive) assembly metadata model.


- M1 does not implement the recursive composition model and would  
require significant changes to support it. Core2 is an attempt to  
implement it but I'm not sure it's quite right, and also think that  
it can be simplified.


It may be able to use a bit of simplification, but why is that an  
argument to start over? Why not have the community leverage and  
refactor it? That would seem to be much more inclusive since it would  
allow a lot of the existing initiatives to proceed and be used to  
help drive the simplification.


- M1 used Lists to represent relationships, Core2 uses Maps, I  
think M1 was better since it allowed to keep the order in the  
relationships.


Some specific reasons would be good here. Also, I hardly think this  
is a reason to start over.


- Core2 only defines implementation classes for the model, I think  
we should have interfaces + default implementation classes instead,  
like we had in M1, to allow for alternate implementations of the  
model.


The model contains no implementation behavior, it's just a set of  
dumb data objects, so interfaces seem superfluous. If you really  
wanted to override setter/getter behavior (perhaps for notification,  
although I don't understand why one would do that in a runtime as  
opposed to tooling) the classes can always be subclassed. Regarding  
alternative implementations of the model, what use cases do you have  
in mind? The base SCA model shouldn't change that much (it's in the  
specification) so I imagine most people will just use the loaders  
that come with Tuscany do load the non-extension parts. And when the  
spec model does change, writing StAX loaders is dead trivial and well  
understood by Java developers (StAX is being included in the JDK).  
For extensions, configuration, etc., the framework Jeremy created  
supports a pluggable databinding mechanism  so SDO, JAXB, XStream,  
etc. can *all* be used to load extensions.


Again, though, the fact that the model does not use interfaces is not  
a reason to jettison the substantial amount of capability already in it.


- Over usage of Java Generics breaks flexibility in some cases, for  
example Component will force you to  
recreate an instance of Component to swap its implementation with  
an implementation of a different type (and lose all the wires going  
in/out of the component).


Not at runtime. This will work fine. Could you outline the specific  
use-case you have in mind?




- Core2 defines ReferenceDefinitions (without bindings) and  
BoundReferenceDefinitions (with bindings). IMO there are Reference  
types and Reference instances and both can have bindings.

or Reference.

Great. Why can't we work on a "proposal"/modification to extend/ 
change core2 and see what it looks like together?



- I think that Remotable should be on Interface and not Service.

Service can be on both I believe. Unfortuna

Re: Tuscany Icon

2006-07-06 Thread Andrew Borley


My favourite so far is one of Ed's:
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)LogoCandidates/attachments/tusc_mod9.jpg



On 7/6/06, haleh mahbod <[EMAIL PROTECTED]> wrote:


What Ed posted in black and brown looks good. Maybe we can get rid of some
of the trees and make it simpler. I'll take a stab at it.


On 7/5/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote:
>
> Cheers!
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 05, 2006 5:45 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Tuscany Icon
>
> On 05/07/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote:
> >
> > I really liked the wine stain on the white background. That was pretty
> > clever, simple, evocative, etc.
> >
> > Plus it'd look really cool on a white tee shirt, and it makes branding
> > of cocktail napkin-based design documents really easy.
> >
> > :-)
>
>
> I always thought that a single cypress tree with no writing was the
> best...
> but now I really like the wine stain. I can supply custom stained shirts
> ;-)
>
> --
> Pete
> The contents of this e-mail are intended for the named addressee only.
It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>





--

Cheers,

Andrew Borley

Re: C++ M1 Release Candidate