[jira] Commented: (TUSCANY-2014) XMLDocument object's rootElement member not intialized properly

[Brandon Werner (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592280#action_12592280
 ] 

Brandon Werner commented on TUSCANY-2014:
-

Has there been any progress on this issue since it was reported?

> XMLDocument object's rootElement member not intialized properly
> ---
>
> Key: TUSCANY-2014
> URL: https://issues.apache.org/jira/browse/TUSCANY-2014
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
> Environment: n/a
>Reporter: David T. Adcox
> Fix For: Java-SDO-Next
>
> Attachments: Test2014.java
>
>
> This problem occurs during a roundtrip operation where a new SDO Type is 
> created, then an instance DO is created from that type.  That instance DO is 
> then serialized to an XML document.  Then, using XMLHelper.load(String), the 
> document is loaded into an XMLDocument object.  When that object is 
> inspected, the rootElement member is not set properly, implying there is 
> either something wrong with the serialization of the DO or the 
> deseriazliation of the xml document. 
> Investigation is underway.  

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

[jira] Resolved: (TUSCANY-2269) Import package could not be resolved in CalculateBindingURITestCase

[Simon Laws (JIRA)]

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

Simon Laws resolved TUSCANY-2269.
-

Resolution: Fixed

Checked in at r651490. Thanks for the patch Ram.

> Import package could not be resolved in CalculateBindingURITestCase
> ---
>
> Key: TUSCANY-2269
> URL: https://issues.apache.org/jira/browse/TUSCANY-2269
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
> Environment: Windows XP
>Reporter: Ramkumar Ramalingam
>Assignee: Simon Laws
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2269.patch
>
>
> The import com.sun.org.apache.xerces.internal.impl.xs.opti.DefaultNode could 
> not be resolved in 
> org.apache.tuscany.sca.implementation.node.builder.impl.CalculateBindingURITestCase.
> Solution: Need to remove the import statement as this class is not used 
> anywhere in the code.

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

[jira] Assigned: (TUSCANY-2269) Import package could not be resolved in CalculateBindingURITestCase

[Simon Laws (JIRA)]

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

Simon Laws reassigned TUSCANY-2269:
---

Assignee: Simon Laws  (was: Ramkumar Ramalingam)

> Import package could not be resolved in CalculateBindingURITestCase
> ---
>
> Key: TUSCANY-2269
> URL: https://issues.apache.org/jira/browse/TUSCANY-2269
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
> Environment: Windows XP
>Reporter: Ramkumar Ramalingam
>Assignee: Simon Laws
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2269.patch
>
>
> The import com.sun.org.apache.xerces.internal.impl.xs.opti.DefaultNode could 
> not be resolved in 
> org.apache.tuscany.sca.implementation.node.builder.impl.CalculateBindingURITestCase.
> Solution: Need to remove the import statement as this class is not used 
> anywhere in the code.

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

Re: WSDL-less deployment using JAX-WS interfaces

[Mike Edwards]

Simon Nash wrote:

I committed r651426 which should provide usable support for
services and references that use Java interfaces containing JAX-WS
annotations without any WSDL files.

At present this code path (Interface2WDLGenerator) is only executed
for interfaces that have an @WebService annotation.  Also, the
JAXB databinding is assumed.

Next steps include the following:
 1. More testing.
 2. Enable this code path for all Java interfaces that are used
with  and no WSDL.
 3. Add support for other databindings, starting with SDO.
 4. Change the Java2WSDL tool to use this code.

  Simon



Well done Simon, a good advance.

Yours,  Mike.

WSDL-less deployment using JAX-WS interfaces

[Simon Nash]

I committed r651426 which should provide usable support for
services and references that use Java interfaces containing JAX-WS
annotations without any WSDL files.

At present this code path (Interface2WDLGenerator) is only executed
for interfaces that have an @WebService annotation.  Also, the
JAXB databinding is assumed.

Next steps include the following:
 1. More testing.
 2. Enable this code path for all Java interfaces that are used
with  and no WSDL.
 3. Add support for other databindings, starting with SDO.
 4. Change the Java2WSDL tool to use this code.

  Simon

Re: What's next for SCA & BPEL Integration

[Matthieu Riou]

On Thu, Apr 24, 2008 at 8:37 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> Now that we are making more progress with the SCA & BPEL integration
> and have figured out how to make References to work, let's discuss
> what could be the next steps on this area. Below are couple examples
> of what we could do next
>
> - WS-BPEL Process Introspection : Currently we are requiring SCA
> componentType files, we could introspect the BPEL process file to
> generate the component type information from it.
>
> - Integrate BEPL with the store scenario tutorial : We could add a
> OrderProcessing step to the store checkout, and illustrate a more real
> integration scenario.
>
> Other then these, we could review the
> SCA_ClientAndImplementationModelFor BPEL and identify other areas that
> we might need enhancements. Scenarios / Samples / Demos are always
> welcome too. Or if you have other suggestions, feel free to jump to
> the discussion.
>
> BTW: Copying the ODE list in case they want to jump and help, or in
> case they have other ideas.
>

I was thinking about the deployment model as well. Right now you still need
a deploy.xml descriptor to tell ODE how to bind a partnerLink to a concrete
port. In an SCA context I'm thinking this should be handled by the
container.

Matthieu


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

Re: Reg: BPEL support in Tuscany

[Luciano Resende]

Hey Ashwini,

   Thanks for you interest in Tuscany and BPEL.

   I have just started a thread on what's next for BPEL [1], feel free
to jump to it and provide your feedback, suggestions, etc.

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

On Tue, Apr 22, 2008 at 9:16 PM, Ashwini Kumar Jeksani
<[EMAIL PROTECTED]> wrote:
>
>  Hi Luciano,
>
>  My name is Ashwini. I'm interested in contributing to BPEL support in 
> Tuscany. From the mailing list I came to know that you have already done 
> quite some work on this. Please let me know if there are any areas in which I 
> can contribute.
>
>  Thanks & Regards
>  Ashwini Kumar Jeksani
>
>
>
>   CAUTION - Disclaimer *
>  This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
> for the use of the addressee(s). If you are not the intended recipient, 
> please notify the sender by e-mail and delete the original message. Further, 
> you are not to copy, disclose, or distribute this e-mail or its contents to 
> any other person and any such actions are unlawful. This e-mail may contain 
> viruses. Infosys has taken every reasonable precaution to minimize this risk, 
> but is not liable for any damage you may sustain as a result of any virus in 
> this e-mail. You should carry out your own virus checks before opening the 
> e-mail or attachment. Infosys reserves the right to monitor and review the 
> content of all messages sent to or from this e-mail address. Messages sent to 
> or from this e-mail address may be stored on the Infosys e-mail system.
>  ***INFOSYS End of Disclaimer INFOSYS***



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

Re: [vtest] getCompositeContext API for non-SCA clients

[Yee-Kang Chang]

Thanks, Scott, Ant.  I think both could work.  Perhaps we can start with 
getComponentContext(String componentURI) and go from there?

I gather a client will typically connect to a domain first and then work 
with its components?  If so, adding getComponentContext() to SCADomain can 
be a good start?

--

Kevin, Yee-Kang,

Did you envision creating a new API that would accept a component URI as
input,
e.g.:
  ComponentContext  getComponentContext(String componentURI);

Or were you talking about some sort of virtual component like Ant 
mentioned?
Scott


On Thu, Apr 24, 2008 at 10:49 AM, ant elder <[EMAIL PROTECTED]> wrote:
> Ok, although with non-SCA clients which component would that be? Does 
there
> need to be a new something like implementation.web but for JSE clients? 
or
> could there be a "virtual" component that has references for all the
> toplevel component services in the domain (which is kind of what we have
> now
> with SCADomain.getService right?).
>
>   ...ant
>
> On Thu, Apr 17, 2008 at 9:10 PM, Yee-Kang Chang <[EMAIL PROTECTED]>
> wrote:
>
> > Just thought to follow-up to see if we will do this ..
> >
> > Perhaps SCADomain can be extended to return the ComponentContext for a
> > particular component?
> >
> > Thanks.
> >
> > On Wed, Apr 2, 2008 at 6:37 PM, Kevin Williams 
<[EMAIL PROTECTED]>
> > wrote:
> > > The current JUnit tests (iTest and vTest) make use of the 
non-standard
> > > SCADomain.getService API to get a handle to an SCA service.  Are 
there
> > > any plans to provide an API to get a ComponentContext as outlined by
> > > the SCA Java Annotations and APIs specification?  I would like to
> > > stick to  stick to specified APIs  as much as possible in vTest.
> > >
> > >
> > > 1.4.2.1. ComponentContext
> > > Non-SCA client code can use the ComponentContext API to perform
> > > operations against a component in an
> > > SCA domain. How client code obtains a reference to a 
ComponentContext
> > > is runtime specific. The following
> > > example demonstrates the use of the component Context API by non-SCA
> > code:
> > >
> > >ComponentContext context = // obtained through host
> > > environment-specific means
> > >
> > >HelloService helloService =
> > > context.getService(HelloService.class,"HelloService");
> > >
> > > Thanks.
> > > --
> > > Kevin
> >
> > I don't remember any discussion about this so i guess there are "no
> plans"
> > yet to change it. I agree it seems like we should though.
> >
> > ...ant

Re: What's next for SCA & BPEL Integration

[Mike Edwards]

Luciano Resende wrote:

Now that we are making more progress with the SCA & BPEL integration
and have figured out how to make References to work, let's discuss
what could be the next steps on this area. Below are couple examples
of what we could do next

- WS-BPEL Process Introspection : Currently we are requiring SCA
componentType files, we could introspect the BPEL process file to
generate the component type information from it.

- Integrate BEPL with the store scenario tutorial : We could add a
OrderProcessing step to the store checkout, and illustrate a more real
integration scenario.

Other then these, we could review the
SCA_ClientAndImplementationModelFor BPEL and identify other areas that
we might need enhancements. Scenarios / Samples / Demos are always
welcome too. Or if you have other suggestions, feel free to jump to
the discussion.

BTW: Copying the ODE list in case they want to jump and help, or in
case they have other ideas.


Luciano,

WS_BPEL Process introspection is top of my list.  Having to write 
componentType side files is a miserable business, particularly when all 
the information you need is sitting there in the BPEL Process XML.  The 
Spring implementation is a good model - the Spring application context 
is ripped through to produce the componentType and so side file is ever 
needed.


A good BPEL sample is called for.  One based on some order process seems 
good to me.  It should also involve the BPEL process making asynchronous 
calls to back end services, which means stretching the support on 
references to include callbacks.


We should consider integrating with the tutorial after building a good 
standalone BPEL sample.



Yours,  Mike.

Re: [vtest] getCompositeContext API for non-SCA clients

[Scott Kurz]

Kevin, Yee-Kang,

Did you envision creating a new API that would accept a component URI as
input,
e.g.:
  ComponentContext  getComponentContext(String componentURI);

Or were you talking about some sort of virtual component like Ant mentioned?
Scott




On Thu, Apr 24, 2008 at 10:49 AM, ant elder <[EMAIL PROTECTED]> wrote:

> Ok, although with non-SCA clients which component would that be? Does there
> need to be a new something like implementation.web but for JSE clients? or
> could there be a "virtual" component that has references for all the
> toplevel component services in the domain (which is kind of what we have
> now
> with SCADomain.getService right?).
>
>   ...ant
>
> On Thu, Apr 17, 2008 at 9:10 PM, Yee-Kang Chang <[EMAIL PROTECTED]>
> wrote:
>
> > Just thought to follow-up to see if we will do this ..
> >
> > Perhaps SCADomain can be extended to return the ComponentContext for a
> > particular component?
> >
> > Thanks.
> >
> > On Wed, Apr 2, 2008 at 6:37 PM, Kevin Williams <[EMAIL PROTECTED]>
> > wrote:
> > > The current JUnit tests (iTest and vTest) make use of the non-standard
> > > SCADomain.getService API to get a handle to an SCA service.  Are there
> > > any plans to provide an API to get a ComponentContext as outlined by
> > > the SCA Java Annotations and APIs specification?  I would like to
> > > stick to  stick to specified APIs  as much as possible in vTest.
> > >
> > >
> > > 1.4.2.1. ComponentContext
> > > Non-SCA client code can use the ComponentContext API to perform
> > > operations against a component in an
> > > SCA domain. How client code obtains a reference to a ComponentContext
> > > is runtime specific. The following
> > > example demonstrates the use of the component Context API by non-SCA
> > code:
> > >
> > >ComponentContext context = // obtained through host
> > > environment-specific means
> > >
> > >HelloService helloService =
> > > context.getService(HelloService.class,"HelloService");
> > >
> > > Thanks.
> > > --
> > > Kevin
> >
> > I don't remember any discussion about this so i guess there are "no
> plans"
> > yet to change it. I agree it seems like we should though.
> >
> > ...ant
> >
>

Re: [DISCUSS] Evolving Implementation-data-xml

[Douglas Leite]

I agree with you. Changing the return type of put and delete methods
wouldn't be useful for all kinds of situations.
To this first version I will let the implementation-data-xml support both
interfaces DATA and Collection.

On Thu, Apr 24, 2008 at 1:48 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> On Thu, Apr 24, 2008 at 8:30 AM, Douglas Leite <[EMAIL PROTECTED]>
> wrote:
> > I have started to integrate the Collection interface with
> >  implentation-data-xml. Although the methods present in the DATA
> interface
> >  (get, insert, update, delete) can be replaced by the Collection
> interface's
> >  methods (get, post, put, delete), there are some differences. The update
> and
> >  delete DATA methods return the number of rows affected by each method.
> On
> >  the other hand, this feature is not present using the Collection
> methods,
> >  because put and delete are void.
> >
>
> I guess what you are describing here is a side effect of Collection
> being a more REST based interface and designed to perform put and
> delete on a given resource, when the current DATA interface allows for
> manipulating multiple rows at a time. Maybe we could have the
> implementation-data-xml to support both DATA and Collection
> interfaces, and let time and integration with real scenarios decide
> witch one would be more useful.
>
> >  Would be better change the signature of the  put and delete  Collection
> >  methods, allowing a K type return, or let a impl-data-xml component has
> the
> >  two interfaces?
> >
>
> I got a little confused here, as returning K (they key type) wouldn't
> solve the first issue you raised. Anyway, looking at the current
> Collection interface, key is used as a parameter thus known to the
> caller.
>
>   void put(K key, D item) throws NotFoundException;
>
>   void delete(K key) throws NotFoundException;
>
> Then, I'm not sure about the benefits of changing it to return K.
>
> >  On Tue, Apr 15, 2008 at 5:06 PM, Luciano Resende <[EMAIL PROTECTED]>
> >  wrote:
> >
> >
> >
> >  > I'd suggest the following as the next steps around
> implementation-data-xml
> >  >
> >  > - Add support for data collection interface from implementation-data
> >  > - At this point, integration with binding-atom-abdera should be
> >  > working, it would be great to integrate this with our store tutorial,
> >  > either by enhancing the catalog-db or by creating a new module
> >  > catalog-db-xml.
> >  > - The exercise above should also help drive the requirements for
> >  > database schema that you are proposing with a concrete scenario.
> >  >
> >  > Thoughts ?
> >  >
> >  > On Tue, Apr 15, 2008 at 12:14 PM, Douglas Leite <[EMAIL PROTECTED]
> >
> >  > wrote:
> >  > > In my last contribution, I have proposed a first version of Update
> and
> >  > >  Insert methods for impl.data.xml component.
> >  > >  One of the insert method limitations is that the table must only
> have
> >  > >  columns which types are char or varchar. However, I want to improve
> >  > this,
> >  > >  allowing any sql primitive type.
> >  > >  The fact is, the syntax to insert a varchar, for example, is
> different
> >  > to
> >  > >  insert a integer. So, it's necessary to know the types of the
> column.
> >  > >  I could resolve this problem in, at least, to different ways:
> First, I
> >  > could
> >  > >  use metadata information on the InsertInvoker, and discover the
> types of
> >  > >  columns. Another way to do this, is to add the column type
> information
> >  > in
> >  > >  the xml stream retrieved by the get method. So, we would have
> something
> >  > like
> >  > >  this:
> >  > >
> >  > >  
> >  > > 
> >  > > New Coorporation
> I
> >  > > +5511990202146
> >  > >  . . .
> >  > > 
> >  > >  
> >  > >
> >  > >  I am not sure if other metadata informations should be added to the
> xml
> >  > >  stream. But, at the moment, I think that column type would be
> useful.
> >  > >
> >  > >  Thoughts?
> >  > >
> >  > >  --
> >  > >  Douglas Siqueira Leite
> >  > >  Computer Science Master's degree student of University of Campinas
> >  > (Unicamp)
> >  > >
> >  >
> >  >
> >  >
> >  > --
> >  > 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]
> >  >
> >  >
> >
> >
> >  --
> >
> >
> > Douglas Siqueira Leite
> >  Computer Science Master's degree student of University of Campinas
> (Unicamp)
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>



