[jira] Commented: (TUSCANY-2285) Make sca-api automatically build as an OSGi bundle

[Rajini Sivaram (JIRA)]

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

Rajini Sivaram commented on TUSCANY-2285:
-

Raymond,

Was the issue with maven-bundle-plugin and SDO related to building on JDK 1.4 
(which is not supported with Tuscany-SCA)? If not, could you describe the 
problem and/or how to recreate it? We can use the manifest goal for sca-api, 
but we may want to use bundle/bundleall goals to generate the high-level 
combinations for distribution. I am sure the Felix team will help to fix the 
problem if we can identify what the issue was.

Thank you...


> Make sca-api automatically build as an OSGi bundle
> --
>
> Key: TUSCANY-2285
> URL: https://issues.apache.org/jira/browse/TUSCANY-2285
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Core Runtime, Java SCA OSGi Integration
>Affects Versions: Java-SCA-Next
> Environment: All
>Reporter: Graham Charters
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: sca-api-bundle.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> Itest/osgi-tuscany creates an OSGi bundle for the sca-api module.  As a step 
> towards providing better support for OSGi, it has been suggested on the 
> dev-list that we simply make sca-api automatically build as an OSGi bundle.  
> This does not preclude it being used as a normal jar.
> I have a patch which I will attached shortly.

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

[jira] Updated: (TUSCANY-2280) No data transformation for fault types

[Simon Laws (JIRA)]

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

Simon Laws updated TUSCANY-2280:


Fix Version/s: (was: Java-SCA-1.2)
   (was: Java-SCA-1.1)
   Java-SCA-Next

Move fix to SCA Next

> No data transformation for fault types
> --
>
> Key: TUSCANY-2280
> URL: https://issues.apache.org/jira/browse/TUSCANY-2280
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-1.1, Java-SCA-1.2
>Reporter: Cezary Wisniewski
> Fix For: Java-SCA-Next
>
>
> DataTransformationInterceptor is not added to the InvocationChain when method 
> has no parameters and no return type e.g.
> void someMethod() throws MyException
> DataTransformationInterceptor should be added to the chain because the 
> exception has to be transformed. DataTransformationInterceptor is added to 
> the chain and exception is transformed when the method has at least one 
> parameter or return type e.g.
> MyStruct someMethod() throws MyExcpetions
> or
> void someMethod(MyStruct param) throws MyException
> The reason for such behavior is that DataBindingRuntimeWireProcessor only 
> takes care of parameters and return types and ignores fault types (see 
> DataBindingRuntimeWireProcessor.isTransformationRequired(Operation, Operation)

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

[jira] Updated: (TUSCANY-2251) Problem with 1.2 RC4 with simple JavaBean

[Simon Laws (JIRA)]

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

Simon Laws updated TUSCANY-2251:


Fix Version/s: (was: Java-SCA-1.2)
   Java-SCA-Next

move fix to SCA Next

> Problem with 1.2 RC4 with simple JavaBean
> -
>
> Key: TUSCANY-2251
> URL: https://issues.apache.org/jira/browse/TUSCANY-2251
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-1.2
> Environment: Eclipse 3.3, Tuscany SCA 1.2 - RC4
>Reporter: Nishant Joshi
> Fix For: Java-SCA-Next
>
> Attachments: generatedClientCode.zip, SimpleBeanProblem.zip
>
>
> Hi there,
> I have one sample which was perfectly working with 1.0 incubating... when i 
> have tried same with 1.2 RC4 all the data come from client was null for all 
> the values for a simple bean.
> Please note that I m creating Client on Eclipse 3.3... using WebService 
> client generation facility of eclipse...
> I m attaching detail for more detail...
> When tried same with SCA client it was giving me perfect result... 

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

[jira] Updated: (TUSCANY-2220) WSDL representations of binding.ws generated incorrectly.

[Simon Laws (JIRA)]

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

Simon Laws updated TUSCANY-2220:


Fix Version/s: (was: Java-SCA-1.2)
   Java-SCA-Next

Move fix to SCA Next

> WSDL representations of binding.ws generated incorrectly.
> -
>
> Key: TUSCANY-2220
> URL: https://issues.apache.org/jira/browse/TUSCANY-2220
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Embedded Runtime
>Affects Versions: Java-SCA-1.2
> Environment: Websphere 6.1.0.14 on AIX, jdk150_10
> Jetty on Windows XP x86, jdk150_10
> Websphere on Windows XP x86, jdk150_10
> Tomcat on Windows XP x86. jdk150_10
>Reporter: Dave Sowerby
> Fix For: Java-SCA-Next
>
>
> WSDL representations of binding.ws generated incorrectly.
> I'm currently facing issues when attmepting to utilise the wsdl
> generated by a service exposed using binding.ws, when I use wsdl2java
> with this wsdl I get the following exception:
> IWAB0399E Error in generating Java from WSDL:  java.io.IOException:
> Emitter failure.  Cannot find endpoint address in port
> ServiceRequestPortType__SOAPHTTPPort in service
> ServiceRequestPortType__ServiceLocator
>java.io.IOException: Emitter failure.  Cannot find endpoint
> address in port ServiceRequestPortType__SOAPHTTPPort in service
> ServiceRequestPortType__ServiceLocator
>at 
> org.apache.axis.wsdl.toJava.JavaServiceImplWriter.writeFileBody(JavaServiceImplWriter.java:189)
>at org.apache.axis.wsdl.toJava.JavaWriter.generate(JavaWriter.java:127)
>at 
> org.apache.axis.wsdl.toJava.JavaServiceWriter.generate(JavaServiceWriter.java:112)
>at 
> org.apache.axis.wsdl.toJava.JavaGeneratorFactory$Writers.generate(JavaGeneratorFactory.java:421)
>at org.apache.axis.wsdl.gen.Parser.generate(Parser.java:476)
>at org.apache.axis.wsdl.gen.Parser.access$000(Parser.java:45)
>at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:362)
>at java.lang.Thread.run(Unknown Source)
> I've diffed a previously functioning wsdl against the currently (RC3a)
> generated wsdl file, the difference causing this problem appears to be
> the additional lines of:
>  
> binding="ns2:ServiceRequestPortType__SOAPBinding">
>
>  
> Which without an address is causing wsdl2java to fail.

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

Re: Improving support for running in OSGi

[Rajini Sivaram]

On 5/1/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:

