[DAS] What's next for Tuscany DAS?

[Amita Vadhavkar]

Hi,
Thinking about RDB DAS Next release, there can be different
interesting features to add like -

1- Integration with SCA policy and transaction support
2- Data Services (following DAS Specification investigations/directions)
3- DAS & WebServices
4- DAS integration with JPA (Fluid)
5 - XML Types and deeper integration with XML Databases
6- Data Feeds
7- Support for non-SDO types

It will be great to add more to this list, provide pointers to some
user requirements that may have come up in the past.

There is some discussion -
for 1- in 
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Design+Discussion
and 3- in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25701.html

Please pour your thoughts there and also start new ML threads for any
other topics.

We can use the current thread as a place to consolidate what items get
prioritized for the next release
and what major features are added to RDB DAS as a result.

Appreciate your comments.

Regards,
Amita

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

Re: [VOTE] Please approve Tuscany SCA Java 1.0.1-incubating release

[Raymond Feng]

Hi, Kevan.

Thank you for the review. We have fixed the issue and republished a RC5a at:

SVN Tag:
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0.1-RC5a/

Stage maven repo: http://people.apache.org/~rfeng/tuscany/maven/1.0.1-RC5a

RAT report:
http://people.apache.org/~rfeng/tuscany/1.0.1-RC5a/1.0.1-RC5a.rat.txt

Binary and source distros (zip/gz/asc/md5) :
http://people.apache.org/~rfeng/tuscany/1.0.1-RC5a/

Since the fix doesn't involve any 'code' changes, can we skip the 
tuscany-dev vote and continue the IPMC vote here? Please advise.


Thanks,
Raymond

- Original Message - 
From: "Kevan Miller" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Sent: Thursday, November 15, 2007 2:28 PM
Subject: Re: [VOTE] Please approve Tuscany SCA Java 1.0.1-incubating release



Hi Raymond,
There are several tuscany jar files which are missing LICENSE, NOTICE,
and DISCLAIMER files. For example tuscany-implementation-xquery-1.0.1-
incubating.jar As they will be released to a maven repo, they must be
updated to contain these files.

Everything else looked good to me.

Here's my -1 until all of your jar files contain the appropriate files.

--kevan

On Nov 12, 2007, at 1:12 AM, Raymond Feng wrote:


Hi,

The Tuscany project had a vote on tuscany-dev@ws.apache.org to
publish the Tuscany SCA Java 1.0.1-incubating release. The vote
thread on tuscany-dev has 7 +1s and the archive can be found at:

http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200711.mbox/[EMAIL 
PROTECTED]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200711.mbox/thread?2

The release is mostly a bug-fix release on top of the 1.0-incubating
release. You can see a list of changes at:
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0.1-RC5/distribution/src/main/release/CHANGES

The signed binary and source distributions, the RAT reports, and the
Maven staging repository are listed at the following links.

SVN Tag: 
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0.1-RC5/


Stage maven repo: http://people.apache.org/~rfeng/tuscany/maven/

RAT report: 
http://people.apache.org/~rfeng/tuscany/1.0.1-RC5/1.0.1-RC5.rat.txt


Binary and source distros (zip/gz/asc/md5) : 
http://people.apache.org/~rfeng/tuscany/1.0.1-RC5/


Please review and approve the release. This vote will remain open
for at least 72 hours.

Thanks,
Raymond


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







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

Re: Change the syntax for qname in META-INF/services/org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor

[Raymond Feng]

The spec case is slightly different as the syntax is 
namespace#wsdl.xxx(...). We know the # before wsdl.xxx(...) is the 
delimiter.


Thanks,
Raymond

- Original Message - 
From: "Simon Laws" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, November 15, 2007 10:17 AM
Subject: Re: Change the syntax for qname in 
META-INF/services/org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor




On Nov 15, 2007 5:38 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

The StAXArtifactProcessor extension point currently uses the
"namespace#localPart" syntax for the qname attribute in the service
registration file

(META-INF/services/org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor).