-- 
Douglas Siqueira Leite
Computer Science Master's degree student of University of Campinas (Unicamp)

Re: What's next for SCA & BPEL Integration

[Matthieu Riou]

On Thu, Apr 24, 2008 at 10:41 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> On Thu, Apr 24, 2008 at 8:53 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <[EMAIL PROTECTED]>
> >  wrote:
> >
> >
> >  > Now that we are making more progress with the SCA & BPEL integration
> >  > and have figured out how to make References to work, let's discuss
> >  > what could be the next steps on this area. Below are couple examples
> >  > of what we could do next
> >  >
> >  > - WS-BPEL Process Introspection : Currently we are requiring SCA
> >  > componentType files, we could introspect the BPEL process file to
> >  > generate the component type information from it.
> >  >
> >  > - Integrate BEPL with the store scenario tutorial : We could add a
> >  > OrderProcessing step to the store checkout, and illustrate a more real
> >  > integration scenario.
> >  >
> >  > Other then these, we could review the
> >  > SCA_ClientAndImplementationModelFor BPEL and identify other areas that
> >  > we might need enhancements. Scenarios / Samples / Demos are always
> >  > welcome too. Or if you have other suggestions, feel free to jump to
> >  > the discussion.
> >  >
> >  > BTW: Copying the ODE list in case they want to jump and help, or in
> >  > case they have other ideas.
> >  >
> >  >
> >  Not a very exciting one but is there any clean up of the dependencies
> >  possible? Currently using the implementation.bpel extension brings in 78
> >  addition dependency jars at about 20meg, i wondered if some of those
> could
> >  get excluded?
> >
> >...ant
> >
>
> Part of this is because we have a Embedded ODE BPEL engine, and that
> itself brings several dependencies. But this is certainly something to
> investigate. It would be also good if ODE could be more
> flexible/dynamic with some dependencies (e.g Saxon) and only really
> require these dependencies if they are going to be in use, this would
> help our side as well.
>

Saxon is going to be hard to remove, there are very few BPEL processes that
won't need any XPath expressions to execute so I'm not sure it's one we can
save. But you're right for the embedded engine, right now we use our own
stuff for everything ODE needs to execute: connection pool, transaction
manager, jpa instance, thread pool, ... I'm guessing for many of these we
could reuse what comes with Tuscany.

Cheers,
Matthieu


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

Re: [vTest] Test design for ConversationAttributes.SinglePrincipal

[Kevin Williams]

I am getting errors during SCADomain initialization:

org.osoa.sca.ServiceRuntimeException:
org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
PolicyValidation exception when processing implementation of component
'AComponent' due to Policy Intent
'{http://tuscany.apache.org/xmlns/sca/1.0}jaasAuthentication' is not
defined in this domain
at 
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
at 
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
at 
org.apache.tuscany.sca.vtest.javaapi.annotations.conversationattributes.SinglePricipalTestCase.init(SinglePricipalTestCase.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)

It seems this is related to warnings received during processing of the
Definitions.xml:

Apr 24, 2008 11:55:22 AM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element
{http://tuscany.apache.org/xmlns/sca/1.0}jaasAuthentication cannot be
processed. ([row,col,system-id]:
[28,9,"file:/C:/tuscanysvn/java/sca/vtest/java-api/annotations/conversationattributes/target/classes/definitions.xml"])
Apr 24, 2008 11:55:22 AM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element
{http://tuscany.apache.org/xmlns/sca/1.0}configurationName cannot be
processed. ([row,col,system-id]:
[29,13,"file:/C:/tuscanysvn/java/sca/vtest/java-api/annotations/conversationattributes/target/classes/definitions.xml"])
Apr 24, 2008 11:55:22 AM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element
{http://tuscany.apache.org/xmlns/sca/1.0}callbackHandler cannot be
processed. ([row,col,system-id]:
[30,13,"file:/C:/tuscanysvn/java/sca/vtest/java-api/annotations/conversationattributes/target/classes/definitions.xml"])
Cleaning up

Here is my definitions file:

http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="http://tuscany.apache.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";
xmlns:convatt="http://convatt";>


http://www.osoa.org/xmlns/sca/1.0";>

AService

org.apache.tuscany.sca.vtest.javaapi.annotations.conversationattributes.security.ACallbackHandler






I have patterned this test after the Calculator-policy sample but I
think I am missing some piece of configuration.  Any help is
appreciated.

Thanks,

--Kevin

On Thu, Apr 24, 2008 at 8:30 AM, Kevin Williams <[EMAIL PROTECTED]> wrote:
> I am adding a test to verify @ConversationalAttributes
>  (SinglePrincipal = true).  Here is the related text from the Java
>  API/Annot specification:
>
> 1669 • singlePrincipal (optional) – If true, only the principal
>  (the user) that started the conversation has
> 1670 authority to continue the conversation. The default value is false
>
>  I would like to create the simplest test possible and this is what I
>  have come up with so far:
>
>--Three components each with a single service: A, B, C.  C is
>  conversational with SinglePrincipal = true.
>--A and B are configured such that each "requires" a policy set
>  (jassAuthentication1 and jassAuthentication2 respectively)
>--A will initiate a conversation with C
>--A will pass its C-reference to B
>--B will attempt to continue the conversation and this should fail
>  since B represents a different "principal"
>
>  I'll start  implementing this but would appreciate any suggestions ...
>  especially if I am way out in the weeds :-)
>
>  Thanks,
>
>  --Kevin
>

Re: What's next for SCA & BPEL Integration

[Luciano Resende]

On Thu, Apr 24, 2008 at 8:53 AM, ant elder <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <[EMAIL PROTECTED]>
>  wrote:
>
>
>  > Now that we are making more progress with the SCA & BPEL integration
>  > and have figured out how to make References to work, let's discuss
>  > what could be the next steps on this area. Below are couple examples
>  > of what we could do next
>  >
>  > - WS-BPEL Process Introspection : Currently we are requiring SCA
>  > componentType files, we could introspect the BPEL process file to
>  > generate the component type information from it.
>  >
>  > - Integrate BEPL with the store scenario tutorial : We could add a
>  > OrderProcessing step to the store checkout, and illustrate a more real
>  > integration scenario.
>  >
>  > Other then these, we could review the
>  > SCA_ClientAndImplementationModelFor BPEL and identify other areas that
>  > we might need enhancements. Scenarios / Samples / Demos are always
>  > welcome too. Or if you have other suggestions, feel free to jump to
>  > the discussion.
>  >
>  > BTW: Copying the ODE list in case they want to jump and help, or in
>  > case they have other ideas.
>  >
>  >
>  Not a very exciting one but is there any clean up of the dependencies
>  possible? Currently using the implementation.bpel extension brings in 78
>  addition dependency jars at about 20meg, i wondered if some of those could
>  get excluded?
>
>...ant
>

Part of this is because we have a Embedded ODE BPEL engine, and that
itself brings several dependencies. But this is certainly something to
investigate. It would be also good if ODE could be more
flexible/dynamic with some dependencies (e.g Saxon) and only really
require these dependencies if they are going to be in use, this would
help our side as well.

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

Re: Adding SVN version to Java files

[Simon Nash]

Mark Combellack wrote:

Hi,

 


The main reasons that I like the SVN details in the header of the files
include:

 


* You can look at the source file and see what revision it is
without having to use SVN commands

* Typically, developers will do an SVN checkout of the code using
SVN so they can get the information via SVN commands or via the headers

* Typically, users do not do an SVN checkout of the source code and
will not have SVN installed. They are typically provided with a jar file
containing the source code. They will not be able to run SVN command to work
out which versions of source code they are running

* Typically, there are many, many more users than there are
developers

* If a source file is printed out or attached as an email as part of
a bug report or published on a web server, the source code will contain the
SVN revision number. This makes the bug easier to fix as you know the
revision number. The SVN commands will not be able to tell you the revision
number in these scenarios.

 

 


The nice thing about the SVN keyword substitution is that a Developer is
free to choose whether they want them or not as the expansion is done on the
client side. If a Developer wants the $Date$ and $Revision$ expanded, then
they have to update their SVN configuration to do so. If they do not, then
they don't need to do anything as it is disabled in SVN by default. The key
thing is that @version $Date$ $Revision$ is in the header to provide this
choice.

 

Thanks for this explanation, and for bringing in the user perspective.
I can see that having expanded version information may be useful in
this user context.  It is not very useful to me as a developer, and
it can hurt me with applying patches if I enable the keyword expansion,
but I can turn this expansion off in my SVN client to suit my preference.

Taking all of this into account, I am +1 on this change.

Regarding whether or not we have consensus and whether we should hold
a vote, consensus is not the same as unanimity.  I think we need to
make a decision on this issue (which is relatively minor) and move
forward.  Holding a vote seems to be a reasonable way to do this.

  Simon



 

 


At the end of the day, from my personal opinion, using @version $Date$
$Revision$ is a nice to have feature in the source code. I would like to
have it there. However, I would rather go without it if its presence is
going to cause disharmony amongst the Tuscany Developers.

 


Thanks,

 


Mark

 


-Original Message-



From: Vamsavardhana Reddy [mailto:[EMAIL PROTECTED]



Sent: 24 April 2008 08:04



To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED]



Subject: Re: Adding SVN version to Java files




I would like to know the last revision and date at which a particular file



is updated just by opening the file in any editor and without having to do



anything extra, for e.g., like installing a plugin for eclipse, opening a



command prompt to issue an svn info command (note that the source I have



need not always be from svn, it could be a source archive for a release



downloaded separately), etc.  I found this info very useful while



investigating JIRAs.




++Vamsi




On Thu, Apr 24, 2008 at 11:12 AM, ant elder <[EMAIL PROTECTED]> wrote:




On Wed, Apr 23, 2008 at 5:52 PM, Vamsavardhana Reddy



<[EMAIL PROTECTED]>



wrote:









 From the above, we have 4 +1s and no -1s - although we have a



preference not




to do this from ant. So, the consensus is to make this change.




 We haven't held a formal vote, so I don't think we should be



trying



to decide this based on a count of +1s and -1s.




Agreed.  We should hold a formal vote.





We do consensus based development. Voting can be a useful gauging



consensus



but voting does not make consensus. Its obvious from this thread that



there



is not (yet) consensus so we don't need a vote, how about instead trying



to



convince us by explaining the value of adding this?




  ...ant

[jira] Updated: (TUSCANY-2271) Java runtime should not inject property into an unannotated non-public field

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated TUSCANY-2271:
-

Attachment: TUSCANY-2271.patch

TUSCANY-2271.patch: Fixes the problem.

Will post a testcase soon.

> Java runtime should not inject property into an unannotated non-public field
> 
>
> Key: TUSCANY-2271
> URL: https://issues.apache.org/jira/browse/TUSCANY-2271
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime, Java SCA Verification Tests
>Affects Versions: Java-SCA-1.2
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2271.patch
>
>
> Java Common Annotations and APIs v1.0 - Sec 1.8.13:
> 1349 Properties may also be injected via public setter methods even when the 
> @Property annotation is not
> 1350 present. However, the @Property annotation must be used in order to 
> inject a property onto a non-public
> 1351 field. In the case where there is no @Property annotation, the name of 
> the property is the same as the
> 1352 name of the field or setter.
> Currently the properties are injected into unannotated protected fields too.

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

Re: [DISCUSS] Evolving Implementation-data-xml

[Luciano Resende]

On Thu, Apr 24, 2008 at 8:30 AM, Douglas Leite <[EMAIL PROTECTED]> wrote:
> I have started to integrate the Collection interface with
>  implentation-data-xml. Although the methods present in the DATA interface
>  (get, insert, update, delete) can be replaced by the Collection interface's
>  methods (get, post, put, delete), there are some differences. The update and
>  delete DATA methods return the number of rows affected by each method. On
>  the other hand, this feature is not present using the Collection methods,
>  because put and delete are void.
>

I guess what you are describing here is a side effect of Collection
being a more REST based interface and designed to perform put and
delete on a given resource, when the current DATA interface allows for
manipulating multiple rows at a time. Maybe we could have the
implementation-data-xml to support both DATA and Collection
interfaces, and let time and integration with real scenarios decide
witch one would be more useful.

>  Would be better change the signature of the  put and delete  Collection
>  methods, allowing a K type return, or let a impl-data-xml component has the
>  two interfaces?
>

I got a little confused here, as returning K (they key type) wouldn't
solve the first issue you raised. Anyway, looking at the current
Collection interface, key is used as a parameter thus known to the
caller.

   void put(K key, D item) throws NotFoundException;

   void delete(K key) throws NotFoundException;

Then, I'm not sure about the benefits of changing it to return K.

>  On Tue, Apr 15, 2008 at 5:06 PM, Luciano Resende <[EMAIL PROTECTED]>
>  wrote:
>
>
>
>  > I'd suggest the following as the next steps around implementation-data-xml
>  >
>  > - Add support for data collection interface from implementation-data
>  > - At this point, integration with binding-atom-abdera should be
>  > working, it would be great to integrate this with our store tutorial,
>  > either by enhancing the catalog-db or by creating a new module
>  > catalog-db-xml.
>  > - The exercise above should also help drive the requirements for
>  > database schema that you are proposing with a concrete scenario.
>  >
>  > Thoughts ?
>  >
>  > On Tue, Apr 15, 2008 at 12:14 PM, Douglas Leite <[EMAIL PROTECTED]>
>  > wrote:
>  > > In my last contribution, I have proposed a first version of Update and
>  > >  Insert methods for impl.data.xml component.
>  > >  One of the insert method limitations is that the table must only have
>  > >  columns which types are char or varchar. However, I want to improve
>  > this,
>  > >  allowing any sql primitive type.
>  > >  The fact is, the syntax to insert a varchar, for example, is different
>  > to
>  > >  insert a integer. So, it's necessary to know the types of the column.
>  > >  I could resolve this problem in, at least, to different ways: First, I
>  > could
>  > >  use metadata information on the InsertInvoker, and discover the types of
>  > >  columns. Another way to do this, is to add the column type information
>  > in
>  > >  the xml stream retrieved by the get method. So, we would have something
>  > like
>  > >  this:
>  > >
>  > >  
>  > > 
>  > > New Coorporation I
>  > > +5511990202146
>  > >  . . .
>  > > 
>  > >  
>  > >
>  > >  I am not sure if other metadata informations should be added to the xml
>  > >  stream. But, at the moment, I think that column type would be useful.
>  > >
>  > >  Thoughts?
>  > >
>  > >  --
>  > >  Douglas Siqueira Leite
>  > >  Computer Science Master's degree student of University of Campinas
>  > (Unicamp)
>  > >
>  >
>  >
>  >
>  > --
>  > 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]
>  >
>  >
>
>
>  --
>
>
> Douglas Siqueira Leite
>  Computer Science Master's degree student of University of Campinas (Unicamp)
>



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

Re: How do you plug in validation monitoring?

[Simon Laws]

On Wed, Apr 23, 2008 at 5:39 AM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:

> Hi Simon,
>
> I opened JIRA 2260 and attached a second batch of validation test cases.
>
> regards
> Hasan
>
> On Tue, Apr 22, 2008 at 8:16 AM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
>
> > Hi Simon
> >
> > I opened JIRA 2255 and attached a patch for the new testcases.
> >
> > Hasan
> >
> >
> > On Fri, Apr 18, 2008 at 12:58 PM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Thu, Apr 17, 2008 at 5:44 PM, Simon Laws <[EMAIL PROTECTED]
> >
> > > wrote:
> > >
> > > >
> > > >
> > > > On Thu, Apr 17, 2008 at 5:02 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > > wrote:
> > > >
> > > > > Hi Simon,
> > > > >
> > > > > We should have an api for plugins to provide a resource bundle.
> This
> > > api
> > > > > probably needs to be on the monitor or somewhere, i am not sure.
> But
> > > the
> > > > > scenario occurs when plugins want to use the default Monitor but
> > > still
> > > > > want
> > > > > to use their own resource bundle for messageIDs.
> > > > >
> > > > > regards
> > > > > Hasan
> > > > >
> > > > > On Wed, Apr 16, 2008 at 3:30 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > > > > wrote:
> > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > I looked at the new Monitor and Problem interfaces. What do
> > > > > getMessageId()
> > > > > > and getMessageParams() actually return? is MessageId a way to
> > > > > categorize the
> > > > > > error message?
> > > > > >
> > > > > > regards
> > > > > > Hasan
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 15, 2008 at 10:59 AM, Hasan Muhammad <
> [EMAIL PROTECTED]
> > > >
> > > > > wrote:
> > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > I was wondering if i can cook up some validation test cases if
> > > they
> > > > > do
> > > > > > > not exist. Or should we wait until the monitor issue is
> resolved
> > > ?
> > > > > > >
> > > > > > > Hasan
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Apr 10, 2008 at 4:34 PM, Hasan Muhammad <
> > > [EMAIL PROTECTED]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > I dont think using an underlying tuscany jdk logger would be
> > > > > useful to
> > > > > > > > plugins as they may not want to log, rather show it somewhere
> > > else
> > > > > such as
> > > > > > > > console etc. Tuscany can use an underlying logger in it's own
> > > > > monitor ( as
> > > > > > > > it uses today). But i think the first approach of using a
> > > monitor
> > > > > is better
> > > > > > > > along with the condition that it be made more usable by the
> > > > > plugins by
> > > > > > > > giving them greater control.
> > > > > > > >
> > > > > > > > Another point is that tuscany should use ResourceBundle for
> > > > > validation
> > > > > > > > messages as well. I dont think this is being done today.
> > > > > > > >
> > > > > > > > regards
> > > > > > > > Hasan
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Apr 9, 2008 at 1:22 PM, Simon Laws <
> > > > > [EMAIL PROTECTED]>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Wed, Apr 9, 2008 at 12:49 PM, Simon Laws <
> > > > > > > > > [EMAIL PROTECTED]>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Apr 9, 2008 at 12:00 PM, Hasan Muhammad <
> > > > > [EMAIL PROTECTED]>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi Simon,
> > > > > > > > > > >
> > > > > > > > > > > I am on revision 634808. The ContributionServiceImpl
> has
> > > > > changed
> > > > > > > > > since
> > > > > > > > > > > then,
> > > > > > > > > > > and with the one that i have, it would lead through the
> > > > > > > > > > > CompositeProcessor
> > > > > > > > > > > instead of the CompositeDocumentProcessor. Hence the
> > > > > difference
> > > > > > > > > in
> > > > > > > > > > > exceptions..
> > > > > > > > > > >
> > > > > > > > > > > Also, dont you think that with the error that you got
> > > should
> > > > > > > > > throw an
> > > > > > > > > > > exception with schema validation, rather than just a
> > > > > warning?
> > > > > > > > > > >
> > > > > > > > > > > Hasan
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Apr 9, 2008 at 6:36 AM, Simon Laws <
> > > > > > > > > [EMAIL PROTECTED]>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On Tue, Apr 8, 2008 at 2:58 PM, Hasan Muhammad <
> > > > > > > > > [EMAIL PROTECTED]>
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thank you for the good information. First up i am
> > > trying
> > > > > to
> > > > > > > > > verify
> > > > > > > > > > > > whether
> > > > > > > > > > > > > the schema validation works when we point to our
> > > > > schemas.
> > > > > > > > > Can you
> > > > > > > > > > > let me
> > > > > > > > > > > > > know what is a simple error that i can introduce so
> > > that
> > > > > i
> > > > > > > > > can
> > > > > > > > 

Re: What's next for SCA & BPEL Integration

[ant elder]

On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> Now that we are making more progress with the SCA & BPEL integration
> and have figured out how to make References to work, let's discuss
> what could be the next steps on this area. Below are couple examples
> of what we could do next
>
> - WS-BPEL Process Introspection : Currently we are requiring SCA
> componentType files, we could introspect the BPEL process file to
> generate the component type information from it.
>
> - Integrate BEPL with the store scenario tutorial : We could add a
> OrderProcessing step to the store checkout, and illustrate a more real
> integration scenario.
>
> Other then these, we could review the
> SCA_ClientAndImplementationModelFor BPEL and identify other areas that
> we might need enhancements. Scenarios / Samples / Demos are always
> welcome too. Or if you have other suggestions, feel free to jump to
> the discussion.
>
> BTW: Copying the ODE list in case they want to jump and help, or in
> case they have other ideas.
>
>
Not a very exciting one but is there any clean up of the dependencies
possible? Currently using the implementation.bpel extension brings in 78
addition dependency jars at about 20meg, i wondered if some of those could
get excluded?

   ...ant

[jira] Created: (TUSCANY-2271) Java runtime should not inject property into an unannotated non-public field

[Vamsavardhana Reddy (JIRA)]

Java runtime should not inject property into an unannotated non-public field


 Key: TUSCANY-2271
 URL: https://issues.apache.org/jira/browse/TUSCANY-2271
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime, Java SCA Verification Tests
Affects Versions: Java-SCA-1.2
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
 Fix For: Java-SCA-Next


Java Common Annotations and APIs v1.0 - Sec 1.8.13:
1349 Properties may also be injected via public setter methods even when the 
@Property annotation is not
1350 present. However, the @Property annotation must be used in order to inject 
a property onto a non-public
1351 field. In the case where there is no @Property annotation, the name of the 
property is the same as the
1352 name of the field or setter.

Currently the properties are injected into unannotated protected fields too.

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

What's next for SCA & BPEL Integration

[Luciano Resende]

Now that we are making more progress with the SCA & BPEL integration
and have figured out how to make References to work, let's discuss
what could be the next steps on this area. Below are couple examples
of what we could do next

- WS-BPEL Process Introspection : Currently we are requiring SCA
componentType files, we could introspect the BPEL process file to
generate the component type information from it.

- Integrate BEPL with the store scenario tutorial : We could add a
OrderProcessing step to the store checkout, and illustrate a more real
integration scenario.

Other then these, we could review the
SCA_ClientAndImplementationModelFor BPEL and identify other areas that
we might need enhancements. Scenarios / Samples / Demos are always
welcome too. Or if you have other suggestions, feel free to jump to
the discussion.

BTW: Copying the ODE list in case they want to jump and help, or in
case they have other ideas.

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

Re: [DISCUSS] Evolving Implementation-data-xml

[Douglas Leite]

I have started to integrate the Collection interface with
implentation-data-xml. Although the methods present in the DATA interface
(get, insert, update, delete) can be replaced by the Collection interface's
methods (get, post, put, delete), there are some differences. The update and
delete DATA methods return the number of rows affected by each method. On
the other hand, this feature is not present using the Collection methods,
because put and delete are void.

Would be better change the signature of the  put and delete  Collection
methods, allowing a K type return, or let a impl-data-xml component has the
two interfaces?

On Tue, Apr 15, 2008 at 5:06 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> I'd suggest the following as the next steps around implementation-data-xml
>
> - Add support for data collection interface from implementation-data
> - At this point, integration with binding-atom-abdera should be
> working, it would be great to integrate this with our store tutorial,
> either by enhancing the catalog-db or by creating a new module
> catalog-db-xml.
> - The exercise above should also help drive the requirements for
> database schema that you are proposing with a concrete scenario.
>
> Thoughts ?
>
> On Tue, Apr 15, 2008 at 12:14 PM, Douglas Leite <[EMAIL PROTECTED]>
> wrote:
> > In my last contribution, I have proposed a first version of Update and
> >  Insert methods for impl.data.xml component.
> >  One of the insert method limitations is that the table must only have
> >  columns which types are char or varchar. However, I want to improve
> this,
> >  allowing any sql primitive type.
> >  The fact is, the syntax to insert a varchar, for example, is different
> to
> >  insert a integer. So, it's necessary to know the types of the column.
> >  I could resolve this problem in, at least, to different ways: First, I
> could
> >  use metadata information on the InsertInvoker, and discover the types of
> >  columns. Another way to do this, is to add the column type information
> in
> >  the xml stream retrieved by the get method. So, we would have something
> like
> >  this:
> >
> >  
> > 
> > New Coorporation I
> > +5511990202146
> >  . . .
> > 
> >  
> >
> >  I am not sure if other metadata informations should be added to the xml
> >  stream. But, at the moment, I think that column type would be useful.
> >
> >  Thoughts?
> >
> >  --
> >  Douglas Siqueira Leite
> >  Computer Science Master's degree student of University of Campinas
> (Unicamp)
> >
>
>
>
> --
> 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]
>
>


-- 
Douglas Siqueira Leite
Computer Science Master's degree student of University of Campinas (Unicamp)

Re: [Discussion] Exception Handing when adding remote binding to services

[Simon Laws]

Hi Ram

snip


> In case of JSON-RPC binding (our original scenario), when the interface is
> not defined @Remotable the runtime just ignores the data transformation
> between the binding without throwing any exception.


In you test do you have binding.jsonrpc on reference and service sides? If
so it's ignore it because I don't think reference side binding.jsonrpc has
been implemented yet.


>
> But I have noticed that in case of Axis2 binding for the same scenario, we
> get an exception as shown below.
> *java.lang.IllegalArgumentException*: Can't handle *mixed* payloads between
> OMElements and other types.
>