> Graham Charters wrote:
>
> > It would seem that the fine-grained/coarse-grained thoughts have
> > people divided.  Rajini's note (aside from the fact she has a tonne of
> > experience having done most, if not all, of the OSGi work in Tuscany)
> > paints a picture where the two are not mutually exclusive.  I don't
> > typically like doing two options because that seems like indecision,
> > but in this case they do appear to complement each other.
> >
> > Based on what I've seen in this thread, I'm hoping this briefly
> > summarizes the collection of thoughts on how we might proceed:
> >
> > Tuscany Running in OSGi
> >
> > 1.  Add bundle manifests to all the Tuscany modules (using maven
> > bundle plugin).  This will ensure the most fine-grained decomposition
> > works and therefore coarser-grained distributions will also work.
> > 2.  Add a distribution which creates bundles around manageable
> > collections of Tuscany modules aligned with how we see the runtime
> > being extended/subsetted/replaced.  Have this build and test on
> > Continuum.
> > 3.  Create 'virtual bundles' for third-party libraries to avoid
> > licensing and disk space issues (based on Rajini's suggestions, which
> > I need to better understand).
> > 4.  Provide guidance on the wiki on how to avoid breaking OSGi.
> >
> > There's also the suggestion that implementation.osgi relate to
> > Distributed OSGi (RFC 119), which shouldn't be lost.
> >
> > Have I missed anything?
> >
> > It sounds like a staging of 1 & 3 first, followed by 2 would work (and
> > 4 if things keep breaking :-( ).  I'd be concerned if we didn't get to
> > 2, and as part of 1&3, we need to make sure these are regularly tested
> > under osgi.
> >
> >
> Sounds good to me, with the following comments:
>
> When you have (1) + (3) you can already run a continuum OSGi build, before
> attacking (2). I'd actually suggest to start building on continuum as soon
> as we have (1).
>
> - I'm not clear on what you meant by 'use the Maven bundle plugin'. Will
> we write something like this for example:
> 
>  ...
>  bundle
>  ...
>  
>org.apache.felix
>maven-bundle-plugin
>true
>
>  
>org.apache.tuscany.sca.foo
>org.apache.tuscany.sca.bar
>org.apache.tuscany.sca.impl.*
>  
>
>  
> ...



I think we have four options on how we start bundle-izing Tuscany modules,
using maven-bundle-plugin.


1. Use the manifest goal to generate the manifest entry in all module jars,
with * and
*, which export all the packages from the
module and import everything used by the module. The Export-Package and
Import-Package statements in the generated manifest will use explicit
package import/exports like:

Import-Package:
javax.xml.namespace,javax.xml.parsers,org.apache.tuscany.sca.contribution.resolver,...
Export-Package:
org.apache.tuscany.sca.implementation.osgi;version="2.0";uses:="o.a.t.s.assembly",/...


The analysis of Import/Export will be done by the maven-bundle-plugin in
this case. The actual generation of the module jar will remain the same as
now, the only addition will be a new generated manifest file.

We might not use * , but instead it would
be something more like
org.apache.tuscany.sca.implementation.osgi.*,
where the packages are wildcarded, but no assumptions about modularity are
made.

2. Use bundle goal with Import/Export as above (generated by
maven-bundle-plugin rather than explicitly specified). In this case the jar
itself will be generated using maven-bundle-plugin. The output jar should be
identical to 1.

3. Use manifest goal with explicitly listed ,
 as in Sebastien's example. All exported and (maybe)
imported packages  are explicitly specified in the pom. Everytime a
new package is added, the pom should be updated.

4.  Use bundle goal with explicitly listed ,
 and  as in Sebastien's example. This
option corresponds to Sebastien's example. In this case both the contents of
the jar, as well as the manifest are based on the explicitly listed
packages.


1. is the easiest to implement. It makes no assumptions about modularity,
and will not have any impact on non-OSGi applications since only the
manifest entry is affected. From an OSGi point of view, this gives all we
need for osgi-tuscany.

2. does not add any value over 1.

3. This is a half-hearted attempt to enforce modularity. osgi-tuscany will
break everytime someone introduces a new package  and doesn't update the
pom. But Tuscany will continue to operate without OSGi since only the
manifest is broken. 3. is not a requirement for OSGi-based Tuscany, but
merely the use of OSGi technology to improve modularity. osgi-tuscany will
take on the role on policing modularity(apart from testing that Tuscany can
be run in an OSGi runtime).

4. This is OSGi best practice. If a new package is introduced and the pom is
not updated, the jar itself will be unusable. Basically this requires all
developers to be OSGi-aware. The

Re: [jira] Commented: (TUSCANY-2285) Make sca-api automatically build as an OSGi bundle

[Graham Charters]

Hi Raymond, I've modified the pom to follow the approach you
suggested.  I need to do a full Tuscany rebuild so will submit an
updated patch when I know it works.

I agree with Rajini that it would be good to understand the bundle
goal problem so we can fix it (or get it fixed).

Regards, Graham.

2008/5/2 Rajini Sivaram (JIRA) :
>
>
> [ 
> https://issues.apache.org/jira/browse/TUSCANY-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593731#action_12593731
>  ]
>
>  Rajini Sivaram commented on TUSCANY-2285:
>  -
>
>  Raymond,
>
>  Was the issue with maven-bundle-plugin and SDO related to building on JDK 
> 1.4 (which is not supported with Tuscany-SCA)? If not, could you describe the 
> problem and/or how to recreate it? We can use the manifest goal for sca-api, 
> but we may want to use bundle/bundleall goals to generate the high-level 
> combinations for distribution. I am sure the Felix team will help to fix the 
> problem if we can identify what the issue was.
>
>  Thank you...
>
>
>  > Make sca-api automatically build as an OSGi bundle
>  > --
>  >
>  > Key: TUSCANY-2285
>  > URL: https://issues.apache.org/jira/browse/TUSCANY-2285
>  > Project: Tuscany
>  >  Issue Type: Improvement
>  >  Components: Java SCA Core Runtime, Java SCA OSGi Integration
>  >Affects Versions: Java-SCA-Next
>  > Environment: All
>  >Reporter: Graham Charters
>  >Priority: Minor
>  > Fix For: Java-SCA-Next
>  >
>  > Attachments: sca-api-bundle.patch
>  >
>  >   Original Estimate: 0.5h
>  >  Remaining Estimate: 0.5h
>  >
>  > Itest/osgi-tuscany creates an OSGi bundle for the sca-api module.  As a 
> step towards providing better support for OSGi, it has been suggested on the 
> dev-list that we simply make sca-api automatically build as an OSGi bundle.  
> This does not preclude it being used as a normal jar.
>  > I have a patch which I will attached shortly.
>
>  --
>  This message is automatically generated by JIRA.
>  -
>  You can reply to this email to add a comment to the issue online.
>
>

Re: Improving support for running in OSGi

[Graham Charters]

Hi Rajini,

FWIW, I agree with starting with 1.  I missed your earlier note saying
you'd be happy to contribute code to do this.  Please let me know what
I can do to help.  I'm particularly interested in the 'virtual bundle'
idea.  I took a look at the way the samples are run in
itest/osgi-tuscany and now I have a better understanding, I agree,
it's not as much work as I first thought (fear of the unknown ;-) ).
I think the challenge will be in finding the right design to enable it
for third-party libraries so it's usable and flexible enough.  Perhaps
you already have thoughts on this?

I was a little surprised you didn't suggest 3 as a stepping stone
towards 4 (I guess the '"half-hearted" comment was a bit of a
give-away ;-) ).  I agree it's not ideal from a modularity perspective
but it does have the advantage that I think it could be introduced a
lot sooner than 4 and would therefore accelerate sensitizing folks to
the issues.

