Re: Understanding Service Discovery

[Meeraj Kunnumpurath]

Thanks Jeremy.

Mario, I think Jeremy has covered most of your points. If you need any more 
clarifications or have further queries, please feel free to ask. As Jeremy 
said, any help in these areas, ongoing and/or especially in the next two 
days :) will be highly appreciated.


Ta
Meeraj



From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: Understanding Service Discovery
Date: Fri, 16 Mar 2007 18:53:14 -0700

On Mar 16, 2007, at 2:03 PM, Antollini, Mario wrote:


Hello Meeraj,

I have read several emails and I got to know that you are working  on the
Discovery service. I am very interested in this topic and I will  like to
get a better understanding about it.


Great to have you involved.



I have seen that you have also mentioned the Federated Deployer,
Federated Assembly and Marshaling Framework throughout your posts. I
think all these components are somewhat connected to the Service
Discovery mechanism, aren't they? I will really appreciate if you can
give me some details on how they all interact, if they do so at all.
And, I will also like to understand the big picture here; i.e. what is
the main goal you are trying to achieve with all that. In addition to
that I will like to understand the role JXTA plays here and how it  also
interacts with these components.


Their interaction is only indirect - they are more just using it as a  
transport.


The discovery layer is responsible for determining which runtime  processes 
are participating in the federation at any time. We're  using JXTA for that 
as it is a standard peer-to-peer protocol and is  available in many 
different languages, specifically both Java and C++  which are the two 
runtime implementations we have in Tuscany. We also  want other protocols 
to work as well (for example, Bonjour or JINI)  but want to get one working 
first.


As well as tracking the available processes it also provides a  mechanism 
for allowing those processes to exchange messages and we  are using that to 
send management operations across the system fabric.


Some of those management operations are associated with federated  
deployment. SCA's deployment model is based on the concept of changes  to 
the domain assembly (e.g. include composite). Our implementation  of that 
routes those changes to the controller nodes (at first one,  next 
replicated, finally distributed) which take those logical  changes and 
convert them to the physical ones that need to be made on  participating 
runtimes. With the JXTA-based fabric, those are XML  encoded JXTA messages; 
the marshalling framework is all about  converting between those messages 
and the internal data structures  (physical model) used by the Java runtime 
(C++ does not support this  yet).


The federated deployer is a runtime node service that receives  
demarshalled change set messages from the fabric and applies the  changes 
they contain to the local runtime - basically creating,  removing 
resources, components and wires.


At the moment there's no interaction between JXTA and user components  but 
if that was useful then we would just need to create a transport  component 
implementation and wire attacher on the physical side and  the binding 
support on the controller side.





Finally, I would like to know which is its is (i.e.; what it is  already
able to do, what parts are missing, if you are willing to receive any
help, you are planning to get it ready for M3, etc).


We are in heavy development right now planning to show it working  next 
week at TSSS - any help would be appreciated, both now and  ongoing. All of 
this is happening in trunk for the 2.0-alpha2 release.




As you saw I am asking way too many things, however I will be really
glad if you can answer at least some of these questions.


Hope I covered the key points.
--
Jeremy


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



_
MSN Hotmail is evolving - check out the new Windows Live Mail.  
http://ideas.live.co.uk/



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

Merge improved databinding code into trunk

[Raymond Feng]

Hi,

As you might have noticed on the ML, I have improved the databinding code in 
the sca-java-integration branch over time. I would like to merge the changes 
back to the trunk and bring up the databinding support again in the trunk.


Here is the summary of the improvements:

1. Minimize the usage of @DataType by agressively introspecting the java 
classes


2. Data transformation for business exceptions

3. Add copy() support for JAXB and AXIOM

4. More databindings and transformers such as:
  * JSON databinding
  * SDO --> AXIOM using OMDataSource
  * JavaBean --> XMLStreamReader

5. More unit and integration test cases for better coverage

To avoid the disruption, I'll stage them as follows:
1) Add a "databinding-framework" module under 
"java/sca/services/databinding" to hold the updated code in spi and core.

2) Update individual databindings
3) Integrate the databinding pieces with the latest core

Thanks,
Raymond


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

Re: Kernel Alpha2 Release

[Jim Marino]

I've seen it. Thanks. The standalone server is nice, but I'm  
looking for a client, similar to what we had in Tuscany M1. I want  
to be able to write the main method of a client program, set up the  
Tuscany environment myself from the main method, and start that  
program like any other Java program without a specific launcher,  
from the command line with java.exe, from an IDE, etc.


Do you want a runtime or a way for non-managed code to obtain a  
ComponentContext? If it is the later, there was a proposal to the  
spec group Jeremy had written up but was not standardized. I think we  
should implement that. This would be semantically different than what  
was in M1 as locateService() has been removed from the spec (which  
was a good thing IMO to have done).


Jim


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

Re: Understanding Service Discovery

[Jeremy Boynes]

On Mar 16, 2007, at 2:03 PM, Antollini, Mario wrote:


Hello Meeraj,

I have read several emails and I got to know that you are working  
on the
Discovery service. I am very interested in this topic and I will  
like to

get a better understanding about it.


Great to have you involved.



I have seen that you have also mentioned the Federated Deployer,
Federated Assembly and Marshaling Framework throughout your posts. I
think all these components are somewhat connected to the Service
Discovery mechanism, aren't they? I will really appreciate if you can
give me some details on how they all interact, if they do so at all.
And, I will also like to understand the big picture here; i.e. what is
the main goal you are trying to achieve with all that. In addition to
that I will like to understand the role JXTA plays here and how it  
also

interacts with these components.


Their interaction is only indirect - they are more just using it as a  
transport.


The discovery layer is responsible for determining which runtime  
processes are participating in the federation at any time. We're  
using JXTA for that as it is a standard peer-to-peer protocol and is  
available in many different languages, specifically both Java and C++  
which are the two runtime implementations we have in Tuscany. We also  
want other protocols to work as well (for example, Bonjour or JINI)  
but want to get one working first.


As well as tracking the available processes it also provides a  
mechanism for allowing those processes to exchange messages and we  
are using that to send management operations across the system fabric.


Some of those management operations are associated with federated  
deployment. SCA's deployment model is based on the concept of changes  
to the domain assembly (e.g. include composite). Our implementation  
of that routes those changes to the controller nodes (at first one,  
next replicated, finally distributed) which take those logical  
changes and convert them to the physical ones that need to be made on  
participating runtimes. With the JXTA-based fabric, those are XML  
encoded JXTA messages; the marshalling framework is all about  
converting between those messages and the internal data structures  
(physical model) used by the Java runtime (C++ does not support this  
yet).


The federated deployer is a runtime node service that receives  
demarshalled change set messages from the fabric and applies the  
changes they contain to the local runtime - basically creating,  
removing resources, components and wires.


At the moment there's no interaction between JXTA and user components  
but if that was useful then we would just need to create a transport  
component implementation and wire attacher on the physical side and  
the binding support on the controller side.





Finally, I would like to know which is its is (i.e.; what it is  
already

able to do, what parts are missing, if you are willing to receive any
help, you are planning to get it ready for M3, etc).


We are in heavy development right now planning to show it working  
next week at TSSS - any help would be appreciated, both now and  
ongoing. All of this is happening in trunk for the 2.0-alpha2 release.




As you saw I am asking way too many things, however I will be really
glad if you can answer at least some of these questions.


Hope I covered the key points.
--
Jeremy


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

Re: IncompatibleClassChangeError with Maven Assembly plugin

[Luciano Resende]

Thanks Daniel, the version you mentioned works !!!

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


On Mar 16, 2007, at 5:55 PM, Daniel Kulp wrote:

>
> The snapshot that was deployed today seems to be very broken.   I
> haven't
> had a chance to look into it at all.   The "quick fix" is to use the
> last snapshot or last relase.  If you require the 2.2 features, set
> the
> version to:
>

IIRC we do

> 2.2-20070112.063452-32


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





--
Luciano Resende
http://people.apache.org/~lresende

Re: IncompatibleClassChangeError with Maven Assembly plugin

[Jeremy Boynes]

On Mar 16, 2007, at 5:55 PM, Daniel Kulp wrote:



The snapshot that was deployed today seems to be very broken.   I  
haven't

had a chance to look into it at all.   The "quick fix" is to use the
last snapshot or last relase.  If you require the 2.2 features, set  
the

version to:



IIRC we do


2.2-20070112.063452-32



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

Re: IncompatibleClassChangeError with Maven Assembly plugin

[Daniel Kulp]

The snapshot that was deployed today seems to be very broken.   I haven't 
had a chance to look into it at all.   The "quick fix" is to use the 
last snapshot or last relase.  If you require the 2.2 features, set the 
version to:

2.2-20070112.063452-32

Dan