So the message is still going via the web service binding which still
expects Axiom formatted input. But there must be a switch somewhere that
says, if the interface is not marked as remotable then don't bother doing
data transformations as messages will only be passed locally. I'll have to
check in the code as I don't know how this fits in with cases where you
might expect transformation to take place, e.g. talking locally to a
non-java implementation such as BPEL.


> I believe, just throwing a warning would not help for all kind of
> bindings as such scenario could even throw runtime exceptions
> sometimes.
> Not sure how to handle such scenarios. Please suggest.
>

We really need to raise an error because it's not really a valid
configuration. Where is the test going to happen?


>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>

Re: [vtest] getCompositeContext API for non-SCA clients

[ant elder]

Ok, although with non-SCA clients which component would that be? Does there
need to be a new something like implementation.web but for JSE clients? or
could there be a "virtual" component that has references for all the
toplevel component services in the domain (which is kind of what we have now
with SCADomain.getService right?).

   ...ant

On Thu, Apr 17, 2008 at 9:10 PM, Yee-Kang Chang <[EMAIL PROTECTED]> wrote:

> Just thought to follow-up to see if we will do this ..
>
> Perhaps SCADomain can be extended to return the ComponentContext for a
> particular component?
>
> Thanks.
>
> On Wed, Apr 2, 2008 at 6:37 PM, Kevin Williams <[EMAIL PROTECTED]>
> wrote:
> > The current JUnit tests (iTest and vTest) make use of the non-standard
> > SCADomain.getService API to get a handle to an SCA service.  Are there
> > any plans to provide an API to get a ComponentContext as outlined by
> > the SCA Java Annotations and APIs specification?  I would like to
> > stick to  stick to specified APIs  as much as possible in vTest.
> >
> >
> > 1.4.2.1. ComponentContext
> > Non-SCA client code can use the ComponentContext API to perform
> > operations against a component in an
> > SCA domain. How client code obtains a reference to a ComponentContext
> > is runtime specific. The following
> > example demonstrates the use of the component Context API by non-SCA
> code:
> >
> >ComponentContext context = // obtained through host
> > environment-specific means
> >
> >HelloService helloService =
> > context.getService(HelloService.class,"HelloService");
> >
> > Thanks.
> > --
> > Kevin
>
> I don't remember any discussion about this so i guess there are "no plans"
> yet to change it. I agree it seems like we should though.
>
> ...ant
>

Re: [jira] Commented: (TUSCANY-2268) Exceptions errors on binding toexternal web services

[ant elder]

>From what you have below only the

 http://tempuri.org/#wsdl.port
(HelloWorld/HelloWorldSoap)"/>

makes sense as the uri attribute should be the actual endpoint of the web
service, eg something like "
http://159.217.144.79/webservices/HelloWorld.asmx";.

The exception thats giving indicates that the request has been sent, a
response has been received and that something has gone wrong while
processing the response. Do you have something like TCPMON available so you
could capture the response XML and post it here so we can see what it looks
like?

You're right, the @Remotable annotation should really have been used on the
translate example, just luck in the Tuscany implementation and using XML
style services meant the example worked in that case anyway without the
annotation,

   ...ant

On Thu, Apr 24, 2008 at 2:37 PM, Marina Deslaugiers <
[EMAIL PROTECTED]> wrote:

> Hi,
>
> Thanks for your quick answer and corrections. With regards to the error in
> the composite file I have made it by inattention (I did not make that
> mistake in my previous tries :=) ). Concerning the @Remotable annotation I
> began to indicate it as I thought it was mandatory; but as I had still an
> error and that it was not indicated in the "translate" code you write for me
> (why is it not necessary in that case ?), I made a try without that
> annotation.
>
> However, after the corrections, it still does not work:
>
> 1) if I use
>   uri="http://tempuri.org/#wsdl.port(HelloWorld/
> HelloWorldSoap)"/>
>
> I get the following exception:
>
> 
>
> 1) if I use
>  http://tempuri.org/#wsdl.port
> (HelloWorld/HelloWorldSoap)"/>
>
> I get the following exception:
> 
>
> I get the same If I promote the reference from the composite.
>
>
> Besides, to answer your demand, I get no service code as I connect to a
> non-SCA (external) web service. So, It brings me back to the primary
> question in my first e-mail in the mail thread: is it achievable in Tuscany
> to use binding.ws to connect from a SCA domain to a non-SCA (so external)
> web service ?
>
>
> Regards,
> Marina.
>
>
> Le 24 avr. 08 à 12:37, ant elder (JIRA) a écrit :
>
>
>
> >[ 
> > https://issues.apache.org/jira/browse/TUSCANY-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591978#action_12591978
> > ]
> >
> > ant elder commented on TUSCANY-2268:
> > 
> >
> > There's two problems I've noticed so far:
> >
> > - the interface HelloWorld has the @Remotable commented out with the
> > comment "utile ?", you need this.
> >  Without  it when everything else is configured ok you'll get the
> > following:
> >  [java] Exception in thread "main" java.lang.IllegalArgumentException:
> > Can't handle mixed payloads betweem OMElements and other types.
> >
> > - in the .composite files the  has an incorrect port name of
> > "HelloWorldSoapPort" instead of ""HelloWorldSoap" as defined in the
> > helloworld.wsdl.
> >
> > Changing those two things gets the client running for me though i can't
> > test it fully as I don't have any service running for it. If you still have
> > trouble invoking the service post the service code so i can help debug that.
> > Apologies that the error messages given for those two problems are so
> > unhelpful, more meaningfull messages would have made that much easier to
> > debug.
> >
> >
> >
> >
> >  Exceptions errors on binding to external web services
> > > -
> > >
> > >Key: TUSCANY-2268
> > >URL: https://issues.apache.org/jira/browse/TUSCANY-2268
> > >Project: Tuscany
> > > Issue Type: Bug
> > > Components: Java SCA Axis Binding Extension
> > >   Affects Versions: Java-SCA-1.1
> > >Environment:  Windows XP, Eclipse 3.3.0 , tuscany incubating
> > > 1.1 , java 6
> > >   Reporter: Marina Deslaugiers
> > >Attachments: ws-webhelloworld.zip
> > >
> > >
> > > Hi,
> > > I am considering  web services that seems to be "doc literal encoded".
> > > I began to try the direct connection to them but I did not succeed.
> > > As these web services are not public ones, I have done a try on a
> > > simple (helloworrd) public one without success. Depending, on the binding
> > > way (uri, wsdlElement and promoted or not promoted reference) I get
> > > different exceptions (some are indicated - within a comment - in the
> > > composite files).
> > > So, what is wrong ?
> > > I attach the code I wrote; please, would you mind to verify (and
> > > correct if necessary) it or send me an equivalent example that works 
> > > because
> > > I need to make it work rapidly now.
> > > Thanks,
> > > Marina.
> > >
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>

[vTest] Test design for ConversationAttributes.SinglePrincipal

[Kevin Williams]

I am adding a test to verify @ConversationalAttributes
(SinglePrincipal = true).  Here is the related text from the Java
API/Annot specification:

1669 • singlePrincipal (optional) – If true, only the principal
(the user) that started the conversation has
1670 authority to continue the conversation. The default value is false

I would like to create the simplest test possible and this is what I
have come up with so far:

   --Three components each with a single service: A, B, C.  C is
conversational with SinglePrincipal = true.
   --A and B are configured such that each "requires" a policy set
(jassAuthentication1 and jassAuthentication2 respectively)
   --A will initiate a conversation with C
   --A will pass its C-reference to B
   --B will attempt to continue the conversation and this should fail
since B represents a different "principal"

I'll start  implementing this but would appreciate any suggestions ...
especially if I am way out in the weeds :-)

Thanks,

--Kevin

Re: [CONF] Apache Tuscany: Build your first Web Services with Tuscany (page edited)

[Luciano Resende]

Totally +1, What I had in mind was to keep it simple and usable by
someone that does not know much of SCA. What if we create a "First
Steps" series of articles ?

On Thu, Apr 24, 2008 at 2:14 AM, ant elder <[EMAIL PROTECTED]> wrote:
> I asked as I'd like to help expand it but don't want to step on your toes.
>  Adding web clients sounds good, expanding the WS bit with how to use other
>  databindings would be useful, maybe something on other bindings like JMS,
>  then it could go on with what to do when you want to run it out side of
>  eclipse - how to make contribution jars or run standalone or in webapps etc.
>  I like that that page is nice and simple and clear and focused so it would
>  be good to try to maintain that, maybe have separate pages for each topic
>  but linked together and in the same sort of style as that one. WDYT?
>
>...ant
>
>  On Wed, Apr 23, 2008 at 5:17 PM, Luciano Resende <[EMAIL PROTECTED]>
>  wrote:
>
>
>
>  > Yes, it's on my todo list for the next couple days...
>  >
>  > Do you have any ideas for what type of extensions to use ? Maybe
>  > JSON-RPC and use a quick web2.0 client app to consume the service ?
>  >
>  > On Wed, Apr 23, 2008 at 4:39 AM, ant elder <[EMAIL PROTECTED]> wrote:
>  > > This looks really good, do you have plans to extend it further like with
>  > >  adding clients or other extension types?
>  > >
>  > >...ant
>  > >
>  > >  On Tue, Apr 22, 2008 at 5:53 PM, <[EMAIL PROTECTED]> wrote:
>  > >
>  > >  >Page Edited : TUSCANY<
>  > http://cwiki.apache.org/confluence/display/TUSCANY>: Build
>  > >  > your first Web Services with Tuscany<
>  > 
> http://cwiki.apache.org/confluence/display/TUSCANY/Build+your+first+Web+Services+with+Tuscany
>  > >
>  > >  >
>  > >  > Build your first Web Services with Tuscany<
>  > 
> http://cwiki.apache.org/confluence/display/TUSCANY/Build+your+first+Web+Services+with+Tuscany>has
>  > been edited by Luciano
>  > >  > Resende<
>  > http://cwiki.apache.org/confluence/display/[EMAIL PROTECTED]> (Apr
>  > >  > 22, 2008).
>  > >  >
>  > >  > (View changes)<
>  > 
> http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=82971&originalVersion=5&revisedVersion=6
>  > >
>  > >  > Content:
>  > >
>  > > > Build your first Web Services with Tuscany
>  > >  >
>  > >  > This guide will give you step by step instructions on how to build
>  > your
>  > >  > first web services.
>  > >  > The first part, we will learn how we can add the Tuscany Runtime to
>  > >  > Eclipse IDE.
>  > >  > The second part, will show how easy is to create a webservices using
>  > >  > Apache Tuscany.
>  > >
>  > > > Install Tuscany Eclipse Plugins 1.1
>  > >  > Install the Tuscany Eclipse Plugin
>  > >  >
>  > >  > The first thing you do is to start Eclipse and go to *Help ->
>  > Software
>  > >  > Updates -> Find and Install*,
>  > >  > select "Search for new features to install" and then click next
>  > >  >
>  > >  > On the next dialog, click on *"New Remote Site..."* to create a new
>  > site
>  > >  > entry. Give it a name such as
>  > >  > "Tuscany" and add the site URL as *
>  > >  > 
> http://people.apache.org/~jsdelfino/tuscany/tools/updatesite/*
>  > 
>  > >  >
>  > >  > Make sure the *"Remote  Site"* that was just created is selected, and
>  > >  > click *"Finish"*
>  > >  >
>  > >  > Select the *"Apache Tuscany SCA Tools"* and click *"Next"*, and then,
>  > on
>  > >  > the next dialog, click *"Finish"*
>  > >  >
>  > >  > Accept the *"Plugin License"*
>  > >  >
>  > >  > and next click on *"Install All"*
>  > >  >
>  > >  > When asked to *"restart eclipse"*, click the  *"yes"* button.
>  > >  >
>  > >  > Create your Service Business Logic Create a Java Project
>  > >
>  > > >
>  > >  > In this step you create a Java Project in Eclipse to hold the
>  > composite
>  > >  > service application.
>  > >  > Click on the *New Java Project* button   in the toolbar to launch the
>  > >
>  > > > project creation dialog.
>  > >  > Next you enter "ws" as the *Project name*, and for *Project Layout*
>  > select
>  > >  > *Create separate*
>  > >  > *folders for sources and class files.*
>  > >
>  > > >
>  > >  >
>  > >  >
>  > >  >
>  > >  > Hit the *Next* button, and on the following page go to the
>  > *Libraries*tab. Use the
>  > >  > *Add Library...*
>  > >  > button on the right to add the *Tuscany Library* library to the
>  > project.
>  > >  >
>  > >  >
>  > >  >
>  > >  >
>  > >
>  > > > Hit the *Finish* button to complete the *New Java Project* dialog to
>  > >  > create the "ws" java project.
>  > >  >
>  > >  >
>  > >  >
>  > >  >
>  > >
>  > > > Construct Services
>  > >  >
>  > >  > First you create the "helloworld" package folders into which later in
>  > this
>  > >  > step you place service implementations.
>  > >  > Select the "ws" project and click on the *New Java Package* button in
>  >

[jira] Assigned: (TUSCANY-2210) Java runtime should inject property to field with common name in absence of @Property

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy reassigned TUSCANY-2210:


Assignee: (was: Vamsavardhana Reddy)

Unassigning so that a committer can pickup.

> Java runtime should inject property to field with common name in absence of 
> @Property
> -
>
> Key: TUSCANY-2210
> URL: https://issues.apache.org/jira/browse/TUSCANY-2210
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Reporter: Gilbert Kwan
>Priority: Minor
> Attachments: TUSCANY-2210.patch
>
>
> The Java Annotations&APIs specification Lines 1349 to 1352:
> Properties may also be injected via public setter methods even when the 
> "@Property" annotation is not present. However, the @Property annotation must 
> be used in order to inject a property onto a non-public field. In the case 
> where there is no "@Property" annotation, the name of the property is the 
> same as the name of the field or setter.
> The vTest to demonstrate this issue will be posted later.

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