Regards, Graham.

2008/5/2 Rajini Sivaram <[EMAIL PROTECTED]>:
> On 5/1/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
>
>
> > Graham Charters wrote:
>  >
>  > > It would seem that the fine-grained/coarse-grained thoughts have
>  > > people divided.  Rajini's note (aside from the fact she has a tonne of
>  > > experience having done most, if not all, of the OSGi work in Tuscany)
>  > > paints a picture where the two are not mutually exclusive.  I don't
>  > > typically like doing two options because that seems like indecision,
>  > > but in this case they do appear to complement each other.
>  > >
>  > > Based on what I've seen in this thread, I'm hoping this briefly
>  > > summarizes the collection of thoughts on how we might proceed:
>  > >
>  > > Tuscany Running in OSGi
>  > >
>  > > 1.  Add bundle manifests to all the Tuscany modules (using maven
>  > > bundle plugin).  This will ensure the most fine-grained decomposition
>  > > works and therefore coarser-grained distributions will also work.
>  > > 2.  Add a distribution which creates bundles around manageable
>  > > collections of Tuscany modules aligned with how we see the runtime
>  > > being extended/subsetted/replaced.  Have this build and test on
>  > > Continuum.
>  > > 3.  Create 'virtual bundles' for third-party libraries to avoid
>  > > licensing and disk space issues (based on Rajini's suggestions, which
>  > > I need to better understand).
>  > > 4.  Provide guidance on the wiki on how to avoid breaking OSGi.
>  > >
>  > > There's also the suggestion that implementation.osgi relate to
>  > > Distributed OSGi (RFC 119), which shouldn't be lost.
>  > >
>  > > Have I missed anything?
>  > >
>  > > It sounds like a staging of 1 & 3 first, followed by 2 would work (and
>  > > 4 if things keep breaking :-( ).  I'd be concerned if we didn't get to
>  > > 2, and as part of 1&3, we need to make sure these are regularly tested
>  > > under osgi.
>  > >
>  > >
>  > Sounds good to me, with the following comments:
>  >
>  > When you have (1) + (3) you can already run a continuum OSGi build, before
>  > attacking (2). I'd actually suggest to start building on continuum as soon
>  > as we have (1).
>  >
>  > - I'm not clear on what you meant by 'use the Maven bundle plugin'. Will
>  > we write something like this for example:
>  > 
>  >  ...
>  >  bundle
>  >  ...
>  >  
>  >org.apache.felix
>  >maven-bundle-plugin
>  >true
>  >
>  >  
>  >org.apache.tuscany.sca.foo
>  >org.apache.tuscany.sca.bar
>  >org.apache.tuscany.sca.impl.*
>  >  
>  >
>  >  
>  > ...
>
>
>
>  I think we have four options on how we start bundle-izing Tuscany modules,
>  using maven-bundle-plugin.
>
>
>  1. Use the manifest goal to generate the manifest entry in all module jars,
>  with * and
>  *, which export all the packages from the
>  module and import everything used by the module. The Export-Package and
>  Import-Package statements in the generated manifest will use explicit
>  package import/exports like:
>
>  Import-Package:
>  
> javax.xml.namespace,javax.xml.parsers,org.apache.tuscany.sca.contribution.resolver,...
>  Export-Package:
>  
> org.apache.tuscany.sca.implementation.osgi;version="2.0";uses:="o.a.t.s.assembly",/...
>
>
>  The analysis of Import/Export will be done by the maven-bundle-plugin in
>  this case. The actual generation of the module jar will remain the same as
>  now, the only addition will be a new generated manifest file.
>
>  We might not use * , but instead it would
>  be something more like
>  
> org.apache.tuscany.sca.implementation.osgi.*,
>  where the packages are wildcarded, but no assumptions about modularity are
>  made.
>
>  2. Use bundle goal with Import/Export as above (generated by
>  maven-bundle-plugin rather than explicitly specified). In this case the jar
>  itself will be generated using maven-bundle-plugin. The output jar should be
>  identical to 1.
>
>  3. Use manifest goal with explicitly listed ,
>   as in Sebastien's example. All exported a

Re: How do you plug in validation monitoring?

[Ramkumar R]

Hi Simon,
While converting the error/warning messages over to the monitor using
TUSCANY-2277, i realized that it would be a tedious/not a practical job to
include monitor in all parts of the code.

For example, for converting the messages from all the ArtifactProcessor (for
which we have 74 instances), I feel it would not be a good idea to pass on
the monitor to each constructor and use them accordingly. Instead what we
can try is to catch the exception thrown by ArtifactProcessor and log them
into the monitor from the calling classes like ContributionServiceImpl
OR CompositeBuilderImpl
OR CompositeActivatorImpl.

Hope this would help. Please let me know your thoughts. Thanks.

-- 
Thanks & Regards,
Ramkumar Ramalingam

On 4/29/08, Ramkumar R <[EMAIL PROTECTED]> wrote:
>
> Hi Simon,
> Thanks for your detailed comments, that gives a clear picture. I have now
> opened a JIRA (TUSCANY-2277) to address this issue. By this defect we
> will standardize the way messages are logged into the monitor.
>
> Will keep things posted in this thread for any complicated situations and
> if i am not sure about any exceptions that are thrown.
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>
>  On 4/29/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, Apr 28, 2008 at 1:42 PM, Ramkumar R <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On 4/25/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On Thu, Apr 24, 2008 at 5:36 PM, Simon Laws <
> > [EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > 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
> > > > >

Re: [DAS] Are re ready for a DAS 1.0 release ?

[ant elder]

Sounds ok to me. The only thing I'd suggest is to depend on the SDO 1.1.1
release that should be out soon. If there's no sign of any imminent fixes
for the couple of issues raised I'll be pushing on with getting out that SDO
1.1.1 release next week.

   ...ant

On Thu, May 1, 2008 at 5:22 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> Looks like we now have a good and stable DAS that went trough two beta
> releases. If the community thinks we are ready, I'd like to propose a
> 1.0 release of DAS that would depend on the latest SDO 1.1 release.
>
> Thoughts ?
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>

Re: Improving support for running in OSGi

[ant elder]

On Thu, May 1, 2008 at 12:40 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:




> Here's what I imagined we'd do:
> 1. add OSGi entries to each of our JAR manifests
> 2. have developers maintain them and pay attention to imports/exports
> 3. use the OSGi build to detect API and SPI import/export violations
> 4. find the best way to OSGi-enable 3rd party dependency JARs
>
> I realize that my suggestion [1] is not very popular and most people on
> this list would prefer to come up with bigger bundles grouping several of
> our JARs/modules. I don't think that the 'bigger aggregate bundle' approach
> will work, but I'll be happy to watch people try it :) if they  want to.
>

Perfectly ok but would you say a bit more about why you don't think the
bigger aggregate bundle approach will work? I like the sound of less bundles
as it seems like it could be easier to use but if you know of issues it
would be nice to hear them now.

   ...ant

Re: How do you plug in validation monitoring?

[Simon Laws]

On Fri, May 2, 2008 at 11:46 AM, Ramkumar R <[EMAIL PROTECTED]> wrote:

> Hi Simon,
> While converting the error/warning messages over to the monitor using
> TUSCANY-2277, i realized that it would be a tedious/not a practical job to
> include monitor in all parts of the code.
>
> For example, for converting the messages from all the ArtifactProcessor
> (for
> which we have 74 instances), I feel it would not be a good idea to pass on
> the monitor to each constructor and use them accordingly. Instead what we
> can try is to catch the exception thrown by ArtifactProcessor and log them
> into the monitor from the calling classes like ContributionServiceImpl
> OR CompositeBuilderImpl
> OR CompositeActivatorImpl.
>
> Hope this would help. Please let me know your thoughts. Thanks.
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>
> On 4/29/08, Ramkumar R <[EMAIL PROTECTED]> wrote:
> >
> > Hi Simon,
> > Thanks for your detailed comments, that gives a clear picture. I have
> now
> > opened a JIRA (TUSCANY-2277) to address this issue. By this defect we
> > will standardize the way messages are logged into the monitor.
> >
> > Will keep things posted in this thread for any complicated situations
> and
> > if i am not sure about any exceptions that are thrown.
> >
> > --
> > Thanks & Regards,
> > Ramkumar Ramalingam
> >
> >  On 4/29/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >
> > > On Mon, Apr 28, 2008 at 1:42 PM, Ramkumar R <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > On 4/25/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > On Thu, Apr 24, 2008 at 5:36 PM, Simon Laws <
> > > [EMAIL PROTECTED]>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > 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,
> > > > > > > > > > > > > >
> > > > >

[jira] Updated: (TUSCANY-2285) Make sca-api automatically build as an OSGi bundle

[Graham Charters (JIRA)]

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

Graham Charters updated TUSCANY-2285:
-

Attachment: sca-api-bundle-2.patch

The following patch logically results in the same changes as the previous 
patch.  The key difference is it only uses maven bundle plugin to create the 
manifest and then uses maven jar plugin to build the jar file (previously maven 
bundle plugin was also being used to build the jar).

> Make sca-api automatically build as an OSGi bundle
> --
>
> Key: TUSCANY-2285
> URL: https://issues.apache.org/jira/browse/TUSCANY-2285
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Core Runtime, Java SCA OSGi Integration
>Affects Versions: Java-SCA-Next
> Environment: All
>Reporter: Graham Charters
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: sca-api-bundle-2.patch, sca-api-bundle.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> Itest/osgi-tuscany creates an OSGi bundle for the sca-api module.  As a step 
> towards providing better support for OSGi, it has been suggested on the 
> dev-list that we simply make sca-api automatically build as an OSGi bundle.  
> This does not preclude it being used as a normal jar.
> I have a patch which I will attached shortly.

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

Re: [jira] Updated: (TUSCANY-2220) WSDL representations of binding.ws generated incorrectly.

[Simon Nash]

This was fixed in 1.2.  I'm updating and resolving the JIRA.

  Simon

Simon Laws (JIRA) wrote:

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

Simon Laws updated TUSCANY-2220:


Fix Version/s: (was: Java-SCA-1.2)
   Java-SCA-Next

Move fix to SCA Next


WSDL representations of binding.ws generated incorrectly.
-

Key: TUSCANY-2220
URL: https://issues.apache.org/jira/browse/TUSCANY-2220
Project: Tuscany
 Issue Type: Bug
 Components: Java SCA Embedded Runtime
   Affects Versions: Java-SCA-1.2
Environment: Websphere 6.1.0.14 on AIX, jdk150_10
Jetty on Windows XP x86, jdk150_10
Websphere on Windows XP x86, jdk150_10
Tomcat on Windows XP x86. jdk150_10
   Reporter: Dave Sowerby
Fix For: Java-SCA-Next


WSDL representations of binding.ws generated incorrectly.
I'm currently facing issues when attmepting to utilise the wsdl
generated by a service exposed using binding.ws, when I use wsdl2java
with this wsdl I get the following exception:
IWAB0399E Error in generating Java from WSDL:  java.io.IOException:
Emitter failure.  Cannot find endpoint address in port
ServiceRequestPortType__SOAPHTTPPort in service
ServiceRequestPortType__ServiceLocator
   java.io.IOException: Emitter failure.  Cannot find endpoint
address in port ServiceRequestPortType__SOAPHTTPPort in service
ServiceRequestPortType__ServiceLocator
   at 
org.apache.axis.wsdl.toJava.JavaServiceImplWriter.writeFileBody(JavaServiceImplWriter.java:189)
   at org.apache.axis.wsdl.toJava.JavaWriter.generate(JavaWriter.java:127)
   at 
org.apache.axis.wsdl.toJava.JavaServiceWriter.generate(JavaServiceWriter.java:112)
   at 
org.apache.axis.wsdl.toJava.JavaGeneratorFactory$Writers.generate(JavaGeneratorFactory.java:421)
   at org.apache.axis.wsdl.gen.Parser.generate(Parser.java:476)
   at org.apache.axis.wsdl.gen.Parser.access$000(Parser.java:45)
   at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:362)
   at java.lang.Thread.run(Unknown Source)
I've diffed a previously functioning wsdl against the currently (RC3a)
generated wsdl file, the difference causing this problem appears to be
the additional lines of:
 
   
   
 
Which without an address is causing wsdl2java to fail.

[jira] Resolved: (TUSCANY-2220) WSDL representations of binding.ws generated incorrectly.

[Simon Nash (JIRA)]

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

Simon Nash resolved TUSCANY-2220.
-

   Resolution: Fixed
Fix Version/s: (was: Java-SCA-Next)
   Java-SCA-1.2

Fixed in SCA Java 1.2 rc4.

> WSDL representations of binding.ws generated incorrectly.
> -
>
> Key: TUSCANY-2220
> URL: https://issues.apache.org/jira/browse/TUSCANY-2220
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Embedded Runtime
>Affects Versions: Java-SCA-1.2
> Environment: Websphere 6.1.0.14 on AIX, jdk150_10
> Jetty on Windows XP x86, jdk150_10
> Websphere on Windows XP x86, jdk150_10
> Tomcat on Windows XP x86. jdk150_10
>Reporter: Dave Sowerby
> Fix For: Java-SCA-1.2
>
>
> WSDL representations of binding.ws generated incorrectly.
> I'm currently facing issues when attmepting to utilise the wsdl
> generated by a service exposed using binding.ws, when I use wsdl2java
> with this wsdl I get the following exception:
> IWAB0399E Error in generating Java from WSDL:  java.io.IOException:
> Emitter failure.  Cannot find endpoint address in port
> ServiceRequestPortType__SOAPHTTPPort in service
> ServiceRequestPortType__ServiceLocator
>java.io.IOException: Emitter failure.  Cannot find endpoint
> address in port ServiceRequestPortType__SOAPHTTPPort in service
> ServiceRequestPortType__ServiceLocator
>at 
> org.apache.axis.wsdl.toJava.JavaServiceImplWriter.writeFileBody(JavaServiceImplWriter.java:189)
>at org.apache.axis.wsdl.toJava.JavaWriter.generate(JavaWriter.java:127)
>at 
> org.apache.axis.wsdl.toJava.JavaServiceWriter.generate(JavaServiceWriter.java:112)
>at 
> org.apache.axis.wsdl.toJava.JavaGeneratorFactory$Writers.generate(JavaGeneratorFactory.java:421)
>at org.apache.axis.wsdl.gen.Parser.generate(Parser.java:476)
>at org.apache.axis.wsdl.gen.Parser.access$000(Parser.java:45)
>at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:362)
>at java.lang.Thread.run(Unknown Source)
> I've diffed a previously functioning wsdl against the currently (RC3a)
> generated wsdl file, the difference causing this problem appears to be
> the additional lines of:
>  
> binding="ns2:ServiceRequestPortType__SOAPBinding">
>
>  
> Which without an address is causing wsdl2java to fail.

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