I propose that we change the syntax to be "{namespace}localPart" for two
reasons:

1) {namespace}localPart is the format produced by QName.toString()
2) # is valid character for namespace, using # as the delimiter could 
lead

to conflict.

If there is no objections, I will make the changes.

Thanks,
Raymond


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

Hi Raymond


Isn't there a problem then with wsdlElement="
http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort)"?

Simon




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

Re: Sample dependencies not pulled in distribution

[Simon Nash]

Jean-Sebastien Delfino wrote:


ant elder wrote:


On Nov 14, 2007 9:11 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:

 


Luciano Resende wrote:
   


Try removing the test scope from derby dependency on the
implementation-data pom.

  


Did that and it works around the problem, but it's a workaround :)





Why is doing this in the implementation-data pom.xml a work around?


Having a dependency on derby in implementation-data would be like having 
a direct dependency on tomcat in binding-ws-axis2. It'll bring derby in 
even if I've decided to use implementation-data with another database.



If
implementation-data needs derby to be used then whats wrong with defining
that as a dependency?


implementation-data doesn't require derby, you should be able to use it 
with another database.



Thats like we do with wstx isn't it, there are other
stax impls available but we still explictly define the wstx one.
  


Is that a good thing? :) I don't think so.

Alternatively, and to answer the initial question, if its just wanted 
that

derby gets included in the bin distro lib folder then that can be done by
adding the dependency to distribution/pom.xml.
  


Ah, this is what I was looking for! Great, I'll try that. Thanks.


I don't think we should put sample dependencies in the bin distro lib
folder.  If we need to include them in the bin distro (and I'm not 100%
convinced about that), then I think they should go in some other directory.

An alternative approach would be to have a samples distro that contains
the samples plus dependencies that are only used by the samples and not
by the main runtime.  I think this is better as it allows us to add more
samples without pushing up the size of the main binary distro.

  Simon



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

Re: Sample dependencies not pulled in distribution

[Simon Laws]

On Nov 15, 2007 6:54 PM, Simon Nash <[EMAIL PROTECTED]> wrote:

>
> Jean-Sebastien Delfino wrote:
>
> > ant elder wrote:
> >
> >> On Nov 14, 2007 9:11 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED] >
> >> wrote:
> >>
> >>
> >>
> >>> Luciano Resende wrote:
> >>>
> >>>
>  Try removing the test scope from derby dependency on the
>  implementation-data pom.
> 
> 
> >>>
> >>> Did that and it works around the problem, but it's a workaround :)
> >>>
> >>>
> >>>
> >>
> >> Why is doing this in the implementation-data pom.xml a work around?
> >
> > Having a dependency on derby in implementation-data would be like having
> > a direct dependency on tomcat in binding-ws-axis2. It'll bring derby in
> > even if I've decided to use implementation-data with another database.
> >
> >> If
> >> implementation-data needs derby to be used then whats wrong with
> defining
> >> that as a dependency?
> >
> > implementation-data doesn't require derby, you should be able to use it
> > with another database.
> >
> >> Thats like we do with wstx isn't it, there are other
> >> stax impls available but we still explictly define the wstx one.
> >>
> >
> > Is that a good thing? :) I don't think so.
> >
> >> Alternatively, and to answer the initial question, if its just wanted
> >> that
> >> derby gets included in the bin distro lib folder then that can be done
> by
> >> adding the dependency to distribution/pom.xml.
> >>
> >
> > Ah, this is what I was looking for! Great, I'll try that. Thanks.
> >
> I don't think we should put sample dependencies in the bin distro lib
> folder.  If we need to include them in the bin distro (and I'm not 100%
> convinced about that), then I think they should go in some other
> directory.
>
> An alternative approach would be to have a samples distro that contains
> the samples plus dependencies that are only used by the samples and not
> by the main runtime.  I think this is better as it allows us to add more
> samples without pushing up the size of the main binary distro.

Personally I like to see samples with whatever I download and I'd rather
have a bigger binary distro than a separate download. If there is a real
need to reduce the distribution size can we do it in a different way, for
example, have groups of extensions (and their samples) distributed
separately?


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

