date:20080228


Luciano Resende wrote:

I have completed most of the work done related to porting the Feed
Binding to use Apache Abdera 0.3.0. I have also moved sample/store and
the Store scenario tutorial to use this new implementation. I'm still
planning to refactor the binding-feed-atom to follow the
modularization used for other extensions as below :

Modules: binding-atom (model), binding-atom-xml (XML handling),
binding-atom-abdera (implementation using Abdera).

I'm also planning to hide the Abdera model objects, and probably use
the implementation-data-api collection interface to handle the actual
data feeds.

Please let me know if you have questions and/or comments.



Great, I'll give it a try.

I just fixed the support for query strings in the Rome based Atom 
binding in SVN r631889. You may want to take a look at the fix and apply 
it to the Abdera version, if it has the same bug.

--
Jean-Sebastien

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

Composite and PolicySet processing in ContributionServiceImpl?

There is a fair amount of special handling code for composites and 
policySets in ContributionServiceImpl.


I guess these are hacked workarounds for some issues? any idea what the 
issues were?

--
Jean-Sebastien

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

Re: Exposing composite file as a web service

Hi Sandeep,

We have some samples to demonstrate this. Have you had a look at
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-ws-webapp
?

- Venkat

On Thu, Feb 28, 2008 at 12:53 PM, Sandeep Raman [EMAIL PROTECTED]
wrote:

Hi ,

When I apply binding to my component , the Tuscany seems to be starting a
server on its own on the port i give in the binding uri.
how can i make the component service run in axis2 which i have already
deployed in tomcat.
i.e. how can i tell the composite file to run the service in axis2
deployed in tomcat which is already running on port 8080.
can you guide me on this.

Regards
Sandeep Raman.

Simon Laws [EMAIL PROTECTED] wrote on 02/26/2008 07:41:58 PM:

On Tue, Feb 26, 2008 at 12:59 PM, Sandeep Raman [EMAIL PROTECTED]
wrote:

Hi,

Can the composite file be exposed as a web service to external world.
how can i go about it. can you please guide me.

regards
Sandeep Raman.
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

Hi Sandeep

I'm not clear what you mean by Can the composite file be exposed as a
web
service.. but you can certainly expose, as web services, component
services
that a composite file describes. For example, take a look at the
helloworld-ws-service sample [1]. In the composite file (
helloworldws.composite) [2] that this sample uses you will see that it
defines a single component with a single service exposed as a web
service.

composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://helloworld;
xmlns:hw=http://helloworld;
name=helloworldws

component name=HelloWorldServiceComponent
implementation.java class=helloworld.HelloWorldImpl /
service name=HelloWorldService
interface.wsdl
interface=http://helloworld#wsdl.interface(HelloWorld)http://helloworld#wsdl.interface%28HelloWorld%29
/
binding.ws uri=http://localhost:8085/HelloWorldService/
/service
/component

/composite

Note that the binding.ws... part make the service a web service. So if
I
run this sample I can reasonably expect to be able to point my browser
at

http://localhost:8085/HelloWorldService?wsdl

To see the WSDL description of the web service that is created and to
prove
that it is running. For this sample there is also a client SCA
application
[3] that can be used to make a call to this web service.

Hope that helps. Let me know if I'm interpreting the question
incorrectly
here of if you need more information

Regards

Simon

[1]
http://svn.apache.
org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service/
[2]
http://svn.apache.
org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-

service/src/main/resources/META-INF/sca-deployables/helloworldws.composite
[3]
http://svn.apache.

org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-reference/

ForwardSourceID:NT573E
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

Re: Trouble with aggregating definitions.xml in distro

Hi,

Alright, point taken :).  I am going to resolve this with the provider
option and also clean up based on your suggestions.  Thanks.

- Venkat

On Thu, Feb 28, 2008 at 12:17 AM, Jean-Sebastien Delfino 
[EMAIL PROTECTED] wrote:

 Venkata Krishnan wrote:
  Hi Sebastien,
 
  Thanks for the suggestion.  Going by the ProviderExtesionPoint way...
 
  - first I'd prefer load the definitions.xml instead of creating
  programmatically so that we don't have to touch the code for every
 change to
  the definitions.

 Definitions.xml is code, it's just XML code and not Java code.

 The choice really depends on what you have in your policy definitions,
 and which one is simpler in each extension case:

 SCADefinitions definition = new SCADefinitionsImpl();
 SCABindingType bindingType = new SCABindingTypeImpl();
 definition.getBindingTypes().add(bindingType);

 or

 sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0;
   targetNamespace=http://www.osoa.org/xmlns/sca/1.0;
   xmlns:sca=http://www.osoa.org/xmlns/sca/1.0;
   xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0;

   bindingType.../

 /sca:definitions

 BTW I noticed that there are two copies of BindingTypeImpl in the policy
 and definitions modules, but no factories for these policy model objects
 (forcing code to depend on the model implementation classes).

 Also I think it would be simpler to regroup the definitions model and
 the policies model in a single module.

  - every module that has its own definitions.xml must define it in a
 unique
  path so that the file does not get lost when we are making the
  tuscany-sca-all jar file in the distro.
 
  So, given that every module HAS to define its definitions.xml in a
 unique
  path I am wondering if it would just enuf for each module then to just
 about
  publish the path for this in a file similar to the ones in
  META-INF/services.  So even when this file is aggregated by the shade
 plugin
  when making the tuscany-sca-all jar, we still have the location paths of
 all
  definitions.xml.  Is this a viable alternative ?
 

 It is a viable alternative but adds yet another mechanism to contribute
 pieces of extensions. I think it's better to stick to a single
 consistent mechanism.

 --
 Jean-Sebastien

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

Re: Classloading code in core contribution processing


Rajini Sivaram wrote:

On 2/22/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

Jean-Sebastien Delfino wrote:
Great to see a *test* case for cycles, but my question was: Do you
have a *use* case for cycles and partial packages right now or can

it  be fixed later?


Rajini Sivaram wrote:
No, I dont have an use-case, at least not an SCA one. But there are

plenty

of them in OSGi - eg. Tuscany modules cannot run in OSGi without support

for

split-packages.  Of course you can fix it later.

I'm not arguing for or against fixing it now or later, I'm trying to get
the real use case to make a decision based on concrete grounds. Can you
point me to your OSGi use cases, or help me understand Tuscany modules
cannot run in OSGi without support for split packages?



 Tuscany node and domain code are split into three modules each for API, SPI
and Implementation eg. tuscany-node-api, tuscany-node and tuscany-node-impl.
The API module defines a set of classes in org.apache.tuscany.sca.node and
the SPI module extends this package with more classes. So the package
org.apache.tuscany.sca.node is split across tuscany-node-api and
tuscany-node. If we used maven-bundle-plugin to generate OSGi manifest
entries for Tuscany modules, we would get three OSGi bundles corresponding
to the node modules. And the API and SPI bundles have to specify that they
use split-packages. It would obviously have been better if API and SPI used
different packages, but the point I am trying to make is that splitting
packages across modules is not as crazy as it sounds, and split packages do
appear in code written by experienced programmers.

IMO, supporting overlapping package import/exports is more important with
SCA contributions than with OSGi bundles since SCA contributions can specify
wildcards in import.java/export.java. eg. If you look at packaging
tuscany-contribution and tuscany-contribution-impl where
tuscany-contribution-impl depends on tuscany-contribution, there is no clear
naming convention to separate the two modules using a single import/export
statement pair. So if I could use wildcards, the simplest option that would
avoid separate import/export statements for each subpackage (as required in
OSGi) would be to export org.apache.tuscany.sca.contribution* from
tuscany-contribution and import org.apache.tuscany.sca.contribution* in
tuscany-contribution-impl. The sub-packages themselves are not shared but
the import/export namespaces are. We need to avoid cycles in these cases.
Again, there is a way to avoid sharing package spaces, but it is simpler to
share, and there is nothing in the SCA spec which stops you sharing packages
across contributions.

I dont think the current model resolver code which recursively searches
exporting contributions for artifacts is correct anyway - even for artifacts
other than classes. IMO, when an exporting contribution is searched for an
artifact, it should only search the exporting contribution itself, not its
imports. And that would avoid cycles in classloading. I would still prefer
not to intertwine classloading and model resolution because that would
unnecessarily make classloading stack traces which are complex anyway, even
more complex that it needs to be. But at least if it works all the time,
rather than run into stack overflows, I might not have to look at those
stack traces



and this will convince me to help fix it now :) Thanks.


It is not broken now - you have to break it first and then fix it :-).



I have reviewed the model resolution and classloading code and found the 
following:


- Split namespaces are currently supported (for example by the WSDL and 
XSD resolvers). The model resolver mechanism does not have an issue with 
split namespaces.


- The Java import/export resolvers do not seem to support split packages 
(if I understood that code which was quite tricky), but that's an issue 
in that Java import/export specific code, which just needs to be fixed. 
I'll work on it.


- The interactions between the Java import/export listener, the model 
resolvers and the ContributionClassLoader are way too complicated IMHO. 
That complexity is mostly caused by ContributionClassLoader, I'll try to 
show a simpler implementation in a few days.


- Dependency cycles are an exception in Java as build tools like Maven 
don't support them, but can exist in XSD for example. Supporting cycles 
just requires a simple fix to the import model resolvers, I'll help fix 
that too.


Hope this helps.
--
Jean-Sebastien

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

Re: Exposing composite file as a web service

2008-02-28 Thread Sandeep Raman

Hi Venkat,

I went through the sample, i have done pretty nmuch the same.
The service component specifies the URL on which the service will be 
available.

Consider this scenario:

I have a web server already running in the port 8080 , now when I try to 
create a new instance of the composite file tusany tries to start itws own 
server on the port mentioned in the composite file. In my case , i want 
tuscany to use the existing connection on 8080 and make the composite 
service available as an axis service on the port i am already running. I 
want to restrict tuscany from starting the server on its own.

Regards
Sandeep.

Venkata Krishnan [EMAIL PROTECTED] wrote on 02/28/2008 02:54:31 
PM:

 Hi Sandeep,
 
 We have some samples to demonstrate this.  Have you had a look at
 http://svn.apache.
 org/repos/asf/incubator/tuscany/java/sca/samples/calculator-ws-webapp
 ?
 
 - Venkat
 
 On Thu, Feb 28, 2008 at 12:53 PM, Sandeep Raman [EMAIL PROTECTED]
 wrote:
 
  Hi ,
 
  When I apply binding to my component , the Tuscany seems to be 
starting a
  server on its own on the port i give in the binding uri.
  how can i make the component service run in axis2 which i have already
  deployed in tomcat.
  i.e.  how can i tell the composite file to run the service in axis2
  deployed in tomcat which is already running on port 8080.
  can you guide me on this.
 
  Regards
  Sandeep Raman.
 
  Simon Laws [EMAIL PROTECTED] wrote on 02/26/2008 07:41:58 
PM:
 
   On Tue, Feb 26, 2008 at 12:59 PM, Sandeep Raman 
[EMAIL PROTECTED]
   wrote:
  
Hi,
   
Can the composite file be exposed as a web service to external 
world.
how can i go about it. can you please guide me.
   
regards
Sandeep Raman.
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
   
   
Hi Sandeep
  
   I'm not clear what you mean by Can the composite file be exposed as 
a
  web
   service.. but you can certainly expose, as web services, component
  services
   that a composite file describes. For example, take a look at the
   helloworld-ws-service sample [1]. In the composite file (
   helloworldws.composite) [2] that this sample uses you will see that 
it
   defines a single component with a single service exposed as a web
  service.
  
   composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
  targetNamespace=http://helloworld;
  xmlns:hw=http://helloworld;
   name=helloworldws
  
   component name=HelloWorldServiceComponent
   implementation.java class=helloworld.HelloWorldImpl /
  service name=HelloWorldService
  interface.wsdl
   interface=http://helloworld#wsdl.interface(HelloWorld)http:
 //helloworld#wsdl.interface%28HelloWorld%29
  /
  binding.ws 
uri=http://localhost:8085/HelloWorldService/
  /service
   /component
  
   /composite
  
  
   Note that the binding.ws... part make the service a web service. 
So if
  I
   run this sample I can reasonably expect to be able to point my 
browser
  at
  
   http://localhost:8085/HelloWorldService?wsdl
  
  
   To see the WSDL description of the web service that is created and 
to
  prove
   that it is running. For this sample there is also a client SCA
  application
   [3] that can be used to make a call to this web service.
  
   Hope that helps. Let me know if I'm interpreting the question
  incorrectly
   here of if you need more information
  
   Regards
  
   Simon
  
   [1]
   http://svn.apache.
   
org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service/
   [2]
   http://svn.apache.
   org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-
  
  
service/src/main/resources/META-INF/sca-deployables/helloworldws.composite
   [3]
   http://svn.apache.
  
  