Re: Improving support for running in OSGi

[Rajini Sivaram]

On 5/2/08, Graham Charters <[EMAIL PROTECTED]> wrote:
>
> Hi Rajini,
>
> FWIW, I agree with starting with 1.  I missed your earlier note saying
> you'd be happy to contribute code to do this.  Please let me know what
> I can do to help.  I'm particularly interested in the 'virtual bundle'
> idea.  I took a look at the way the samples are run in
> itest/osgi-tuscany and now I have a better understanding, I agree,
> it's not as much work as I first thought (fear of the unknown ;-) ).
> I think the challenge will be in finding the right design to enable it
> for third-party libraries so it's usable and flexible enough.  Perhaps
> you already have thoughts on this?



I thought it would be very unfair of me to suggest that this is not a very
big task, when you were the one who had to go and implement it. But now that
you agree that it is not too much work, can I change my mind? Seriously
though, I could help with getting something up and running quickly, and you
could take over from there (I will continue to help if you run into
problems).

Let me take a look this weekend and see if I can get a quick build with OSGi
manifest entries for the modules. There are some modules which require
additional options like Require-Bundle for the split packages. Since I have
done this once before (even though that was with different plugins) for
running Tuscany using OBR, it may be quicker for me to add these (and you
can refine them later). I will also try to update osgi-tuscany to use these
with some basic support for virtual 3rd party bundles copied over from the
existing code and see if they run into any problems. You could then take
over and drive it forward, initially fine tuning the OSGi support
(finalizing the design for 3rd party libs as well as reducing disk space for
tests, getting them to run on Continuum etc) followed by improving
modularity. I suspect modularity requires a lot more discussion since it
affects everyone. You might want to start a new thread on the mailing list
without including "OSGi" in
the subject :-).