Re: Mvn errors in SDO build

[Simon Laws]

On Nov 14, 2007 7:04 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:

> I have added the proper version to maven-javadoc-plugin (revision
> #595010) and it seems to fix the issue.
>
>
>org.apache.maven.plugins
>maven-javadoc-plugin
>2.2
>
>
> Let me know if it works for you now.
>
>
> On Nov 14, 2007 7:27 AM, Simon Laws <[EMAIL PROTECTED]> wrote:
> > I just did an svn up and started getting very strange mvn errors (see
> > attached). I can't relate it to any particular change in svn. The only
> way
> > I've been able to get past it is to revert from maven 2.0.7 to 2.0.5.
> Will
> > investigate more but is anyone else seeing build problems
> >
> > Simon
> >
> >
> > [INFO]
> >
> -
> > ---
> > [INFO] Building SDO API
> > [INFO]task-segment: [install]
> > [INFO]
> >
> -
> > ---
> > [INFO] [resources:resources]
> > [INFO] Using default encoding to copy filtered resources.
> > [INFO] [compiler:compile]
> > [INFO] Compiling 18 source files to
> > C:\simon\tuscany\java-head\sdo\sdo-api\targe
> > t\classes
> > [INFO] [resources:testResources]
> > [INFO] Using default encoding to copy filtered resources.
> > [INFO] [compiler:testCompile]
> > [INFO] Compiling 3 source files to
> > C:\simon\tuscany\java-head\sdo\sdo-api\target
> > \test-classes
> > [INFO] [surefire:test]
> > [INFO] Surefire report directory:
> > C:\simon\tuscany\java-head\sdo\sdo-api\target\
> > surefire-reports
> >
> > ---
> >  T E S T S
> > ---
> > Running commonj.sdo.impl.HelperProviderTestCase
> > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.11 sec
> >
> > Results :
> >
> > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0
> >
> > [INFO] [osgi:osgi-bundle]
> > [INFO] Generating JAR bundle
> > C:\simon\tuscany\java-head\sdo\sdo-api\target\tusca
> > ny-sdo-api-r2.1-1.0-incubating-SNAPSHOT.jar
> > [INFO] No manifest file specified. Default will be used.
> > [INFO] Building jar:
> > C:\simon\tuscany\java-head\sdo\sdo-api\target\tuscany-sdo-a
> > pi-r2.1-1.0-incubating-SNAPSHOT.jar
> > [INFO] Preparing javadoc:jar
> > [INFO]
> >
> -
> > ---
> > [INFO] Building SDO API
> > [INFO]
> >
> -
> > ---
> > [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> > invocation.
> > [INFO] No goals needed for project - skipping
> >
>
>
>
> --
> 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]
>
> Thanks Luciano

Simon

Implementation BPEL updates and issues

[Luciano Resende]

I have recently started to work back on the BPEL reference support,
and have been finding couple issues either in our BPEL implementation
support or WSDL support. Most of the issues in the BPEL implementation
were fixed, and WSDL related issues were workarounded, so let me try
to list some of them here :

- WSDL2Java not generating interfaces if WSDL does not have a service
declared. I tried to fix this issue, but it wasn't so easy and it
looked to me that AXIS2 needed some of the information from the
services. So I workarounded by adding the service to my wsdl.
(TUSCANY-1882)

- Still seeing issues from TUSCANY-1142 in some WSDL (pong.wsdl for example)

- WSDL inline schema, defined with Namespace
xmlns="http://www.w3.org/2000/10/XMLSchema"; are not being processed by
Tuscany. And XSDGenerator throws exceptions and don't generate types
on this case. It seems that couple ODE sample WSDL files use this
namespace.

- I was having some issues around wsdl with namespace like urn:/.
Couple of BPEL process and WSDL I was tying to re-use from ODE were
failing in our environment. But I can't reproduce this anymore and it
might be related to the schema issue mentioned above.

http://docs.oasis-open.org/wsbpel/2.0/process/executable";
targetNamespace="urn:/Pong.bpel"
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:tns="urn:/Pong.bpel"
xmlns:pong="urn:/Pong.wsdl"
expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0">


In the BPEL invocation chain, data binding transformation is producing
unexpected results

-1


As for some the issues I have already addressed/fixed :
   - Better support for multiple BPEL process
  - Fixing resolve issues when there where multiple BPEL process
  - Fixing componentType issues when there were multiple BPEL process
   - Properly generating BPEL invocation message that were affecting
more complex BPEL process
   - Properly process BPEL Executable process


Anyway, I'll keep you guys updated on the progress, and any help is
appreciated on the wsdl issues.


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

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

Re: Change the syntax for qname in META-INF/services/org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor

[Simon Laws]

On Nov 15, 2007 5:38 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> Hi,
>
> The StAXArtifactProcessor extension point currently uses the
> "namespace#localPart" syntax for the qname attribute in the service
> registration file
>
> (META-INF/services/org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor).
>
> I propose that we change the syntax to be "{namespace}localPart" for two
> reasons:
>
> 1) {namespace}localPart is the format produced by QName.toString()
> 2) # is valid character for namespace, using # as the delimiter could lead
> to conflict.
>
> If there is no objections, I will make the changes.
>
> Thanks,
> Raymond
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Hi Raymond