On Friday 16 March 2007 20:39, Luciano Resende wrote:
> I recently started to get this on an assembly distribution, does
> anyone have any ideas here ?
> https://svn.apache.org/repos/asf/incubator/tuscany/java/das/distributi
>on/binary/
>
> [ERROR] FATAL ERROR
> [INFO]
> --
>-- [INFO] null
> [INFO]
> --
>-- [INFO] Trace
> java.lang.IncompatibleClassChangeError
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssembli
>es( DefaultAssemblyReader.java:74)
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute (
> AbstractAssemblyMojo.java:253)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(
> DefaultPluginManager.java:420)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(
> DefaultLifecycleExecutor.java :539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLif
>ecycle (DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(
> DefaultLifecycleExecutor.java :459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHand
>leFailures (DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegment
>s ( DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
> DefaultLifecycleExecutor.java:143)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) at
> org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke (Method.java:585)
> at
> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java
>
> :315)
>
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode
> (Launcher.java
>
> :430)
>
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

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

Re: Kernel Alpha2 Release

[Jean-Sebastien Delfino]

[snip]
Meeraj Kunnumpurath wrote:

From: Jean-Sebastien Delfino <[EMAIL PROTECTED]>
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: Kernel Alpha2 Release
Date: Fri, 16 Mar 2007 12:35:56 -0700

[snip]
Jeremy Boynes wrote:
I like the timing - about a month, 6 weeks at the most is a good 
window between releases in early stages like we are.



+1 from me

I agree federation is the big delta between now and then - we should 
have by then

* federated classloading (with multi-classloader support)
* federated scope
* the changes done for separating controller and physical runtime
* contribution store and artifact redistribution

It would be good to increase the spec coverage e.g.
* support for casting between proxies and service references
* support the new Conversation API
* clean up around complex properties - specifically being able to 
use an external file to configure the server runtime

* some more integration tests


Yes it will be good to increase the spec coverage. Adding to your 
list, I'd also like to support things like:
- Ability to override service/reference/property configuration at the 
componentType/component/composite level.
- More coverage of the SCDL 1.0 syntax with things like qnames on 
composites, or composite resolution without requiring a scdlLocation 
attribute for example, I think we need to do some work to bring our 
SCDL model in sync with the latest revision of the spec.
- Complex and multi-valued properties (I think Venkat has done some 
work in that area that could be included too)

- Support for both WSDL and java interfaces and mapping between the two

I can also help bring over some of the integration tests from the 
integration branch.




Also, user support such as:
* the composite plugin (i.e. pick an archive type)
* JUnit4/TestNG support in the itest plugin
* contribution tool (command line and plugin?)
* a start on some form of console
* some more samples
* doco for all the above


This looks good to me, I also want to have a very minimal runtime 
that will work without a Tuscany launcher.


There is already support in the runtime for standlone server other 
than the laucher with some basic JMX management.


I've seen it. Thanks. The standalone server is nice, but I'm looking for 
a client, similar to what we had in Tuscany M1. I want to be able to 
write the main method of a client program, set up the Tuscany 
environment myself from the main method, and start that program like any 
other Java program without a specific launcher, from the command line 
with java.exe, from an IDE, etc.



--
Jean-Sebastien


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

IncompatibleClassChangeError with Maven Assembly plugin

[Luciano Resende]

I recently started to get this on an assembly distribution, does anyone have
any ideas here ?
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/distribution/binary/

[ERROR] FATAL ERROR
[INFO]

[INFO] null
[INFO]

[INFO] Trace
java.lang.IncompatibleClassChangeError
   at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies(
DefaultAssemblyReader.java:74)
   at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute (
AbstractAssemblyMojo.java:253)
   at org.apache.maven.plugin.DefaultPluginManager.executeMojo(
DefaultPluginManager.java:420)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(
DefaultLifecycleExecutor.java :539)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle
(DefaultLifecycleExecutor.java:480)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(
DefaultLifecycleExecutor.java :459)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures
(DefaultLifecycleExecutor.java:311)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments (
DefaultLifecycleExecutor.java:278)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
DefaultLifecycleExecutor.java:143)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke (Method.java:585)
   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java
:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java
:430)
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

--
Luciano Resende
http://people.apache.org/~lresende 

Re: svn commit: r519138

[Jim Marino]

On Mar 16, 2007, at 4:58 PM, Jeremy Boynes wrote:



On Mar 16, 2007, at 4:50 PM, Jim Marino wrote:

On Mar 16, 2007, at 4:25 PM, Luciano Resende wrote:
After thinking about it, I'm starting to think that a better  
place for it is

under /java/sca/services.Thoughts ?


That was exactly why I asked :-) I think it should be under  
services and modularizing kernel is a different topic.


sca/runtime/services is probably better as this is likely to be  
primordial.


Ah yes, I didn't look closely at which /services directory - sca/ 
runtime/services is better.


Jim



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

Re: svn commit: r519138

[Jeremy Boynes]

On Mar 16, 2007, at 4:50 PM, Jim Marino wrote:

On Mar 16, 2007, at 4:25 PM, Luciano Resende wrote:
After thinking about it, I'm starting to think that a better place  
for it is

under /java/sca/services.Thoughts ?


That was exactly why I asked :-) I think it should be under  
services and modularizing kernel is a different topic.


sca/runtime/services is probably better as this is likely to be  
primordial.


--
Jeremy


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

Re: svn commit: r519138

[Jim Marino]

On Mar 16, 2007, at 4:25 PM, Luciano Resende wrote:


I think there has been various threads talking about the contribution
services on the dev mailing list. Jeremy suggested having a  
contribution
tool (command line and plugin) [1] and there was some other  
discussions

around integrating WSDL2Java with the contribution service [2]
and I think it does not make sense to have direct dependency on the  
whole

kernel core for these tools.

There was also couple discussions around modularization as well,  
where I
mentioned I'd start having contribution services moved to a  
separate module
[3]. And the idea is to have the contribution implementation on  
this new

module.

After thinking about it, I'm starting to think that a better place  
for it is

under /java/sca/services.Thoughts ?


That was exactly why I asked :-) I think it should be under services  
and modularizing kernel is a different topic.


Jim


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

Re: Kernel Alpha2 Release

[Meeraj Kunnumpurath]

From: Jean-Sebastien Delfino <[EMAIL PROTECTED]>
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: Kernel Alpha2 Release
Date: Fri, 16 Mar 2007 12:35:56 -0700

[snip]
Jeremy Boynes wrote:
I like the timing - about a month, 6 weeks at the most is a good window 
between releases in early stages like we are.



+1 from me

I agree federation is the big delta between now and then - we should have 
by then

* federated classloading (with multi-classloader support)
* federated scope
* the changes done for separating controller and physical runtime
* contribution store and artifact redistribution

It would be good to increase the spec coverage e.g.
* support for casting between proxies and service references
* support the new Conversation API
* clean up around complex properties - specifically being able to use an 
external file to configure the server runtime

* some more integration tests


Yes it will be good to increase the spec coverage. Adding to your list, I'd 
also like to support things like:
- Ability to override service/reference/property configuration at the 
componentType/component/composite level.
- More coverage of the SCDL 1.0 syntax with things like qnames on 
composites, or composite resolution without requiring a scdlLocation 
attribute for example, I think we need to do some work to bring our SCDL 
model in sync with the latest revision of the spec.
- Complex and multi-valued properties (I think Venkat has done some work in 
that area that could be included too)

- Support for both WSDL and java interfaces and mapping between the two

I can also help bring over some of the integration tests from the 
integration branch.




Also, user support such as:
* the composite plugin (i.e. pick an archive type)
* JUnit4/TestNG support in the itest plugin
* contribution tool (command line and plugin?)
* a start on some form of console
* some more samples
* doco for all the above


This looks good to me, I also want to have a very minimal runtime that will 
work without a Tuscany launcher.


There is already support in the runtime for standlone server other than the 
laucher with some basic JMX management.


The Guice idea is intriguing - support for their PM and annotations would 
be good. I also would like to take a look at using their EDSL for assembly 
- perhaps for hooking up the runtime as an alternative to SCDL.


Yes, this is an interesting idea. I like the idea of trying to use an 
alternative to SCDL to hook up the runtime.


Finally, I'd like to see if we could turn kernel/core into a few smaller 
modules for this release.




--
Jeremy



--
Jean-Sebastien


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



_
MSN Hotmail is evolving - check out the new Windows Live Mail 
http://ideas.live.co.uk



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

Re: svn commit: r519138

[Luciano Resende]

I think there has been various threads talking about the contribution
services on the dev mailing list. Jeremy suggested having a contribution
tool (command line and plugin) [1] and there was some other discussions
around integrating WSDL2Java with the contribution service [2]
and I think it does not make sense to have direct dependency on the whole
kernel core for these tools.