I was a little surprised you didn't suggest 3 as a stepping stone
> towards 4 (I guess the '"half-hearted" comment was a bit of a
> give-away ;-) ).  I agree it's not ideal from a modularity perspective
> but it does have the advantage that I think it could be introduced a
> lot sooner than 4 and would therefore accelerate sensitizing folks to
> the issues.



My problem with option 3. is purely psychological. It seems rather strange
to have centralized control of modularity :-). And paranoia - who is going
to maintain a continually breaking itest/osgi-tuscany? Probably you,
still...

I do completely agree that 3. will help us get there faster. But it could
reduce the motivation for 4, and throw away the opportunity to involve the
entire Tuscany community to drive the improvements in modularity.

There was a purpose to writing itest/osgi-tuscany - and that was to ensure
that Tuscany could run inside an OSGi runtime. It already has the
responsibility to test classloader usage in Tuscany, other issues like URL
handling, which used to break under OSGi, and OSGi-specific problems in
Tuscany. It might collapse under pressure if also burdened with defining and
maintaining Tuscany modularity.

But honestly, I think you should choose whichever path makes it easiest for
you to drive the modularity work.


Regards, Graham.



2008/5/2 Rajini Sivaram <[EMAIL PROTECTED]>:
> > On 5/1/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > > Graham Charters wrote:
> >  >
> >  > > It would seem that the fine-grained/coarse-grained thoughts have
> >  > > people divided.  Rajini's note (aside from the fact she has a tonne
> of
> >  > > experience having done most, if not all, of the OSGi work in
> Tuscany)
> >  > > paints a picture where the two are not mutually exclusive.  I don't
> >  > > typically like doing two options because that seems like
> indecision,
> >  > > but in this case they do appear to complement each other.
> >  > >
> >  > > Based on what I've seen in this thread, I'm hoping this briefly
> >  > > summarizes the collection of thoughts on how we might proceed:
> >  > >
> >  > > Tuscany Running in OSGi
> >  > >
> >  > > 1.  Add bundle manifests to all the Tuscany modules (using maven
> >  > > bundle plugin).  This will ensure the most fine-grained
> decomposition
> >  > > works and therefore coarser-grained distributions will also work.
> >  > > 2.  Add a distribution which creates bundles around manageable
> >  > > collections of Tuscany modules aligned with how we see the runtime
> >  > > being extended/subsetted/replaced.  Have this build and test on
> >  > > Continuum.
> >  > > 3.  Create 'virtual bundles' for third-party libraries to avoid
> >  > > licensing and disk space issues (based on Rajini's suggestions,
> which
> >  > > I need to better understand).
> >  > > 4.  Provide guidance on the wiki on how to avoid breaking OSGi.
> >  > >
> >  > > There's also the suggestion tha

More Java security fixes on the way

[Dan Becker]

FYI, so every one is aware of recent Tuscany security changes and for 
your comments. Over the last few weeks I have been making fixes to the 
Tuscany core in order to make the code a bit safer with Java 2 security 
enabled. There are many instances in which we want Tuscany code to 
perform some privileged action (such as read a system property or write 
a file to the file system), yet we do not want client code to have this 
ability.


There are over 300 Tuscany calls to privileged Java APIs which may throw 
some sort of security exception if proper access is not granted. Since 
there are so many APIs, I have have been issuing patches in smaller 
increments. This makes the patch easier to review, commit, and reverse 
if there is a problem.


Following is a list of past changes related to security.
TUSCANY-2108 - Enabled Simple Calculator to run with security on
TUSCANY-2227 - Enabled ITests to run with secuirty on
TUSCANY-2030 - Enabled Simple Caclulator to run on WebSphere