org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-reference/
 
   ForwardSourceID:NT573E
  =-=-=
  Notice: The information contained in this e-mail
  message and/or attachments to it may contain
  confidential or privileged information. If you are
  not the intended recipient, any dissemination, use,
  review, distribution, printing or copying of the
  information contained in this e-mail message
  and/or attachments to it are strictly prohibited. If
  you have received this communication in error,
  please notify us by reply e-mail or telephone and
  immediately and permanently delete the message
  and any attachments. Thank you
 
 
 

 ForwardSourceID:NT5B96

Re: Composite and PolicySet processing in ContributionServiceImpl?

On Thu, Feb 28, 2008 at 9:04 AM, Jean-Sebastien Delfino 
[EMAIL PROTECTED] wrote:

 There is a fair amount of special handling code for composites and
 policySets in ContributionServiceImpl.

 I guess these are hacked workarounds for some issues? any idea what the
 issues were?
 --
 Jean-Sebastien

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


This was the pseudo code that Venkat used to describe the appliesTo
processing here [1].

Enhance composite with policy sets based on appliesTo information

   1. For each composite file read the xml content first...
  1. For each policyset in the domain...
 1. Extract the value of 'appliesTo' attribute with is an
 xpath expression
 2. Evaluate this expression against the composite xml
 3. For each node that results out of the above evaluation
1. if the node contains an attribute named
'applicablePolicySets'
   1. concatenate to its value, the name of the
   PolicySet
2. else
   1. create an attribute named
   'applicablePolicySet' and set its value to the name of
the PolicySet
  2. Wherever applicable the composite's elements
   will have the additional attribute name 'applicablePolicySets'.

Don't know if that covers all of the policy processing in
ContributionServiceImpl

Regards

Simon

[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Runtime+Phases

Re: [DISCUSSION] PassByValue SPI, was: Re: svn commit: r628163

2008-02-28 Thread Simon Nash


Answers inline.

  Simon

Jean-Sebastien Delfino wrote:

Simon Nash wrote:

See inline.

  Simon

Raymond Feng wrote:

Hi,

I think Simon's proposal should work as follows instead of passing 
the properties to the createInvoker() call.


public interface Invoker {
   InvokerProperties getProperties(); // Contribute properties
}

public class InvokerProperties {
   public void setAllowsPassByReference(boolean allowsPBR) {
 
   }
   public boolean allowsPassByReference() {
   
   }

   // Add more properties without impacting the Invoker interface
   public AnotherPropertyType getAnotherProperty() {
  ...
   }

   public void setAnotherProperty(AnotherPropertyType anotherProp) {
...
   }
}

So the difference is whether having simple properties on the Invoker 
interface or defining a complex property as a collection of properties.



I'm not very keen on this modification to my proposal.  See [1] for
the reason why.

Anyway, since we have different opinions, I'm OK to have a vote to 
get it decided.


So far we have the following options on the table:

1) Add allowsPassByReference() to the Invoker interface directly
2) Add getInvokerProperties() to the Invoker interface directly and 
the InvokerProperties will encapasulate known properties including 
allowsPassByReference.
3) Add allowsPassByReference() to an optional SPI (either a 
separate interface or a sub-interface of Invoker)
4) Add getInvokerProperties() to an optional SPI (either a separate 
interface or a sub-interface of Invoker)


Please add your options if I miss them before we call a vote.


Please add my proposal as described in [2] (using interfaces not classes,
and adding a parameter to the createInvoker() method).



This is going in circles :) If you add a parameter to createInvoker to 
pass an InvokerProperties... then I have two questions:

- who actually creates the InvokerProperties?


The Tuscany core runtime code that calls createInvoker().


- can it still be an interface implemented by the extension?


No.  It's used by the extension but not implemented by it.

See [1] for a more detailed explanation.

  Simon

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28292.html


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

Re: [VOTE] Change Tuscany Charter to remove SDO reference

2008-02-28 Thread Simon Nash


kelvin goodson wrote:

Please vote to alter the wording of the existing draft Tuscany charter as
discussed in

http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/[EMAIL 
PROTECTED]

to the following 

WHEREAS, the Board of Directors deems it to be in the best
 interests of the Foundation and consistent with the Foundation's
 purpose to establish a Projectt Management Committee charged with the
creation
 and maintenance of open-source software for distribution at no charge
 to the public, that simplifies the development, deployment and management
 of distributed applications built as compositions of service components.
 These components may be implemented with a range of technologies and
 connected using a variety of communication protocols. This software will
 implement relevant open standards including, but not limited to, the
 SCA standard defined by the OASIS OpenCSA member section, and related
 technologies.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
 Committee (PMC), to be known as the Apache Tuscany Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further

RESOLVED, that the Apache Tuscany Project be and hereby is
 responsible for the creation and maintenance of software
 related to Apache Tuscany;
 and be it further

RESOLVED, that the office of Vice President, Apache Tuscany be
 and hereby is created, the person holding such office to
 serve at the direction of the Board of Directors as the chair
 of the Apache Tuscany Project, and to have primary responsibility
 for management of the projects within the scope of
 responsibility of the Apache Tuscany Project; and be it further

RESOLVED, that the persons listed immediately below be and
 hereby are appointed to serve as the initial members of the
 Apache Tuscany Project:

 Adriano Crestaniadrianocrestani at apache dot org
 Andrew Borley   ajborley at apache dot org
 ant elder   antelder at apache dot org
 Brady Johnson  bjohnson at apache dot org
 Frank Budinsky frankb at apache dot org
 Ignacio Silva-Lepe  isilval at apache dot org
 Jean-Sebastien Delfino   jsdelfino at apache dot org
 kelvin goodson   kelvingoodson at apache dot org
 Luciano Resende   lresende at apache dot org
 Mike Edwards   edwardsmj at apache dot org
 Pete Robbinsrobbinspg at apache dot org
 Raymond Feng  rfeng at apache dot org
 Simon Laws  slaws at apache dot org
 Simon Nash  nash at apache dot org
 Venkata Krishnan  svkrish at apache dot org
 Mark Combellack   mcombellack at apache dot org

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
 be appointed to the office of Vice President, Apache Tuscany, to
 serve in accordance with and subject to the direction of the
 Board of Directors and the Bylaws of the Foundation until
 death, resignation, retirement, removal or disqualification,
 or until a successor is appointed; and be it further

RESOLVED, that the Apache Tuscany Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator Tuscany podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
 Incubator Tuscany podling encumbered upon the Apache Incubator
 Project are hereafter discharged.


Please can you highlight all the changes that are in this proposed
new text, or point to the current version so that I can do a
comparison.  Thanks.

  Simon


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

[jira] Resolved: (TUSCANY-2055) ServiceReference.getConversationID() not returning generated conversation IDs

2008-02-28 Thread Simon Nash (JIRA)


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

Simon Nash resolved TUSCANY-2055.
-

Resolution: Invalid

The current implementation is correct.  This API returns the conversation ID 
that was set by ServiceReference.setConversationID() and will be used for the 
next conversation to be initiated by this service reference.  This is not the 
same as the conversation ID for the current conversation, which is returned by 
CallableReference.getConversation().getConversationID().

 ServiceReference.getConversationID() not returning generated conversation IDs
 -

 Key: TUSCANY-2055
 URL: https://issues.apache.org/jira/browse/TUSCANY-2055
 Project: Tuscany
  Issue Type: Bug
  Components: Specification
Affects Versions: Java-SCA-Next
Reporter: Kevin Williams

 ServiceReference.getConversationID() returns null unless the Conversation ID 
 is set by the user.
 This is the current  implementaiton:
 public Object getConversationID() {
 return conversationID;
 }
 It seems that that if the cached ID is null, and there is a valid related 
 Converasation object then the impl should return the related 
 Conversation.getConversationID.

-- 
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: A Chinese version of Tuscany's technical page

2008-02-28 Thread Simon Nash

Luciano Resende wrote:
 We have fixed the technical issues that were preventing us to continue
 with this effort, so I guess we are ready to accept the Chinese
 translation of the Tuscany website.
 
 I think the following are the next steps we should take :
 
 - Remove the old corrupted contents from our wiki ( I can do this
 later today if people are ok)
 - Chinese community to post a fresh version of the Chinese translation
 of Tuscany website
 - Raymond (our Chinese guru) would help us review the contents
 - Make sure the contributors ha CLAs on file with Apache (they don't
 have it as of today), see [1]
 - Once contents are reviewed and CLAs in place, migrate the contents
 to our website wiki.
 
 Thoughts ?
 
Thanks Luciano for following through on this.

+1 to all your suggestions for how to proceed.

  Simon

 [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25115.html
 
 2007/11/7 Mike Edwards [EMAIL PROTECTED]:
 Luciano,

  Just to let you know that in principle Confluence Wiki software can deal
  with pages in Chinese and other languages using non-Western scripts.

  The OSOA Wiki has some Chinese and Japanese pages, here is an example:

  http://www.osoa.org/pages/viewpage.action?pageId=416

  The OSOA installation uses the Postgre database.  Which one is being
  used by the Apache Wiki?


  Yours,  Mike.



  Luciano Resende wrote:
   Unfortunately, I haven't heard back from infra@ yet, and the guys on
   Infra IRC weren't able to give much help this morning. I'm going to
   check if the confluence guys have a IRC chat or something similar...
  
 (cut)


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

Re: [VOTE] Change Tuscany Charter to remove SDO reference

2008-02-28 Thread kelvin goodson

The wording of the existing draft charter was taken from
http://mail-archives.apache.org/mod_mbox/incubator-general/200710.mbox/[EMAIL 
PROTECTED]

Be sure to note when looking at that posting that it consists of a previous
version + a modification at the end of the posting.

The changes are ...
1) This software will implement relevant open standards including, but not
limited to, the SCA and SDO standards defined by the OASIS OpenCSA member
section.
becomes ...
This software will implement relevant open standards including, but not
limited to, the SCA standard defined by the OASIS OpenCSA member section,
and related technologies.

2) Andy Grove removed as initial member as per his request to step down from
PPMC
3) Mark Combellack added as member by virtue of PPMC membership

Kelvin.


On 28/02/2008, Simon Nash [EMAIL PROTECTED] wrote:

 kelvin goodson wrote:
  Please vote to alter the wording of the existing draft Tuscany charter
 as
  discussed in
 
 
 http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/[EMAIL 
 PROTECTED]
 
  to the following 
 
  WHEREAS, the Board of Directors deems it to be in the best
   interests of the Foundation and consistent with the Foundation's
   purpose to establish a Projectt Management Committee charged with the
  creation
   and maintenance of open-source software for distribution at no charge
   to the public, that simplifies the development, deployment and
 management
   of distributed applications built as compositions of service
 components.
   These components may be implemented with a range of technologies and
   connected using a variety of communication protocols. This software
 will
   implement relevant open standards including, but not limited to, the
   SCA standard defined by the OASIS OpenCSA member section, and related
   technologies.
 
  NOW, THEREFORE, BE IT RESOLVED, that a Project Management
   Committee (PMC), to be known as the Apache Tuscany Project,
   be and hereby is established pursuant to Bylaws of the
   Foundation; and be it further
 
  RESOLVED, that the Apache Tuscany Project be and hereby is
   responsible for the creation and maintenance of software
   related to Apache Tuscany;
   and be it further
 
  RESOLVED, that the office of Vice President, Apache Tuscany be
   and hereby is created, the person holding such office to
   serve at the direction of the Board of Directors as the chair
   of the Apache Tuscany Project, and to have primary responsibility
   for management of the projects within the scope of
   responsibility of the Apache Tuscany Project; and be it further
 
  RESOLVED, that the persons listed immediately below be and
   hereby are appointed to serve as the initial members of the
   Apache Tuscany Project:
 
   Adriano Crestaniadrianocrestani at apache dot org
   Andrew Borley   ajborley at apache dot org
   ant elder   antelder at apache dot org
   Brady Johnson  bjohnson at apache dot org
   Frank Budinsky frankb at apache dot org
   Ignacio Silva-Lepe  isilval at apache dot org
   Jean-Sebastien Delfino   jsdelfino at apache dot org
   kelvin goodson   kelvingoodson at apache dot org
   Luciano Resende   lresende at apache dot org
   Mike Edwards   edwardsmj at apache dot org
   Pete Robbinsrobbinspg at apache dot org
   Raymond Feng  rfeng at apache dot org
   Simon Laws  slaws at apache dot org
   Simon Nash  nash at apache dot org
   Venkata Krishnan  svkrish at apache dot org
   Mark Combellack   mcombellack at apache dot org
 
  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
   be appointed to the office of Vice President, Apache Tuscany, to
   serve in accordance with and subject to the direction of the
   Board of Directors and the Bylaws of the Foundation until
   death, resignation, retirement, removal or disqualification,
   or until a successor is appointed; and be it further
 
  RESOLVED, that the Apache Tuscany Project be and hereby
   is tasked with the migration and rationalization of the Apache
   Incubator Tuscany podling; and be it further
 
  RESOLVED, that all responsibilities pertaining to the Apache
   Incubator Tuscany podling encumbered upon the Apache Incubator
   Project are hereafter discharged.
 

 Please can you highlight all the changes that are in this proposed
 new text, or point to the current version so that I can do a
 comparison.  Thanks.

Simon


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