There was also couple discussions around modularization as well, where I
mentioned I'd start having contribution services moved to a separate module
[3]. And the idea is to have the contribution implementation on this new
module.

After thinking about it, I'm starting to think that a better place for it is
under /java/sca/services.Thoughts ?

[1] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg15557.html
[2] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg15179.html
[3] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg15359.html

On 3/16/07, Jim Marino <[EMAIL PROTECTED]> wrote:



> From: [EMAIL PROTECTED]
> Date: March 16, 2007 1:45:22 PM PDT
> To: tuscany-commits@ws.apache.org
> Subject: svn commit: r519138 - in /incubator/tuscany/java/sca/
> kernel/contribution: ./ src/ src/main/ src/main/java/ src/main/java/
> org/ src/main/java/org/apache/ src/main/java/org/apache/tuscany/
> src/main/java/org/apache/tuscany/spi/ src/main/java/org/apache/tus...
> Reply-To: tuscany-dev@ws.apache.org
>
> Author: lresende
> Date: Fri Mar 16 13:45:21 2007
> New Revision: 519138
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=519138
> Log:
> Placeholder to make contribution a separate kernel module

Where/when was this discussed? Also, what would be in it?

Jim



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





--
Luciano Resende
http://people.apache.org/~lresende

[jira] Commented: (TUSCANY-1164) Container of root object is non-null after endLogging()

[Yang ZHONG (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481764
 ] 

Yang ZHONG commented on TUSCANY-1164:
-

I'll try to patch once the EMF fix becomes available in a snapshot build.

> Container of root object is non-null after endLogging()
> ---
>
> Key: TUSCANY-1164
> URL: https://issues.apache.org/jira/browse/TUSCANY-1164
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-M3
>Reporter: Kelvin Goodson
> Fix For: Java-SDO-Mx
>
> Attachments: RootContainedByChSumTestCase.java
>
>
> When change logging is turned off on a root data object which has a 
> ChangeSummary property, the DataObject  becomes contained by the 
> ChangeSummaryImpl (test case to be appended)
> I believe that the issue is associated with the assumptions behind the EMF 
> code at line 272 of ChangeRecorder.java (EMF 2.2.2) in the 
> consolidateChanges() method
> if (eObject.eContainer() == null && eObject.eResource() == null)
> {
>   if (originalTargetObjects.contains(eObject))
>   {
> orphanedObjects.add(eObject);

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Fwd: svn commit: r519138

[Jim Marino]

From: [EMAIL PROTECTED]
Date: March 16, 2007 1:45:22 PM PDT
To: tuscany-commits@ws.apache.org
Subject: svn commit: r519138 - in /incubator/tuscany/java/sca/ 
kernel/contribution: ./ src/ src/main/ src/main/java/ src/main/java/ 
org/ src/main/java/org/apache/ src/main/java/org/apache/tuscany/  
src/main/java/org/apache/tuscany/spi/ src/main/java/org/apache/tus...

Reply-To: tuscany-dev@ws.apache.org

Author: lresende
Date: Fri Mar 16 13:45:21 2007
New Revision: 519138

URL: http://svn.apache.org/viewvc?view=rev&rev=519138
Log:
Placeholder to make contribution a separate kernel module


Where/when was this discussed? Also, what would be in it?

Jim



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

Understanding Service Discovery

[Antollini, Mario]

Hello Meeraj,

 

I have read several emails and I got to know that you are working on the
Discovery service. I am very interested in this topic and I will like to
get a better understanding about it. 

 

I have seen that you have also mentioned the Federated Deployer,
Federated Assembly and Marshaling Framework throughout your posts. I
think all these components are somewhat connected to the Service
Discovery mechanism, aren't they? I will really appreciate if you can
give me some details on how they all interact, if they do so at all.
And, I will also like to understand the big picture here; i.e. what is
the main goal you are trying to achieve with all that. In addition to
that I will like to understand the role JXTA plays here and how it also
interacts with these components.

 

Finally, I would like to know which is its is (i.e.; what it is already
able to do, what parts are missing, if you are willing to receive any
help, you are planning to get it ready for M3, etc).

 

As you saw I am asking way too many things, however I will be really
glad if you can answer at least some of these questions.

 

Thanks a lot in advance!

 

Looking forward to your reply,

 

Mario E. Antollini

Intel Software

ASDC

+54 351 414 5594

[EMAIL PROTECTED]  

 

 

Re: ArtifactResolver questions

[Jim Marino]

My orginal mindset is that we need some context for the resolving,  
for example, a resolver might use the classloader to resolve  
relative URIs.


Isn't DeploymentContext designed for Load/Resolve/Build?


With the federated architecture, we can't assume DeploymentContext  
anymore or that the steps above occur in the same VM. I posted a  
message earlier today outlining some of this but the key thing is  
that building happens on slave nodes and it is against a  
PhysicalChangeSet, not the logical model. The logical model will be  
handled on the Controller, which will also be responsible for  
resolution, normalization, and generation of PhysicalChangeSets sets  
comprising PhysicalComponentDefinitions, PhysicalWireDefinitions, and  
PhysicalResourceDefinitions. This will be marshalled across to the  
appropriate nodes.


Jim



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

UnrecognizedElementException: binding.jms

[muhwas]

hi everybody,

I am getting UnrecognizedElementException about jms
binding. Can somebody please point me to the jms
extension jar file?

org.apache.tuscany.spi.loader.UnrecognizedElementException:
{http://www.osoa.org/xmlns/sca/1.0}binding.jms

thank you

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

Re: Kernel Alpha2 Release

[Jean-Sebastien Delfino]

[snip]
Jeremy Boynes wrote:
I like the timing - about a month, 6 weeks at the most is a good 
window between releases in early stages like we are.



+1 from me

I agree federation is the big delta between now and then - we should 
have by then

* federated classloading (with multi-classloader support)
* federated scope
* the changes done for separating controller and physical runtime
* contribution store and artifact redistribution

It would be good to increase the spec coverage e.g.
* support for casting between proxies and service references
* support the new Conversation API
* clean up around complex properties - specifically being able to use 
an external file to configure the server runtime

* some more integration tests


Yes it will be good to increase the spec coverage. Adding to your list, 
I'd also like to support things like:
- Ability to override service/reference/property configuration at the 
componentType/component/composite level.
- More coverage of the SCDL 1.0 syntax with things like qnames on 
composites, or composite resolution without requiring a scdlLocation 
attribute for example, I think we need to do some work to bring our SCDL 
model in sync with the latest revision of the spec.
- Complex and multi-valued properties (I think Venkat has done some work 
in that area that could be included too)

- Support for both WSDL and java interfaces and mapping between the two

I can also help bring over some of the integration tests from the 
integration branch.




Also, user support such as:
* the composite plugin (i.e. pick an archive type)
* JUnit4/TestNG support in the itest plugin
* contribution tool (command line and plugin?)
* a start on some form of console
* some more samples
* doco for all the above


This looks good to me, I also want to have a very minimal runtime that 
will work without a Tuscany launcher.




The Guice idea is intriguing - support for their PM and annotations 
would be good. I also would like to take a look at using their EDSL 
for assembly - perhaps for hooking up the runtime as an alternative to 
SCDL.


Yes, this is an interesting idea. I like the idea of trying to use an 
alternative to SCDL to hook up the runtime.


Finally, I'd like to see if we could turn kernel/core into a few smaller 
modules for this release.




--
Jeremy



--
Jean-Sebastien


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

Re: Add generic builders to support SCDL extensibility elements

[Jeremy Boynes]

Raymond

There are two sets of issues here:
* How to support SCDL extensibility elements
* How to support import.sdo as an instance of that

As seed for discussion of the second, I don't think @Reference is the  
right way to declare access to a HelperContext - this seems more like  
a resource. Specifically, I think using @Reference or  in  
the component type will result in SCDL that is not semantically valid  
by SCA rules even if it happens to work in Tuscany and I think that's  
a problem. This is probably a big enough issue that it warrants its  
own thread.


In terms of extension, I think we need to look at the protocol  
between the controller and the runtime. That is based on a concept of  
a PhysicalChangeSet (PCS) contaning:
* resource definitions (e.g. for scopes, classloaders, or other  
runtime-specific things)

* component definitions
* wire definitions

So the question really is about how does a SCDL extension map to one  
of those definitions and I think there are a couple of patterns for  
that:

1) the element extends the function of the containing model object
   in that case it is not really generic and would be handled by the  
Generator for the container
2) the element creates one of the definitions above independent of  
the containing model object
   this is just a regular Generator acting on the extension object  
and adding a definition to a PCS
3) the element does something in the context of the containing model  
object

   again just a Generator, but one that needs to be passed the parent

With that in mind, I think we end up with a API more like:

  interface Generator {
void generate(M modelObject, P parent, GenerationContext  
context) throws Something;

  }

  class GenerationContext {
property Map changeSets;
  }

Generator implementation may also need access to a physical model  
that tracks the state of each physical runtime so that they can  
determine what the current runtime context is. This would be updated  
based on change events sent back from the runtime as it applied  
various PCS messages. That though is getting off topic :-)