[jira] Updated: (TUSCANY-2210) Java runtime should inject property to field with common name in absence of @Property

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated TUSCANY-2210:
-

Attachment: TUSCANY-2210.patch

TUSCANY-2210.patch: Fixes the vtest.

> Java runtime should inject property to field with common name in absence of 
> @Property
> -
>
> Key: TUSCANY-2210
> URL: https://issues.apache.org/jira/browse/TUSCANY-2210
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Reporter: Gilbert Kwan
>Assignee: Vamsavardhana Reddy
>Priority: Minor
> Attachments: TUSCANY-2210.patch
>
>
> The Java Annotations&APIs specification Lines 1349 to 1352:
> Properties may also be injected via public setter methods even when the 
> "@Property" annotation is not present. However, the @Property annotation must 
> be used in order to inject a property onto a non-public field. In the case 
> where there is no "@Property" annotation, the name of the property is the 
> same as the name of the field or setter.
> The vTest to demonstrate this issue will be posted later.

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

Re: [jira] Commented: (TUSCANY-2268) Exceptions errors on binding toexternal web services

[Marina Deslaugiers]

Hi,

Thanks for your quick answer and corrections. With regards to the  
error in the composite file I have made it by inattention (I did not  
make that mistake in my previous tries :=) ). Concerning the  
@Remotable annotation I began to indicate it as I thought it was  
mandatory; but as I had still an error and that it was not indicated  
in the "translate" code you write for me (why is it not necessary in  
that case ?), I made a try without that annotation.


However, after the corrections, it still does not work:

1) if I use
  http://tempuri.org/#wsdl.port(HelloWorld/ 
HelloWorldSoap)"/>


 I get the following exception:

 

1) if I use
  http://tempuri.org/#wsdl.port 
(HelloWorld/HelloWorldSoap)"/>


 I get the following exception:
 

I get the same If I promote the reference from the composite.


Besides, to answer your demand, I get no service code as I connect to  
a non-SCA (external) web service. So, It brings me back to the  
primary question in my first e-mail in the mail thread: is it  
achievable in Tuscany to use binding.ws to connect from a SCA domain  
to a non-SCA (so external) web service ?



Regards,
Marina.


Le 24 avr. 08 à 12:37, ant elder (JIRA) a écrit :



[ https://issues.apache.org/jira/browse/TUSCANY-2268? 
page=com.atlassian.jira.plugin.system.issuetabpanels:comment- 
tabpanel&focusedCommentId=12591978#action_12591978 ]


ant elder commented on TUSCANY-2268:


There's two problems I've noticed so far:

- the interface HelloWorld has the @Remotable commented out with  
the comment "utile ?", you need this.
  Without  it when everything else is configured ok you'll get the  
following:
  [java] Exception in thread "main"  
java.lang.IllegalArgumentException: Can't handle mixed payloads  
betweem OMElements and other types.


- in the .composite files the  has an incorrect port  
name of "HelloWorldSoapPort" instead of ""HelloWorldSoap" as  
defined in the helloworld.wsdl.


Changing those two things gets the client running for me though i  
can't test it fully as I don't have any service running for it. If  
you still have trouble invoking the service post the service code  
so i can help debug that. Apologies that the error messages given  
for those two problems are so unhelpful, more meaningfull messages  
would have made that much easier to debug.






Exceptions errors on binding to external web services
-

Key: TUSCANY-2268
URL: https://issues.apache.org/jira/browse/ 
TUSCANY-2268

Project: Tuscany
 Issue Type: Bug
 Components: Java SCA Axis Binding Extension
   Affects Versions: Java-SCA-1.1
Environment:  Windows XP, Eclipse 3.3.0 , tuscany  
incubating 1.1 , java 6

   Reporter: Marina Deslaugiers
Attachments: ws-webhelloworld.zip


Hi,
I am considering  web services that seems to be "doc literal  
encoded". I began to try the direct connection to them but I did  
not succeed.
As these web services are not public ones, I have done a try on a  
simple (helloworrd) public one without success. Depending, on the  
binding way (uri, wsdlElement and promoted or not promoted  
reference) I get different exceptions (some are indicated - within  
a comment - in the composite files).

So, what is wrong ?
I attach the code I wrote; please, would you mind to verify (and  
correct if necessary) it or send me an equivalent example that  
works because I need to make it work rapidly now.

Thanks,
Marina.


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

[jira] Commented: (TUSCANY-2266) Problem with protected field computed as a reference for an unannotated implementation

[Vamsavardhana Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592061#action_12592061
 ] 

Vamsavardhana Reddy commented on TUSCANY-2266:
--

Issue in OASIS SCA Java TC - Ref: http://www.osoa.org/jira/browse/JAVA-38

> Problem with protected field computed as a reference for an unannotated 
> implementation
> --
>
> Key: TUSCANY-2266
> URL: https://issues.apache.org/jira/browse/TUSCANY-2266
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Java Implementation Extension
>Affects Versions: Java-SCA-1.2
>Reporter: Vamsavardhana Reddy
>
> Looks like an unannotated protected field computed as reference in an 
> unannotated java implementation can not get its value injected.  The 
> following is a query posted to the dev-list:
> 
> PART-1:
> The Java Annotations&APIs specification Lines 1407, 1408, 1409, 1410 ...
>  * References may also be injected via public setter methods even when the
>  * "@Reference" annotation is not present. However, the "@Reference"
>  * annotation must be used in order to inject a reference onto a non 
> public
>  * field. In the case where there is no "@Reference" annotation, the name 
> of
>  * the reference is the same as the name of the field or setter.
> This means a reference can not be injected onto a protected field without an 
> @Reference annotation.
> PART-2:
> Java Component Implementation Specification - Section 1.2.7 line 358 to 365:
> 358 1.2.7. Semantics of an Unannotated Implementation
> 359 The section defines the rules for determining properties and references 
> for a Java component
> 360 implementation that does not explicitly declare them using @Reference or 
> @Property.
> 361 In the absence of @Property and @Reference annotations, the properties 
> and references of a class are
> 362 defined according to the following rules:
> 363 1. Public setter methods that are not included in any interface specified 
> by an @Service annotation.
> 364 2. Protected setter methods
> 365 3. Public or protected fields unless there is a public or protected 
> setter method for the same name
> This means a protected field could end up as a reference in an unannotated 
> implementation.  But from PART-1 above, a reference can not be injected 
> unless an @Reference annotation is present on a protected field!!!  How will 
> a protected field computed as a reference for an unannotated implementation 
> get its value set?
> 
> The issue has been raised in OASIS SCA Java TC (See 
> http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200804/msg00041.html).
>   This JIRA is created to track progress on resolution in Tuscany once the 
> spec issue is resolved in OASIS TC.

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

RE: [jira] Created: (TUSCANY-2259) Multiplicity for heterogeneous bindings not working

[Antollini, Mario]

Hello Simon,

I was not sure where to get the resolved composite generated b the
workspace from. However, if I did not understood wrong from [1], it can
be obtained from the domain composite page of the workspace
(http://localhost:9990/ui/composite) by clicking the desired composite
from the "Composite" column.  Thus, I did that and the resolved
composite for Approach 1 was:




http://www.osoa.org/xmlns/sca/1.0";
xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0";
targetNamespace="http://store"; name="store-market">- 
- 












USD- 










USD



- 











Is this the file you were expecting?  It looks exactly the same to the
composite I wrote myself. So, if this is not the resolved composite,
please let me know where I can obtain it from.

Thanks and regards,
Mario


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




-Original Message-
From: Simon Laws [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 23, 2008 5:14 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [jira] Created: (TUSCANY-2259) Multiplicity for
heterogeneous bindings not working

On Wed, Apr 23, 2008 at 3:53 AM, Mario Antollini (JIRA) <
tuscany-dev@ws.apache.org> wrote:

> Multiplicity for heterogeneous bindings not working
> ---
>
> Key: TUSCANY-2259
> URL:
https://issues.apache.org/jira/browse/TUSCANY-2259
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Assembly Model
>Affects Versions: Java-SCA-1.2
> Environment: Maven version: 2.0.8
> Java version: 1.6.0_05
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Mario Antollini
>
>
> Hello,
>
> I have been trying to make the catalog of store-market to be
referencing
> targets with heterogenous bindings (by means of multiplicity)
>
> The following reference (two targets using the same binding) works
fine:
>
>  target="VegetablesCatalogWebService FruitsCatalogWebService" >
>
>
>
> 
>
> At runtime, the goodsCatalog gets "populated" with both vegetables and
> fruits.
>
> However, I could not get goodsCatalog to be populated with the same
items
> when using heterogenous bindings. I was trying with a local
FruitsCatalog
> and a WS VegetablesCatalog.
>
> I tried:
>
> 1 - Approach 1:
>
>  target="VegetablesCatalogWebService MarketFruitsCatalog" >
>
>
>
>
>
> 
>
> Result:
> Only fruits were obtained. Thus, the local binding was working but the
web
> service one was not.
>
> 2 - Approach 2:
>
>  target="MarketFruitsCatalog VegetablesCatalogWebService " >
>
>
>
>
>
> 
>
> Result:
> Only fruits were obtained. Thus, the local binding was working but the
web
> service one was not.
>
> 3 - Approach 3
>
>  target="MarketFruitsCatalog VegetablesCatalogWebService " >
>
>
>
> 
>
> Result:
> Nothing was obtained in the catalog.
>
> 4 - Approach 4
>
>  target="VegetablesCatalogWebService  MarketFruitsCatalog " >
>
> 
>
> Result:
> Nothing was obtained in the catalog.
>
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
Hi Mario

Is it possible for you to print out the resolved composite that the
workspace generates based on, for example, approach 1. I had a similar
scenario work for me recently but this wasn't in the context of the
Tutorial
and it would be interesting to see how the workspace is resolving the
bindings in you example.

Simon

[jira] Updated: (TUSCANY-2210) Java runtime should inject property to field with common name in absence of @Property

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated TUSCANY-2210:
-

Assignee: Vamsavardhana Reddy

The vtest is incorrect as this is applicable to unannotated implementation.  
The vtest needs AnotherAServiceImpl which is should be unannotated.

> Java runtime should inject property to field with common name in absence of 
> @Property
> -
>
> Key: TUSCANY-2210
> URL: https://issues.apache.org/jira/browse/TUSCANY-2210
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Reporter: Gilbert Kwan
>Assignee: Vamsavardhana Reddy
>Priority: Minor
>
> The Java Annotations&APIs specification Lines 1349 to 1352:
> Properties may also be injected via public setter methods even when the 
> "@Property" annotation is not present. However, the @Property annotation must 
> be used in order to inject a property onto a non-public field. In the case 
> where there is no "@Property" annotation, the name of the property is the 
> same as the name of the field or setter.
> The vTest to demonstrate this issue will be posted later.

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

[jira] Created: (TUSCANY-2270) Conversations do not to work with binding.rmi

[Daniel Stucky (JIRA)]

Conversations do not to work with binding.rmi
-

 Key: TUSCANY-2270
 URL: https://issues.apache.org/jira/browse/TUSCANY-2270
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.2
 Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 
1.5.0_10 
Reporter: Daniel Stucky


I have implemented a Service that uses conversations. The interface is 
annotated with @Conversational, the implementation is annotated with 
@Scope("CONVERSATION") and has a member protected String conversationId 
annotated with @ConversationID.

The Service runs fine when using binding.sca or binding.ws. If I use 
binding.rmi I get the following exception:

org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException
at 
org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:123)
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:134)
at 
org.apache.tuscany.sca.binding.rmi.RMIService.invokeTarget(RMIService.java:110)
at 
org.apache.tuscany.sca.binding.rmi.RMIService$1.intercept(RMIService.java:95)
at 
$java.rmi.server.UnicastRemoteObject$$EnhancerByCGLIB$$8c0275ac.setup()
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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
at java.lang.Thread.run(Thread.java:595)
at 
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
at 
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
at 
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:179)
at 
java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:132)
at $Proxy14.setup(Unknown Source)
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.binding.rmi.RMIReferenceInvoker.invokeTarget(RMIReferenceInvoker.java:74)
at 
org.apache.tuscany.sca.binding.rmi.RMIReferenceInvoker.invoke(RMIReferenceInvoker.java:51)
at 
org.apache.tuscany.sca.extension.helper.impl.InvokerProxy.invoke(BindingsActivator.java:252)
at 
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy13.setup(Unknown Source)
at impl.CrawlerControllerImpl.doImport(CrawlerControllerImpl.java:23)
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:109)
at 
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108)
at 
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at 
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.in

[jira] Commented: (TUSCANY-2266) Problem with protected field computed as a reference for an unannotated implementation

[Vamsavardhana Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591997#action_12591997
 ] 

Vamsavardhana Reddy commented on TUSCANY-2266:
--

Looks like unannotated protected fields computed as properties also have the 
same problem!!

PART-3:
Java Common Annotations and APIs - v1.0 - Sec 1.8.13:
1349 Properties may also be injected via public setter methods even when the 
@Property annotation is not
1350 present. However, the @Property annotation must be used in order to inject 
a property onto a non-public
1351 field. In the case where there is no @Property annotation, the name of the 
property is the same as the
1352 name of the field or setter.