Re: [DISCUSSION] PassByValue SPI, was: Re: svn commit: r628163


Simon Nash wrote:
...
This is going in circles :) If you add a parameter to createInvoker to 
pass an InvokerProperties... then I have two questions:

- who actually creates the InvokerProperties?

 
The Tuscany core runtime code that calls createInvoker().


- can it still be an interface implemented by the extension?


No.  It's used by the extension but not implemented by it.


I don't understand why. If my extension must implement InvokerProperties 
getInvokerProperties(); and InvokerProperties is an interface, I should 
be able to provide my own implementation of InvokerProperties.


--
Jean-Sebastien

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

Re: Composite and PolicySet processing in ContributionServiceImpl?


Simon Laws wrote:

On Thu, Feb 28, 2008 at 9:04 AM, Jean-Sebastien Delfino 
[EMAIL PROTECTED] wrote:


There is a fair amount of special handling code for composites and
policySets in ContributionServiceImpl.

I guess these are hacked workarounds for some issues? any idea what the
issues were?
--
Jean-Sebastien

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



This was the pseudo code that Venkat used to describe the appliesTo
processing here [1].

Enhance composite with policy sets based on appliesTo information

   1. For each composite file read the xml content first...
  1. For each policyset in the domain...
 1. Extract the value of 'appliesTo' attribute with is an
 xpath expression
 2. Evaluate this expression against the composite xml
 3. For each node that results out of the above evaluation
1. if the node contains an attribute named
'applicablePolicySets'
   1. concatenate to its value, the name of the
   PolicySet
2. else
   1. create an attribute named
   'applicablePolicySet' and set its value to the name of
the PolicySet
  2. Wherever applicable the composite's elements
   will have the additional attribute name 'applicablePolicySets'.

Don't know if that covers all of the policy processing in
ContributionServiceImpl

Regards

Simon

[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Runtime+Phases



OK, the algorithm makes sense to me but I'm surprised that it's done in 
contribution-impl. IMO contribution-impl should not have dependencies on 
the specifics of composites and policies and all this work should be 
pushed one level up in the dependency stack.


--
Jean-Sebastien

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

[jira] Reopened: (TUSCANY-2055) ServiceReference.getConversationID() not returning generated conversation IDs

2008-02-28 Thread Kevin Williams (JIRA)


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

Kevin Williams reopened TUSCANY-2055:
-


This is from the Java Annotations and API V100-5


521   1.6.6.2. Accessing Conversation IDs from Clients
522Whether the conversation ID is chosen by the client or is generated by 
the system, the client may access
523the conversation ID by calling ServiceReference.getConversationID().

Am I misreading this?


 ServiceReference.getConversationID() not returning generated conversation IDs
 -

 Key: TUSCANY-2055
 URL: https://issues.apache.org/jira/browse/TUSCANY-2055
 Project: Tuscany
  Issue Type: Bug
  Components: Specification
Affects Versions: Java-SCA-Next
Reporter: Kevin Williams

 ServiceReference.getConversationID() returns null unless the Conversation ID 
 is set by the user.
 This is the current  implementaiton:
 public Object getConversationID() {
 return conversationID;
 }
 It seems that that if the cached ID is null, and there is a valid related 
 Converasation object then the impl should return the related 
 Conversation.getConversationID.

-- 
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: [DISCUSS] altering the Tuscany Charter in relation to SDO Java


kelvin goodson wrote:

Implicit in this rewording is the understanding within the Tuscany community
that there would be one Apache home for SDO Java development.   When this
thread is referenced in proposal for the new project, or discussions around
it,  it must be clear to the wider Apache community that the Tuscany
community accepts that.  Without this clear acceptance I fear the new
project will face further periods of delay whilst questions are asked about
the Tuscany communities intentions with regards to SDO Java development.

So the answer to your question is conditional.
If the new project is accepted an an incubator 

- does not require Tuscany to implement SDO anymore --- yes
- and still allows Tuscany to implement SDO   --- no
- and still allows Tuscany to use SDO or any other related technology?   ---
yes

if the project is not accepted as an incubator ...

- does not require Tuscany to implement SDO anymore --- yes
- and still allows Tuscany to implement SDO   --- yes
- and still allows Tuscany to use SDO or any other related technology?   ---
yes



I'm trying to understand how to vote, or if I should vote, on your other 
thread. Maybe I'm missing something. There is an SDO implementation in 
Tuscany at the moment. SDO is a related technology worked on in 
OpenCSA too. Why would we want to remove it from the charter?


--
Jean-Sebastien

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

Re: [DISCUSS] altering the Tuscany Charter in relation to SDO Java

This software will implement relevant open standards including, but not
limited to, the
 SCA standard defined by the OASIS OpenCSA member section, and related
 technologies.

When we say including but not limited to I understand that it would very
well contain SDO and others implicitly.  Or, does this have a different
interprettation ?

- Venkat

On Thu, Feb 28, 2008 at 10:00 PM, Jean-Sebastien Delfino 
[EMAIL PROTECTED] wrote:

 kelvin goodson wrote:
  Implicit in this rewording is the understanding within the Tuscany
 community
  that there would be one Apache home for SDO Java development.   When
 this
  thread is referenced in proposal for the new project, or discussions
 around
  it,  it must be clear to the wider Apache community that the Tuscany
  community accepts that.  Without this clear acceptance I fear the new
  project will face further periods of delay whilst questions are asked
 about
  the Tuscany communities intentions with regards to SDO Java development.
 
  So the answer to your question is conditional.
  If the new project is accepted an an incubator 
 
  - does not require Tuscany to implement SDO anymore --- yes
  - and still allows Tuscany to implement SDO   --- no
  - and still allows Tuscany to use SDO or any other related technology?
 ---
  yes
 
  if the project is not accepted as an incubator ...
 
  - does not require Tuscany to implement SDO anymore --- yes
  - and still allows Tuscany to implement SDO   --- yes
  - and still allows Tuscany to use SDO or any other related technology?
 ---
  yes
 

 I'm trying to understand how to vote, or if I should vote, on your other
 thread. Maybe I'm missing something. There is an SDO implementation in
 Tuscany at the moment. SDO is a related technology worked on in
 OpenCSA too. Why would we want to remove it from the charter?

 --
 Jean-Sebastien

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

Re: Composite and PolicySet processing in ContributionServiceImpl?

On Thu, Feb 28, 2008 at 3:58 PM, Jean-Sebastien Delfino 
[EMAIL PROTECTED] wrote:

 Simon Laws wrote:
  On Thu, Feb 28, 2008 at 9:04 AM, Jean-Sebastien Delfino 
  [EMAIL PROTECTED] wrote:
 
  There is a fair amount of special handling code for composites and
  policySets in ContributionServiceImpl.
 
  I guess these are hacked workarounds for some issues? any idea what the
  issues were?
  --
  Jean-Sebastien
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
  This was the pseudo code that Venkat used to describe the appliesTo
  processing here [1].
 
  Enhance composite with policy sets based on appliesTo information
 
 1. For each composite file read the xml content first...
1. For each policyset in the domain...
   1. Extract the value of 'appliesTo' attribute with is an
   xpath expression
   2. Evaluate this expression against the composite xml
   3. For each node that results out of the above evaluation
  1. if the node contains an attribute named
  'applicablePolicySets'
 1. concatenate to its value, the name of the
 PolicySet
  2. else
 1. create an attribute named
 'applicablePolicySet' and set its value to the name of
  the PolicySet
2. Wherever applicable the composite's elements
 will have the additional attribute name 'applicablePolicySets'.
 
  Don't know if that covers all of the policy processing in
  ContributionServiceImpl
 
  Regards
 
  Simon
 
  [1]
 http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Runtime+Phases
 

 OK, the algorithm makes sense to me but I'm surprised that it's done in
 contribution-impl. IMO contribution-impl should not have dependencies on
 the specifics of composites and policies and all this work should be
 pushed one level up in the dependency stack.

 --
 Jean-Sebastien

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

 Well I think this is one of the things that could be usefully extracted
from the contribution service and into a separate enhance composite with
policy function. As to where it should go? I'm in a bit of a quandry. It
feels like we need something between what is currently in the contribution
service and some of the things that are currently in policy and in the
assembly builders. Could we have a new module
assembly-processor/assembly-builder/assembly-configurator? where we can put
functions that manipulate an assembly model that has already been read and
where function from other modules needs to be bought together.

I have an interest in this as in looking into the way that we can configure
a domain's composites with any endpoint information we know ahead of
deployment time and will likely want a home for an enhance composite will
endpoint info function.

Simon

Investigating assignment of endpoint information to the domain model was: Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes

On Tue, Feb 26, 2008 at 5:49 PM, Simon Laws [EMAIL PROTECTED]
wrote:



 On Tue, Feb 5, 2008 at 8:34 AM, Jean-Sebastien Delfino 
 [EMAIL PROTECTED] wrote:

  Venkata Krishnan wrote:
   It would also be good to have some sort of 'ping' function that could
  be
   used to check if a service is receptive to requests.  Infact I wonder
  if the
   Workspace Admin should also be able to test this sort of a ping per
   binding.  Is this something that can go into the section (B) .. or is
  this
   out of place ?
  
 
  Good idea, I'd put it section (D). A node runtime needs to provide a way
  to monitor its status.
 
  --
  Jean-Sebastien
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
  Hi Sebastien

 I see you have started to check in code related to steps A and B. I have
 time this week to start helping on this and thought I would start looking at
 the back end of B and moving into C but don't want to tread on you toes.

 I made some code to experiment with before I went on holiday so it's not
 integrated with your code (it just uses the Workspace interface). What I was
 starting to look at was resolving a domain level composite which includes
 unresolved composites. I.e. I built a composite which includes the
 deployable composites for a series of contributions and am learning about
 resolution and re-resolution.

 I'm not doing anything about composite selection for deployment just yet.
 That will come from the node model/gui/command line. I just want to work out
 how we get the domain resolution going in this context.

 If you are not already doing this I'll carry on experimenting in my
 sandbox for a little while longer and spawn of a separate thread to discuss.

 Simon


 And here's the separate thread following on from [1]... I'm looking at
what we can do with any endpoint information we have prior to the point at
which a composite is deployed to a node. This is an alternative to
(replacement for?) having the Tuscany runtime go and query for endpoint
information after it has been started. I have been summarizing info here
[2][3].  Looking at this I need to do something like...

- associate composites with nodes/apply physical binding defaults/propagate
physical addresses based on domain level wiring

   1. Read in node model - which provides
  1. Mapping of composite to node
  2. Default configuration of bindings at that node, e.g. the root
  URL required for binding.ws
   2. For each composite in the domain (I'm assuming I have access to the
   domain level composite model)
  1. Find, from the node model, the node which will host the
  composite
  2. for each service in the composite
 1. If there are no bindings for the service
1. Create a default binding configured with the
default URI from the node model
2. We maybe should only configure the URI if we know
there is a remote reference.
2. else
1. find each binding in the service
   1. Take the default binding configuration and
   apply it to the binding
   2. What to do about URLs as they may be either

  1. Unset
 1. Apply algorithm from Assembly
 Spec 1.7.2
  2. Set relatively
 1. Apply algorithm from Assembly
 Spec 1.7.2
  3. Set absolutely
 1. Assume it is set correctly?
  4. Set implicitly (from WSDL
  information)
 1. Assume it is set correctly?
3. The above is similar to what goes
 during compositeConfiguration in the build phase
  3. For each reference in the composite
 1. Look for any targets that cannot be satisfied within
 the current node (need an interface to call through which
scans the domain)
 2. Find the service model for this target
 3. Do policy and binding matching
 4. For matching bindings ensure that the binding URL is
 unset and set with information from the target service
 5. The above is also similar to what happens during the
 build phase
 4. Domain Level Autowiring also needs to be taken into
  account
  5. Wire by impl that uses domain wide references also need to be
  considered

Referring to the builder code now is feels like 2.2 above is a new model
enhancement step that could reuse (some of) the function in
CompositeConfigurationBuilderImpl.configureComponents but with extra binding
specific feature to ensure that URLs are set correctly.

2.3 looks very like CompositeWireBuilder.

My quandry at the moment is that the process has a dependency on the node
description so it doesn't fit in the builders where they are at the moment.
It feels like we need

Are comments on SVN commit messages archived anywhere?

Are comments posted against SVN commit messages in tuscany-dev archived
anywhere?

Simon

Re: Are comments on SVN commit messages archived anywhere?

2008-02-28 Thread Luciano Resende

Not sure I understood what you are looking for, but tuscany-commits is
archived in [1]

[1] http://www.mail-archive.com/tuscany-commits%40ws.apache.org/maillist.html

On Thu, Feb 28, 2008 at 10:58 AM, Simon Laws [EMAIL PROTECTED] wrote:
 Are comments posted against SVN commit messages in tuscany-dev archived
  anywhere?

  Simon




-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

Re: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project

2008-02-28 Thread Raymond Feng


It should be fixed by r632098 now.

Thanks,
Raymond
--
From: Continuum VMBuild Server [EMAIL PROTECTED]
Sent: Thursday, February 28, 2008 10:16 AM
To: tuscany-dev@ws.apache.org
Subject: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation 
Project


Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=57105projectId=277


Build statistics:
 State: Failed
 Previous State: Ok
 Started at: Thu 28 Feb 2008 10:08:35 -0800
 Finished at: Thu 28 Feb 2008 10:10:53 -0800
 Total time: 2m 18s
 Build Trigger: Schedule
 Build Number: 80
 Exit code: 1
 Building machine hostname: vmbuild.apache.org
 Operating system : Linux(unknown)
 Java Home version : java version 1.5.0_12
 Java(TM) 2 Runtime Environment, Standard Edition (build 
1.5.0_12-b04)
 Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, 
sharing)

   Builder version :
 Maven version: 2.0.7
 Java version: 1.5.0_12
 OS name: linux version: 2.6.20-16-server arch: i386





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