--
Jeremy

On Mar 16, 2007, at 10:16 AM, Raymond Feng wrote:


Hi,

We had discussions on this ML before on how to support SCDL  
extensibility elements which are not part of the base SCDL model  
and are used in SCDL for .


Let's use  as an example to illustrate my proposal.

1) ImportSDOLoader is a StAXElementLoader to load   
element into ImportSDO model object.


2) The model object is attached to the parent model object which is  
CompositeComponentType in this case. We can use  
ModeObject.getExtensions() to keep the models loaded from the  
extensibility elements.


3) Add a GenericBuilder interface and GenericBuidlerExtension in  
SPI as follows:


public interface GenericBuilderModelObject> {
   S build(SCAObject parent, M modelObject, DeploymentContext  
deploymentContext) throws BuilderException;

}

4) Change the Buidler and BuilderRegistry interface to support  
GenericBuilder.


5) Create an ImportSDOBuilder which will create HelperContext from  
the ImportSDO model.


6) When the BuilderRegistery builds Component/Service/Reference, we  
look at the extensions for the corresponding model objects and try  
to run the GenericBuilders against the objects in  
ModelObject.getExtensions().


7) The ImportSDOBuilder creates a AtomicComponent to wrap  
HelperContext. and register it in the composite so that the  
component impl can use @Reference (autowire=true) to get access to  
this HelperContext.


If we agree I'm on track with the overall direction, I'll work on it.

Thanks,
Raymond


-
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: ArtifactResolver questions

[Raymond Feng]

Hi,

I think it might be better to polish the interface later on during the 
integration of contribution service stuff that Luciano is working on.


Anyway, some comments below.

Thanks,
Raymond

- Original Message - 
From: "Jeremy Boynes" <[EMAIL PROTECTED]>

To: 
Sent: Friday, March 16, 2007 10:08 AM
Subject: ArtifactResolver questions



On Mar 16, 2007, at 9:46 AM, Raymond Feng wrote:


Hi,

Contribution is the model object that hosts the metadata and 
introspected result for the contribution. Logically, you can use  the URI 
of the contribution to look up the ContributionService to  get the 
Contribution. I found it simpler for ArtifactResolver  extensions to 
receive Contribution directly.


Doesn't this just move the responsibility for lookup to the caller of 
this SPI? And given the caller should not know about the  implementation, 
it has to be passed every time even if the resolver  does not need that 
information?




I thought "lookup once" at the higher level is better.

Actually, why is this a parameter at all? What makes Contribution 
different from any other attribute passed in the Map?




The Map is used to hold addiontal attributes to further constrain the query 
and the entries are resolver-specific as I understand. I think we like the 
"strongly-typed" approach more.


Finally, why is DeploymentContext passed - can't I use this outside  the 
load phase?




My orginal mindset is that we need some context for the resolving, for 
example, a resolver might use the classloader to resolve relative URIs.


Isn't DeploymentContext designed for Load/Resolve/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]

Add generic builders to support SCDL extensibility elements

[Raymond Feng]

Hi,

We had discussions on this ML before on how to support SCDL extensibility 
elements which are not part of the base SCDL model and are used in SCDL for 
.


Let's use  as an example to illustrate my proposal.

1) ImportSDOLoader is a StAXElementLoader to load  element into 
ImportSDO model object.


2) The model object is attached to the parent model object which is 
CompositeComponentType in this case. We can use ModeObject.getExtensions() 
to keep the models loaded from the extensibility elements.


3) Add a GenericBuilder interface and GenericBuidlerExtension in SPI as 
follows:


public interface GenericBuilder 
{
   S build(SCAObject parent, M modelObject, DeploymentContext 
deploymentContext) throws BuilderException;

}

4) Change the Buidler and BuilderRegistry interface to support 
GenericBuilder.


5) Create an ImportSDOBuilder which will create HelperContext from the 
ImportSDO model.


6) When the BuilderRegistery builds Component/Service/Reference, we look at 
the extensions for the corresponding model objects and try to run the 
GenericBuilders against the objects in ModelObject.getExtensions().


7) The ImportSDOBuilder creates a AtomicComponent to wrap HelperContext. and 
register it in the composite so that the component impl can use @Reference 
(autowire=true) to get access to this HelperContext.


If we agree I'm on track with the overall direction, I'll work on it.

Thanks,
Raymond


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

[jira] Created: (TUSCANY-1182) Add multi-threaded test case for data object creation

[Kelvin Goodson (JIRA)]

Add multi-threaded test case for data object creation
-

 Key: TUSCANY-1182
 URL: https://issues.apache.org/jira/browse/TUSCANY-1182
 Project: Tuscany
  Issue Type: Test
  Components: Java SDO Implementation
Affects Versions: Java-SDO-M2
Reporter: Kelvin Goodson
Priority: Minor
 Fix For: Java-SDO-Mx


The fix contributed for TUSCANY-1179 includes a test case that uses GroboUtils 
for extending the unit test capability.  This JIRA is opened to decouple the 
fixing of the issue from the addition of the test case in order to ensure that 
we are clean with regards to licensing.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-1179) Race condition due to lazy metada initialization when SDO is shared across threads for read intent

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson resolved TUSCANY-1179.
-

Resolution: Fixed

committing the fix for this -- I'll close this JIRA and open another for the 
test case which will allow inclusion of the test case once the groboutils 
licensing issues are resolved

> Race condition due to lazy metada initialization when SDO is shared across 
> threads for read intent
> --
>
> Key: TUSCANY-1179
> URL: https://issues.apache.org/jira/browse/TUSCANY-1179
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
> Environment: ALL
>Reporter: Hasan Muhammad
> Fix For: Java-SDO-Mx
>
> Attachments: 1179.patch, CreateDataObjectMultiThreadedTestCase.java
>
>
> An a DataObject is being shared across multiple threads for read-only purpose 
> ( no modification), due to lazy metadata initialization, we have a race 
> condition which results in different exceptions at different times ( 
> ConcurrentModificationException, NoSuchElementException). The following is 
> one trace;
> java.util.ConcurrentModificationException
>   at 
> org.eclipse.emf.common.util.BasicEList$EIterator.checkModCount(BasicEList.java:1327)
>   at 
> org.eclipse.emf.common.util.BasicEList$EIterator.next(BasicEList.java:1275)
>   at 
> org.apache.tuscany.sdo.impl.ClassImpl.initAliasNames(ClassImpl.java:404)
>   at org.apache.tuscany.sdo.impl.ClassImpl.getProperty(ClassImpl.java:423)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:731)
>   at 
> org.apache.tuscany.sdo.impl.DataObjectImpl.get(DataObjectImpl.java:216)
>   at 
> org.apache.tuscany.sdo.impl.DataObjectImpl.getDataObject(DataObjectImpl.java:326)
>   at 
> org.apache.tuscany.sdo.test.CreateDataObjectMultiThreadedTestCase$CreateDataObjectMultiThread.runTest(CreateDataObjectMultiThreadedTestCase.java:67)
>   at 
> net.sourceforge.groboutils.junit.v1.TestRunnable.run(TestRunnable.java:154)
>   at java.lang.Thread.run(Thread.java:797)
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

ArtifactResolver questions

[Jeremy Boynes]

On Mar 16, 2007, at 9:46 AM, Raymond Feng wrote:


Hi,

Contribution is the model object that hosts the metadata and  
introspected result for the contribution. Logically, you can use  
the URI of the contribution to look up the ContributionService to  
get the Contribution. I found it simpler for ArtifactResolver  
extensions to receive Contribution directly.


Doesn't this just move the responsibility for lookup to the caller of  
this SPI? And given the caller should not know about the  
implementation, it has to be passed every time even if the resolver  
does not need that information?


Actually, why is this a parameter at all? What makes Contribution  
different from any other attribute passed in the Map?


Finally, why is DeploymentContext passed - can't I use this outside  
the load phase?


--
Jeremy


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

Re: New dependency on GroboUtils, and hence MIT license

[ant elder]

On 3/16/07, kelvin goodson <[EMAIL PROTECTED]> wrote:


http://issues.apache.org/jira/browse/TUSCANY-1179 has a useful concurrency
test case attached to it which would introduce a test scope dependency on
GroboUtils, from http://groboutils.sourceforge.net/,  and therefore on the
MIT license (http://groboutils.sourceforge.net/license.html).  Note, we
don't need to distribute this in a release,  but anyone building and
testing
SDO would download it from a maven repository as part of the build/unit
test
process. The license looks OK to be, but having dug around a bit I'm still
not completely confident I can introduce this dependency. Is there a
precedent for using this license in Tuscany?  Do I need IP clearance, and
if
so how do I ask for it?

Regards, Kelvin.



The MIT license is fine, so you can just go ahead. See:
http://people.apache.org/~cliffs/3party.html

  ...ant

Re: svn commit: r519040 - /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/deployer/ArtifactResolver.java

[Raymond Feng]

Hi,

Contribution is the model object that hosts the metadata and introspected 
result for the contribution. Logically, you can use the URI of the 
contribution to look up the ContributionService to get the Contribution. I 
found it simpler for ArtifactResolver extensions to receive Contribution 
directly.


Thanks,
Raymond

- Original Message - 
From: "Jeremy Boynes" <[EMAIL PROTECTED]>

To: 
Sent: Friday, March 16, 2007 9:33 AM
Subject: Re: svn commit: r519040 - 
/incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/deployer/ArtifactResolver.java




Why?

On Mar 16, 2007, at 9:26 AM, [EMAIL PROTECTED] wrote:


Author: rfeng
Date: Fri Mar 16 09:26:05 2007
New Revision: 519040

URL: http://svn.apache.org/viewvc?view=rev&rev=519040
Log:
Change the ArtifactResolver interface to take Contribution instead  of 
URI


Modified:
incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/ 
tuscany/spi/deployer/ArtifactResolver.java


Modified: incubator/tuscany/java/sca/kernel/spi/src/main/java/org/ 
apache/tuscany/spi/deployer/ArtifactResolver.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/kernel/ 
spi/src/main/java/org/apache/tuscany/spi/deployer/ 
ArtifactResolver.java?view=diff&rev=519040&r1=519039&r2=519040
== 

--- incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/ 
tuscany/spi/deployer/ArtifactResolver.java (original)
+++ incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/ 
tuscany/spi/deployer/ArtifactResolver.java Fri Mar 16 09:26:05 2007

@@ -19,10 +19,11 @@

 package org.apache.tuscany.spi.deployer;

-import java.net.URI;
 import java.net.URL;
 import java.util.Map;

+import org.apache.tuscany.spi.model.Contribution;
+

 /**
  * SCA Assemblies reference many artifacts of a wide variety of  types. 
These

@@ -46,7 +47,7 @@
 /**
  * Resolve an artifact by the qualified name
  *
- * @param contribution the URI of the contribution
+ * @param contribution the model of the contribution
  * @param modelClass The java type of the artifact
  * @param namespace The namespace of the artifact
  * @param name The name of the artifact
@@ -55,7 +56,7 @@
  * @param context The deployment context
  * @return The resolved artifact
  */
- T resolve(URI contribution,
+ T resolve(Contribution contribution,
   Class modelClass,
   String namespace,
   String name,
@@ -78,6 +79,6 @@
  *
  * @return The URI of the resolved artifact
  */
-URL resolve(URI contribution, String targetNamespace, String 
location, String baseURI);
+URL resolve(Contribution contribution, String targetNamespace, 
String location, String baseURI);


 }



-
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: [VOTE] Release Milestone 3 of Tuscany SCA Native and Tuscany SDO C++

[Andrew Borley]

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


Please vote to approve the release of milestone 3 of Tuscany SCA Native
and
Tuscany SDO C++.

The SDO release includes performance improvements (30-40%) along with
improvements to robustness.
The SCA release includes support for C++, Python and Ruby languages and
sca,
webservice and REST bindings.

The distribution artifacts are here:

   - linux and Mac OS X (source only) -
   http://people.apache.org/~robbinspg/M3-RC4/linux-macosx/
   - windows (source and binary) -
   http://people.apache.org/~robbinspg/M3-RC4/win32/

The RAT tool output for the release artifacts is here:
http://people.apache.org/~robbinspg/M3-RC4/

The SDO release is tagged here

http://svn.apache.org/repos/asf/incubator/tuscany/tags/cpp-sdo-1.0.incubating-M3-RC1/
The SCA release is tagged here

http://svn.apache.org/repos/asf/incubator/tuscany/tags/native-sca-1.0.incubating-M3-RC4/

Thank you.

--
Pete



I've gone through the Windows bin & src distros. All the samples work
happily & docs look good (but I would say that, I wrote half of 'em!)

Here's my +1

Cheers
Andy

New dependency on GroboUtils, and hence MIT license

[kelvin goodson]

http://issues.apache.org/jira/browse/TUSCANY-1179 has a useful concurrency
test case attached to it which would introduce a test scope dependency on
GroboUtils, from http://groboutils.sourceforge.net/,  and therefore on the
MIT license (http://groboutils.sourceforge.net/license.html).  Note, we
don't need to distribute this in a release,  but anyone building and testing
SDO would download it from a maven repository as part of the build/unit test
process. The license looks OK to be, but having dug around a bit I'm still
not completely confident I can introduce this dependency. Is there a
precedent for using this license in Tuscany?  Do I need IP clearance, and if
so how do I ask for it?

Regards, Kelvin.

Re: svn commit: r519040 - /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/deployer/ArtifactResolver.java

[Jeremy Boynes]

Why?

On Mar 16, 2007, at 9:26 AM, [EMAIL PROTECTED] wrote:


Author: rfeng
Date: Fri Mar 16 09:26:05 2007
New Revision: 519040

URL: http://svn.apache.org/viewvc?view=rev&rev=519040
Log:
Change the ArtifactResolver interface to take Contribution instead  
of URI


Modified:
incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/ 
tuscany/spi/deployer/ArtifactResolver.java


Modified: incubator/tuscany/java/sca/kernel/spi/src/main/java/org/ 
apache/tuscany/spi/deployer/ArtifactResolver.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/kernel/ 
spi/src/main/java/org/apache/tuscany/spi/deployer/ 
ArtifactResolver.java?view=diff&rev=519040&r1=519039&r2=519040
== 

--- incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/ 
tuscany/spi/deployer/ArtifactResolver.java (original)
+++ incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/ 
tuscany/spi/deployer/ArtifactResolver.java Fri Mar 16 09:26:05 2007

@@ -19,10 +19,11 @@

 package org.apache.tuscany.spi.deployer;

-import java.net.URI;
 import java.net.URL;
 import java.util.Map;

+import org.apache.tuscany.spi.model.Contribution;
+

 /**
  * SCA Assemblies reference many artifacts of a wide variety of  
types. These

@@ -46,7 +47,7 @@
 /**
  * Resolve an artifact by the qualified name
  *
- * @param contribution the URI of the contribution
+ * @param contribution the model of the contribution
  * @param modelClass The java type of the artifact
  * @param namespace The namespace of the artifact
  * @param name The name of the artifact
@@ -55,7 +56,7 @@
  * @param context The deployment context
  * @return The resolved artifact
  */
- T resolve(URI contribution,
+ T resolve(Contribution contribution,
   Class modelClass,
   String namespace,
   String name,
@@ -78,6 +79,6 @@
  *
  * @return The URI of the resolved artifact
  */
-URL resolve(URI contribution, String targetNamespace, String  
location, String baseURI);
+URL resolve(Contribution contribution, String targetNamespace,  
String location, String baseURI);


 }



-
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: svn move, was: Databinding itest reorg proposal

[Jeremy Boynes]

Ah, apollogies for that. I have to admit that I'm a cvs person at  
heart so
just getting to grips with svn. I ljust ooked up svn move and got  
that "why
didn't I look there first" feeling, so I'll remember that for next  
time.

Thanks for taking the time to explain.


If you're new to Subversion I highly recommend reading this:
  http://svnbook.red-bean.com/

There's an Appendix on "Subversion for CVS Users" :-)
--
Jeremy


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

Re: Current state of the SPI?

[Jim Marino]

On Mar 16, 2007, at 4:16 AM, ant elder wrote:

With trying to get containers and bindings going in the trunk again  
and it
looks like with all the core changes the SPI is a little out of  
date now.
Eg, there's classes like InsanceWrapperBase in the core that could  
be in the

SPI, TargetInvokerExtension could have more methods on TargetInvoker,
there's a whole bunch of old methods on AtomicComponent that aren't in
AtomicComponentExtension so have to be implemented in new Component  
impls,
etc. What are the plans for cleaning up this type of thing? I know  
there's a
a whole lot of change going on in the core right now so should i  
just wait
for that to settle down a bit before thinking about tidying up the  
SPI?


  ...ant
Yeah we're in the process of trying to cut-over but do it in a way  
that does not break things. Consequently there are a lot of  
deprecated APIs. What we are trying to do is simplify the extension  
model along these lines:


1. ServiceBindings and ReferenceBindings will go away and people just  
write Components for extensions. This means wires in the runtime will  
be connected in on of the following ways:


- Component to Component. This is the basic case where a component  
reference is wired to a component service, i.e. two components wired  
together


- Transport binding Component to Component. For example, a component  
service exposed as a web service in the runtime could be a wire  
running from the Axis extension Component to the application  
Component providing the service. The Axis extension service may have  
to work with a ServletHost to accept incoming requests and pass then  
down one of the Wire's invocation chain.


- Component to transport binding Component. This is when an  
application component reference is wired to a composite reference  
that is configured with a binding. In the web services example, the  
transport binding Component would be responsible for taking  
invocations as they flowed through InvocationChains on the wire and  
flowing them out over the transport.


We have a new interface, WireAttacher, which is responsible for  
connecting a wire to a particular component type on the source and  
target sides. Each binding extension, component implementation type  
extension, etc. would provide an implementation. The same class that  
implements PhysicalComponentBuilder can also implement WireAttacher.  
The WireAttacher will have access to specific metadata for attaching  
the wire as subclasses of PhysicalWireSourceDefinition or  
PhysicalWireTargetDefinition. These can contain specific information  
related to the binding. A transport binding Component may also expose  
a specific contract for the WireAttacher to use when it give it the  
Wire.


2. We also don't need TargetInvoker anymore. Since we can perform  
wire optimization (i.e. just pass a direct reference), and we have  
the WireAttacher, the InvocationChains will just have interceptors.  
Typically, during the wire attach process for the target, an  
interceptor will be added to the chain. For Java component  
implementations, the JavaInvokerInterceptor does this. It is similar  
to TargetInvoker but is one less concept. Also, later, I think this  
design will allow us to further decompose some of the functions that  
were in TargetInvoker related to conversations out into separate  
interceptors thereby making the design cleaner.


I've made a start on the Hessian Binding  if you want to take a look  
for some examples.



Right now we have this refactored invocation and wiring  
infrastructure in place. We just need to connect this to the  
federation and marshalling parts over the next day or so. Once that  
is in place, all of the deprecated stuff can be removed.


One of the specific things that need to be done is we need to  
"bridge" the logical assembly model and the physical model used to  
instantiate runtime artifacts. As some background, in federation,  
there will be a master "Controller" (right now it is one physical  
node but in the future could be many) and "slave" nodes. When an  
assembly is contributed, it will be processed and indexed by the  
contribution service on the Controller. This would involve  
determining things like the component type. When a component is  
"deployed", the Controller will be responsible for converting the  
logical assembly model (basically what can be represented by SCDL)  
into a physical model. These will be done by Generators.


Generation is a multi-step process. The first step is to take a pass  
resolving autowires against the SCA Domain (the Controller always has  
a representation of the Domain). Once this is done, the Generators  
will convert ComponentDefinitions to PhysicalComponentDefinitions.  
The PCDs are a compact representation of the configured component  
used by the slave nodes to create Components. This process will be  
done by PhysicalComponentBuilders.


The second step is for binding target URIs expressed

Re: How to associate some context with a composite?

[Raymond Feng]

Great.

I'll move it to SPI under "org.apache.tuscany.spi.component" in a few 
minutes.


Thanks,
Raymond

- Original Message - 
From: "Jeremy Boynes" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, March 15, 2007 11:12 PM
Subject: Re: How to associate some context with a composite?



On Mar 15, 2007, at 10:35 PM, Raymond Feng wrote:


Hi,

When I try to register a HelperContext component for the composite  from 
databinding-sdo extension, I found that I need to access the 
ComponentManager which is in the core. Can we promote it to SPI?


Makes sense.



BTW, do we still have the distinction of system component or  regular 
component?


No. Just components, some of which have a system implementation at  the 
logical level and a different PCD type at the physical level, but  by the 
time they get registered with the ComponentManager they are  all just 
Components.


I hope we can actually merge Component and AtomicComponent together  as 
well.

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

[VOTE] Release Milestone 3 of Tuscany SCA Native and Tuscany SDO C++

[Pete Robbins]

Please vote to approve the release of milestone 3 of Tuscany SCA Native and
Tuscany SDO C++.

The SDO release includes performance improvements (30-40%) along with
improvements to robustness.
The SCA release includes support for C++, Python and Ruby languages and sca,
webservice and REST bindings.

The distribution artifacts are here:

  - linux and Mac OS X (source only) -
  http://people.apache.org/~robbinspg/M3-RC4/linux-macosx/
  - windows (source and binary) -
  http://people.apache.org/~robbinspg/M3-RC4/win32/

The RAT tool output for the release artifacts is here:
http://people.apache.org/~robbinspg/M3-RC4/

The SDO release is tagged here
http://svn.apache.org/repos/asf/incubator/tuscany/tags/cpp-sdo-1.0.incubating-M3-RC1/
The SCA release is tagged here
http://svn.apache.org/repos/asf/incubator/tuscany/tags/native-sca-1.0.incubating-M3-RC4/

Thank you.

--
Pete

[jira] Commented: (TUSCANY-1180) Unable to initialize read-only properties

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481626
 ] 

Frank Budinsky commented on TUSCANY-1180:
-

The SDO specification workgroup is planning to define an SPI for setting 
readonly properties, but until then we recommend not using readonly properties.

> Unable to initialize read-only properties
> -
>
> Key: TUSCANY-1180
> URL: https://issues.apache.org/jira/browse/TUSCANY-1180
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Mx
>Reporter: Stepan Ilchenko
> Fix For: Java-SDO-M3
>
>
> The problem is that we can't initialize read-only property in recently 
> created DataObject, when we fill it with data by own DAS. SDO API says, that 
> Exception should be raized in case of attempting to change that king of 
> property through API. That's why new method in SDO Implementation needs to be 
> created to provide property initialization.
> Maybe 'isSet' parameter should be used to control initialization process of 
> the property.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (TUSCANY-1181) XSDSerializationTest is Tuscany-specific

[Andy Grove (JIRA)]

XSDSerializationTest is Tuscany-specific


 Key: TUSCANY-1181
 URL: https://issues.apache.org/jira/browse/TUSCANY-1181
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Reporter: Andy Grove


XSDSerializationTest contains assertions like the following that expect 2 types 
to be created from simple.xsd, which just contains a single type called "Quote".

assertEquals("XSDHelper.define() did not create the expected number of Types", 
2, types.size());

Presumably the current assertion is based on DocumentRoot being in the types 
list.

It would be better to check that the "Quote" type is in the list rather than 
just checking the size of the list.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (TUSCANY-1179) Race condition due to lazy metada initialization when SDO is shared across threads for read intent

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson updated TUSCANY-1179:


   Patch Info: [Patch Available]
Fix Version/s: Java-SDO-Mx

Setting patch available=true, and target fix version to SDO-Java-Mx

> Race condition due to lazy metada initialization when SDO is shared across 
> threads for read intent
> --
>
> Key: TUSCANY-1179
> URL: https://issues.apache.org/jira/browse/TUSCANY-1179
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
> Environment: ALL
>Reporter: Hasan Muhammad
> Fix For: Java-SDO-Mx
>
> Attachments: 1179.patch, CreateDataObjectMultiThreadedTestCase.java
>
>
> An a DataObject is being shared across multiple threads for read-only purpose 
> ( no modification), due to lazy metadata initialization, we have a race 
> condition which results in different exceptions at different times ( 
> ConcurrentModificationException, NoSuchElementException). The following is 
> one trace;
> java.util.ConcurrentModificationException
>   at 
> org.eclipse.emf.common.util.BasicEList$EIterator.checkModCount(BasicEList.java:1327)
>   at 
> org.eclipse.emf.common.util.BasicEList$EIterator.next(BasicEList.java:1275)
>   at 
> org.apache.tuscany.sdo.impl.ClassImpl.initAliasNames(ClassImpl.java:404)
>   at org.apache.tuscany.sdo.impl.ClassImpl.getProperty(ClassImpl.java:423)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:731)
>   at 
> org.apache.tuscany.sdo.impl.DataObjectImpl.get(DataObjectImpl.java:216)
>   at 
> org.apache.tuscany.sdo.impl.DataObjectImpl.getDataObject(DataObjectImpl.java:326)
>   at 
> org.apache.tuscany.sdo.test.CreateDataObjectMultiThreadedTestCase$CreateDataObjectMultiThread.runTest(CreateDataObjectMultiThreadedTestCase.java:67)
>   at 
> net.sourceforge.groboutils.junit.v1.TestRunnable.run(TestRunnable.java:154)
>   at java.lang.Thread.run(Thread.java:797)
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (TUSCANY-1098) Add get() and getInstanceProperties() methods in Type and Property

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson updated TUSCANY-1098:


Fix Version/s: Java-SDO-M3

> Add get() and getInstanceProperties() methods in Type and Property
> --
>
> Key: TUSCANY-1098
> URL: https://issues.apache.org/jira/browse/TUSCANY-1098
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Mx
>Reporter: Kelvin Goodson
> Fix For: Java-SDO-M3
>
> Attachments: TestRetrieveMetadataInfo.java, 
> TestRetrieveMetadataInfo.java, tuscany-1098.patch1, tuscany-1098.patch1, 
> TypePropertyMetadataInfo.xsd, TypePropertyMetadataInfo.xsd
>
>
> The 2.1 spec introduced these new methods on Type and Property

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (TUSCANY-708) Should TypeHelper.define return List of Types that includes DocumentRootType

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson updated TUSCANY-708:
---

Fix Version/s: (was: Java-SDO-Mx)
   Java-SDO-M3

> Should TypeHelper.define return List of Types that includes DocumentRootType
> 
>
> Key: TUSCANY-708
> URL: https://issues.apache.org/jira/browse/TUSCANY-708
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-M2
> Environment: All 
>Reporter: Robbie Minshall
>Priority: Minor
> Fix For: Java-SDO-M3
>
> Attachments: 708.patch
>
>
> TypeHelper.define returns List of Types that includes the DocumentRoot Type
> Perhaps is shoudl only include Types that are deifned within the XSD ( i.e 
> CompanyType, DeptartmentType etc ) 
> SDOUtil.getTypes( scope, uri ) explicidly removes the DocumentRoot Type 
>result.remove(((TypeHelperImpl) 
> scope).getExtendedMetaData().getDocumentRoot(ePackage));
> Should the Types returned by TypeHelper.define(...) and SDOUtil(scope, uri ) 
> be consistent ?  They probably should at least treat DocumentRoot Type 
> consistently.
> FrankB says: Currently the DocumentRoot contains the global properties but he 
> current SDO spec does not say how they are handled.   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-708) Should TypeHelper.define return List of Types that includes DocumentRootType

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson resolved TUSCANY-708.


Resolution: Fixed

applied Fuhwei's patch which removes the function that hid the DocumentRoot 
type from the set of types retuned by SDOUtil.getTypes(TypeHelper,String) method

> Should TypeHelper.define return List of Types that includes DocumentRootType
> 
>
> Key: TUSCANY-708
> URL: https://issues.apache.org/jira/browse/TUSCANY-708
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-M2
> Environment: All 
>Reporter: Robbie Minshall
>Priority: Minor
> Fix For: Java-SDO-Mx
>
> Attachments: 708.patch
>
>
> TypeHelper.define returns List of Types that includes the DocumentRoot Type
> Perhaps is shoudl only include Types that are deifned within the XSD ( i.e 
> CompanyType, DeptartmentType etc ) 
> SDOUtil.getTypes( scope, uri ) explicidly removes the DocumentRoot Type 
>result.remove(((TypeHelperImpl) 
> scope).getExtendedMetaData().getDocumentRoot(ePackage));
> Should the Types returned by TypeHelper.define(...) and SDOUtil(scope, uri ) 
> be consistent ?  They probably should at least treat DocumentRoot Type 
> consistently.
> FrankB says: Currently the DocumentRoot contains the global properties but he 
> current SDO spec does not say how they are handled.   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Current state of the SPI?

[ant elder]

With trying to get containers and bindings going in the trunk again and it
looks like with all the core changes the SPI is a little out of date now.
Eg, there's classes like InsanceWrapperBase in the core that could be in the
SPI, TargetInvokerExtension could have more methods on TargetInvoker,
there's a whole bunch of old methods on AtomicComponent that aren't in
AtomicComponentExtension so have to be implemented in new Component impls,
etc. What are the plans for cleaning up this type of thing? I know there's a
a whole lot of change going on in the core right now so should i just wait
for that to settle down a bit before thinking about tidying up the SPI?

  ...ant

[jira] Updated: (TUSCANY-1177) CTS should not expect DocumentRoot to be included in results from XSDHelper.define()

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson updated TUSCANY-1177:


Patch Info: [Patch Available]

setting patch available

> CTS should not expect DocumentRoot to be included in results from 
> XSDHelper.define()
> 
>
> Key: TUSCANY-1177
> URL: https://issues.apache.org/jira/browse/TUSCANY-1177
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Community Test Suite
>Reporter: Andy Grove
> Attachments: 1177.patch
>
>
> DocumentRoot was mentioned in SDO 2.0.1 and was only relevant to XML 
> documents without an XSD. All mentioned of DocumentRoot were removed from SDO 
> 2.1 and the CTS should not be expecting DocumentRoot to be returned by 
> XSDHelper.define().

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (TUSCANY-1176) DynamicTypesFromSchemaTestCase should not expect "mixed" and "text" properties

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson updated TUSCANY-1176:


Patch Info: [Patch Available]

setting patch available flag

> DynamicTypesFromSchemaTestCase should not expect "mixed" and "text" properties
> --
>
> Key: TUSCANY-1176
> URL: https://issues.apache.org/jira/browse/TUSCANY-1176
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Community Test Suite
>Reporter: Andy Grove
> Attachments: 1176.patch
>
>
> DynamicTypesFromSchemaTestCase currently fails if a call to 
> getInstanceProperties does not return "mixed" or "text" properties. I see no 
> mention of these properties in the SDO for Java 2.1 specification. The "text" 
> property was mentioned in SDO 2.0.1 but then removed for SDO 2.1.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (TUSCANY-1169) Property.getType() throws ClassCastException if the property is from AnyDataObjectType.getInstanceProperties()

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson updated TUSCANY-1169:


Fix Version/s: Java-SDO-M3

> Property.getType() throws ClassCastException if the property is from 
> AnyDataObjectType.getInstanceProperties()
> --
>
> Key: TUSCANY-1169
> URL: https://issues.apache.org/jira/browse/TUSCANY-1169
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-M3
>Reporter: Raymond Feng
> Fix For: Java-SDO-M3
>
>
> I try to load the following XML document without defining XSD against the 
> XSDHelper.
> 
> http://www.example.com/wrapper"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://www.example.com/wrapper wrapper.xsd ">
> message
> symbol
> message1
> symbol1
> symbol2
> 
> Then when I call:
> List properties = rootObject.getInstanceProperties();
> For a property in the list, calling p.getType() gives me a ClassCastException.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (TUSCANY-1168) Type.isSequenced() returns wrong value for my XSD

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson updated TUSCANY-1168:


Fix Version/s: Java-SDO-M3

> Type.isSequenced() returns wrong value for my XSD
> -
>
> Key: TUSCANY-1168
> URL: https://issues.apache.org/jira/browse/TUSCANY-1168
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-M3
>Reporter: Raymond Feng
> Fix For: Java-SDO-M3
>
>
> For the following XSD:
> http://www.example.com/wrapper"; 
> xmlns="http://www.w3.org/2001/XMLSchema";>
> 
> 
> 
> 
> 
>  type="string" />
> 
> 
> 
> 
> 
> 
>  type="string" />
> 
> 
> 
> 
> I assume the type for "op" element is sequenced since maxOccurs >1.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (TUSCANY-1167) SDO Codegen generates bad code when the noNotification option is used

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson updated TUSCANY-1167:


Patch Info: [Patch Available]

Setting patch available flag

> SDO Codegen generates bad code when the noNotification option is used
> -
>
> Key: TUSCANY-1167
> URL: https://issues.apache.org/jira/browse/TUSCANY-1167
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-M3
> Environment: n/a
>Reporter: David T. Adcox
> Fix For: Java-SDO-Mx
>
> Attachments: 1167.patch
>
>
> The code generated using the -noNotification option causes the SDO codegen 
> tool to create code that can not be compiled.  There is an issue in the 
> basicUnsetx method, where the return statement is excluded.  This is 
> because the return has accidentally been included inside the suppress 
> notification condition.  The return statement should be outside of this 
> condition.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Native M3 Release Candidate

[Pete Robbins]

On 16/03/07, Andrew Borley <[EMAIL PROTECTED]> wrote:


On 3/15/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
>
>
> On 3/15/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > On 3/15/07, Pete Robbins < [EMAIL PROTECTED]> wrote:
> > >
> > > Here is the latest candidate with fixes to the samples deploy
location
> > > on
> > > linux/mac
> > >
> > > http://people.apache.org/~robbinspg/M3-RC3/<
http://people.apache.org/%7Erobbinspg/M3-RC3/>
> > >
> > > If there are no major issues with this I will start a vote tomorrow.
> > >
> > > Cheers,
> > >
> > > --
> > > Pete
> > >
> >
> > I'm having trouble with RubyBigBank on Windows. It's crashing when it
> > tries to convert an SDO into a Rexml document  - anyone else see this
or is
> > it just my Ruby?
> > The line that's failing is 357 in RubyServiceProxy.cpp:
> >
> > value = rb_class_new_instance(1, vstr,
> > RubyImplementation::getXMLDocumentClass());
> >
> > This is trying to instantiate a new Document object from the
serialized
> > XML
> >
> > Cheers
> > Andy
> >
>
>
> The sample works fine on Linux BTW, it's just Windows that's failing.
>
> Andy
>

Ruby REXML problem found and fixed in r518904. A static method was being
called & returning variables that were only being initialized in the
constructor...

Cheers
Andy



Great. I have added the copyright to the Notice files and applied Caroline's
patch to SDO. I think we are at a point where I can generate a candidate to
vote on.

Cheers

--
Pete

[jira] Updated: (TUSCANY-1156) CodeGen generates lowercase feature name when the schema specifies uppercase

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson updated TUSCANY-1156:


Fix Version/s: Java-SDO-M3

> CodeGen generates lowercase feature name when the schema specifies uppercase
> 
>
> Key: TUSCANY-1156
> URL: https://issues.apache.org/jira/browse/TUSCANY-1156
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-M2
> Environment: All
>Reporter: Hasan Muhammad
> Fix For: Java-SDO-M3
>
> Attachments: 1156.patch, example1156.zip
>
>
> When the schema is let us say the following
> 
> 
> 
> 
> 
> 
> The codegen tool generates the name for the feature "ID" in lower case i.e 
> "id". Hence when we use the DataObject.setString("ID","value"), it throws the 
> following exception because it could not find the feature ID.
> Caused by: java.lang.IllegalArgumentException: Class 'HolderDetail' does not 
> have a feature named 'ID'
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2069)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2211)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1941)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1858)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil.setString(DataObjectUtil.java:474)
>   at 
> org.apache.tuscany.sdo.impl.DataObjectImpl.setString(DataObjectImpl.java:566)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Native M3 Release Candidate