Isn't there a problem then with wsdlElement="
http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort)"?

Simon

[jira] Updated: (TUSCANY-1868) Schema imports not working in multiple class-loader environment

[David T. Adcox (JIRA)]

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

David T. Adcox updated TUSCANY-1868:


Attachment: 1868.patch

This patch will resolve this problem, but it does introduce a bit of 
redundancy.  Instead of searching up the Class loader parent tree, a new 
EcoreBuilder is created per CL.  This insures that the EcoreBuilder will 
contain the required models.  This solution does mean we lose some reuse, but 
given the alternatives, it seems acceptable.

> Schema imports not working in multiple class-loader environment
> ---
>
> Key: TUSCANY-1868
> URL: https://issues.apache.org/jira/browse/TUSCANY-1868
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: n/a
>Reporter: David T. Adcox
> Fix For: Java-SDO-Next
>
> Attachments: 1868.patch, Test1868.java
>
>
> There is a problem with loading schemas that import an additional namespace 
> when in a multiple class-loader environment.  The problem exists due to a 
> design flaw in how the EcoreBuilder and package registries interact under a 
> specific circumstance.  That circumstance exists when the default helper 
> context is used to load a schema model using the XSDHelper.define() method in 
> two different, peer class-loaders.  These peer class-loaders must share the 
> same parentage.  
>---
>   | CL parent  | 
>---
>  /\
>   /  \
>  /\
> /  \
> ---   --- 
>   | CL1  || CL2  | 
> ---   --- 
> In this scenario, the same EcoreBuilder is used on both passes of 
> XSDHelper.define(), because the EcoreBuilder is associated with the CL 
> Parent.  A unique registry is created for CL1 and another for CL2.  During 
> the processing for CL1, the target namespace and all imported namespaces are 
> properly parsed and the models stored in the associated registry, but during 
> the processing for CL2, because the same EcoreBuilder is used, only the 
> target namespace is processed.  So, any imported models are missing from the 
> CL2 registry.   
> I've attached an example that will demonstrate this issue.

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


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

Change the syntax for qname in META-INF/services/org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor

[Raymond Feng]

Hi,

The StAXArtifactProcessor extension point currently uses the 
"namespace#localPart" syntax for the qname attribute in the service 
registration file 
(META-INF/services/org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor).


I propose that we change the syntax to be "{namespace}localPart" for two 
reasons:


1) {namespace}localPart is the format produced by QName.toString()
2) # is valid character for namespace, using # as the delimiter could lead 
to conflict.


If there is no objections, I will make the changes.

Thanks,
Raymond


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

Re: Amazon Cart

[Jean-Sebastien Delfino]

Antollini, Mario wrote:

Jean-Sebastien,

 


I added the amazon cart to jire:
https://issues.apache.org/jira/secure/attachment/12369533/tutorial-amazo
n.zip

 


Sadly, I could not get the test running, therefore I am not sure it will
run properly.
  


I committed your new module with the following minor changes:

- Grouped amazon-cart-api and amazon-cart into one module, as an SCA 
contribution cannot span 2 Maven modules and using 2 SCA contributions 
with a dependency and an SCA  of the WSDL namespace would 
probably complicate the tutorial at this point.


- Changed the test case to use the same node API as you were using in 
the Launcher.


- Fixed some of the dependencies and added missing license headers.

I am now able to start the test case and the launcher but running into 
the following exception:


Caused by: java.lang.NullPointerException
   at 
org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.processInterface(DataBindingJavaInterfaceProcessor.java:97)
   at 
org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.visitInterface(DataBindingJavaInterfaceProcessor.java:59)
   at 
org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:90)
   at 
org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:48)
   at 
org.apache.tuscany.sca.implementation.java.introspect.impl.HeuristicPojoProcessor.createService(HeuristicPojoProcessor.java:568)
   at 
org.apache.tuscany.sca.implementation.java.introspect.impl.HeuristicPojoProcessor.addService(HeuristicPojoProcessor.java:127)
   at 
org.apache.tuscany.sca.implementation.java.introspect.impl.HeuristicPojoProcessor.visitEnd(HeuristicPojoProcessor.java:106)
   at 
org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:109)
   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:133)
   at 
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:1)
   at 
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:212)
   at 
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
   at 
org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation(BaseAssemblyProcessor.java:236)
   at 
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:730)
   at 
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:1)
   at 
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
   at 
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:113)
   at 
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:1)
   at 
org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86)
   at 
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:415)
   at 
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:329)
   at 
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:165)
   at 
org.apache.tuscany.sca.node.impl.SCANodeImpl.addContribution(SCANodeImpl.java:302)

   ... 22 more

The good news is that it goes way further than before before hitting an 
issue with the DataBinding stuff. Could some of the folks working on 
databindings please help understand that Exception? Thanks.


Once we get past that error, I guess you'll need to add more meat to the 
test case to create an SDO etc. Also could you please try to configure 
the surefireplugin to pick /**/*TestCase.java?


Thanks!

--
Jean-Sebastien


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

Re: Sample dependencies not pulled in distribution

[Jean-Sebastien Delfino]

ant elder wrote:

On Nov 14, 2007 9:11 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:

  

Luciano Resende wrote:


Try removing the test scope from derby dependency on the
implementation-data pom.

  

Did that and it works around the problem, but it's a workaround :)




Why is doing this in the implementation-data pom.xml a work around?
Having a dependency on derby in implementation-data would be like having 
a direct dependency on tomcat in binding-ws-axis2. It'll bring derby in 
even if I've decided to use implementation-data with another database.



If
implementation-data needs derby to be used then whats wrong with defining
that as a dependency?
implementation-data doesn't require derby, you should be able to use it 
with another database.



Thats like we do with wstx isn't it, there are other
stax impls available but we still explictly define the wstx one.
  

Is that a good thing? :) I don't think so.


Alternatively, and to answer the initial question, if its just wanted that
derby gets included in the bin distro lib folder then that can be done by
adding the dependency to distribution/pom.xml.
  

Ah, this is what I was looking for! Great, I'll try that. Thanks.

--
Jean-Sebastien


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

Re: Sample dependencies not pulled in distribution

[ant elder]

On Nov 14, 2007 9:11 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:

> Luciano Resende wrote:
> > Try removing the test scope from derby dependency on the
> > implementation-data pom.
> >
>
> Did that and it works around the problem, but it's a workaround :)
>
>
Why is doing this in the implementation-data pom.xml a work around? If
implementation-data needs derby to be used then whats wrong with defining
that as a dependency? Thats like we do with wstx isn't it, there are other
stax impls available but we still explictly define the wstx one.