Re: [DISCUSS] altering the Tuscany Charter in relation to SDO Java

2008-02-28 Thread kelvin goodson

This is about creating the healthiest Apache environment for fostering
creative ongoing SDO Java development.

The feedback from Apache members to the proposal I put forward for a new
project, was that it was too tightly scoped around JSR 235.

In order to broaden the scope of the new project proposal, and yet not split
the pool of potential Apache contributors to this technology, I am asking
the Tuscany community if it is prepared to drop the explicit reference to
SDO.  This would seem to be a necessary step before going back to the Apache
community with a broader scoped proposal for the new project,  since it is
clear that we would get objections on the basis that the pool of potential
contributors would be split across the two Apache projects.

So as I mentioned before,  implicit in this change to the charter is the
understanding that if another Apache other project is established with an
explicit remit for SDO Java development,  then we would work towards
ensuring that new  development happened in that new project.

I believe I need to be able to point to the changed draft charter, and to
point to discussions that demonstrate a willingness on the part of the
Tuscany community to be prepared to act in the spirit of these discussions,
if the new project is to stand a chance of being accepted into incubation.

Kelvin.


On 28/02/2008, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 kelvin goodson wrote:
  Implicit in this rewording is the understanding within the Tuscany
 community
  that there would be one Apache home for SDO Java development.   When
 this
  thread is referenced in proposal for the new project, or discussions
 around
  it,  it must be clear to the wider Apache community that the Tuscany
  community accepts that.  Without this clear acceptance I fear the new
  project will face further periods of delay whilst questions are asked
 about
  the Tuscany communities intentions with regards to SDO Java development.
 
  So the answer to your question is conditional.
  If the new project is accepted an an incubator 
 
  - does not require Tuscany to implement SDO anymore --- yes
  - and still allows Tuscany to implement SDO   --- no
  - and still allows Tuscany to use SDO or any other related technology?
 ---
  yes
 
  if the project is not accepted as an incubator ...
 
  - does not require Tuscany to implement SDO anymore --- yes
  - and still allows Tuscany to implement SDO   --- yes
  - and still allows Tuscany to use SDO or any other related technology?
 ---
  yes
 


 I'm trying to understand how to vote, or if I should vote, on your other
 thread. Maybe I'm missing something. There is an SDO implementation in
 Tuscany at the moment. SDO is a related technology worked on in
 OpenCSA too. Why would we want to remove it from the charter?


 --

 Jean-Sebastien

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

Re: Are comments on SVN commit messages archived anywhere?

On Thu, Feb 28, 2008 at 7:01 PM, Luciano Resende [EMAIL PROTECTED]
wrote:

 Not sure I understood what you are looking for, but tuscany-commits is
 archived in [1]

 [1]
 http://www.mail-archive.com/tuscany-commits%40ws.apache.org/maillist.html

 On Thu, Feb 28, 2008 at 10:58 AM, Simon Laws [EMAIL PROTECTED]
 wrote:
  Are comments posted against SVN commit messages in tuscany-dev archived
   anywhere?
 
   Simon
 



 --
 Luciano Resende
 Apache Tuscany Committer
 http://people.apache.org/~lresende http://people.apache.org/%7Elresende
 http://lresende.blogspot.com/

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

 Thanks Luciano

I'm having a bit of a senior moment:-( I looked at the commit list but of
course when someone comments back it goes back to the dev list and I didn't
look there. Doh.

Simon

Re: [DISCUSS] altering the Tuscany Charter in relation to SDO Java


kelvin goodson wrote:
...

implicit in this change to the charter is the
understanding that if another Apache other project is established with an
explicit remit for SDO Java development,  then we would work towards
ensuring that new  development happened in that new project.


OK that helps, Thanks. I have a few more questions:

Would Tuscany contribute its current SDO Java implementation [1] to that 
new project?


Would Tuscany continue to maintain the SDO code that has been delivered 
in several releases?


What about the SDO Java test suite [2]?

What about the Tuscany SDO C++ implementation [3]?

[1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/
[2] http://svn.apache.org/repos/asf/incubator/tuscany/java/cts/
[3] http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sdo/

--
Jean-Sebastien

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

Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes

On Tue, Feb 26, 2008 at 5:57 PM, Simon Laws [EMAIL PROTECTED]
wrote:



 On Mon, Feb 25, 2008 at 4:17 PM, Jean-Sebastien Delfino 
 [EMAIL PROTECTED] wrote:

Jean-Sebastien Delfino wrote:
   Looks good to me, building on your initial list I added a few more
  items
   and tried to organize them in three categories:
  
   A) Contribution workspace (containing installed contributions):
   - Contribution model representing a contribution
   - Reader for the contribution model
   - Workspace model representing a collection of contributions
   - Reader/writer for the workspace model
   - HTTP based service for accessing the workspace
   - Web browser client for the workspace service
   - Command line client for the workspace service
   - Validator for contributions in a workspace
  
  
   ant elder wrote:
   Do you have you heart set on calling this a workspace or are you open
  to
   calling it something else like a repository?
  
 
  I think that they are two different concepts, here are two analogies:
 
  - We in Tuscany assemble our distro out of artifacts from multiple Maven
  repositories.
 
  - An application developer (for example using Eclipse) can connect
  Eclipse workspace to multiple SVN repositories.
 
  What I'm looking after here is similar to the above 'distro' or 'Eclipse
  workspace', basically an assembly of contributions, artifacts of various
  kinds, that I can load in a 'workspace', resolve, validate and run,
  different from the repository or repositories that I get the artifacts
  from.
  --
  Jean-Sebastien
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 

 To me repository (in my mind somewhere to store things) describes a much
 less active entity compared to the workspace which has to do a lot of work
 to load and assimilate information from multiple contributions. I'm not sure
 about workspace either but to me it's better than repository and it's not
 domain which has caused us all kinds of problems.

 My 2c

 Simon


I started looking at step D). Having a rest from URLs :-) In the context of
this thread the node can loose it's connection to the domain and hence the
factory and the node interface slims down. So Runtime that loads a set of
contributions and a composite becomes;

create a node
add some contributions (addContribution) and mark a composite for
starting(currently called addToDomainLevelComposite).
start the node
stop the node

You could then recycle (destroy) the node and repeat if required.

This all sound like a suggestion Sebastien made about 5 months ago ;-) I
have started to check in an alternative implementation of the node
(node2-impl). I haven't changed any interfaces yet so I don't break any
existing tests (and the code doesn't run yet!).

Anyhow. I've been looking at the workspace code for parts A and B that has
recently been committed. It would seem to be fairly representative of the
motivating scenario [1].  I don't have detailed question yet but
interestingly it looks like contributions, composites etc are exposed as
HTTP resources. Sebastien, It would be useful to have a summary of you
thoughts on how it is intended to hang together and how these will be used.

I guess these HTTP resource bring a deployment dimension.

Local - Give the node contribution URLs that point to the local file system
from where the node reads the contribution (this is how it has worked to
date)
Remote - Give it contribution URLs that point out to HTTP resource so the
node can read the contributions from where they are stored in the network

Was that the intention?

Simon

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27362.html

[jira] Closed: (TUSCANY-2053) BUILD FAILURE : Building Apache Tuscany SCA Domain Integration Tests


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

Raymond Feng closed TUSCANY-2053.
-

Resolution: Fixed

The build is now successful.

 BUILD FAILURE : Building Apache Tuscany SCA Domain Integration Tests
 

 Key: TUSCANY-2053
 URL: https://issues.apache.org/jira/browse/TUSCANY-2053
 Project: Tuscany
  Issue Type: Bug
Reporter: Venkatakrishnan

 INFO] 
 
 [INFO] Building Apache Tuscany SCA Domain Integration Tests
 [INFO]task-segment: [clean, install]
 [INFO] 
 
 [INFO] [clean:clean]
 [INFO] Deleting directory 
 /home/continuum/data/working-directory/277/itest/domain/target
 [INFO] Deleting directory 
 /home/continuum/data/working-directory/277/itest/domain/target/classes
 [INFO] Deleting directory 
 /home/continuum/data/working-directory/277/itest/domain/target/test-classes
 [INFO] Deleting directory 
 /home/continuum/data/working-directory/277/itest/domain/target/site
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:compile]
 [INFO] Compiling 11 source files to 
 /home/continuum/data/working-directory/277/itest/domain/target/classes
 [INFO] [resources:testResources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:testCompile]
 [INFO] Compiling 1 source file to 
 /home/continuum/data/working-directory/277/itest/domain/target/test-classes
 [INFO] [surefire:test]
 [INFO] Surefire report directory: 
 /home/continuum/data/working-directory/277/itest/domain/target/surefire-reports
 ---
  T E S T S
 ---
 Running org.apache.tuscany.sca.itest.domain.DomainAPITestCase
 Setting up domain
 Feb 20, 2008 10:35:25 PM org.apache.tuscany.sca.domain.impl.SCADomainImpl init
 INFO: Domain management configured from 
 file:/home/continuum/data/working-directory/277/modules/domain-impl/target/tuscany-domain-impl-1.2-incubating-SNAPSHOT.jar
 Feb 20, 2008 10:35:29 PM org.apache.catalina.core.StandardEngine start
 INFO: Starting Servlet Engine: Apache Tomcat/6.0.14
 Feb 20, 2008 10:35:30 PM org.apache.catalina.startup.ContextConfig 
 defaultWebConfig
 INFO: No default web.xml
 Feb 20, 2008 10:35:30 PM org.apache.catalina.startup.DigesterFactory register
 WARNING: Could not get url for /javax/servlet/jsp/resources/jsp_2_0.xsd
 Feb 20, 2008 10:35:30 PM org.apache.catalina.startup.DigesterFactory register
 WARNING: Could not get url for /javax/servlet/jsp/resources/jsp_2_1.xsd
 Feb 20, 2008 10:35:30 PM org.apache.catalina.startup.DigesterFactory register
 WARNING: Could not get url for 
 /javax/servlet/jsp/resources/web-jsptaglibrary_1_1.dtd
 Feb 20, 2008 10:35:30 PM org.apache.catalina.startup.DigesterFactory register
 WARNING: Could not get url for 
 /javax/servlet/jsp/resources/web-jsptaglibrary_1_2.dtd
 Feb 20, 2008 10:35:30 PM org.apache.catalina.startup.DigesterFactory register
 WARNING: Could not get url for 
 /javax/servlet/jsp/resources/web-jsptaglibrary_2_0.xsd
 Feb 20, 2008 10:35:30 PM org.apache.catalina.startup.DigesterFactory register
 WARNING: Could not get url for 
 /javax/servlet/jsp/resources/web-jsptaglibrary_2_1.xsd
 Feb 20, 2008 10:35:30 PM org.apache.catalina.startup.DigesterFactory register
 WARNING: Could not get url for 
 /javax/servlet/resources/j2ee_web_services_1_1.xsd
 Feb 20, 2008 10:35:30 PM org.apache.coyote.http11.Http11Protocol init
 INFO: Initializing Coyote HTTP/1.1 on http-
 Feb 20, 2008 10:35:30 PM org.apache.coyote.http11.Http11Protocol start
 INFO: Starting Coyote HTTP/1.1 on http-
 Feb 20, 2008 10:35:30 PM org.apache.tuscany.sca.http.tomcat.TomcatServer 
 addServletMapping
 INFO: Added Servlet mapping: http://vmbuild.apache.org:/domain/*
 Feb 20, 2008 10:35:30 PM org.apache.tuscany.sca.http.tomcat.TomcatServer 
 addServletMapping
 INFO: Added Servlet mapping: 
 http://vmbuild.apache.org:/SCADomainManagerComponent/SCADomainManagerService/*
 Feb 20, 2008 10:35:30 PM org.apache.tuscany.sca.http.tomcat.TomcatServer 
 addServletMapping
 INFO: Added Servlet mapping: 
 http://vmbuild.apache.org:/SCADomainManagerComponent/SCADomainManagerService
 Feb 20, 2008 10:35:30 PM org.apache.tuscany.sca.http.tomcat.TomcatServer 
 addServletMapping
 INFO: Added Servlet mapping: 
 http://vmbuild.apache.org:/SCADomain/scaDomain.js
 Feb 20, 2008 10:35:30 PM org.apache.tuscany.sca.http.tomcat.TomcatServer 
 addServletMapping
 INFO: Added Servlet mapping: 
 http://vmbuild.apache.org:/SCADomainManagerComponent/SCADomainEventService
 Feb 20, 2008 10:35:30 PM