> Problem with protected field computed as a reference for an unannotated 
> implementation
> --
>
> Key: TUSCANY-2266
> URL: https://issues.apache.org/jira/browse/TUSCANY-2266
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Java Implementation Extension
>Affects Versions: Java-SCA-1.2
>Reporter: Vamsavardhana Reddy
>
> Looks like an unannotated protected field computed as reference in an 
> unannotated java implementation can not get its value injected.  The 
> following is a query posted to the dev-list:
> 
> PART-1:
> The Java Annotations&APIs specification Lines 1407, 1408, 1409, 1410 ...
>  * References may also be injected via public setter methods even when the
>  * "@Reference" annotation is not present. However, the "@Reference"
>  * annotation must be used in order to inject a reference onto a non 
> public
>  * field. In the case where there is no "@Reference" annotation, the name 
> of
>  * the reference is the same as the name of the field or setter.
> This means a reference can not be injected onto a protected field without an 
> @Reference annotation.
> PART-2:
> Java Component Implementation Specification - Section 1.2.7 line 358 to 365:
> 358 1.2.7. Semantics of an Unannotated Implementation
> 359 The section defines the rules for determining properties and references 
> for a Java component
> 360 implementation that does not explicitly declare them using @Reference or 
> @Property.
> 361 In the absence of @Property and @Reference annotations, the properties 
> and references of a class are
> 362 defined according to the following rules:
> 363 1. Public setter methods that are not included in any interface specified 
> by an @Service annotation.
> 364 2. Protected setter methods
> 365 3. Public or protected fields unless there is a public or protected 
> setter method for the same name
> This means a protected field could end up as a reference in an unannotated 
> implementation.  But from PART-1 above, a reference can not be injected 
> unless an @Reference annotation is present on a protected field!!!  How will 
> a protected field computed as a reference for an unannotated implementation 
> get its value set?
> 
> The issue has been raised in OASIS SCA Java TC (See 
> http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200804/msg00041.html).
>   This JIRA is created to track progress on resolution in Tuscany once the 
> spec issue is resolved in OASIS TC.

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

[jira] Updated: (TUSCANY-2269) Import package could not be resolved in CalculateBindingURITestCase

[Ramkumar Ramalingam (JIRA)]

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

Ramkumar Ramalingam updated TUSCANY-2269:
-

Attachment: TUSCANY-2269.patch

> Import package could not be resolved in CalculateBindingURITestCase
> ---
>
> Key: TUSCANY-2269
> URL: https://issues.apache.org/jira/browse/TUSCANY-2269
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
> Environment: Windows XP
>Reporter: Ramkumar Ramalingam
>Assignee: Ramkumar Ramalingam
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2269.patch
>
>
> The import com.sun.org.apache.xerces.internal.impl.xs.opti.DefaultNode could 
> not be resolved in 
> org.apache.tuscany.sca.implementation.node.builder.impl.CalculateBindingURITestCase.
> Solution: Need to remove the import statement as this class is not used 
> anywhere in the code.

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

[jira] Created: (TUSCANY-2269) Import package could not be resolved in CalculateBindingURITestCase

[Ramkumar Ramalingam (JIRA)]

Import package could not be resolved in CalculateBindingURITestCase
---

 Key: TUSCANY-2269
 URL: https://issues.apache.org/jira/browse/TUSCANY-2269
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Verification Tests
Affects Versions: Java-SCA-Next
 Environment: Windows XP
Reporter: Ramkumar Ramalingam
Assignee: Ramkumar Ramalingam
Priority: Minor
 Fix For: Java-SCA-Next


The import com.sun.org.apache.xerces.internal.impl.xs.opti.DefaultNode could 
not be resolved in 
org.apache.tuscany.sca.implementation.node.builder.impl.CalculateBindingURITestCase.

Solution: Need to remove the import statement as this class is not used 
anywhere in the code.

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

[jira] Commented: (TUSCANY-2268) Exceptions errors on binding to external web services

[ant elder (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591978#action_12591978
 ] 

ant elder commented on TUSCANY-2268:


There's two problems I've noticed so far:

- the interface HelloWorld has the @Remotable commented out with the comment 
"utile ?", you need this.
  Without  it when everything else is configured ok you'll get the following:
  [java] Exception in thread "main" java.lang.IllegalArgumentException: Can't 
handle mixed payloads betweem OMElements and other types.

- in the .composite files the  has an incorrect port name of 
"HelloWorldSoapPort" instead of ""HelloWorldSoap" as defined in the 
helloworld.wsdl.

Changing those two things gets the client running for me though i can't test it 
fully as I don't have any service running for it. If you still have trouble 
invoking the service post the service code so i can help debug that. Apologies 
that the error messages given for those two problems are so unhelpful, more 
meaningfull messages would have made that much easier to debug.




> Exceptions errors on binding to external web services
> -
>
> Key: TUSCANY-2268
> URL: https://issues.apache.org/jira/browse/TUSCANY-2268
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding Extension
>Affects Versions: Java-SCA-1.1
> Environment:  Windows XP, Eclipse 3.3.0 , tuscany incubating 1.1 , 
> java 6
>Reporter: Marina Deslaugiers
> Attachments: ws-webhelloworld.zip
>
>
> Hi,
> I am considering  web services that seems to be "doc literal encoded". I 
> began to try the direct connection to them but I did not succeed.
> As these web services are not public ones, I have done a try on a simple 
> (helloworrd) public one without success. Depending, on the binding way (uri, 
> wsdlElement and promoted or not promoted reference) I get different 
> exceptions (some are indicated - within a comment - in the composite files).
> So, what is wrong ?
> I attach the code I wrote; please, would you mind to verify (and correct if 
> necessary) it or send me an equivalent example that works because I need to 
> make it work rapidly now.
> Thanks,
> Marina.

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

Re: [Discussion] Exception Handing when adding remote binding to services

[Ramkumar R]

On 4/23/08, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On Wed, Apr 23, 2008 at 12:43 PM, Ramkumar R <[EMAIL PROTECTED]>
> wrote:
>
> > On 4/18/08, Ramkumar R <[EMAIL PROTECTED]> wrote:
> > >
> > >  On 4/18/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >>
> > >> On Fri, Apr 18, 2008 at 9:18 AM, Ramkumar R <[EMAIL PROTECTED]>
> > >> wrote:
> > >>
> > >> > TUSCANY 1881, talks about throwing a warning msg when adding remote
> > >> > bindings
> > >> > to services with interfaces not marked as remotable, by which the
> > data
> > >> > transformation might get messed up.
> > >> >
> > >> > From the current implementation, I understand that the
> > >> datatransformation
> > >> > interceptor will not be inserted in the invocation chain if the
> > target
> > >> > interface is not marked as remotable. Not having this interceptor
> > will
> > >> end
> > >> > up with binding specific data transformations not being done.. So
> > unless
> > >> > the
> > >> > target binding does have any trouble with the arguments and
> > returntypes
> > >> > because of the absence of transformations... we do not have any
> > issues.
> > >> > But
> > >> > otherwise we might end up in runtime exceptions being thrown.
> > >> >
> > >> > While thinking at a solution to this issue, i could think of various
> > >> > options
> > >> > as shown below, but not sure which one is the right approach?
> > >> >
> > >> > OPTION 1: About issue shows how lack of Remotable ends up in runtime
> > >> > exception when service methods are invoked, can't we somehow trap
> > this
> > >> > during component build or activatoin time itself?
> > >> >
> > >> > OPTION 2: I believe this whole thing can be solved if we can simply
> > >> check
> > >> > in
> > >> > the binding if the interface is marked remote.
> > >> >
> > >> > OPTION 3: Currently DataBindingRuntimeWireProcessor.process() method
> > >> > checks
> > >> > if the source and target interfaces is remotable before it validates
> > to
> > >> > see
> > >> > if data transformation is required. One way of solution to throw a
> > >> warning
> > >> > msg is to check the source and target datatypes, if their datatypes
> > are
> > >> > diff
> > >> > we assume that data transformation is required and we look if the
> > >> > interfaces
> > >> > are marked remotable, if not we throw a warning msg to alert that
> > there
> > >> > could be an unexpected behaviour in data transformation.
> > >> >
> > >> > OPTION 4: In the DataBindingRuntimeWireProcessor.process() method,
> > just
> > >> > check if the source and target interface is remotable OR if the
> > source
> > >> and
> > >> > target datatypes are different. If any one condition is satisfied
> > then
> > >> we
> > >> > assume that data transformation is required.
> > >> >
> > >> > Apart from the above mentioned issue, do we need to make such checks
> > for
> > >> > ws
> > >> > binding as well OR do we need this checks for all kind of bindings.
> > Like
> > >> > to
> > >> > know people's view on this regard. Thanks.
> > >> >
> > >> > --
> > >> > Thanks & Regards,
> > >> > Ramkumar Ramalingam
> > >> >
> > >>
> > >> Hi Ramkumar
> > >>
> > >> When I originally raised the JIRA I had imagined the solution would be
> > >> your
> > >> OPTION 1. So that we get a warning that at least tells the user that
> > they
> > >> are doing something odd. In my case it took me a while to work out
> what
> > >> the
> > >> problem was so it would have been nice if the runtime had at least
> said
> > >> "you
> > >> are dong something strange are you sure you want to do this".
> > >>
> > >> I hadn't imagines that we could introduce a data transformation in
> this
> > >> case. Is there code in there that tries and optimizes away the remote
> > >> binding if it detects that the components are running locally?
> > >>
> > >> Simon
> > >>
> > >
> > > Hi Simon,
> > > I believe, we don't do any validatation to identify if the component is
> > > local / remote. But anyway we assume that the component is remote by
> > > checking if the interface is remotable. I could see that we only check
> > if
> > > the interfaces are remotable and we try to apply appropriate binding
> and
> > > data transformation upon them.
> > >
> > > I agree with your idea of identifying the component as local/remote and
> > do
> > > some optimization on binding and data transformation part. If everyone
> > > agrees that we need this in place we can probably think of taking this
> > > suggestion forward.
> > >
> > > --
> > > Thanks & Regards,
> > > Ramkumar Ramalingam
> > >
> >
> > Hi Simon,
> > In the mean time, while leaving the optimization part. To fix the issue
> > mentioned in TUSCANY-1881, i believe the best solution would be to
> > identify
> > at the bindingProvider level (except for binding.sca) to check if the
> > source
> > and target interface is remotable and throw a warning message as
> required.
> >
> > Hope this helps.
> >
> > --
> > Thanks & Regards,
> > Ramkumar Ramalingam
> >
>
> Sounds good to me.
>
> Simon
>

[jira] Updated: (TUSCANY-2268) Exceptions errors on binding to external web services

[Marina Deslaugiers (JIRA)]

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

Marina Deslaugiers updated TUSCANY-2268:


Attachment: ws-webhelloworld.zip

> Exceptions errors on binding to external web services
> -
>
> Key: TUSCANY-2268
> URL: https://issues.apache.org/jira/browse/TUSCANY-2268
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding Extension
>Affects Versions: Java-SCA-1.1
> Environment:  Windows XP, Eclipse 3.3.0 , tuscany incubating 1.1 , 
> java 6
>Reporter: Marina Deslaugiers
> Attachments: ws-webhelloworld.zip
>
>
> Hi,
> I am considering  web services that seems to be "doc literal encoded". I 
> began to try the direct connection to them but I did not succeed.
> As these web services are not public ones, I have done a try on a simple 
> (helloworrd) public one without success. Depending, on the binding way (uri, 
> wsdlElement and promoted or not promoted reference) I get different 
> exceptions (some are indicated - within a comment - in the composite files).
> So, what is wrong ?
> I attach the code I wrote; please, would you mind to verify (and correct if 
> necessary) it or send me an equivalent example that works because I need to 
> make it work rapidly now.
> Thanks,
> Marina.

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

[jira] Created: (TUSCANY-2268) Exceptions errors on binding to external web services

[Marina Deslaugiers (JIRA)]

Exceptions errors on binding to external web services
-

 Key: TUSCANY-2268
 URL: https://issues.apache.org/jira/browse/TUSCANY-2268
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-1.1
 Environment:  Windows XP, Eclipse 3.3.0 , tuscany incubating 1.1 , 
java 6
Reporter: Marina Deslaugiers


Hi,

I am considering  web services that seems to be "doc literal encoded". I began 
to try the direct connection to them but I did not succeed.

As these web services are not public ones, I have done a try on a simple 
(helloworrd) public one without success. Depending, on the binding way (uri, 
wsdlElement and promoted or not promoted reference) I get different exceptions 
(some are indicated - within a comment - in the composite files).
So, what is wrong ?

I attach the code I wrote; please, would you mind to verify (and correct if 
necessary) it or send me an equivalent example that works because I need to 
make it work rapidly now.


Thanks,
Marina.


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

Re: [CONF] Apache Tuscany: Build your first Web Services with Tuscany (page edited)

[ant elder]

I asked as I'd like to help expand it but don't want to step on your toes.
Adding web clients sounds good, expanding the WS bit with how to use other
databindings would be useful, maybe something on other bindings like JMS,
then it could go on with what to do when you want to run it out side of
eclipse - how to make contribution jars or run standalone or in webapps etc.
I like that that page is nice and simple and clear and focused so it would
be good to try to maintain that, maybe have separate pages for each topic
but linked together and in the same sort of style as that one. WDYT?

   ...ant

On Wed, Apr 23, 2008 at 5:17 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> Yes, it's on my todo list for the next couple days...
>
> Do you have any ideas for what type of extensions to use ? Maybe
> JSON-RPC and use a quick web2.0 client app to consume the service ?
>
> On Wed, Apr 23, 2008 at 4:39 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > This looks really good, do you have plans to extend it further like with
> >  adding clients or other extension types?
> >
> >...ant
> >
> >  On Tue, Apr 22, 2008 at 5:53 PM, <[EMAIL PROTECTED]> wrote:
> >
> >  >Page Edited : TUSCANY<
> http://cwiki.apache.org/confluence/display/TUSCANY>: Build
> >  > your first Web Services with Tuscany<
> http://cwiki.apache.org/confluence/display/TUSCANY/Build+your+first+Web+Services+with+Tuscany
> >
> >  >
> >  > Build your first Web Services with Tuscany<
> http://cwiki.apache.org/confluence/display/TUSCANY/Build+your+first+Web+Services+with+Tuscany>has
> been edited by Luciano
> >  > Resende<
> http://cwiki.apache.org/confluence/display/[EMAIL PROTECTED]> (Apr
> >  > 22, 2008).
> >  >
> >  > (View changes)<
> http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=82971&originalVersion=5&revisedVersion=6
> >
> >  > Content:
> >
> > > Build your first Web Services with Tuscany
> >  >
> >  > This guide will give you step by step instructions on how to build
> your
> >  > first web services.
> >  > The first part, we will learn how we can add the Tuscany Runtime to
> >  > Eclipse IDE.
> >  > The second part, will show how easy is to create a webservices using
> >  > Apache Tuscany.
> >
> > > Install Tuscany Eclipse Plugins 1.1
> >  > Install the Tuscany Eclipse Plugin
> >  >
> >  > The first thing you do is to start Eclipse and go to *Help ->
> Software
> >  > Updates -> Find and Install*,
> >  > select "Search for new features to install" and then click next
> >  >
> >  > On the next dialog, click on *"New Remote Site..."* to create a new
> site
> >  > entry. Give it a name such as
> >  > "Tuscany" and add the site URL as *
> >  > 
> > http://people.apache.org/~jsdelfino/tuscany/tools/updatesite/*
> 
> >  >
> >  > Make sure the *"Remote  Site"* that was just created is selected, and
> >  > click *"Finish"*
> >  >
> >  > Select the *"Apache Tuscany SCA Tools"* and click *"Next"*, and then,
> on
> >  > the next dialog, click *"Finish"*
> >  >
> >  > Accept the *"Plugin License"*
> >  >
> >  > and next click on *"Install All"*
> >  >
> >  > When asked to *"restart eclipse"*, click the  *"yes"* button.
> >  >
> >  > Create your Service Business Logic Create a Java Project
> >
> > >
> >  > In this step you create a Java Project in Eclipse to hold the
> composite
> >  > service application.
> >  > Click on the *New Java Project* button   in the toolbar to launch the
> >
> > > project creation dialog.
> >  > Next you enter "ws" as the *Project name*, and for *Project Layout*
> select
> >  > *Create separate*
> >  > *folders for sources and class files.*
> >
> > >
> >  >
> >  >
> >  >
> >  > Hit the *Next* button, and on the following page go to the
> *Libraries*tab. Use the
> >  > *Add Library...*
> >  > button on the right to add the *Tuscany Library* library to the
> project.
> >  >
> >  >
> >  >
> >  >
> >
> > > Hit the *Finish* button to complete the *New Java Project* dialog to
> >  > create the "ws" java project.
> >  >
> >  >
> >  >
> >  >
> >
> > > Construct Services
> >  >
> >  > First you create the "helloworld" package folders into which later in
> this
> >  > step you place service implementations.
> >  > Select the "ws" project and click on the *New Java Package* button in
> the
> >
> > > toolbar to launch
> >  > the package creation dialog.
> >  >
> >  > Next you enter "helloworld" as the package *Name*, and press the
> *Finish*button to complete the
> >  > dialog.
> >  >
> >  >
> >
> > > *HelloWorld*
> >  >
> >  > In this step you create the HelloWorld service interface and
> >  > implementation.
> >  > Select the "helloworld" package. Next you click on the dropdown arrow
> next
> >  > to the *New Java Class*
> >  > buttonand select the *New Java Interface*option from the
> dropdown
> >
> > > list. In the dialog
> >  > enter "HelloWorld" as the *Name* of the inter