[Andrew Borley]

On 3/15/07, Andrew Borley <[EMAIL PROTECTED]> wrote:




On 3/15/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
>
>
> On 3/15/07, Pete Robbins < [EMAIL PROTECTED]> wrote:
> >
> > Here is the latest candidate with fixes to the samples deploy location
> > on
> > linux/mac
> >
> > 
http://people.apache.org/~robbinspg/M3-RC3/
> >
> > If there are no major issues with this I will start a vote tomorrow.
> >
> > Cheers,
> >
> > --
> > Pete
> >
>
> I'm having trouble with RubyBigBank on Windows. It's crashing when it
> tries to convert an SDO into a Rexml document  - anyone else see this or is
> it just my Ruby?
> The line that's failing is 357 in RubyServiceProxy.cpp:
>
> value = rb_class_new_instance(1, vstr,
> RubyImplementation::getXMLDocumentClass());
>
> This is trying to instantiate a new Document object from the serialized
> XML
>
> Cheers
> Andy
>


The sample works fine on Linux BTW, it's just Windows that's failing.

Andy



Ruby REXML problem found and fixed in r518904. A static method was being
called & returning variables that were only being initialized in the
constructor...

Cheers
Andy

Re: svn move, was: Databinding itest reorg proposal

[Simon Laws]

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