[jira] Commented: (TUSCANY-2050) WSDL/xml interface referring to wsdl with XSD imports that cannot be resolved throws nullpointer


[ 
https://issues.apache.org/jira/browse/TUSCANY-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573546#action_12573546
 ] 

Raymond Feng commented on TUSCANY-2050:
---

Please attach your test case including the WSDL/XSDs so that I can look into it.

Thanks,
Raymond

 WSDL/xml interface referring to wsdl with XSD imports that cannot be resolved 
 throws nullpointer
 

 Key: TUSCANY-2050
 URL: https://issues.apache.org/jira/browse/TUSCANY-2050
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.1
Reporter: clemens utschig
Priority: Critical
 Fix For: Java-SCA-1.2


 having a wsdl interface, that points to a valid wsdl which contains XML 
 schema imports that cannot be resolved throws nullpointer.
 Caused by: java.lang.RuntimeException: java.lang.NullPointerException
   at 
 org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1886)
   at 
 org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1620)
   at 
 org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:175)
   at 
 org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:82)
   at 
 org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:359)
   at 
 org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:353)
   at 
 org.apache.tuscany.sca.interfacedef.wsdl.xml.XSDModelResolver.loadOnDemand(XSDModelResolver.java:143)
   at 
 org.apache.tuscany.sca.interfacedef.wsdl.xml.XSDModelResolver.aggregate(XSDModelResolver.java:173)
   at 
 org.apache.tuscany.sca.interfacedef.wsdl.xml.XSDModelResolver.resolveModel(XSDModelResolver.java:104)
   at 
 org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel(ExtensibleModelResolver.java:127)
   at 
 org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolver.readInlineSchemas(WSDLModelResolver.java:389)
   at 
 org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolver.loadDefinition(WSDLModelResolver.java:323)
   at 
 org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolver.loadOnDemand(WSDLModelResolver.java:288)
   at 
 org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolver.aggregate(WSDLModelResolver.java:223)
   at 
 org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolver.resolveModel(WSDLModelResolver.java:256)
   at 
 org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel(ExtensibleModelResolver.java:127)
   at 
 org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLInterfaceProcessor.resolveWSDLInterface(WSDLInterfaceProcessor.java:144)
   at 
 org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLInterfaceProcessor.resolve(WSDLInterfaceProcessor.java:168)
   at 
 org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLInterfaceProcessor.resolve(WSDLInterfaceProcessor.java:43)
   at 
 org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:242)
   at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
   at 
 org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveContracts(BaseAssemblyProcessor.java:290)
   at 
 org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:752)
   at 
 org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:74)
   at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
   at 
 org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:113)
   at 
 org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:47)
   at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86)
   at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:423)
   at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:333)
   at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:155)
   at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:125)
   at

[jira] Closed: (TUSCANY-2046) BUILD FAILURE : Apache Tuscany SCA Multiple WSDL File Support Integration Tests


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

Raymond Feng closed TUSCANY-2046.
-

Resolution: Fixed

 BUILD FAILURE : Apache Tuscany SCA Multiple WSDL File Support Integration 
 Tests
 ---

 Key: TUSCANY-2046
 URL: https://issues.apache.org/jira/browse/TUSCANY-2046
 Project: Tuscany
  Issue Type: Bug
Reporter: Venkatakrishnan
Assignee: Simon Laws
 Fix For: Java-SCA-Next


 [INFO] 
 
 [INFO] Building Apache Tuscany SCA Multiple WSDL File Support Integration 
 Tests
 [INFO]task-segment: [clean, install]
 [INFO] 
 
 [INFO] [clean:clean]
 [INFO] Deleting directory 
 /home/continuum/data/working-directory/277/itest/wsdl-multiple/target
 [INFO] Deleting directory 
 /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/classes
 [INFO] Deleting directory 
 /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/test-classes
 [INFO] Deleting directory 
 /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/site
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:compile]
 [INFO] Compiling 4 source files to 
 /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/classes
 [INFO] [resources:testResources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:testCompile]
 [INFO] Compiling 2 source files to 
 /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/test-classes
 [INFO] [surefire:test]
 [INFO] Surefire report directory: 
 /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/surefire-reports
 ---
  T E S T S
 ---
 Running org.apache.tuscany.sca.itest.ManualWSDLTestCase
 org.osoa.sca.ServiceRuntimeException: 
 org.apache.tuscany.sca.host.http.ServletMappingException: 
 java.net.BindException: Address already in use
at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
at 
 org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
at 
 org.apache.tuscany.sca.itest.ManualWSDLTestCase.init(ManualWSDLTestCase.java:41)
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.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74)
at 
 org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50)
at 
 org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33)
at 
 org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at 
 org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at 
 org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
 Caused by: org.apache.tuscany.sca.host.http.ServletMappingException: 
 java.net.BindException: Address already in use
at 
 org.apache.tuscany.sca.http.jetty.JettyServer.addServletMapping(JettyServer.java:207)
at 
 org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.start(Axis2ServiceProvider.java:244)
at 
 org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceBindingProvider.start(Axis2ServiceBindingProvider.java:94)
at 
 org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:484)
at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:221)
at

[jira] Assigned: (TUSCANY-2045) Refine processing of multiple WSDL with the same namespace to avoid aggregated artifacts


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

Raymond Feng reassigned TUSCANY-2045:
-

Assignee: Raymond Feng

 Refine processing of multiple WSDL with the same namespace to avoid 
 aggregated artifacts
 

 Key: TUSCANY-2045
 URL: https://issues.apache.org/jira/browse/TUSCANY-2045
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.1
Reporter: Simon Laws
Assignee: Raymond Feng
 Fix For: Java-SCA-Next


 Currently when multiple WSDL or XSD appear in the same namespace they are 
 aggregated together behind a facade at resolution time. The runtime is then 
 responsible for unpicking this aggregation in order to use the artifacts. We 
 should look into changing the code in order that specific artifacts are 
 targeted at resolution time rather than relying on synthetic aggregations. 
 This thought was started by the JIRA here 
 (http://issues.apache.org/jira/browse/TUSCANY-2043) and there are some 
 comments on the thread here 
 (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27968.html)

-- 
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] Assigned: (TUSCANY-2033) java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is ignoring the namespace


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

Raymond Feng reassigned TUSCANY-2033:
-

Assignee: Raymond Feng

 java interface exposed as service, annoted with 
 javax.xml.ws.RequestWrapper(...) is ignoring the namespace
 --

 Key: TUSCANY-2033
 URL: https://issues.apache.org/jira/browse/TUSCANY-2033
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-1.0.1
Reporter: clemens utschig
Assignee: Raymond Feng
Priority: Critical
 Fix For: Java-SCA-Next

 Attachments: EmpFlexFieldService.java, EmpFlexFieldService.wsdl, 
 SDOReferenceBinding.zip


 I have a composite defined that uses an external referenced webservice which 
 provides SDOs
 ?xml version=1.0 encoding=UTF-8?
 composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=/model/common/
 
 xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
 name=FlexEmployeeComposite xmlns:tns=/model/common/types/
 xmlns:types=/model/common/types/
 xmlns:errors=http://xmlns.oracle.com/adf/svc/errors/;
 xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
component name=FlexEmployeeServiceComponent
  implementation.java 
 class=com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent/
  reference name=empFlexFieldService/
/component
   reference name=empFlexFieldService
   promote=FlexEmployeeServiceComponent/empFlexFieldService
  interface.java 
 interface=model.common.serviceinterface.EmpFlexFieldService/
  binding.ws 
 uri=http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService/
/reference
  /composite
 The java interface that is promoted as service interface / and reflects the 
 webservice endpoint, contains jaxws annotations for namespaces as below ..
 @javax.jws.soap.SOAPBinding(parameterStyle=javax.jws.soap.SOAPBinding.ParameterStyle.WRAPPED,
  
 style=javax.jws.soap.SOAPBinding.Style.DOCUMENT)
 @javax.jws.WebService(targetNamespace=/model/common/, 
 name=EmpFlexFieldService, 
 wsdlLocation=model/common/serviceinterface/EmpFlexFieldService.wsdl)
 @oracle.j2ee.ws.common.sdo.SchemaLocation(value=model/common/serviceinterface/EmpFlexFieldService.xsd)
 public interface EmpFlexFieldService {
 public static final String NAME = 
 new QName(/model/common/, EmpFlexFieldService).toString();
 @javax.jws.WebMethod(action=/model/common/getEmployees1, 
 operationName=getEmployees1)
 @javax.xml.ws.RequestWrapper(targetNamespace=/model/common/types/, 
 localName=getEmployees1)
 @javax.xml.ws.ResponseWrapper(targetNamespace=/model/common/types/, 
 localName=getEmployees1Response)
 @javax.jws.WebResult(name=result)
 DataObject 
 getEmployees1(@javax.jws.WebParam(mode=javax.jws.WebParam.Mode.IN, 
 name=empno)
 Integer empno) throws ServiceException;
 At runtime - axis generates the following soap message - which is derived 
 from the base targetNamespace
  ?xml version='1.0' encoding='UTF-8'?
  soapenv:Envelope 
  xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
  soapenv:Body
  _ns_:getEmployees1 xmlns:_ns_=/model/common/
  empno xmlns=/model/common/1/empno
  /_ns_:getEmployees1
  /soapenv:Body
  /soapenv:Envelope
 obviously this is wrong - it should be ..
  soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
  soap:Body xmlns:ns1=/model/common/types/
  ns1:getEmployees1
  ns1:empno/ns1:empno
  /ns1:getEmployees1
  /soap:Body
  /soap:Envelope

-- 
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] Assigned: (TUSCANY-2020) Need a consitent way to handle generics in java interfaces and method--operation mapping


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

Raymond Feng reassigned TUSCANY-2020:
-

Assignee: Raymond Feng

 Need a consitent way to handle generics in java interfaces and 
 method--operation mapping
 --

 Key: TUSCANY-2020
 URL: https://issues.apache.org/jira/browse/TUSCANY-2020
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-Next
Reporter: Raymond Feng
Assignee: Raymond Feng
 Fix For: Java-SCA-Next


 Java generics can be used to declare business interfaces for SCA services and 
 references. For example,
 public interface ResourceT {
 T get(String name);
 }
 Parameterized types and wildcard types can be used too.
 It will impact the interface compatibility check and java--wsdl interop. We 
 need to have a consisten strategy to handle the generics. 
 We might be able to follow the rules defined by JAXWS 2.x spec section 3.9.

-- 
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] Assigned: (TUSCANY-2022) Generated build-dependency.xml for demos\xml-bigbank points to the wrong version of wstx-asl


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

Raymond Feng reassigned TUSCANY-2022:
-

Assignee: Raymond Feng

 Generated build-dependency.xml for demos\xml-bigbank points to the wrong 
 version of wstx-asl
 

 Key: TUSCANY-2022
 URL: https://issues.apache.org/jira/browse/TUSCANY-2022
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples, Java SCA Tools, Maven Plugins
Affects Versions: Java-SCA-1.1
Reporter: Raymond Feng
Assignee: Raymond Feng
 Fix For: Java-SCA-Next


 Here is the exception I'm seeing by running ant run under demos\xml-bigbank.
 Buildfile: build.xml
 run:
  [java] Exception in thread main 
 javax.xml.stream.FactoryConfigurationErro
 r: Provider com.bea.xml.stream.MXParserFactory not found
  [java] at 
 javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java
 :72)
  [java] at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:176)
  [java] at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92)
  [java] at 
 javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.
 java:136)
  [java] at 
 org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntimeB
 uilder.createContributionService(ReallySmallRuntimeBuilder.java:181)
  [java] at 
 org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.
 start(ReallySmallRuntime.java:129)
  [java] at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.i
 nit(DefaultSCADomain.java:99)
  [java] at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInsta
 nce(SCADomain.java:230)
  [java] at 
 org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SC
 ADomain.java:69)
  [java] at bigbank.BigBankClient.main(BigBankClient.java:30)
  [java] Java Result: 1
 The dependency analysis shows that wstx-asl-3.2.0 is pulled by neethi.
 [INFO] |  +- 
 org.apache.tuscany.sca:tuscany-policy-xml:jar:1.1-incubating:compile
 [INFO] |  |  +- org.apache.ws.commons.axiom:axiom-api:jar:1.2.5:compile
 [INFO] |  |  |  \- jaxen:jaxen:jar:1.1-beta-10:compile
 [INFO] |  |  \- org.apache.neethi:neethi:jar:2.0.2:compile
 [INFO] |  | +- org.apache.ws.commons.axiom:axiom-impl:jar:1.2.5:compile
 [INFO] |  | |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  | +- org.codehaus.woodstox:wstx-asl:jar:3.2.0:compile
 [INFO] |  | \- commons-logging:commons-logging:jar:1.1:compile
 Our binary contribution ships wstx-asl-3.2.1.jar. The 