Re: SVN version keyword expansion

[Vamsavardhana Reddy]

On Thu, Apr 24, 2008 at 1:32 PM, Simon Nash <[EMAIL PROTECTED]> wrote:

> Luciano Resende wrote:
>
> > My understanding is that expanded keywords are not considered in svn
> > diff, commit, etc, and it's more like a local visual piece of
> > information.
> >
> >  From [1], here is a little info on the subject.
> > >
> >
> > "Keywords and Spurious Differences
> >
> > The user-visible result of keyword substitution might lead you to
> > think that every version of a file with that feature in use differs
> > from the previous version in at least the area where the keyword
> > anchor was placed. However, this is actually not the case. While
> > checking for local modifications during svn diff, and before
> > transmitting those local modifications during svn commit, Subversion
> > "un-substitutes" any keywords that it previously substituted. The
> > result is that the versions of the file that are stored in the
> > repository contain only the real modifications that users make to the
> > file."
> >
> > [1] http://svnbook.red-bean.com/en/1.1/ch07s02.html
> >
> >  Thanks for providing the missing piece of the puzzle to explain
> my recent experience.  svn does this when producing a patch, but
> the "patch" tool is not aware of these keywords and cannot adjust
> for them when I apply the patch to a different level of code.
>
> Here's the problem that I ran into.
>  1. Check out a file at version x.  The keywords are expanded
>to indicate version x.
>  2. Make a change near the version line.
>  3. Produce a patch using svn diff.  The version keywords are
>automatically unsubstituted by svn in the patch lines that
>provide surrounding positional context for the change.
>  4. Check out the file again at version y.  It doesn't matter
>whether y > x or y == x.
>  5. Use "patch" to apply the patch produced in step 3 to the
>file checked out in step 4.  This will fail because the
>surrounding context lines in the patch have unexpanded
>keywords, but the same lines in the file that was checked
>out in step 4 have the keywords expanded.

I use TortoiseSVN to apply patches and I don't recall running into this kind
of problem.  May be it is a problem with the patch command??


>
>
> I think there are two possible solutions to this.  Either I
> can recover from the failure when it occurs by manually
> expanding or unexpanding keywords in the patch or base file
> to force the surrounding context lines to match, or I can
> avoid the issue by setting my svn config to disable keyword
> expansion when I do checkouts.  I'd be more inclined to do
> the second than the first, but this calls into question the
> value of having these keywords in our source files.
>
>  Simon
>
>
>  On Wed, Apr 23, 2008 at 5:45 AM, Simon Nash <[EMAIL PROTECTED]> wrote:
> >
> > > Mark Combellack wrote:
> > >
> > >  Hi Simon,
> > > >
> > > > Have you recently changed your Subversion configuration file to
> > > > enable SVN
> > > > keyword expansion? The file in question is located:
> > > >
> > > > Windows  %USERPROFILE%\Application Data\Subversion\config
> > > > Linux   ~/.subversion/config
> > > >
> > > > The value in question is enable-auto-props. If this is set to yes
> > > > then it
> > > > will expand keywords. By default this value is set to no.
> > > >
> > > > There were discussions on the dev list about this around the end of
> > > > March
> > > > beginning of April. See:
> > > >
> > > >
> > > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29637.html
> > > >
> > > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29781.html
> > > > These discussions suggested changing the SVN config to enable
> > > > keyword
> > > > expansion.
> > > >
> > > > Perhaps this is the cause of the problem?
> > > >
> > > > Mark
> > > >
> > > >
> > > >   Thanks for the explanation.  If I understand this correctly, this
> > >  configuration setting will cause these keywords to expand differently
> > >  every time an update is made to the file.  This will cause problems
> > >  when applying a patch derived from an earlier checked out version
> > >  of the file to a later checked out version, if the patch happens to
> > >  include this line and if any updates have been made elsewhere in
> > >  the file between the two checkouts.
> > >
> > >  This won't occur very often, but it did happen to me today, and it
> > >  is a nuisance having to work around it by reverse engineering the
> > >  patch.
> > >
> > >  Simon
> > >
> > >
> > >
> > >
> > >  -Original Message-
> > > > > From: Simon Nash [mailto:[EMAIL PROTECTED]
> > > > > Sent: 23 April 2008 10:16
> > > > > To: tuscany-dev
> > > > > Subject: SVN version keyword expansion
> > > > >
> > > > > On April 1, I checked out a file from SVN.  Its version keywords
> > > > > were not expanded in my local copy.  Yesterday I checked out the
> > > > > same file and the version keywords were expanded.  This caused my
> > > > > attempt to apply a patch (derived from the pre

RE: Adding SVN version to Java files

[Mark Combellack]

Hi,

 

The main reasons that I like the SVN details in the header of the files
include:

 

* You can look at the source file and see what revision it is
without having to use SVN commands

* Typically, developers will do an SVN checkout of the code using
SVN so they can get the information via SVN commands or via the headers

* Typically, users do not do an SVN checkout of the source code and
will not have SVN installed. They are typically provided with a jar file
containing the source code. They will not be able to run SVN command to work
out which versions of source code they are running

* Typically, there are many, many more users than there are
developers

* If a source file is printed out or attached as an email as part of
a bug report or published on a web server, the source code will contain the
SVN revision number. This makes the bug easier to fix as you know the
revision number. The SVN commands will not be able to tell you the revision
number in these scenarios.

 

 

The nice thing about the SVN keyword substitution is that a Developer is
free to choose whether they want them or not as the expansion is done on the
client side. If a Developer wants the $Date$ and $Revision$ expanded, then
they have to update their SVN configuration to do so. If they do not, then
they don't need to do anything as it is disabled in SVN by default. The key
thing is that @version $Date$ $Revision$ is in the header to provide this
choice.

 

 

 

At the end of the day, from my personal opinion, using @version $Date$
$Revision$ is a nice to have feature in the source code. I would like to
have it there. However, I would rather go without it if its presence is
going to cause disharmony amongst the Tuscany Developers.

 

Thanks,

 

Mark

 

> -Original Message-

> From: Vamsavardhana Reddy [mailto:[EMAIL PROTECTED]

> Sent: 24 April 2008 08:04

> To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED]

> Subject: Re: Adding SVN version to Java files

> 

> I would like to know the last revision and date at which a particular file

> is updated just by opening the file in any editor and without having to do

> anything extra, for e.g., like installing a plugin for eclipse, opening a

> command prompt to issue an svn info command (note that the source I have

> need not always be from svn, it could be a source archive for a release

> downloaded separately), etc.  I found this info very useful while

> investigating JIRAs.

> 

> ++Vamsi

> 

> On Thu, Apr 24, 2008 at 11:12 AM, ant elder <[EMAIL PROTECTED]> wrote:

> 

> > On Wed, Apr 23, 2008 at 5:52 PM, Vamsavardhana Reddy

> <[EMAIL PROTECTED]>

> > wrote:

> >

> > 

> >

> > > >  From the above, we have 4 +1s and no -1s - although we have a

> > > > > > preference not

> > > > > >

> > > > > to do this from ant. So, the consensus is to make this change.

> > > > >

> > > > >  We haven't held a formal vote, so I don't think we should be

> trying

> > > > to decide this based on a count of +1s and -1s.

> > >

> > > Agreed.  We should hold a formal vote.

> > >

> > >

> > We do consensus based development. Voting can be a useful gauging

> > consensus

> > but voting does not make consensus. Its obvious from this thread that

> > there

> > is not (yet) consensus so we don't need a vote, how about instead trying

> > to

> > convince us by explaining the value of adding this?

> >

> >   ...ant

> >

Re: [GSoC] Accepted Student Proposals for 2008 Announced

[Mike Edwards]

Wojtek Janiszewski wrote:

Hi all,
first of all I'd like to thank you for your support and encouragement
during GSoC student approval process (and for votes of course:))!
I'll do my best to end this task with success.

I'd like to wish more luck for those whose weren't accepted.
Congratulations for students which are in - it looks we are quite many:)

Yesterday I made short presentation for university seminar, which was
soft introduction to SCA and Tuscany (it was planned for first step into
technology). I realized SCA and Tuscany in all this SOA soup is quite
unknown, so conclusion is that besides coding we shouldn't forget to
popularise SCA and Tuscany. I bet there are many places where we can
mention Tuscany (which can be university classes discussions, Java users
groups etc.).

In next few days I'm planning to produce some plan for next month. Stay
tuned;)

Thanks,
Wojtek


Wojtek,

Useful materials for presentations about SCA and Tuscany can be found 
linked off the following places:


http://www.osoa.org/display/Main/SCA+Resources

and

http://incubator.apache.org/tuscany/sca-overview.html

and

http://www.oasis-opencsa.org/resources


--- and if you have a particular topic in mind, which isn't dealt with 
on those pages, please feel free to ask for help on this list - or ask 
any of the "regulars" (like me) directly - we often have more material 
that is not posted publicly yet.



Yours,  Mike.

[jira] Created: (TUSCANY-2267) Raise a warning if both reference target and binding URI are specified

[Simon Laws (JIRA)]

Raise a warning if both reference target and binding URI are specified
--

 Key: TUSCANY-2267
 URL: https://issues.apache.org/jira/browse/TUSCANY-2267
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.2
 Environment: All
Reporter: Simon Laws
Priority: Minor
 Fix For: Java-SCA-Next


The assembly spec says around line 1380 that " A reference must not mix the use 
of endpoints specified via binding elements with target endpoints specified via 
the target attribute". We should raise a warning if this is detected in a 
composite. 

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

Re: Some questions for workspace module in Tuscany

[Jean-Sebastien Delfino]

Jean-Sebastien Delfino wrote:

Jean-Sebastien Delfino wrote:
- Started to create sample tasks showing how to bootstrap a subset of 
Tuscany to work with the various models [1], see ListDeployables.java, 
ListDependencies.java, ListComponents.java, and WireComponents.java.

...


The init() methods in the sample programs are there to help explore 
the various Tuscany bootstrap patterns required for these common 
tasks, candidate to become generic utility methods if people want that.


This is work in progress, subject to changes and improvements in the 
next few days. I'm also in the process of adding more sample tasks to 
show XML schema based validation, composite include processing, 
assignment of composites to SCA nodes etc.


Feedback is welcome.

[1] 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/domain-management/ 



I've added more code to these samples, got WireComponents working and 
added a DistributeComponents sample that shows how to describe the 
allocation of deployable composites to SCA nodes and then use it to 
configure the services that run on each node.


I'm planning to make the following improvements tomorrow or Friday:

- Fix the samples that use CompositeBuilder to correctly handle SCA 
.