Expect a few JIRAs in the next weeks to enable the demos, samples, and 
vtests to run with security on. And then I would like to make a maven 
profile that allows a user to test with security on or off.


If you have any other ideas related to Java 2 security, I encourage you 
to mention them here.


--
Thanks, Dan Becker

Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object

[Jean-Sebastien Delfino]

Simon Laws wrote:

Was just looking at the checkin. Thanks for making the fix. Now we don't
generate invalid composite files when they get written out.

Re. the second part dealing with URIs. It looks to me like this is picking
up the case where the URI has been specified as the name of the target
service. A feature which the spec call for. I have to admit that I can't
recall a test for this now you mention it but are you saying this used to
work at some point. I'd be a little surprised if we hadn't implemented that.
But maybe I'm wrong.


My understanding is that the implementation was missing and there was no 
test for it :)




Anyhow if this code is doing what I think it's doing then maybe we should
move it to be a little earlier in the process and more general than the sca
binding. We could take the checking code you have here and put it a little
higher up where the reference targets are identified. If you are able to
check a test in the I could have a look at this if you like.



OK, I'll post here as soon as the test is in. Thanks.


Simon




--
Jean-Sebastien

Re: Some questions for workspace module in Tuscany

[Jean-Sebastien Delfino]

Jean-Sebastien Delfino wrote:

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.




Looking at these init methods, a lot of the setup code is about setting 
up XML and document artifact processors, which we shouldn't have to 
write if all the necessary processors were correctly registered under 
META-INF/services.


I noticed that some of the base processors (CompositeProcessor, 
ComponentTypeProcessor, ConstrainingType etc) are missing from 
META-INF/services so I'm going to try to fix that and register them 
dynamically like all the other ones.


That should help simplify that setup code.

--
Jean-Sebastien

[jira] Updated: (TUSCANY-2286) Add vtest for @Init annotation

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated TUSCANY-2286:
-

Attachment: TUSCANY-2286-3.patch

TUSCANY-2286-3.patch: I have added the javadoc comments for each of the test 
methods.  Please ignore the other two patches.

> Add vtest for @Init annotation
> --
>
> Key: TUSCANY-2286
> URL: https://issues.apache.org/jira/browse/TUSCANY-2286
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2286-2.patch, TUSCANY-2286-3.patch, 
> TUSCANY-2286.patch
>
>
> Add verification tests for @Init annotation.
> Java Common Annotations and APIs v1.00 - Section 1.8.11 - Lines 1290 to 1293:
> 1290 The @Init annotation type is used to annotate a Java class method that 
> is called when the scope defined for
> 1291 the local service implemented by the class starts. The method must have 
> a void return value and no
> 1292 arguments. The annotated method must be public. The annotated method is 
> called after all property and
> 1293 reference injection is complete.

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

Re: How do you plug in validation monitoring?

[Jean-Sebastien Delfino]

Simon Laws wrote:


Depending where you actually catch the exception you should be able to
continue on and process the next artifact.



Hmmm, the idea with monitors is to allow the processing code to report 
warnings and continue or multiple errors per artifact for example.


Not sure about how it'll work with exceptions?
--
Jean-Sebastien

[jira] Updated: (TUSCANY-2287) Add vtest for @Destroy annotation

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated TUSCANY-2287:
-

Attachment: TUSCANY-2287-2.patch

TUSCANY-2287-2.patch:  Added javadoc comments to each of the test methods.  
Please ignore the other patch.

> Add vtest for @Destroy annotation
> -
>
> Key: TUSCANY-2287
> URL: https://issues.apache.org/jira/browse/TUSCANY-2287
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2287-2.patch, TUSCANY-2287.patch
>
>
> Add verification tests for @Destroy annotation.
> Java Common Annotations and APIs v1.00 - Sec 1.8.8 - Lines 1225 to 1227:
> 1225 The @Destroy annotation type is used to annotate a Java class method 
> that will be called when the scope
> 1226 defined for the local service implemented by the class ends. The method 
> must have a void return value and
> 1227 no arguments. The annotated method must be public

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

Re: How do you plug in validation monitoring?

[Simon Laws]

On Fri, May 2, 2008 at 4:23 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:

> Simon Laws wrote:
>
> >
> > Depending where you actually catch the exception you should be able to
> > continue on and process the next artifact.
> >
> >
> Hmmm, the idea with monitors is to allow the processing code to report
> warnings and continue or multiple errors per artifact for example.
>
> Not sure about how it'll work with exceptions?
> --
> Jean-Sebastien
>

Ok,  well we could push the problem generation right down into the
processors. There are quite a lot of specific exceptions down there. Does
anything depend on these or can we just remove them.

Simon

[jira] Commented: (TUSCANY-2285) Make sca-api automatically build as an OSGi bundle

[Raymond Feng (JIRA)]

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

Raymond Feng commented on TUSCANY-2285:
---

To respond on Rajini's comment, the problem we had with maven-bundle-plugin in 
sd-api happened with JDK 1.4.

> Make sca-api automatically build as an OSGi bundle
> --
>
> Key: TUSCANY-2285
> URL: https://issues.apache.org/jira/browse/TUSCANY-2285
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Core Runtime, Java SCA OSGi Integration
>Affects Versions: Java-SCA-Next
> Environment: All
>Reporter: Graham Charters
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: sca-api-bundle-2.patch, sca-api-bundle.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> Itest/osgi-tuscany creates an OSGi bundle for the sca-api module.  As a step 
> towards providing better support for OSGi, it has been suggested on the 
> dev-list that we simply make sca-api automatically build as an OSGi bundle.  
> This does not preclude it being used as a normal jar.
> I have a patch which I will attached shortly.

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

User guide revamp

[Simon Laws]

While Subversion has been down I've made a start upgrading the user guide to
make it a little more coherent and bring it up to date a little. Big changes
so far are that I've moved the command line walk through out into a separate
guide and I've started replacing some out of date material in the user guide
itself.

I'm making a stab at keeping a single guide relevant to all recent releases.
I think it's useful to explain, for example, why we have host.embedded and
node implementations in one place but I welcome thoughts on that. I'm not
done with the edits yet by a long way but I've run out of time today and
wanted to point out I've started in case people wonder why things are
changing or, more importantly, feel like helping ;-)

Regards

Simon

[jira] Updated: (TUSCANY-2288) MappingWrapper.getInsertOrder() uses incorrect algorithm

[Florian Pinel (JIRA)]

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

Florian Pinel updated TUSCANY-2288:
---

Attachment: MappingWrapper.java

Attached is a suggested fix.