-- 
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] Assigned: (TUSCANY-2018) Is WARNING: Service not found for component service: required for promoted services?


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

Raymond Feng reassigned TUSCANY-2018:
-

Assignee: Raymond Feng

 Is WARNING: Service not found for component service:  required for promoted 
 services?
 ---

 Key: TUSCANY-2018
 URL: https://issues.apache.org/jira/browse/TUSCANY-2018
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.1
 Environment: Win XP SP2, JDK 1.5, maven 2.0.7
Reporter: Simon Laws
Assignee: Raymond Feng
Priority: Minor
 Fix For: Java-SCA-Next


 running itest/contribution-multiple gives
 INFO] 
 -
 ---
 [INFO] Building Apache Tuscany SCA Multiple Contribution Integration Tests
 [INFO]task-segment: [install]
 [INFO] 
 -
 ---
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:compile]
 [INFO] Nothing to compile - all classes are up to date
 [INFO] [resources:testResources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:testCompile]
 [INFO] Nothing to compile - all classes are up to date
 [INFO] [surefire:test]
 [INFO] Surefire report directory: 
 C:\simon\tuscany\java-head\sca\itest\contribut
 ion-multiple\target\surefire-reports
 ---
  T E S T S
 ---
 Running test.ContributionTestCase
 28-Jan-2008 10:35:33 
 org.apache.tuscany.sca.assembly.builder.impl.CompositeBuild
 erImpl$1 problem
 WARNING: Service not found for component service: 
 HelloServiceComponent/$promote
 d$.HelloService
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.031 sec
 Results :
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
 [INFO] [jar:jar]
 [INFO] Building jar: 
 C:\simon\tuscany\java-head\sca\itest\contribution-multiple\
 target\itest-contribution-multiple-1.2-incubating-SNAPSHOT.jar
 [INFO] [install:install]
 [INFO] Installing 
 C:\simon\tuscany\java-head\sca\itest\contribution-multiple\tar
 get\itest-contribution-multiple-1.2-incubating-SNAPSHOT.jar to C:\Documents 
 and
 Settings\slaws\.m2\repository\org\apache\tuscany\sca\itest-contribution-multiple
 \1.2-incubating-SNAPSHOT\itest-contribution-multiple-1.2-incubating-SNAPSHOT.jar
 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 12 seconds
 [INFO] Finished at: Mon Jan 28 10:35:35 GMT 2008
 [INFO] Final Memory: 9M/27M
 [INFO] 
 
 Is this reported WARNING required?  I think what is happening here is that 
 Tuscany creates new $promoted$ services to represent the composite level 
 services that are promoted from them. I'm guessing that the logic that 
 reconciles component services with the services defined by the component type 
  is complaining that it can't find a real service in the implementation to 
 match the name of the promoted service, i.e. $promoted$.HelloService. 
 Should it conplain in this case

-- 
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-2013) Remove derby sample databases from svn and create it dynamicaly


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

Raymond Feng resolved TUSCANY-2013.
---

Resolution: Fixed

My understanding is that this issue has been fixed. Please reopen if it's not 
the case.

 Remove derby sample databases from svn and create it dynamicaly
 ---

 Key: TUSCANY-2013
 URL: https://issues.apache.org/jira/browse/TUSCANY-2013
 Project: Tuscany
  Issue Type: Improvement
  Components: Build System
Affects Versions: Java-SCA-Next
Reporter: Luciano Resende
Assignee: Luciano Resende
 Fix For: Java-SCA-Next


 See discussion on the following thread :
 http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27351.html

-- 
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] Assigned: (TUSCANY-2002) SDO databinding doesn't have access to the SDO factories which are not referenced by an component service/reference interface


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

Raymond Feng reassigned TUSCANY-2002:
-

Assignee: Raymond Feng

 SDO databinding doesn't have access to the SDO factories which are not 
 referenced by an component service/reference interface
 -

 Key: TUSCANY-2002
 URL: https://issues.apache.org/jira/browse/TUSCANY-2002
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-Next
Reporter: Raymond Feng
Assignee: Raymond Feng
 Fix For: Java-SDO-Next


 In a doc-lit-wrapped WSDL (a.wsdl), we define the wrapper element 
 (http://ns1) in the inline schema which imports other XSD types (http://ns2) 
 from an XSD file (b.xsd), Running the SDO XSD2Java codegen on a.wsdl and 
 b.xsd will generate two SDO factories, one for http://ns1 and one for 
 http://ns2. 
 Now let's assume a java interface is used by the component, and it has the 
 following method.
 Quote getQuote(String symbol);   // Quote is a generated SDO class/interface, 
 getQuote and getQuoteResponse are the wrapper elements.  
 The SDO databinding gains access to the fatory for http://ns2 but not 
 http://ns1 since the getQuote/getQuoteResponse is not referenced on this 
 method. As a result, the SDO wrapping/unwrapping data transformation will be 
 broken as the SDO factory for http://ns2 is not registered.
 The workaround is to use import.sdo.

-- 
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] Assigned: (TUSCANY-2003) Optimize the simple type to OM transformation


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

Raymond Feng reassigned TUSCANY-2003:
-

Assignee: Raymond Feng

 Optimize the simple type to OM transformation
 -

 Key: TUSCANY-2003
 URL: https://issues.apache.org/jira/browse/TUSCANY-2003
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-Next
Reporter: Raymond Feng
Assignee: Raymond Feng
 Fix For: Java-SCA-Next


 As discussed on 
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26810.html, we could 
 optimze the simple type to AXIOM transformation instead of going the through 
 the lengthy JAXB, DOM path. One idea is to implement a JAXB2OMElement 
 transformer that handles different cases smartly.

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

Fail to run helloworld.HelloWorldJmsClient in module sample-helloworld-reference-jms

2008-02-28 Thread Raymond Feng


Hi,

I got the following exception. It seems that tuscany-node-impl module is 
missing in the pom.xml.


Exception in thread main org.apache.tuscany.sca.node.NodeException: 
java.lang.ClassNotFoundException: 
org.apache.tuscany.sca.node.impl.SCANodeFactoryImpl
at 
org.apache.tuscany.sca.node.SCANodeFactory.createNodeWithComposite(SCANodeFactory.java:157)

at helloworld.HelloWorldJmsClient.main(HelloWorldJmsClient.java:32)
Caused by: org.osoa.sca.ServiceRuntimeException: 
java.lang.ClassNotFoundException: 
org.apache.tuscany.sca.node.impl.SCANodeFactoryImpl
at 
org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:66)
at 
org.apache.tuscany.sca.node.SCANodeFactory.getInstance(SCANodeFactory.java:80)
at 
org.apache.tuscany.sca.node.SCANodeFactory.createNodeWithComposite(SCANodeFactory.java:149)

... 1 more
Caused by: java.lang.ClassNotFoundException: 
org.apache.tuscany.sca.node.impl.SCANodeFactoryImpl

at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at 
org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:49)

... 3 more

Thanks,
Raymond 



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

[jira] Resolved: (TUSCANY-2001) helloworld-ws-service-jms Sample does not shut down correctly


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

Raymond Feng resolved TUSCANY-2001.
---

Resolution: Fixed

I just tried the trunk code and it seems to be shutting down correctly. Please 
reopen if you see otherwise.

 helloworld-ws-service-jms Sample does not shut down correctly
 -

 Key: TUSCANY-2001
 URL: https://issues.apache.org/jira/browse/TUSCANY-2001
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-1.1
 Environment: Windows, 1.1 RC2
Reporter: Mike Edwards
Priority: Minor
 Fix For: Java-SCA-Next


 Running the helloworld-ws-service-jms sample, it runs correctly and the 
 service can be called.
 However, the server is supposed to shutdown when enter is pressed - the 
 sample appears to hang after printing the message:
 [java] HelloWorld server stopped

-- 
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-1987) Build break in osgi-implementation itest


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

Raymond Feng resolved TUSCANY-1987.
---

Resolution: Fixed

I assume the problem is fixed as the patch has been applied.

 Build break in osgi-implementation itest
 

 Key: TUSCANY-1987
 URL: https://issues.apache.org/jira/browse/TUSCANY-1987
 Project: Tuscany
  Issue Type: Bug
  Components: Build System
Affects Versions: Java-SCA-1.1
 Environment: Daily build
Reporter: Jean-Sebastien Delfino
Assignee: Simon Laws
Priority: Blocker
 Fix For: Java-SCA-1.2

 Attachments: implementation-osgi-patch.txt


 See 
 http://vmbuild.apache.org/continuum/buildResult.action?buildId=37962projectId=277
 Error in the osgi-implementation itest, breaking the daily build.
 I think that this is the random break issue I've seen several times on Linux 
 already discussed with Rajini on the tuscany-dev list a while ago. Rajini was 
 not seeing that issue on Windows and I was seeing it randomly on Linux.
 I'm putting this issue in the SCA 1.1 release category as I believe it'll 
 probably happen on 1.1 as well.

-- 
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] Assigned: (TUSCANY-1949) import.sdo element is not resolved if it follows a property element

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

Raymond Feng reassigned TUSCANY-1949:
-

Assignee: Raymond Feng

import.sdo element is not resolved if it follows a property element
---

Key: TUSCANY-1949
URL: https://issues.apache.org/jira/browse/TUSCANY-1949
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.0
Reporter: Greg Dritschler
Assignee: Raymond Feng
Priority: Minor
Fix For: Java-SCA-Next

I have an SCA composite that uses both a property element and an import.sdo
element. If the property element appears before the import.sdo element as
shown below, then the application fails during execution when it tries to
create an SDO.
composite ...
component ...
property name=p type=xsd:stringXYZZY/property
/component
dbsdo:import.sdo .../
/composite
If I reorder the elements as shown below then the application works.
composite ...
dbsdo:import.sdo .../
component ...
property name=p type=xsd:stringXYZZY/property
/component
/composite
I found the problem in CompositeProcessor. When a property element is found,
it calls a method readPropertyValue. This method consumes the property end
element so CompositeProcessor won't see it. Since CompositeProcessor does
not see the property end element, it does not clear the property method
variable. Then when it processes the import.sdo element, it sees the
property variable is non-null and mistakenly associates the import.sdo
extension with the property instead of with the composite.
I was able to work around the problem by clearing the property variable after
the readPropertyValue call as shown below. (There are actually two such
calls, one for component level and one for composite level, and I cleared it
in both cases.)
// Read the property value
Document value =
readPropertyValue(property.getXSDElement(), property.getXSDType(), reader);
property.setValue(value);

composite.getProperties().add(property);
property = null; // **WORKAROUND**

--
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] Assigned: (TUSCANY-1941) NPE and classcast exceptions when putting all SCA jars from libs and modules on classpath


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

Raymond Feng reassigned TUSCANY-1941:
-

Assignee: Raymond Feng

 NPE and classcast exceptions when putting all SCA jars from libs and modules 
 on classpath
 -

 Key: TUSCANY-1941
 URL: https://issues.apache.org/jira/browse/TUSCANY-1941
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-1.0.1
 Environment: windows, jdk1.6.0_02
Reporter: andrej koelewijn
Assignee: Raymond Feng
Priority: Trivial
 Fix For: Java-SCA-Next

 Attachments: ReallySmallRuntime-patch.txt


 When i put all jars from the libs and modules directories on my classpath 
 (modules first, then libs), i get a nullpointer exception (when running 
 standalone), or a classcast exception (when running as part of a webapp). In 
 both stacktraces i can see that it's using axion in the axis2 binding code.
 Stacktrace for cli application:
 Dec 19, 2007 12:15:55 AM 
 org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiver 
 invokeBusinessLogic
 SEVERE: java.lang.ClassCastException: java.lang.String
 org.osoa.sca.ServiceRuntimeException: java.lang.ClassCastException: 
 java.lang.String
 at 
 org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:127)
 at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke 
 (RuntimeWireInvoker.java:89)
 at 
 org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:83)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.invoke(RuntimeWireImpl.java
  :127)
 at 
 org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.invokeTarget(Axis2ServiceProvider.java:587)
 at 
 org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic
  (Axis2ServiceInOutSyncMessageReceiver.java:59)
 at 
 org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:42)
 at org.apache.axis2.receivers.AbstractMessageReceiver.receive 
 (AbstractMessageReceiver.java:96)
 at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145)
 at 
 org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
 at 
 org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:120)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
 at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
 at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
 at org.mortbay.jetty.servlet.SessionHandler.handle 
 (SessionHandler.java:181)
 at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
 at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
 at org.mortbay.jetty.Server.handle (Server.java:285)
 at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
 at 
 org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:835)
 at org.mortbay.jetty.HttpParser.parseNext (HttpParser.java:641)
 at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
 at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
 at org.mortbay.io.nio.SelectChannelEndPoint.run 
 (SelectChannelEndPoint.java:368)
 at org.apache.tuscany.sca.core.work.Jsr237Work.run(Jsr237Work.java:61)
 at 
 org.apache.tuscany.sca.core.work.ThreadPoolWorkManager$DecoratingWork.run(ThreadPoolWorkManager.java
  :205)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
 at java.lang.Thread.run( Thread.java:595)
 Caused by: java.lang.ClassCastException: java.lang.String
 at 
 org.apache.tuscany.sca.databinding.axiom.OMElementWrapperHandler.getChildren(OMElementWrapperHandler.java:46)
 at 
 org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform
  (Input2InputTransformer.java:176)
 at 
 org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:46)
 at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate 
 (MediatorImpl.java:73)
 at 
 org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:173)
 at 
 org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke

[jira] Assigned: (TUSCANY-1933) policy-transaction one step further, use JNDI to host TM, itest/transaction supplemented too


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

Raymond Feng reassigned TUSCANY-1933:
-

Assignee: Raymond Feng

 policy-transaction one step further, use JNDI to host TM, itest/transaction 
 supplemented too
 

 Key: TUSCANY-1933
 URL: https://issues.apache.org/jira/browse/TUSCANY-1933
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-Next
 Environment: svn trunk, jdk1.6
Reporter: gengshaoguang
Assignee: Raymond Feng
 Fix For: Java-SCA-Next

 Attachments: itest.transaction.diff.txt, itest.transaction.zip, 
 policy-transaction.diff.txt, policy-transaction.zip


 Hi, Raymond, Hi every one:
 This patch addresses TM held in JNDI and manipulated by 
 TransactionPolicyHandler (per thread);
 Supplement involve TransactionPolicyHandler and TransactionManagerWrapper;
 In itest/transaction:
 A TestCase addresses managed account transfer is created;
 which includes JNDI mock ;
 There is some change to the definitions.xml and the pom as well.
 Suggestion expected, thanks.

-- 
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-1911) Amazon Cart for Tutorial


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

Raymond Feng resolved TUSCANY-1911.
---

Resolution: Fixed

I think the patch has been applied. Thanks for the contribution!

 Amazon Cart for Tutorial
 

 Key: TUSCANY-1911
 URL: https://issues.apache.org/jira/browse/TUSCANY-1911
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Samples
Reporter: Mario Antollini
Priority: Minor
 Fix For: Java-SCA-Next

 Attachments: tutorial-amazon.zip


 I am attaching the amazon components for the tutorial. It is composed of two 
 folders which must be located under the tutorial folder. I could not test the 
 amazon-cart project since I was not able to run the testcase. Therefore I am 
 not sure it works.

-- 
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] Commented: (TUSCANY-1917) Insert and Update operations in impl.data module


[ 
https://issues.apache.org/jira/browse/TUSCANY-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573557#action_12573557
 ] 

Raymond Feng commented on TUSCANY-1917:
---

Can somebody working on this area review the patch?

Thanks,
Raymond

 Insert and Update operations in impl.data module
 

 Key: TUSCANY-1917
 URL: https://issues.apache.org/jira/browse/TUSCANY-1917
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SCA Java Implementation Extension
Reporter: Douglas Siqueira Leite
Assignee: Luciano Resende
 Fix For: Java-SCA-Next

 Attachments: dastest.zip, tuscany1917_main_douglas_2007_11_22.patch, 
 tuscany1917_test_douglas_2007_11_22.patch


 -Add Update operation in implementation.data SCA module.
 -Add Insert operation in implementation.data SCA module.

-- 
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] Assigned: (TUSCANY-1910) XStream Databinding extension for Object XML serialization


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

Raymond Feng reassigned TUSCANY-1910:
-

Assignee: Raymond Feng

 XStream Databinding extension for Object XML serialization
 --

 Key: TUSCANY-1910
 URL: https://issues.apache.org/jira/browse/TUSCANY-1910
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SCA Misc Implementation Extensions
 Environment: Linux/JDK
Reporter: Giorgio Zoppi
Assignee: Raymond Feng
Priority: Minor
 Fix For: Java-SCA-Next

 Attachments: databinding-xstream.tar.gz


 Hi, I attach my xstream databinding extension for serializing objects in xml. 
 It simply convert an object in a MetaObject and serialize it with XStream 
 library, then it build an OMElement, so you can send every object which 
 implements the XObject interface over axis2-sca-binding. So if you support 
 MTOM, it will be necessary add a way to support it with XStream, customizing 
 XStream Converters in order to achieve better performance. XStream allows to 
 register a custom converter for every kind of class.  For now i attach my 
 databinding-xstream directory.

-- 
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] Assigned: (TUSCANY-1899) Java2WSDL (trivial) - do we have to assume method names start w/ a lowercase char?


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

Raymond Feng reassigned TUSCANY-1899:
-

Assignee: Raymond Feng

 Java2WSDL (trivial) - do we have to assume method names start w/ a lowercase 
 char?
 --

 Key: TUSCANY-1899
 URL: https://issues.apache.org/jira/browse/TUSCANY-1899
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Tools
Affects Versions: Java-SCA-1.0, Java-SCA-1.0.1
Reporter: Scott Kurz
Assignee: Raymond Feng
Priority: Trivial
 Fix For: Java-SCA-Next


 The fact that:   TuscanyWSDLTypesGenerator .createSchemaTypeForMethodPart
 on line 267 calls:
 globalElement.setName(formGlobalElementName(localPartName));
 which lowercases the first char in the parm passed to formGlobalElementName 
 ends up implying that method names must start in a lowercase char. 
 Because otherwise..the elem name
 so constructed won't match the operation name... which will cause us to not 
 end up with doc-lit-wrapped WSDL.
 Since everyone uses lowercase method names this in Java, I ranked this as 
 'trivial'.   
 Still, I opened this anyway because I didn't see why we bother to lowercase 
 this string at all, and thought that if someone cancelled this JIRA, at least 
 I'd learn
 there was a good reason for doing so.

-- 
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-1898) Job Databinding with XStream


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

Raymond Feng resolved TUSCANY-1898.
---

Resolution: Duplicate
  Assignee: Raymond Feng

I marked it as duplicate to  TUSCANY-1998 as the job interface is not a general 
data format. We should handle it under the xstream databinding. Thanks.

 Job Databinding with XStream
 

 Key: TUSCANY-1898
 URL: https://issues.apache.org/jira/browse/TUSCANY-1898
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SCA Samples
Affects Versions: Java-SCA-1.0
 Environment: JDK 1.5  Linux
Reporter: Giorgio Zoppi
Assignee: Raymond Feng
Priority: Minor
 Fix For: Java-SCA-Next

 Attachments: databinding-job.zip


 This is a transformer from an XML serialized Object which has a Job 
 Interface, to OMElement. This can be an example in order to create a new 
 databinding. It allows every object which it implements the Job interface to 
 be sent by SCA over WebServices binding. This example can be coupled with 
 workpool example in order to do some remote scheduling or distributed task 
 processing.

-- 
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] Issue Comment Edited: (TUSCANY-1898) Job Databinding with XStream

[
https://issues.apache.org/jira/browse/TUSCANY-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573564#action_12573564
]

rfeng edited comment on TUSCANY-1898 at 2/28/08 6:12 PM:

I marked it as duplicate to TUSCANY-1910 as the job interface is not a general
data format. We should handle it under the xstream databinding. Thanks.

was (Author: rfeng):
I marked it as duplicate to TUSCANY-1998 as the job interface is not a
general data format. We should handle it under the xstream databinding. Thanks.

Job Databinding with XStream

Key: TUSCANY-1898
URL: https://issues.apache.org/jira/browse/TUSCANY-1898
Project: Tuscany
Issue Type: New Feature
Components: Java SCA Samples
Affects Versions: Java-SCA-1.0
Environment: JDK 1.5 Linux
Reporter: Giorgio Zoppi
Assignee: Raymond Feng
Priority: Minor
Fix For: Java-SCA-Next

Attachments: databinding-job.zip

This is a transformer from an XML serialized Object which has a Job
Interface, to OMElement. This can be an example in order to create a new
databinding. It allows every object which it implements the Job interface to
be sent by SCA over WebServices binding. This example can be coupled with
workpool example in order to do some remote scheduling or distributed task
processing.

--
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-1889) ShoppingStore.wsdl for the tutorial: Modeling and Implementing a Tuscany Application out of a WSDL File


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

Raymond Feng resolved TUSCANY-1889.
---

Resolution: Fixed

 ShoppingStore.wsdl for the tutorial: Modeling and Implementing a Tuscany 
 Application out of a WSDL File
 ---

 Key: TUSCANY-1889
 URL: https://issues.apache.org/jira/browse/TUSCANY-1889
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SCA Documentation
Affects Versions: Java-SCA-0.90
Reporter: Mario Antollini
Priority: Trivial
 Fix For: Java-SCA-Next

 Attachments: ShoppingStore.wsdl


 I am creating a Jira Issue to upload a wsdl file which will be referred from 
 a Tutorial I recently wrote called Modeling and Implementing a Tuscany 
 Application out of a WSDL File

-- 
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] Commented: (TUSCANY-1876) @Reference(required=false) ignored


[ 
https://issues.apache.org/jira/browse/TUSCANY-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573566#action_12573566
 ] 

Raymond Feng commented on TUSCANY-1876:
---

The proxy lazily report the non-exisiting target. Is it violating the SCA spec?

 @Reference(required=false) ignored
 --

 Key: TUSCANY-1876
 URL: https://issues.apache.org/jira/browse/TUSCANY-1876
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.0
 Environment: Ubuntu 7.10, Gutsy Gibbon
 Sun JDK version 1.5.0_13
Reporter: Olivier Abdoun
 Fix For: Java-SCA-Next

 Attachments: optionalreference.tar.gz


 When specifying @Reference(required=false) and providing no reference for the 
 component in the composite, a proxy is injected in the component and next 
 call to the component fails with:
 org.osoa.sca.ServiceUnavailableException: No service invoker is available for 
 reference foo (bindingURI=null operation=getFoo).
   at 
 org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:192)
   at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addBindingInterceptor(RuntimeWireImpl.java:214)
   at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:156)
   at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:97)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:190)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:124)
   at $Proxy6.getFoo(Unknown Source)
   at foo.Baz.getBar(Baz.java:20)
   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.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:105)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:233)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:130)
   at $Proxy5.getBar(Unknown Source)
   at 
 foo.OptionalReferenceTestCase.testOptionalReference(OptionalReferenceTestCase.java:13)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at junit.framework.TestCase.runTest(TestCase.java:154)
   at junit.framework.TestCase.runBare(TestCase.java:127)
   at junit.framework.TestResult$1.protect(TestResult.java:106)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.framework.TestResult.run(TestResult.java:109)
   at junit.framework.TestCase.run(TestCase.java:118)
   at junit.framework.TestSuite.runTest(TestSuite.java:208)
   at junit.framework.TestSuite.run(TestSuite.java:203)
   at 
 org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
   at 
 org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
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] Assigned: (TUSCANY-1869) one step further, enlist ws over jms and local XAResource in one transaction


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

Raymond Feng reassigned TUSCANY-1869:
-

Assignee: Raymond Feng

 one step further, enlist *ws over jms* and local XAResource in one transaction
 --

 Key: TUSCANY-1869
 URL: https://issues.apache.org/jira/browse/TUSCANY-1869
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn trunk, jencks, activemq
Reporter: gengshaoguang
Assignee: Raymond Feng
 Fix For: Java-SCA-Next

 Attachments: derby_jdbc_XAResource.png, mysql_jdbc_xaresource.png, 
 outbound_xaresource.png, sca_diagram_2_references_in_1_transaction.gif




-- 
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-1869) one step further, enlist ws over jms and local XAResource in one transaction


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

Raymond Feng resolved TUSCANY-1869.
---

Resolution: Won't Fix

For documents, it's better to load them into the Tuscany wiki site. There is no 
fix needed for the code. Thank you for the contribution.

 one step further, enlist *ws over jms* and local XAResource in one transaction
 --

 Key: TUSCANY-1869
 URL: https://issues.apache.org/jira/browse/TUSCANY-1869
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn trunk, jencks, activemq
Reporter: gengshaoguang
Assignee: Raymond Feng
 Fix For: Java-SCA-Next

 Attachments: derby_jdbc_XAResource.png, mysql_jdbc_xaresource.png, 
 outbound_xaresource.png, sca_diagram_2_references_in_1_transaction.gif




-- 
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-1861) Improve binding.ws over jms global transaction aware


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

Raymond Feng resolved TUSCANY-1861.
---

Resolution: Won't Fix

The patch is for the documents. I'll load them into the wiki instead.

 Improve binding.ws over jms global transaction aware
 

 Key: TUSCANY-1861
 URL: https://issues.apache.org/jira/browse/TUSCANY-1861
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-Next
 Environment: jdk1.6 svn trunk
Reporter: gengshaoguang
 Fix For: Java-SCA-Next

 Attachments: axis2-substitute.png, TM-Related-Object.png, 
 TM-secquence-in-axis2.png


 Hello every one:
 I make this proposal to improve one step closer to sca1.0 global transaction 
 support.
 Currently, Tuscany's distributed reference work over jms is provided by 
 axis2's jms feature. But unfortunately, axis2 doesn't provide a feature of 
 transactional ws invoke.
 So we must do something here.
 Detail:
 1.replace transportReceiver name=jms 
 class=org.apache.axis2.transport.jms.JMSListener inside axis2.xml with an 
 new one, like shown in the diagram.