- Clean up the samples to remove code dependencies on the builder 
implementation classes (they all implement the CompositeBuilder 
interface now so it'll be easy).


- Add a sample that feeds the SCA models to an SCA runtime node.

On a related subject, I'm also thinking about the renaming the 
workspace-admin module to domain-admin or domain-manager as it has 
expanded to manage more than just a workspace of contributions. That'll 
be in line with the sample module currently named domain-management.


Hope this helps.


One more thing. I just saw that Raymond seems to have fixed the 
databinding dependency issues so I'll try to add the databinding 
modules. Hopefully they won't add runtime dependencies to the mix.


--
Jean-Sebastien

Re: Some questions for workspace module in Tuscany

[Jean-Sebastien Delfino]

Jean-Sebastien Delfino wrote:
- Started to create sample tasks showing how to bootstrap a subset of 
Tuscany to work with the various models [1], see ListDeployables.java, 
ListDependencies.java, ListComponents.java, and WireComponents.java.

...


The init() methods in the sample programs are there to help explore the 
various Tuscany bootstrap patterns required for these common tasks, 
candidate to become generic utility methods if people want that.


This is work in progress, subject to changes and improvements in the 
next few days. I'm also in the process of adding more sample tasks to 
show XML schema based validation, composite include processing, 
assignment of composites to SCA nodes etc.


Feedback is welcome.

[1] 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/domain-management/ 


I've added more code to these samples, got WireComponents working and 
added a DistributeComponents sample that shows how to describe the 
allocation of deployable composites to SCA nodes and then use it to 
configure the services that run on each node.


I'm planning to make the following improvements tomorrow or Friday:

- Fix the samples that use CompositeBuilder to correctly handle SCA 
.


- Clean up the samples to remove code dependencies on the builder 
implementation classes (they all implement the CompositeBuilder 
interface now so it'll be easy).


- Add a sample that feeds the SCA models to an SCA runtime node.

On a related subject, I'm also thinking about the renaming the 
workspace-admin module to domain-admin or domain-manager as it has 
expanded to manage more than just a workspace of contributions. That'll 
be in line with the sample module currently named domain-management.


Hope this helps.
--
Jean-Sebastien

Re: SVN version keyword expansion

[Simon Nash]

Luciano Resende wrote:

My understanding is that expanded keywords are not considered in svn
diff, commit, etc, and it's more like a local visual piece of
information.


From [1], here is a little info on the subject.


"Keywords and Spurious Differences

The user-visible result of keyword substitution might lead you to
think that every version of a file with that feature in use differs
from the previous version in at least the area where the keyword
anchor was placed. However, this is actually not the case. While
checking for local modifications during svn diff, and before
transmitting those local modifications during svn commit, Subversion
"un-substitutes" any keywords that it previously substituted. The
result is that the versions of the file that are stored in the
repository contain only the real modifications that users make to the
file."

[1] http://svnbook.red-bean.com/en/1.1/ch07s02.html


Thanks for providing the missing piece of the puzzle to explain
my recent experience.  svn does this when producing a patch, but
the "patch" tool is not aware of these keywords and cannot adjust
for them when I apply the patch to a different level of code.

Here's the problem that I ran into.
 1. Check out a file at version x.  The keywords are expanded
to indicate version x.
 2. Make a change near the version line.
 3. Produce a patch using svn diff.  The version keywords are
automatically unsubstituted by svn in the patch lines that
provide surrounding positional context for the change.
 4. Check out the file again at version y.  It doesn't matter
whether y > x or y == x.
 5. Use "patch" to apply the patch produced in step 3 to the
file checked out in step 4.  This will fail because the
surrounding context lines in the patch have unexpanded
keywords, but the same lines in the file that was checked
out in step 4 have the keywords expanded.

I think there are two possible solutions to this.  Either I
can recover from the failure when it occurs by manually
expanding or unexpanding keywords in the patch or base file
to force the surrounding context lines to match, or I can
avoid the issue by setting my svn config to disable keyword
expansion when I do checkouts.  I'd be more inclined to do
the second than the first, but this calls into question the
value of having these keywords in our source files.

  Simon


On Wed, Apr 23, 2008 at 5:45 AM, Simon Nash <[EMAIL PROTECTED]> wrote:

Mark Combellack wrote:


Hi Simon,

Have you recently changed your Subversion configuration file to enable SVN
keyword expansion? The file in question is located:

Windows  %USERPROFILE%\Application Data\Subversion\config
Linux   ~/.subversion/config

The value in question is enable-auto-props. If this is set to yes then it
will expand keywords. By default this value is set to no.

There were discussions on the dev list about this around the end of March
beginning of April. See:

   http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29637.html
   http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29781.html
These discussions suggested changing the SVN config to enable keyword
expansion.

Perhaps this is the cause of the problem?

Mark



 Thanks for the explanation.  If I understand this correctly, this
 configuration setting will cause these keywords to expand differently
 every time an update is made to the file.  This will cause problems
 when applying a patch derived from an earlier checked out version
 of the file to a later checked out version, if the patch happens to
 include this line and if any updates have been made elsewhere in
 the file between the two checkouts.

 This won't occur very often, but it did happen to me today, and it
 is a nuisance having to work around it by reverse engineering the
 patch.

  Simon





-Original Message-
From: Simon Nash [mailto:[EMAIL PROTECTED]
Sent: 23 April 2008 10:16
To: tuscany-dev
Subject: SVN version keyword expansion

On April 1, I checked out a file from SVN.  Its version keywords
were not expanded in my local copy.  Yesterday I checked out the
same file and the version keywords were expanded.  This caused my
attempt to apply a patch (derived from the previous checkout)
to fail.

The file when viewed in SVN contains the header line
 * @version $Rev$ $Date$
My previous local checkout had the identical line.  My current
local checkout has the line
 * @version $Rev: 643696 $ $Date: 2008-04-02 04:24:11 +0100 (Wed, 02 Apr
2008) $

What is causing this line to now get expanded in my local checked out
copy, and why wasn't it expanded when I checked it out previously?

  Simon

Re: SCADomain.getService () should throw exception when bogus component name is passed?

[Simon Laws]

On Thu, Apr 24, 2008 at 8:49 AM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Thu, Apr 24, 2008 at 8:08 AM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > I'm going to close TUSCANY-2145 as working as designed in a few days
> > unless
> > someone says otherwise.
> >
> > I still get the feeling that there is actually no way for
> > o.a.t.s.host.imbedded.impl.DefaultSCADomain to find any new services at
> > invocation time so it could just throw the exception as suggested in the
> > JIRA, but it seems harder to prove that than to just go with the flow
> > and
> > keep the current behaviour.
> >
> >   ...ant
> >
> > On Sun, Apr 13, 2008 at 3:35 PM, Yang Lei <[EMAIL PROTECTED]> wrote:
> >
> > > I think we should keep the following piece. As the comment
> > > said,"create a remote service ref" , so it can delegate to the binding
> > > implementation to handle remote case.
> > >
> > >// Lookup the component in the domain
> > >Component component =
> > componentManager.getComponent(componentName);
> > >if (component == null) {
> > >// The component is not local in the partition, try to
> > > create a remote service ref
> > >return createServiceReference(businessInterface, name);
> > >}
> > >
> > > I agree if we already find the component ( component !=null case), we
> > > should check if the service is defined on the component and throw the
> > > service not found exception if it is not defined. I think the current
> > > implementation already does it in the ComponentContextImpl...
> > >
> > > Yang.
> > >
> > > On Thu, Apr 10, 2008 at 4:17 AM, Wang Feng <[EMAIL PROTECTED]> wrote:
> > > > +1 throw an exception.
> > > >
> > > > The scenario like this class.getMethod(methodName).
> > > > If a matching method  is not found,it will throw
> > NoSuchMethodException.
> > > >
> > > > Thanks,
> > > > Wang Feng
> > > >
> > > >
> > > > On 2008-04-10,ant elder <[EMAIL PROTECTED]> wrote:
> > > >
> > > > >TUSCANY-2145 asks about SCADomain.getService () returning a proxy
> > even
> > > when
> > > > >the service doesn't exist, but looking back through the SVN history
> > it
> > > looks
> > > > >like this is intentional. Before I close the JIRA does anyone have
> > any
> > > > >comments on if this is/isn't the correct behaviour?
> > > > >
> > > > >   ...ant
> > > > >
> > > >
> > > >
> > > >
> > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
> Hi Ant
>
> I agree with the sentiment that given the way that we have the code in
> Tuscany organized at the moment there is no way for DefaultSCADomain to find
> any new service at invocation time. However in the past we have have had
> Nodes that have allowed this and I'm currently changing the builder code [1]
> to allow for this more generally in the future. So I agree we should just
> close this JIRA with the expectation that, in the future, returning a
> reference that is not, yet, resolved is a useful feature.
>
> Simon
>

oops, forgot the reference which talks about some experiments to make the
binding of references more flexible. I'm not done just yet but I hope to
check some code in shortly that we can take a look at and discuss to see if
we think it's a sensible thing to do i.e. move from a brainstorm into a
concrete feature.

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

Re: SCADomain.getService () should throw exception when bogus component name is passed?

[Simon Laws]

On Thu, Apr 24, 2008 at 8:08 AM, ant elder <[EMAIL PROTECTED]> wrote:

> I'm going to close TUSCANY-2145 as working as designed in a few days
> unless
> someone says otherwise.
>
> I still get the feeling that there is actually no way for
> o.a.t.s.host.imbedded.impl.DefaultSCADomain to find any new services at
> invocation time so it could just throw the exception as suggested in the
> JIRA, but it seems harder to prove that than to just go with the flow and
> keep the current behaviour.
>
>   ...ant
>
> On Sun, Apr 13, 2008 at 3:35 PM, Yang Lei <[EMAIL PROTECTED]> wrote:
>
> > I think we should keep the following piece. As the comment
> > said,"create a remote service ref" , so it can delegate to the binding
> > implementation to handle remote case.
> >
> >// Lookup the component in the domain
> >Component component =
> componentManager.getComponent(componentName);
> >if (component == null) {
> >// The component is not local in the partition, try to
> > create a remote service ref
> >return createServiceReference(businessInterface, name);
> >}
> >
> > I agree if we already find the component ( component !=null case), we
> > should check if the service is defined on the component and throw the
> > service not found exception if it is not defined. I think the current
> > implementation already does it in the ComponentContextImpl...
> >
> > Yang.
> >
> > On Thu, Apr 10, 2008 at 4:17 AM, Wang Feng <[EMAIL PROTECTED]> wrote:
> > > +1 throw an exception.
> > >
> > > The scenario like this class.getMethod(methodName).
> > > If a matching method  is not found,it will throw
> NoSuchMethodException.
> > >
> > > Thanks,
> > > Wang Feng
> > >
> > >
> > > On 2008-04-10,ant elder <[EMAIL PROTECTED]> wrote:
> > >
> > > >TUSCANY-2145 asks about SCADomain.getService () returning a proxy
> even
> > when
> > > >the service doesn't exist, but looking back through the SVN history
> it
> > looks
> > > >like this is intentional. Before I close the JIRA does anyone have
> any
> > > >comments on if this is/isn't the correct behaviour?
> > > >
> > > >   ...ant
> > > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

Hi Ant

I agree with the sentiment that given the way that we have the code in
Tuscany organized at the moment there is no way for DefaultSCADomain to find
any new service at invocation time. However in the past we have have had
Nodes that have allowed this and I'm currently changing the builder code [1]
to allow for this more generally in the future. So I agree we should just
close this JIRA with the expectation that, in the future, returning a
reference that is not, yet, resolved is a useful feature.

Simon

Re: SCADomain.getService () should throw exception when bogus component name is passed?

[ant elder]

I'm going to close TUSCANY-2145 as working as designed in a few days unless
someone says otherwise.

I still get the feeling that there is actually no way for
o.a.t.s.host.imbedded.impl.DefaultSCADomain to find any new services at
invocation time so it could just throw the exception as suggested in the
JIRA, but it seems harder to prove that than to just go with the flow and
keep the current behaviour.

   ...ant

On Sun, Apr 13, 2008 at 3:35 PM, Yang Lei <[EMAIL PROTECTED]> wrote:

> I think we should keep the following piece. As the comment
> said,"create a remote service ref" , so it can delegate to the binding
> implementation to handle remote case.
>
>// Lookup the component in the domain
>Component component = componentManager.getComponent(componentName);
>if (component == null) {
>// The component is not local in the partition, try to
> create a remote service ref
>return createServiceReference(businessInterface, name);
>}
>
> I agree if we already find the component ( component !=null case), we
> should check if the service is defined on the component and throw the
> service not found exception if it is not defined. I think the current
> implementation already does it in the ComponentContextImpl...
>
> Yang.
>
> On Thu, Apr 10, 2008 at 4:17 AM, Wang Feng <[EMAIL PROTECTED]> wrote:
> > +1 throw an exception.
> >
> > The scenario like this class.getMethod(methodName).
> > If a matching method  is not found,it will throw NoSuchMethodException.
> >
> > Thanks,
> > Wang Feng
> >
> >
> > On 2008-04-10,ant elder <[EMAIL PROTECTED]> wrote:
> >
> > >TUSCANY-2145 asks about SCADomain.getService () returning a proxy even
> when
> > >the service doesn't exist, but looking back through the SVN history it
> looks
> > >like this is intentional. Before I close the JIRA does anyone have any
> > >comments on if this is/isn't the correct behaviour?
> > >
> > >   ...ant
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Adding SVN version to Java files

[Vamsavardhana Reddy]

I would like to know the last revision and date at which a particular file
is updated just by opening the file in any editor and without having to do
anything extra, for e.g., like installing a plugin for eclipse, opening a
command prompt to issue an svn info command (note that the source I have
need not always be from svn, it could be a source archive for a release
downloaded separately), etc.  I found this info very useful while
investigating JIRAs.

++Vamsi

On Thu, Apr 24, 2008 at 11:12 AM, ant elder <[EMAIL PROTECTED]> wrote:

> On Wed, Apr 23, 2008 at 5:52 PM, Vamsavardhana Reddy <[EMAIL PROTECTED]>
> wrote:
>
> 
>
> > >  From the above, we have 4 +1s and no -1s - although we have a
> > > > > preference not
> > > > >
> > > > to do this from ant. So, the consensus is to make this change.
> > > >
> > > >  We haven't held a formal vote, so I don't think we should be trying
> > > to decide this based on a count of +1s and -1s.
> >
> > Agreed.  We should hold a formal vote.
> >
> >
> We do consensus based development. Voting can be a useful gauging
> consensus
> but voting does not make consensus. Its obvious from this thread that
> there
> is not (yet) consensus so we don't need a vote, how about instead trying
> to
> convince us by explaining the value of adding this?
>
>   ...ant
>