Alternatively, and to answer the initial question, if its just wanted that
derby gets included in the bin distro lib folder then that can be done by
adding the dependency to distribution/pom.xml.

...ant

[jira] Resolved: (TUSCANY-1698) Changes in DAS Config to support authenticated connection using data source

[Amita Vadhavkar (JIRA)]

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

Amita Vadhavkar resolved TUSCANY-1698.
--

Resolution: Fixed

With all the discussion under [DAS] DAS Samples, it is decided to remove sample 
dataSource and any test cases which can add
dependencies on jars having licensing issues. Instead explain the feature in 
detail in user guide.

Code changes for this are checked in under revision 595223 for this.

> Changes in DAS Config to support authenticated connection using data source
> ---
>
> Key: TUSCANY-1698
> URL: https://issues.apache.org/jira/browse/TUSCANY-1698
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-Next
>Reporter: Amita Vadhavkar
>Assignee: Amita Vadhavkar
> Fix For: Java-DAS-Next
>
> Attachments: 1698.patch
>
>
>  in RDB-DAS, when we use external DataSource, we do not  pass  userName, 
> password. But MySQL (which with InnoDB supports Txn and works well  with 
> JOTM) does need id, pwd in ds.getConnection(). This can be case with  other 
> DBs as well. 
>  So, it looks like DAS config.xsd needs to allow passing userName, password  
> in ConnectionInfo too ( and not just for ConnectionProperties).
>  Thus below will be the changed DAS config portion:-
> 
>
>   name="ConnectionProperties" type="config:ConnectionProperties"/>
>
>
>
>
>
> 
> 
>   
>   
>   
> 

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


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

Re: svn commit: r595217 - /incubator/tuscany/java/sca/modules/node-impl/src/main/java/org/apache/tuscany/sca/node/impl/SCANodeImpl.java

[Simon Laws]

On Nov 15, 2007 5:59 AM, <[EMAIL PROTECTED]> wrote:

> Author: jsdelfino
> Date: Wed Nov 14 21:59:04 2007
> New Revision: 595217
>
> URL: http://svn.apache.org/viewvc?rev=595217&view=rev
> Log:
> Configure the default HTTP port from service uris declared in the
> composite running on a node.
>
> Modified:
>
>  
> incubator/tuscany/java/sca/modules/node-impl/src/main/java/org/apache/tuscany/sca/node/impl/SCANodeImpl.java
>
> Modified:
> incubator/tuscany/java/sca/modules/node-impl/src/main/java/org/apache/tuscany/sca/node/impl/SCANodeImpl.java
> URL:
> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/node-impl/src/main/java/org/apache/tuscany/sca/node/impl/SCANodeImpl.java?rev=595217&r1=595216&r2=595217&view=diff
>
> ==
> ---
> incubator/tuscany/java/sca/modules/node-impl/src/main/java/org/apache/tuscany/sca/node/impl/SCANodeImpl.java
> (original)
> +++
> incubator/tuscany/java/sca/modules/node-impl/src/main/java/org/apache/tuscany/sca/node/impl/SCANodeImpl.java
> Wed Nov 14 21:59:04 2007
> @@ -417,7 +417,6 @@
> /**
>  * Configure the default HTTP port for this node.
>  */
> -/*
> private void configureDefaultPort() {
> Composite composite = composites.get(compositesToStart.get(0));
> if (composite == null) {
> @@ -472,7 +471,7 @@
> }
> }
> }
> -*/
> +
> private void startComposites() throws NodeException {
> try {
> if (compositesToStart.size() == 0 ){
> @@ -481,7 +480,7 @@
> } else {
>
> // Configure the default server port for the node
> -//configureDefaultPort();
> +configureDefaultPort();
>
> for (QName compositeName : compositesToStart) {
> Composite composite = composites.get(compositeName);
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Hi Sebastien

I'm guessing you needed this back into play because you happened to get the
trunk between Ant's checkins to allow the default path to be specified
rather than just the port.  For a time, by accident,  the node wasn't
setting the default HTTP information at all.

I'm a little confused by this code as it seems to be trying to find the
first valid port number from domain level or composite level services in the
first composite running in the node. If it finds one it uses it as the
default port, if not it takes the port from the node uri.  Why is it
important to set the default port in this way?

I though that getting the port number from the Node URL or inventing one if
the Node URL is not provided would be sufficient. If someone specifies one
in a URL in a binding shouldn't that be used anyhow and override any default
setting? There must be a case I'm missing.

Simon

[jira] Commented: (TUSCANY-1907) Dynamic Wiring: Adding a new component to a contribution

[Simon Laws (JIRA)]

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

Simon Laws commented on TUSCANY-1907:
-

Thanks Giorgio

> Dynamic Wiring: Adding a new component to a contribution 
> -
>
> Key: TUSCANY-1907
> URL: https://issues.apache.org/jira/browse/TUSCANY-1907
> Project: Tuscany
>  Issue Type: New Feature
>Reporter: Giorgio Zoppi
> Attachments: editedpatch.txt, mypatch.txt
>
>
> My second patch is a working patch. Now with this patch you're able to add a 
> new component to a composition in a contribution.
> I provided a new component processor in artifacts' processor registry and 
> modified parts of ConfigureBuilderImpl, WireBuilderImpl to adapt to a single 
> component. I still modified ActivatorComponentImpl for the same reason. So 
> you can inside a SCANodeImpl configure and start a new component, subclassing 
> a MetaComponent interface.

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


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

[jira] Resolved: (TUSCANY-1842) IOException loading DataGraph containing a deleted dataObject with a property whose type extends a complexType w/simple integer content

[Kelvin Goodson (JIRA)]

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

Kelvin Goodson resolved TUSCANY-1842.
-

Resolution: Fixed

Applied patch, many thanks Ron.

> IOException loading DataGraph containing a deleted dataObject with a property 
> whose type extends a complexType w/simple integer content
> ---
>
> Key: TUSCANY-1842
> URL: https://issues.apache.org/jira/browse/TUSCANY-1842
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
> Environment: Windows XP, Sun JDK 1.5.0_09
>Reporter: Ron Gavlin
>Priority: Critical
> Fix For: Java-SDO-Next
>
> Attachments: 1842data.zip, tuscany-sdo.TUSCANY-1842.patch
>
>
> In the test method, testComplexTypeWithSimpleContentExtensionChangeSummary() 
> listed below, a DataGraph is created with a dataObject whose property type 
> extends a complexType with simple integer content. After the dataObject is 
> deleted, an attempt is made to save and load the DataGraph. While the 
> DataGraph is being loaded, an unsuccessful attempt is made to convert a 
> zero-length string into a BigInteger. 
> Any suggestions on how to best fix this are most welcome.
> Thanks,
> - Ron
> ==
> substitutionWithExtensionValues.xsd
> == 
> http://www.w3.org/2001/XMLSchema";
>   targetNamespace="http://www.example.com/substitutionEV";
>   xmlns:sev="http://www.example.com/substitutionEV";>
>   
>   
>   
>  substitutionGroup="sev:result" />
>   
>   
>   
>  maxOccurs="unbounded" />
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>value="English" />
>value="French" />
>value="Spanish" />
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
> ==
> substitutionWithExtensionValues2.xsd
> ==
> http://www.w3.org/2001/XMLSchema";
>   targetNamespace="http://www.example.com/substitutionEV2";
>   xmlns:sev2="http://www.example.com/substitutionEV2";
>   xmlns:sev="http://www.example.com/substitutionEV";>
>   
>   http://www.example.com/substitutionEV";
>   schemaLocation="substitutionWithExtensionValues.xsd" />
>   
>   
>   
>   
>maxOccurs="unbounded"
>   type="sev2:Results2Type" />
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
> ==
> substitutionWithExtensionValues1.xml
> ==
> 
> http://www.example.com/substitutionEV2";>
>   
>   http://www.example.com/substitutionEV";>
>   
>   
>   
>   name1
>   1
>