On Mar 15, 2007, at 3:34 PM, Simon Laws wrote:
> I forgot to mention that the reason that so many XML files have
> suddenly
> appeared is that I've take the files that currently live in /
> interop and
> renamed and refactored them.

Thanks for explaining as this did look a bit odd.

One way to avoid that is to use "svn move" to move the files rather
than adding them again. When you do that, SVN shows that the file was
copied from somewhere else in the repo and so it is fairly clear that
it isn't a new work but just a derivative. This also has the
advantage that the history of the file is maintained so users can
track changes even across the move. It has an even bigger benefit in
that it makes life easier for the lawyers, and a happy lawyer is much
nicer to have than a grumpy one :-)

Some IDEs which grew up with CVS don't seem to realize that SVN
allows them to just move things rather than delete old and add new
(losing history in the process). If that's the case, then you can
still get the benefits of moving through the svn command.

--
Jeremy


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

Ah, apollogies for that. I have to admit that I'm a cvs person at heart so

just getting to grips with svn. I ljust ooked up svn move and got that "why
didn't I look there first" feeling, so I'll remember that for next time.
Thanks for taking the time to explain.

Regards

Simon

[jira] Created: (TUSCANY-1180) Unable to initialize read-only properties

[Stepan Ilchenko (JIRA)]