-- 
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] Assigned: (TUSCANY-1803) expections to Amita's Transaction picture


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

Raymond Feng reassigned TUSCANY-1803:
-

Assignee: Raymond Feng

 expections to Amita's Transaction picture
 -

 Key: TUSCANY-1803
 URL: https://issues.apache.org/jira/browse/TUSCANY-1803
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-Next
Reporter: gengshaoguang
Assignee: Raymond Feng
 Fix For: Java-SCA-Next

 Attachments: diff.txt, java.zip, local_transaction.png, 
 local_transaction_commit.jpg, local_transaction_rollback.jpg, 
 localtransaction-updated.png




-- 
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] Assigned: (TUSCANY-1816) local container managed transaction support test case


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

Raymond Feng reassigned TUSCANY-1816:
-

Assignee: Raymond Feng

 local container managed transaction support test case 
 --

 Key: TUSCANY-1816
 URL: https://issues.apache.org/jira/browse/TUSCANY-1816
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: jdk1.6 win2000 svn trunk derby
Reporter: gengshaoguang
Assignee: Raymond Feng
 Fix For: Java-SCA-Next

 Attachments: initate_TransactionManager.jpg, transaction.zip, 
 transaction.zip


 Hello Tuscany Funs,
 I attach this folder of files to demonstrate scenarios of a container managed 
 local transaction support, my implementation is very common to those popular 
 CMPs, and its very low level too, and component could use a 
 java.sql.Connection provided by TransactionInfo which is held for each user 
 thread..
 TODOs:
 I don't know what is the best way to describe out a transaction need for a 
 component, but Annotations would be easier for me.

-- 
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] Assigned: (TUSCANY-1802) RMI Implementation Error Handling lost inner exception's detail information


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

Raymond Feng reassigned TUSCANY-1802:
-

Assignee: Venkatakrishnan

 RMI Implementation Error Handling lost inner exception's detail information
 ---

 Key: TUSCANY-1802
 URL: https://issues.apache.org/jira/browse/TUSCANY-1802
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
Reporter: Yang Sun
Assignee: Venkatakrishnan
 Fix For: Java-SCA-Next


 Here is an email I sent to the tuscany user group. Raymond Feng confirms it 
 may be a potential bug. Please have a look.
 /--
 Hi,
 I am a new user of Tuscany and I am very excited with this great software. I 
 am trying to introduce it into my project and currently I am evaluate it with 
 every possible situations. 
 Currently, I met a small problem with the spring implementation. I am not 
 sure if I understand the background and configure the composites right. 
 Please correct me if I make anything wrong. 
 The problem I met is that I cannot get the detailed original exception when 
 the server-side throw any kinds of exceptions. After a rough looking at the 
 src code and debugging, I see the following code in SpringInvoker.java :
 ---
 private Object doInvoke(Object payload) throws SpringInvocationException {
 if (theMethod == null)
 setupMethod(); 
 if (badInvoker)
 throw new SpringInvocationException(Spring invoker incorrectly 
 configured);
 // Invoke the method on the Spring bean using the payload, returning 
 the results 
 try {
 Object ret;
 if (payload != null  !payload.getClass().isArray()) {
 ret = theMethod.invoke(bean, payload);
 } else {
 ret = theMethod.invoke(bean, (Object[])payload);
 }
 return ret;
 } catch (InvocationTargetException e) {
 throw new SpringInvocationException(e.getMessage());
 } catch (Exception e) { 
 throw new SpringInvocationException(e.getMessage());
 }
 } // end method doInvoke
  
 When the invoked method throw an exception (checked or unchecked), the 
 program flow will go to the InvocationTargetException exception handler. Then 
 the program only put the message of the original message to the wrapper 
 exception SpringInvocationException. The detailed information of the original 
 exception is missing. I am thinking it is here that will lost the detailed 
 information of the original exception detail. 
 The reason for me to bring this question is that if we cannot get the 
 detailed information of the original exception, how can we deal with the 
 application exceptions (such as NotEnoughMoneyException)? The only thing I 
 can get is the java.lang.reflect.InvocationTargetException wrapped in 
 java.rmi.UnexpectedException. And with those information, I cannot get the 
 right information to make the further decision in the program.
 I am not sure whether I got the right point or if I misunderstand anything. 
 Please give me some suggestions on this problem. 
 Best Regards,
 Yang Sun
 /

-- 
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] Assigned: (TUSCANY-1778) Creation of new msg structure to handle faults from web service calls


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

Raymond Feng reassigned TUSCANY-1778:
-

Assignee: Raymond Feng

 Creation of new msg structure to handle faults from web service calls
 -

 Key: TUSCANY-1778
 URL: https://issues.apache.org/jira/browse/TUSCANY-1778
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-1.0
Reporter: Simon Laws
Assignee: Raymond Feng
Priority: Minor
 Fix For: Java-SCA-Next


 If Axis2 returns a fault it sets the fault into the contents of the original 
 message. In the Axis2BindingInvoker the invoke code looks like this...
 public Message invoke(Message msg) {
 try {
 Object resp = invokeTarget(msg);
 msg.setBody(resp);
 } catch (AxisFault e) {
 if (e.getDetail() != null) {
 FaultException f = new FaultException(e.getMessage(), 
 e.getDetail());
 f.setLogical(e.getDetail().getQName());
 msg.setFaultBody(f);
 } else {
 msg.setFaultBody(e);
 }
 } catch (Throwable e) {
 msg.setFaultBody (e);
 }
 return msg;
 }
 Why does it set values in the input message as well as returning it as a 
 return value? I can see the point in the case of a real return value as you 
 avoid the resource of creating a extra message object. In the fault case 
 though this limits the ability of the infrastructure to resend the message if 
 it wants to as it gets overwritten.

-- 
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] Reopened: (TUSCANY-2013) Remove derby sample databases from svn and create it dynamicaly

2008-02-28 Thread Luciano Resende (JIRA)


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

Luciano Resende reopened TUSCANY-2013:
--


This is still valid, we still have some unit testing dependent on canned derby 
databases. I plan to fix these.

 Remove derby sample databases from svn and create it dynamicaly
 ---

 Key: TUSCANY-2013
 URL: https://issues.apache.org/jira/browse/TUSCANY-2013
 Project: Tuscany
  Issue Type: Improvement
  Components: Build System
Affects Versions: Java-SCA-Next
Reporter: Luciano Resende
Assignee: Luciano Resende
 Fix For: Java-SCA-Next


 See discussion on the following thread :
 http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27351.html

-- 
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: Trouble with aggregating definitions.xml in distro

2008-02-28 Thread ant elder

I also quiet liked being able to define these in definitions.xml files
instead of programmatically, is that still going to be an option? Seems a
shame if we have to give that up just because of a problem with our build
assembly.

   ...ant

On Thu, Feb 28, 2008 at 9:27 AM, Venkata Krishnan [EMAIL PROTECTED]
wrote:

 Hi,

 Alright, point taken :).  I am going to resolve this with the provider
 option and also clean up based on your suggestions.  Thanks.

 - Venkat

 On Thu, Feb 28, 2008 at 12:17 AM, Jean-Sebastien Delfino 
 [EMAIL PROTECTED] wrote:

  Venkata Krishnan wrote:
   Hi Sebastien,
  
   Thanks for the suggestion.  Going by the ProviderExtesionPoint way...
  
   - first I'd prefer load the definitions.xml instead of creating
   programmatically so that we don't have to touch the code for every
  change to
   the definitions.
 
  Definitions.xml is code, it's just XML code and not Java code.
 
  The choice really depends on what you have in your policy definitions,
  and which one is simpler in each extension case:
 
  SCADefinitions definition = new SCADefinitionsImpl();
  SCABindingType bindingType = new SCABindingTypeImpl();
  definition.getBindingTypes().add(bindingType);
 
  or
 
  sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://www.osoa.org/xmlns/sca/1.0;
xmlns:sca=http://www.osoa.org/xmlns/sca/1.0;
xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0;
 
bindingType.../
 
  /sca:definitions
 
  BTW I noticed that there are two copies of BindingTypeImpl in the policy
  and definitions modules, but no factories for these policy model objects
  (forcing code to depend on the model implementation classes).
 
  Also I think it would be simpler to regroup the definitions model and
  the policies model in a single module.
 
   - every module that has its own definitions.xml must define it in a
  unique
   path so that the file does not get lost when we are making the
   tuscany-sca-all jar file in the distro.
  
   So, given that every module HAS to define its definitions.xml in a
  unique
   path I am wondering if it would just enuf for each module then to just
  about
   publish the path for this in a file similar to the ones in
   META-INF/services.  So even when this file is aggregated by the shade
  plugin
   when making the tuscany-sca-all jar, we still have the location paths
 of
  all
   definitions.xml.  Is this a viable alternative ?
  
 
  It is a viable alternative but adds yet another mechanism to contribute
  pieces of extensions. I think it's better to stick to a single
  consistent mechanism.
 
  --
  Jean-Sebastien
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]

Moving ServiceDiscovery and related classes to tuscany-util

Hi,

I find that ServiceDiscovery is getting to be used widely and want to move
it out of Contribution module to a separate module like Utils.  The
immediate benefit I see from this is some relief from cyclic dependencies.
For example, I am trying to use the ServiceDiscovery in the 'definitions'
module and to do that I'd need the 'contribution' module.  But the
'contribution' already has dependency on 'definitions'.

I agree that 'contibutions' could be cleaned up a bit so as to not depend on
'definitions' but I wish to deal with that separately and not as an
alternative.

Thoughts ?

- Venkat

Re: Trouble with aggregating definitions.xml in distro

Hi,

This is certainly a good option. We just about have to do two simple things
in this transformer.

- Create a definitions.xml file with the xml declaration and
sca:definitions start element
- The for every definitions.xml file read, skip upto the sca:
definitions.xml and copy everything else upto the /sca:definitions
element
- Finally end this aggregated file with /sca:definitions

Let me look up the link you provided to see if this is quickly workable.

Thanks.

- Venkat

On Fri, Feb 29, 2008 at 1:09 PM, ant elder [EMAIL PROTECTED] wrote:

Could we just add our own Shade transformer that knows how to aggregate
the
definitions files? Eg TO SUPPORT something like this in the shade plugin
config:

transformer implementation=
org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer
resourceMETA-INF/services/definitions.xml/resource
/transformer

You can see the src of other Shade plugins and they're not too complicated
-

https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.java

...ant

On Fri, Feb 29, 2008 at 6:35 AM, ant elder [EMAIL PROTECTED] wrote:

I also quiet liked being able to define these in definitions.xml files
instead of programmatically, is that still going to be an option? Seems
a
shame if we have to give that up just because of a problem with our
build
assembly.

...ant

On Thu, Feb 28, 2008 at 9:27 AM, Venkata Krishnan [EMAIL PROTECTED]

wrote:

Hi,

Alright, point taken :). I am going to resolve this with the provider
option and also clean up based on your suggestions. Thanks.

- Venkat

On Thu, Feb 28, 2008 at 12:17 AM, Jean-Sebastien Delfino
[EMAIL PROTECTED] wrote:

Venkata Krishnan wrote:
Hi Sebastien,

Thanks for the suggestion. Going by the ProviderExtesionPoint
way...

- first I'd prefer load the definitions.xml instead of creating
programmatically so that we don't have to touch the code for every
change to
the definitions.

Definitions.xml is code, it's just XML code and not Java code.

The choice really depends on what you have in your policy
definitions,
and which one is simpler in each extension case:

SCADefinitions definition = new SCADefinitionsImpl();
SCABindingType bindingType = new SCABindingTypeImpl();
definition.getBindingTypes().add(bindingType);

sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://www.osoa.org/xmlns/sca/1.0;
xmlns:sca=http://www.osoa.org/xmlns/sca/1.0;
xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0;

bindingType.../

/sca:definitions

BTW I noticed that there are two copies of BindingTypeImpl in the
policy
and definitions modules, but no factories for these policy model
objects
(forcing code to depend on the model implementation classes).

Also I think it would be simpler to regroup the definitions model
and
the policies model in a single module.

- every module that has its own definitions.xml must define it in
a
unique
path so that the file does not get lost when we are making the
tuscany-sca-all jar file in the distro.

So, given that every module HAS to define its definitions.xml in a
unique
path I am wondering if it would just enuf for each module then to
just
about
publish the path for this in a file similar to the ones in
META-INF/services. So even when this file is aggregated by the
shade
plugin
when making the tuscany-sca-all jar, we still have the location
paths of
all
definitions.xml. Is this a viable alternative ?

It is a viable alternative but adds yet another mechanism to
contribute
pieces of extensions. I think it's better to stick to a single
consistent mechanism.

--
Jean-Sebastien

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

Re: Trouble with aggregating definitions.xml in distro