> MappingWrapper.getInsertOrder() uses incorrect algorithm
> 
>
> Key: TUSCANY-2288
> URL: https://issues.apache.org/jira/browse/TUSCANY-2288
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Florian Pinel
>Priority: Critical
> Attachments: MappingWrapper.java
>
>
> MappingWrapper.getInsertOrder() uses an incorrect algorithm:
> while (parents.size() > 0) {
> String parent = (String) parents.get(0);
> if (!children.contains(parent)) {
> if (!inserts.contains(parent)) {
> inserts.add(parent);
> }
> String child = (String) parentToChild.get(parent);
> if (!inserts.contains(child)) {
> inserts.add(child);
> }
> parents.remove(parent);
> children.remove(child);
> } else {
> parents.add(parents.remove(0));
> }
> The following line causes a bug:
> String child = (String) parentToChild.get(parent);
> A parent can have multiple children, and this line will not return the 
> correct child.
> The bug will become visible if you try a data object with 1 parent, 2 
> children and 1 grandchild.

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

Tuscany support an usage of binding.ws wsdl.service

[Lou Amodeo]

I am reading the WS Binding Specification and am trying to understand the
meaning of the wsdl.service form of the WSDL Element's URI and to what
extent and how it is supported in Tuscany?   Thanks for your help.

Service:

39 #wsdl.service()

40 In this case, all the endpoints in the WSDL Service that have equivalent
PortTypes with

41 the SCA service or reference must be available to the SCA service or
reference.

[jira] Created: (TUSCANY-2290) Java 2 Security enablement for Tuscany sample (part 1)

[Dan Becker (JIRA)]

Java 2 Security enablement for Tuscany sample (part 1)
--

 Key: TUSCANY-2290
 URL: https://issues.apache.org/jira/browse/TUSCANY-2290
 Project: Tuscany
  Issue Type: Bug
Affects Versions: Java-SCA-1.2
 Environment: Windows, Java 1.5
Reporter: Dan Becker
 Fix For: Java-SCA-Next
 Attachments: TUSCANY-2290.patch

Fix security issues that arise in Tuscany samples when Java 2 security is 
turned on via 
-java.security.manager  -Djava.security.policy=tuscany.policy 
-Dpolicy.allowSystemProperty=true

A typical exception might be for sample helloworld sdo ws 
Problems trying to access System properties: 
java.security.AccessControlException: access denied 
(java.util.PropertyPermission java.specification.version read)
java.lang.NoClassDefFoundError
at 
org.apache.tuscany.sca.databinding.sdo.SDODataBinding.introspect(SDODataBinding.java:61)
at 
org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.introspect(DefaultDataBindingExtensionPoint.java:191)
at 
org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:246)
at 
org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:202)
at 
org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.processInterface(DataBindingJavaInterfaceProcessor.java:116)
at 
org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.visitInterface(DataBindingJavaInterfaceProcessor.java:58)
at 
org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:113)
at 
org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:48)
at 
org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.createService(ServiceProcessor.java:159)
at 
org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitClass(ServiceProcessor.java:90)
at 
org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:72)
at 
org.apache.tuscany.sca.implementation.java.impl.JavaImplementationFactoryImpl.createJavaImplementation(JavaImplementationFactoryImpl.java:53)
at 
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:152)
at 
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:63)
...

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

[jira] Updated: (TUSCANY-2290) Java 2 Security enablement for Tuscany sample (part 1)

[Dan Becker (JIRA)]

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

Dan Becker updated TUSCANY-2290:


Attachment: TUSCANY-2290.patch

Please let me know if there are improvements to  be made to the patch or 
comments.

> Java 2 Security enablement for Tuscany sample (part 1)
> --
>
> Key: TUSCANY-2290
> URL: https://issues.apache.org/jira/browse/TUSCANY-2290
> Project: Tuscany
>  Issue Type: Bug
>Affects Versions: Java-SCA-1.2
> Environment: Windows, Java 1.5
>Reporter: Dan Becker
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2290.patch
>
>
> Fix security issues that arise in Tuscany samples when Java 2 security is 
> turned on via 
> -java.security.manager  -Djava.security.policy=tuscany.policy 
> -Dpolicy.allowSystemProperty=true
> A typical exception might be for sample helloworld sdo ws 
> Problems trying to access System properties: 
> java.security.AccessControlException: access denied 
> (java.util.PropertyPermission java.specification.version read)
> java.lang.NoClassDefFoundError
>   at 
> org.apache.tuscany.sca.databinding.sdo.SDODataBinding.introspect(SDODataBinding.java:61)
>   at 
> org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.introspect(DefaultDataBindingExtensionPoint.java:191)
>   at 
> org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:246)
>   at 
> org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:202)
>   at 
> org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.processInterface(DataBindingJavaInterfaceProcessor.java:116)
>   at 
> org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.visitInterface(DataBindingJavaInterfaceProcessor.java:58)
>   at 
> org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:113)
>   at 
> org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:48)
>   at 
> org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.createService(ServiceProcessor.java:159)
>   at 
> org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitClass(ServiceProcessor.java:90)
>   at 
> org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:72)
>   at 
> org.apache.tuscany.sca.implementation.java.impl.JavaImplementationFactoryImpl.createJavaImplementation(JavaImplementationFactoryImpl.java:53)
>   at 
> org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:152)
>   at 
> org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:63)
> ...

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

[jira] Resolved: (TUSCANY-2288) MappingWrapper.getInsertOrder() uses incorrect algorithm

[Luciano Resende (JIRA)]

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

Luciano Resende resolved TUSCANY-2288.
--

   Resolution: Fixed
Fix Version/s: Java-SCA-Next
 Assignee: Luciano Resende

Patch from Florian Pinel applied under revision #652897