Unable to initialize read-only properties
-

 Key: TUSCANY-1180
 URL: https://issues.apache.org/jira/browse/TUSCANY-1180
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-Mx
Reporter: Stepan Ilchenko
 Fix For: Java-SDO-M3


The problem is that we can't initialize read-only property in recently created 
DataObject, when we fill it with data by own DAS. SDO API says, that Exception 
should be raized in case of attempting to change that king of property through 
API. That's why new method in SDO Implementation needs to be created to provide 
property initialization.
Maybe 'isSet' parameter should be used to control initialization process of the 
property.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: C++ DAS Lite versus C++ DAS, was Fwd: [jira] Updated: (TUSCANY-1140) Implementation of DAS Lite Command classes

[Luciano Resende]

I have just applied your patch. At some point, once we get things more
stable, we should decide witch way to go, and maybe promote the das_lite to
just c++ das. For now this should be OK.

BTW, I liked Pete's comments : "keep DASing ;-)"

--
Luciano Resende
http://people.apache.org/~lresende

On 3/15/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:


I think you got the point when you said to remove the files from the
project, I don't know how I hadn't thought about it. Because the main
reason
to create a new project in VS solution is to avoid the compilation errors
from those many classes that are not completed implemented.

But also because I wanted to keep the previous implementation, for
example,
of the class ReadCommandImpl that was reimplemented in das_lite project.
With diferent versions of classes we can define what is already
implemented
completely(das_lite project) and what remains to be
implemented(das_runtime
project).

I think we could try another approach where we could move the classes from
the das_runtime to a trunk or something like and the classes that we are
actually implementing from the das_lite(cpp/das/runtime/das_lite/src/)
project to the das_runtime(cpp/das/runtime/core/src) project and
continuing
implementing from there.

What do you think?

Adriano Crestani





On 3/15/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> Hi Adriano
>
>I was looking into your patch, and realized you had created a new
> project
> located at (cpp/das/runtime/das_lite/src/) instead of continuing to work
> on
> (cpp/das/runtime/core/src). I tought that from a previous quick
discussion
>
> we had agreed that das_lite was more a initial simple scenario rather
then
> a
> new project.
>
>I have couple questions :
>- Could you please elaborate what your plans are here ?
>- What's the main differences between C++ DAS and C++ DAS Lite ?
>- Is this new project a small subset of files that were
duplicated
> from cpp/das/runtime/core/src ? If so, is there a way to have one
project
> but only compile/use the subset of files required, maybe just not adding
> them to the VS project ?
>
>I'll wait after clarification on this subject before I apply the
patch.
>If anyone else have other thoughts/questions, please let me know.
>
> --
> Luciano Resende
> http://people.apache.org/~lresende 
>
> -- Forwarded message --
> From: Adriano Crestani (JIRA) 
> Date: Mar 15, 2007 10:39 AM
> Subject: [jira] Updated: (TUSCANY-1140) Implementation of DAS Lite
Command
> classes
> To: tuscany-dev@ws.apache.org
>
>
>  [
>
>
https://issues.apache.org/jira/browse/TUSCANY-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Adriano Crestani updated TUSCANY-1140:
> --
>
> Attachment: tuscany1040.crestani.20070315.patch
>
> - Added a new project to vs solution titled das_lite
>
> - Implementation of ReadCommanImpl, BaseCommandImpl and CommandImpl
> classes
>
> - Integration with sdo on ReadCommanImpl::buildGraph method is not
working
>
> correctly
>
> - Also added other classes of das_lite library, but not completely
> implemented yet
>
> > Implementation of DAS Lite Command classes
> > --
> >
> > Key: TUSCANY-1140
> > URL:
https://issues.apache.org/jira/browse/TUSCANY-1140
> > Project: Tuscany
> >  Issue Type: Sub-task
> >  Components: C++ DAS
> >Affects Versions: Wish list
> >Reporter: Adriano Crestani
> > Assigned To: Adriano Crestani
> > Fix For: Wish list
> >
> > Attachments: tuscany1040.crestani.20070315.patch
> >
> >
> > Implementation of BaseCommandImpl, Command, CommandImpl and
> ReadCommandImpl classes as described on the DAS Lite  class diagram:
> http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=45093
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>