> MappingWrapper.getInsertOrder() uses incorrect algorithm
> 
>
> Key: TUSCANY-2288
> URL: https://issues.apache.org/jira/browse/TUSCANY-2288
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Florian Pinel
>Assignee: Luciano Resende
>Priority: Critical
> Fix For: Java-SCA-Next
>
> Attachments: MappingWrapper.java
>
>
> MappingWrapper.getInsertOrder() uses an incorrect algorithm:
> while (parents.size() > 0) {
> String parent = (String) parents.get(0);
> if (!children.contains(parent)) {
> if (!inserts.contains(parent)) {
> inserts.add(parent);
> }
> String child = (String) parentToChild.get(parent);
> if (!inserts.contains(child)) {
> inserts.add(child);
> }
> parents.remove(parent);
> children.remove(child);
> } else {
> parents.add(parents.remove(0));
> }
> The following line causes a bug:
> String child = (String) parentToChild.get(parent);
> A parent can have multiple children, and this line will not return the 
> correct child.
> The bug will become visible if you try a data object with 1 parent, 2 
> children and 1 grandchild.

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

GSoC Project - Allow Google Android applications to easily consume business services

[Oscar Castaneda]

Hi,

Today I continued working on getting familiar with Apache Tuscany. I went
through the first couple of getting started guides and posted a brief update
on the project wiki page [1]. I plan to do this most every day if possible
to give everyone a snapshot summary. Comments are welcomed and appreciated.

[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Allow+Google+Android+applications+to+easily+consume+business+services

-- 
best,
-oscar

Oscar Castañeda

Re: GSoC Project - Allow Google Android applications to easily consume business services

[Adriano Crestani]

So, lets make the conversation public:

===>
Hi Oscar,

I noticed that an Android developer suggested to use retrotranslator[1] as a
workaround to the reported issue[2] on annotations. Have you tried that?
What are your thoughts? Hopefully, they will release the new SDK soon.
Otherwise the lightweight SCA core/runtime will be the solution until they
do.

The retrotranslator would be a solution, but I never tried it. I think it
really would be an workaround for the annotations problem, however I would
recommend this kind of workaround if there would be no plans for Android to
support annotations. But as the Android devs are telling the next version
will support annotations, I think we should wait. If they postpone too much
the release of next version, what I think they won't do, we can try this
workaround ; )

Your eclipse workspace will be really useful to see the adaptations you made
to SCA code to run on Android. Where will you upload it to? From that I will
try to find out why the projects are so coupled and hopefully a way to
disentangle or reduce dependencies. I'll rely on your kind help and that of
the Tuscany community as we discussed previously.

Sorry for the delay, it was holyday here at brazil yesterday, so I had no
time to organize my workspace to upload. But I expect to upload it till the
end of day. I will upload it on the Tuscany sandbox, I will send you the url
when I get the code uploaded.

I've been looking for more reference info about Android. Up to now the best
references I've found are the Android webpage and mailing lists. Do you know
of more sources? I bought the attached "Hello, Android" book earlier today
but unfortunately the interesting information has not yet been added.
Hopefully, the author will add new content soon.

Good work : ). There are no many references about Android on net really. You
will really find most of information on mailing lists or forums. This book
is not so much helpful to solve our actual problems, but it can be used for
references and etc ; )

Finally, I created a project wiki page [3] to keep track of my progress.

Good initiative. Keep it updated, though the Tuscany community will be able
to track your progress ; )

<===

Regards,
Adriano Crestani


On Thu, May 1, 2008 at 10:06 AM, Oscar Castaneda <[EMAIL PROTECTED]>
wrote:

> Hi Luciano,
> I agree. I've posted my reply to Adriano below.
>
> ===>
> Hi Adriano,
> Thank you very much for keeping me in mind :-)
>
> I think you're right that I should start working on the project. This
> Tuesday my submission to perform research based on this project for one of
> my CS courses was approved, so also there I need to provide results soon.
> Luckily, I have a teammate helping me. So, today I officially started.
> First
> I read all your posts on the Android Developers list. I could see right
> away
> posts related to annotations, conversion of jar's and your efforts to run
> Tuscany/SCA in Android. I also read the post about waiting for the next
> SDK.
>
> I noticed that an Android developer suggested to use retrotranslator[1] as
> a
> workaround to the reported issue[2] on annotations. Have you tried that?
> What are your thoughts? Hopefully, they will release the new SDK soon.
> Otherwise the lightweight SCA core/runtime will be the solution until they
> do.
>
> Your eclipse workspace will be really useful to see the adaptations you
> made
> to SCA code to run on Android. Where will you upload it to? From that I
> will
> try to find out why the projects are so coupled and hopefully a way to
> disentangle or reduce dependencies. I'll rely on your kind help and that
> of
> the Tuscany community as we discussed previously.
>
> I've been looking for more reference info about Android. Up to now the
> best
> references I've found are the Android webpage and mailing lists. Do you
> know
> of more sources? I bought the "Hello, Android" book earlier today but
> unfortunately the interesting information has not yet been added.
> Hopefully,
> the author will add new content soon.
>
> Finally, I created a project wiki page [3] to keep track of my progress.
>
> [1] http://retrotranslator.sourceforge.net/#android
> [2] http://code.google.com/p/android/issues/detail?id=29
> [3]
>
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Allow+Google+Android+applications+to+easily+consume+business+services
>
> best,
> -oscar
> <===
>
> best,
> -oscar
>
> Oscar Castañeda
>
> On Thu, May 1, 2008 at 7:43 PM, Luciano Resende <[EMAIL PROTECTED]>
> wrote:
>
> > Thanks, Let's try to keep project related discussions happening on the
> > dev mailing list, as others on the community might be interested, and
> > I certainly am.
> >
> > On Thu, May 1, 2008 at 10:34 AM, Raymond Feng <[EMAIL PROTECTED]>
> wrote:
> > > Hi,
> > >
> > >  To be consistent, I moved it under "Google Summer of Code (2008)"
> page.
> > The
> > > URL stays the same:
> > >
> > >
> > >
> > >
> >
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Allow+Google+An

Re: Some questions for workspace module in Tuscany

[Jean-Sebastien Delfino]

Jean-Sebastien Delfino wrote:

Jean-Sebastien Delfino wrote:

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.




Looking at these init methods, a lot of the setup code is about setting 
up XML and document artifact processors, which we shouldn't have to 
write if all the necessary processors were correctly registered under 
META-INF/services.


I noticed that some of the base processors (CompositeProcessor, 
ComponentTypeProcessor, ConstrainingType etc) are missing from 
META-INF/services so I'm going to try to fix that and register them 
dynamically like all the other ones.


That should help simplify that setup code.



I've done a first pass through all the artifact processors and declared 
them under META-INF/services. I had to make minor changes or add the 
expected constructors to some of them to follow the pattern that was 
already in place to support lazy / automatic loading and initialization.


The following methods:
StAXArtifactProcessorExtensionPoint.getProcessor(modelClass)
StAXArtifactProcessorExtensionPoint.getProcessor(qname)
URLArtifactProcessorExtensionPoint.getProcess(modelClass)
URLArtifactProcessorExtensionPoint.getProcess(artifactType)
should now work for all artifact processors, hoping that I didn't miss any.

With these changes I was able to simplify the bootstrapping code, as it 
doesn't need to create all these artifact processors manually anymore.


It was a little tedious but I also went through most artifact processor 
unit test cases and was able to simplify their setup method as well.


I'll try to go through the remaining test cases and samples in the next 
day or two.

--
Jean-Sebastien

Re: GSoC Project - Allow Google Android applications to easily consume business services

[Adriano Crestani]

Great, it will be easier for the community to track your progress and help
me to mentor you : )

Just let us know if you have any doubts about the stuffs you have been
reading ; )

Regards,
Adriano Crestani

On Fri, May 2, 2008 at 3:31 PM, Oscar Castaneda <
[EMAIL PROTECTED]> wrote:

> Hi,
>
> Today I continued working on getting familiar with Apache Tuscany. I went
> through the first couple of getting started guides and posted a brief
> update
> on the project wiki page [1]. I plan to do this most every day if possible
> to give everyone a snapshot summary. Comments are welcomed and
> appreciated.
>
> [1]
>
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Allow+Google+Android+applications+to+easily+consume+business+services
>
> --
> best,
> -oscar
>
> Oscar Castañeda
>