Re: Running Tuscany/SCA in Google Android mobile platform
Hi Oscar, I was indeed using the sca modules not from the sandbox. As you suggested, I removed the tuscany-contribution-impl from my workspace and added the version you uploaded to the sandbox. Then, I uncommented the lines in org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator following the comments pointing out why those lines had been commented. I'm no longer getting the ClassNotFoundException. However, it's getting stuck somewhere else (before getting there I guess)...I think this is the case because before and after commenting the code I get the same error in the Android emulator, an InstantiationException [1]. Have you debugged to check exactly where this exception is being thrown? I have done the procedure I previously described again and I got it "running" as expected, which means, running till the expected exception is thrown. I also started tinkering with retrotranslator. First I tried doing it with Ant, but it seems that in order to build I have to include the whole tuscany projects in a way similar to how I now have in Eclipse. I also tried making a jar out of org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator and then feeding it to retrotranslator but unfortunately it's not translating anything, as shown below. Voyager-2:Retrotranslator-1.2.6-bin ocastaneda$ java -jar retrotranslator-transformer-1.2.6.jar -srcjar JavaRuntimeModuleActivator.jar -target 1.5 -reflection safe -stripannot -classpath retrotranslator-android-1.2.6.jar Processing 136 file(s) in JavaRuntimeModuleActivator.jar. Transformed 0 file(s). There's also a maven plugin, so I might try that...but first I'll give Ant another go. Hopefully Google will release a new SDK soon, otherwise as you say...retrotranslator will have to be the workaround to proceed with our project ;-) Unfortunately the rumors say the new SDK version will not be released until july 28th :S. So, it's really good you have already started working on the retrotranslator, it will probably be the best workaround for the annotations problem till the next SDK release. I suggest you to forget about the build process right now, before, check if this retrotranslator works and if it really works on android platform. I´m really getting upset with Android, even its API methods does not work as expected :@. Anyway, try initially to compile a simple class (coded by you), which contains annotations, and access these annotations. If it works, make it more complex and test again, do it until you reach a scenario as complex as the SCA (a lot of external jars with annotated classes accessed by the other external jars and the Android app). Got it? : ) Regards, Adriano Crestani On Tue, May 20, 2008 at 1:53 PM, Oscar Castaneda < [EMAIL PROTECTED]> wrote: > Hi Adriano, > > I was indeed using the sca modules not from the sandbox. As you suggested, > I > removed the tuscany-contribution-impl from my workspace and added the > version you uploaded to the sandbox. Then, I uncommented the lines in > > > org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator > > following the comments pointing out why those lines had been commented. I'm > no longer getting the ClassNotFoundException. However, it's getting stuck > somewhere else (before getting there I guess)...I think this is the case > because before and after commenting the code I get the same error in the > Android emulator, an InstantiationException [1]. > > I also started tinkering with retrotranslator. First I tried doing it with > Ant, but it seems that in order to build I have to include the whole > tuscany > projects in a way similar to how I now have in Eclipse. I also tried making > a jar out of > > > org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator > > and then feeding it to retrotranslator but unfortunately it's not > translating anything, as shown below. > > Voyager-2:Retrotranslator-1.2.6-bin ocastaneda$ java -jar > retrotranslator-transformer-1.2.6.jar -srcjar > JavaRuntimeModuleActivator.jar > -target 1.5 -reflection safe -stripannot -classpath > retrotranslator-android-1.2.6.jar > Processing 136 file(s) in JavaRuntimeModuleActivator.jar. > Transformed 0 file(s). > > There's also a maven plugin, so I might try that...but first I'll give Ant > another go. Hopefully Google will release a new SDK soon, otherwise as you > say...retrotranslator will have to be the workaround to proceed with our > project ;-) > > Thanks again for all your help...I'm getting ready for the official start > :-) > > [1] http://androidindelft.googlepages.com/20may2008.html > > > > On Fri, May 16, 2008 at 12:20 PM, Adriano Crestani < > [EMAIL PROTECTED]> wrote: > > > Hi Oscar, > > > > My mistake again, the eclipse project files of contribution-impl module > > were > > not uploaded, so you are probably using the modules you have downloaded > > from > > the sca modules. If you remove the tuscany-contribution-impl from your > > workspace a
Re: Running Tuscany/SCA in Google Android mobile platform
Ah, the expected exception should look like this on android emulator: http://people.apache.org/~adrianocrestani/android_emulator.jpg On Tue, May 20, 2008 at 11:54 PM, Adriano Crestani < [EMAIL PROTECTED]> wrote: > Hi Oscar, > > I was indeed using the sca modules not from the sandbox. As you suggested, > I > removed the tuscany-contribution-impl from my workspace and added the > version you uploaded to the sandbox. Then, I uncommented the lines in > > > org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator > > following the comments pointing out why those lines had been commented. I'm > no longer getting the ClassNotFoundException. However, it's getting stuck > somewhere else (before getting there I guess)...I think this is the case > because before and after commenting the code I get the same error in the > Android emulator, an InstantiationException [1]. > > Have you debugged to check exactly where this exception is being thrown? I > have done the procedure I previously described again and I got it "running" > as expected, which means, running till the expected exception is thrown. > > I also started tinkering with retrotranslator. First I tried doing it with > Ant, but it seems that in order to build I have to include the whole > tuscany > projects in a way similar to how I now have in Eclipse. I also tried making > a jar out of > > > org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator > > and then feeding it to retrotranslator but unfortunately it's not > translating anything, as shown below. > > Voyager-2:Retrotranslator-1.2 > .6-bin ocastaneda$ java -jar > retrotranslator-transformer-1.2.6.jar -srcjar > JavaRuntimeModuleActivator.jar > -target 1.5 -reflection safe -stripannot -classpath > retrotranslator-android-1.2.6.jar > Processing 136 file(s) in JavaRuntimeModuleActivator.jar. > Transformed 0 file(s). > > There's also a maven plugin, so I might try that...but first I'll give Ant > another go. Hopefully Google will release a new SDK soon, otherwise as you > say...retrotranslator will have to be the workaround to proceed with our > project ;-) > > Unfortunately the rumors say the new SDK version will not be released until > july 28th :S. So, it's really good you have already started working on the > retrotranslator, it will probably be the best workaround for the annotations > problem till the next SDK release. > > I suggest you to forget about the build process right now, before, check if > this retrotranslator works and if it really works on android platform. I´m > really getting upset with Android, even its API methods does not work as > expected :@. Anyway, try initially to compile a simple class (coded by you), > which contains annotations, and access these annotations. If it works, make > it more complex and test again, do it until you reach a scenario as complex > as the SCA (a lot of external jars with annotated classes accessed by the > other external jars and the Android app). Got it? : ) > > Regards, > Adriano Crestani > > > On Tue, May 20, 2008 at 1:53 PM, Oscar Castaneda < > [EMAIL PROTECTED]> wrote: > >> Hi Adriano, >> >> I was indeed using the sca modules not from the sandbox. As you suggested, >> I >> removed the tuscany-contribution-impl from my workspace and added the >> version you uploaded to the sandbox. Then, I uncommented the lines in >> >> >> org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator >> >> following the comments pointing out why those lines had been commented. >> I'm >> no longer getting the ClassNotFoundException. However, it's getting stuck >> somewhere else (before getting there I guess)...I think this is the case >> because before and after commenting the code I get the same error in the >> Android emulator, an InstantiationException [1]. >> >> I also started tinkering with retrotranslator. First I tried doing it with >> Ant, but it seems that in order to build I have to include the whole >> tuscany >> projects in a way similar to how I now have in Eclipse. I also tried >> making >> a jar out of >> >> >> org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator >> >> and then feeding it to retrotranslator but unfortunately it's not >> translating anything, as shown below. >> >> Voyager-2:Retrotranslator-1.2.6-bin ocastaneda$ java -jar >> retrotranslator-transformer-1.2.6.jar -srcjar >> JavaRuntimeModuleActivator.jar >> -target 1.5 -reflection safe -stripannot -classpath >> retrotranslator-android-1.2.6.jar >> Processing 136 file(s) in JavaRuntimeModuleActivator.jar. >> Transformed 0 file(s). >> >> There's also a maven plugin, so I might try that...but first I'll give Ant >> another go. Hopefully Google will release a new SDK soon, otherwise as you >> say...retrotranslator will have to be the workaround to proceed with our >> project ;-) >> >> Thanks again for all your help...I'm getting ready for the official start >> :-) >> >> [1] http://androidindelft.googlepages.com
Re: TUSCANY-2277 & validation messages
On Tue, May 20, 2008 at 11:19 AM, Ramkumar R <[EMAIL PROTECTED]> wrote: > Thanks Simon, itests for these validation messages are now available with > TUSCANY-2329. > > On 5/19/08, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > I've just checked in Ram's patch to convert validation messages (i.e. > those > > messages indicating that the user have provided invalid input of some > form) > > to resource bundles and pass them through the Monitor. We need to take > > account of this change as we change or add code to do with validation. > > Primarily the change; > > > > - Pushes down a Monitor object to various parts of code that produce > > validation type messages. > > - Creates a problem object to hold any reported warning or error > (sometimes > > there a convenience error() or warning() operation has been added if > there > > are a lot of messages in a file) > > -- Each problem is identified by an id string > > -- The id string references into a resource bundle where the full message > > has been moved to. There is now a resource bundle in each module that > > raises > > validation messages > > - Passes the Problem on to the Monitor object > > > > Our default Monitor object simply passes the message to the JDK logger at > > the moment but you could imagine a Monitor that collects them all > together > > for later analysis. Currently the majority of the exceptions that are > > thrown > > during validation are still there so I guess we need to go through taking > > out the ones that are not now absolutely necessary. The next job! > > > > With this done we have catalogs of all of the errors/warnings that a user > > is > > likely to come across (and examples of why the occur in the validation > > itests) which should help our documentation somewhat. > > > > Big thanks to Ram > > > > > > > > Simon > > > > > > -- > Thanks & Regards, > Ramkumar Ramalingam > Hi Ram Thanks for the patch. It was a big one. In the future it would be easier to have smaller committable chunks so we can review as you go;-) I had to fix up the pom file to make it work so maybe that got missed out of the patch. Also, you seem to have you tab key configured to include tabs. In your IDE could you change it to include four spaces instead? I'm going to check these changes in. Now we need to sort out what to do about all of the exceptions that get thrown. I'll remove the validation itests from the build temporarily while we do that. Regards Simon
[jira] Commented: (TUSCANY-2330) Calculator sample running in OSGi
[ https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598616#action_12598616 ] Graham Charters commented on TUSCANY-2330: -- Hi Rajini, I think what you're suggesting make sense. I won't be able to look at this until Friday. Thanks for the offer of help, I'll let you know if I need some. Regards, Graham. > Calculator sample running in OSGi > - > > Key: TUSCANY-2330 > URL: https://issues.apache.org/jira/browse/TUSCANY-2330 > Project: Tuscany > Issue Type: Wish > Components: Java SCA Samples >Affects Versions: Java-SCA-Next > Environment: All >Reporter: Graham Charters > Fix For: Java-SCA-Next > > Attachments: calculator-osgi-sample.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > It would help with preserving OSGi support if an OSGi sample were run as a > matter of course, rather than only by a small number of developers. This > wish is to add the smallest sample possible based on existing Tuscany module > dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2330) Calculator sample running in OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598635#action_12598635
]
Rajini Sivaram commented on TUSCANY-2330:
-
Graham,
I tried out the test (listed below), using your patch, and it seems to work
fine. So if you want, I can check in this code, along with the rest of your
patch tonight, and you can continue from there.
If this is going to be a sample, I think it should use Felix rather than
Equinox to avoid both Felix and Equinox being added to the Tuscany distribution
(depending on the order in which they appear in tuscany-sca-manifest.jar file,
they can result in conflicts when running Tuscany outside OSGi).
The test that I ran looks like:
public class CalculatorTestCase {
private BundleContext bundleContext;
@Before
public void setUp() throws Exception {
String[] equinoxArgs = new String[] {"-clean", "-console",
"-configuration", "target/configuration"};
bundleContext = EclipseStarter.startup(equinoxArgs, null);
}
@After
public void tearDown() throws Exception {
if (bundleContext != null) {
bundleContext.getBundle().stop();
}
}
@Test
public void runCalculator() throws Exception {
Bundle tuscanyInstallerBundle =
bundleContext.installBundle("file:../tuscany-osgi-installer/target/tuscany-sca-osgi-installer.jar");
tuscanyInstallerBundle.start();
Bundle calculatorBundle =
bundleContext.installBundle("file:../calculator/target/sample-calculator-bundle.jar");
calculatorBundle.start();
}
}
> Calculator sample running in OSGi
> -
>
> Key: TUSCANY-2330
> URL: https://issues.apache.org/jira/browse/TUSCANY-2330
> Project: Tuscany
> Issue Type: Wish
> Components: Java SCA Samples
>Affects Versions: Java-SCA-Next
> Environment: All
>Reporter: Graham Charters
> Fix For: Java-SCA-Next
>
> Attachments: calculator-osgi-sample.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> It would help with preserving OSGi support if an OSGi sample were run as a
> matter of course, rather than only by a small number of developers. This
> wish is to add the smallest sample possible based on existing Tuscany module
> dependencies.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TUSCANY-2329) itests for validation messages
[ https://issues.apache.org/jira/browse/TUSCANY-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-2329: --- Assignee: Simon Laws (was: Ramkumar Ramalingam) > itests for validation messages > -- > > Key: TUSCANY-2329 > URL: https://issues.apache.org/jira/browse/TUSCANY-2329 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Integration Tests >Affects Versions: Java-SCA-Next > Environment: Windows XP >Reporter: Ramkumar Ramalingam >Assignee: Simon Laws > Fix For: Java-SCA-Next > > Attachments: TUSCANY-2329-Part1.patch > > > itests for validation messages introduced through monitors (with > TUSCANY-2277) for various processors during read and resolve phase of the > composite. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Tuscany Java2WSDL and WSDL2Java tools
Do we really need these as they are today? Currently they contain copies of various Axis2 classes updated for Tuscany so its not a completely trivial upgrade to move to Axis2 1.4 and while looking at that I wondered what we really want them for. The Java2WSDL tool doesn't look like its actually used anywhere by any of the Tuscany samples or demos or anything. We have all the new runtime Java2WSDL code so ideally we'd move to that instead of using all the patched Java2WSDL classes. WSDL2Java is only used by one BPEL sample, the other samples needing that type of thing use the SDO tools directly to gen Java classes from XML schema. We've now changed all the runtime to use jaxb and jaxws so should we look at using the tools for those instead of the Axis2 WSDL2Java tool? Any one have any thoughts? ...ant
Re: Tuscany Java2WSDL and WSDL2Java tools
ant elder wrote: Do we really need these as they are today? Currently they contain copies of various Axis2 classes updated for Tuscany so its not a completely trivial upgrade to move to Axis2 1.4 and while looking at that I wondered what we really want them for. The Java2WSDL tool doesn't look like its actually used anywhere by any of the Tuscany samples or demos or anything. We have all the new runtime Java2WSDL code so ideally we'd move to that instead of using all the patched Java2WSDL classes. WSDL2Java is only used by one BPEL sample, the other samples needing that type of thing use the SDO tools directly to gen Java classes from XML schema. We've now changed all the runtime to use jaxb and jaxws so should we look at using the tools for those instead of the Axis2 WSDL2Java tool? Any one have any thoughts? ...ant Ant, Whoa there One of the main points of having Tuscany tools in this area is to assist developers who are having to use WSDL and who want to use SDOs in their Java code. If we get rid of the Tuscany tools, how are developers supposed to handle this? Yours, Mike.
Re: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bin
On Fri, May 16, 2008 at 9:26 AM, Simon Laws <[EMAIL PROTECTED]>
wrote:
> ...snip
>
> >
> > The two sets of SPIs could co-exist for a while with BindingProviders
> > working with bindings and ServiceProviders (I just made up that name)
> with
> > service endpoints.
> > --
> > Jean-Sebastien
>
>
> At r656959 I've just enabled some changes to take a step toward using an
> Endpoint representation in the model as an alternative to using cloned
> bindings as the representation of valid reference targets. It's not
> replacing the cloned binding approach just yet, to avoid breaking anything,
> but is the first step on the road. This is what I have done.
>
> Made a new Endpoint model type
> Created a separate factory for it (separate as I though the model may need
> to be pluggable as some point)
> Created a new EndpointProvider type and associated factory.
> Created an Endpoint module to provide a provider implementation.
> Created an Endpoint wire to trap attempted calls over unresolved endpoints
> Separated off the Endpoint builder code into a new builder class. Same code
> but easier to identify.
> Added an endpoint collection to references
> Used the Endpoint in the wire builder in place of the old internal target
> structure. The logic is weaved in to the existing logic as follows.
> For references with no target, put the binding into reference binding as
> before
> Create an Endpoint for all explicit reference targets
> For resolved endpoints (Endpoints where the target is resolved) put the
> binding into reference bindings, i.e. the same as before
> For unresolved endpoints create an endpoint provider and a wire. We don't
> have unresolved targets in tuscany (except in the sca binding test) so
> should not happen. If you do put a target name in that can't be matched
> with
> a service you'll get a warning.
>
> If there is no Endpoint module on the classpath it will not create a
> provider or a wire hence disabling any Endpoint based processing. The
> Endpoint model will still be used though
>
> As part of this change I've updated the logic that looks for target names
> in
> binding uri. It's now applied to all binding types which I believe is what
> the spec says, There is though an issue here. I'll raise a separate thread.
>
> There are also a couple of thoughts I had.
>
> Can we make the CompositeBuilderImpl have just one constructor?
> Should builders be pluggable?
> I've used some of the CompoisteActivator functions in the EndpointWire that
> could do with moving into the activator interface.
>
> Simon
>
Last week i updated the runtime-tomcat module to use this Endpoint code to
get the Tomcat deep integration with webapps talking to each other as being
discussed in [1] and [2]. Its a complete hack at the moment but at least
gives a start at something more real to be talking about in those threads.
You can try it by building the runtime-tomcat module, and the doing a "mvn
dependency:copy-dependencies"
- in tomcat conf/catalina.properties add the runtime-tomcat jar and
dependencies:
common.loader=${catalina.home}/lib,${catalina
.home}/lib/*.jar,/Tuscany/SVN/trunk/modules/runtime-tomcat/target/*.jar,/Tuscany/SVN/trunk/modules/runtime-tomcat/target/dependency/*.jar
- in tomcat conf/server.xml add the TuscanyHost class name to the localhost
definition, eg:
Now you can deploy webapps to tomcat without needing to include _any_
Tuscany stuff in the webapp - no tuscany jars or web.xml config. You can try
it with the calculator-webapp and calculator-ws-webapp samples, delete all
the jars and Tuscany web.xml config from the webapps and delete the subtract
component and impl from the calculator-ws-webapp and it should all still
work with the caclulator-ws-webapp using the subtract component in the
calculator-webapp sample.
...ant
[1] http://apache.markmail.org/message/2i6gtkveapk3n4nr
[2] http://apache.markmail.org/message/l7pgz2sxuitdhmxm
Re: Tuscany Java2WSDL and WSDL2Java tools
On Wed, May 21, 2008 at 2:53 PM, Mike Edwards < [EMAIL PROTECTED]> wrote: > ant elder wrote: > >> Do we really need these as they are today? Currently they contain copies >> of >> various Axis2 classes updated for Tuscany so its not a completely trivial >> upgrade to move to Axis2 1.4 and while looking at that I wondered what we >> really want them for. >> >> The Java2WSDL tool doesn't look like its actually used anywhere by any of >> the Tuscany samples or demos or anything. We have all the new runtime >> Java2WSDL code so ideally we'd move to that instead of using all the >> patched >> Java2WSDL classes. WSDL2Java is only used by one BPEL sample, the other >> samples needing that type of thing use the SDO tools directly to gen Java >> classes from XML schema. We've now changed all the runtime to use jaxb and >> jaxws so should we look at using the tools for those instead of the Axis2 >> WSDL2Java tool? >> >> Any one have any thoughts? >> >> ...ant >> >> Ant, > > Whoa there :-) > > > One of the main points of having Tuscany tools in this area is to assist > developers who are having to use WSDL and who want to use SDOs in their Java > code. If we get rid of the Tuscany tools, how are developers supposed to > handle this? > > Handle what exactly is what I'm asking. What are the use cases we want to support? Looking at the state of the code I'm not sure these tools actually are working properly today and its not that clear (to me) what it is we want them to do anyway. SDO has its own tools for dealing with WSDL which we use, eg, look at the bottom of the pom.xml in the wsdl itest [1]. ...ant [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/wsdl/pom.xml
[jira] Resolved: (TUSCANY-2329) itests for validation messages
[ https://issues.apache.org/jira/browse/TUSCANY-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws resolved TUSCANY-2329. - Resolution: Fixed Checked in at 658706. Thanks Ram for the patch. I had a few of the tests fail so I need you to take a look. The asserts are currently commented out. impl.spring.UnableToResolveComponentTypeTestCase impl.java.ContributionResolveExceptionTestCase interfacejava.xml.ContributionResolveExceptionTestCase > itests for validation messages > -- > > Key: TUSCANY-2329 > URL: https://issues.apache.org/jira/browse/TUSCANY-2329 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Integration Tests >Affects Versions: Java-SCA-Next > Environment: Windows XP >Reporter: Ramkumar Ramalingam >Assignee: Simon Laws > Fix For: Java-SCA-Next > > Attachments: TUSCANY-2329-Part1.patch > > > itests for validation messages introduced through monitors (with > TUSCANY-2277) for various processors during read and resolve phase of the > composite. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: TUSCANY-2277 & validation messages
On Wed, May 21, 2008 at 10:06 AM, Simon Laws <[EMAIL PROTECTED]> wrote: > > > On Tue, May 20, 2008 at 11:19 AM, Ramkumar R <[EMAIL PROTECTED]> > wrote: > >> Thanks Simon, itests for these validation messages are now available with >> TUSCANY-2329. >> >> On 5/19/08, Simon Laws <[EMAIL PROTECTED]> wrote: >> > >> > I've just checked in Ram's patch to convert validation messages (i.e. >> those >> > messages indicating that the user have provided invalid input of some >> form) >> > to resource bundles and pass them through the Monitor. We need to take >> > account of this change as we change or add code to do with validation. >> > Primarily the change; >> > >> > - Pushes down a Monitor object to various parts of code that produce >> > validation type messages. >> > - Creates a problem object to hold any reported warning or error >> (sometimes >> > there a convenience error() or warning() operation has been added if >> there >> > are a lot of messages in a file) >> > -- Each problem is identified by an id string >> > -- The id string references into a resource bundle where the full >> message >> > has been moved to. There is now a resource bundle in each module that >> > raises >> > validation messages >> > - Passes the Problem on to the Monitor object >> > >> > Our default Monitor object simply passes the message to the JDK logger >> at >> > the moment but you could imagine a Monitor that collects them all >> together >> > for later analysis. Currently the majority of the exceptions that are >> > thrown >> > during validation are still there so I guess we need to go through >> taking >> > out the ones that are not now absolutely necessary. The next job! >> > >> > With this done we have catalogs of all of the errors/warnings that a >> user >> > is >> > likely to come across (and examples of why the occur in the validation >> > itests) which should help our documentation somewhat. >> > >> > Big thanks to Ram >> > >> > >> > >> > Simon >> > >> >> >> >> -- >> Thanks & Regards, >> Ramkumar Ramalingam >> > Hi Ram > > Thanks for the patch. It was a big one. In the future it would be easier to > have smaller committable chunks so we can review as you go;-) > > I had to fix up the pom file to make it work so maybe that got missed out > of the patch. Also, you seem to have you tab key configured to include tabs. > In your IDE could you change it to include four spaces instead? > > I'm going to check these changes in. Now we need to sort out what to do > about all of the exceptions that get thrown. I'll remove the validation > itests from the build temporarily while we do that. > > Regards > > Simon > Ok, the tests are checked in now but I had a few problems with some of the tests. I just commented out the assets for the time being. impl.spring.UnableToResolveComponentTypeTestCase impl.java.ContributionResolveExceptionTestCase interfacejava.xml.ContributionResolveExceptionTestCase Also it seems that some of the message conversion till needs to be done, for example, Seems that some of the underlying exceptions/log statements still need converting JavaIntrospectionHelper JavaInterfaceIntrospectorImpl etc. Maybe you fixed these but didn't make a patch? Thanks Simon
Re: Tuscany Java2WSDL and WSDL2Java tools
That 'generate-sdo' only generates the Java types from the schema types, right? It's the WSDL2Java which maps portType operations t**o Java methods and (last I checked) our W2J is the only tool which knows how to do this with an SDO databinding. I'm not sure how useful the SDO-based J2W is, however. There are a lot of ways to generate a WSDL and as long as the work Simon Nash is doing to do a J2W at runtime can handle SDOs it would seem the tool-time code could be abandoned. On Wed, May 21, 2008 at 10:05 AM, ant elder <[EMAIL PROTECTED]> wrote: > On Wed, May 21, 2008 at 2:53 PM, Mike Edwards < > [EMAIL PROTECTED]> wrote: > > > ant elder wrote: > > > >> Do we really need these as they are today? Currently they contain copies > >> of > >> various Axis2 classes updated for Tuscany so its not a completely > trivial > >> upgrade to move to Axis2 1.4 and while looking at that I wondered what > we > >> really want them for. > >> > >> The Java2WSDL tool doesn't look like its actually used anywhere by any > of > >> the Tuscany samples or demos or anything. We have all the new runtime > >> Java2WSDL code so ideally we'd move to that instead of using all the > >> patched > >> Java2WSDL classes. WSDL2Java is only used by one BPEL sample, the other > >> samples needing that type of thing use the SDO tools directly to gen > Java > >> classes from XML schema. We've now changed all the runtime to use jaxb > and > >> jaxws so should we look at using the tools for those instead of the > Axis2 > >> WSDL2Java tool? > >> > >> Any one have any thoughts? > >> > >> ...ant > >> > >> Ant, > > > > Whoa there > > > :-) > > > > > > > > One of the main points of having Tuscany tools in this area is to assist > > developers who are having to use WSDL and who want to use SDOs in their > Java > > code. If we get rid of the Tuscany tools, how are developers supposed to > > handle this? > > > > > Handle what exactly is what I'm asking. What are the use cases we want to > support? Looking at the state of the code I'm not sure these tools actually > are working properly today and its not that clear (to me) what it is we > want > them to do anyway. SDO has its own tools for dealing with WSDL which we > use, > eg, look at the bottom of the pom.xml in the wsdl itest [1]. > > ...ant > > [1] > > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/wsdl/pom.xml >
[jira] Created: (TUSCANY-2332) reconsider non-support for Holders
reconsider non-support for Holders -- Key: TUSCANY-2332 URL: https://issues.apache.org/jira/browse/TUSCANY-2332 Project: Tuscany Issue Type: Improvement Components: Java SCA Data Binding Runtime Reporter: Scott Kurz Though the Java annotations/API spec specifically says wrt WSDL-> Java mapping: The JAX-WS mappings are applied with the following restrictions: • No support for holders I'd like to suggest that we look into enabling such support anyway, as this seems overly restrictive and prevents us from supporting existing WSDLs with inout data. At least I don't see how we'd map these WSDLs to Java and would think we'd be way better off relying on the mapping defined by JAX-WS which does use Holders. (Not sure what this statement in the spec was trying to accomplish.) I attached an example WSDL with two operations which we'd want to use Holders in the corresponding Java methods. One has a common child element of both input/output wrapper elem and the other has a common part of input/output message. (Maybe it would be better to bring this up before opening a JIRA, but I wanted to attach the WSDL.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2332) reconsider non-support for Holders
[ https://issues.apache.org/jira/browse/TUSCANY-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-2332: Attachment: guessAndGreet.wsdl > reconsider non-support for Holders > -- > > Key: TUSCANY-2332 > URL: https://issues.apache.org/jira/browse/TUSCANY-2332 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Data Binding Runtime >Reporter: Scott Kurz > Attachments: guessAndGreet.wsdl > > > Though the Java annotations/API spec specifically says wrt WSDL-> Java > mapping: > The JAX-WS mappings are applied with the following restrictions: > • No support for holders > I'd like to suggest that we look into enabling such support anyway, as this > seems overly restrictive and prevents us from supporting existing WSDLs with > inout data. > At least I don't see how we'd map these WSDLs to Java and would think we'd be > way better off relying on the mapping defined by JAX-WS which does use > Holders. > (Not sure what this statement in the spec was trying to accomplish.) > I attached an example WSDL with two operations which we'd want to use Holders > in the corresponding Java methods. One has a common child element of both > input/output wrapper elem and the other has a common part of input/output > message. > (Maybe it would be better to bring this up before opening a JIRA, but I > wanted to attach the WSDL.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tuscany Java2WSDL and WSDL2Java tools
Scott Kurz wrote: That 'generate-sdo' only generates the Java types from the schema types, right? It's the WSDL2Java which maps portType operations t**o Java methods and (last I checked) our W2J is the only tool which knows how to do this with an SDO databinding. Are the Java Service Endpoint Interfaces generated from WSDL portTypes when using an SDO databinding different from what JAX-WS would produce when using a JAXB databinding? Or are the differences confined to the Java code that's generated for the XSD types referenced in the WSDL? If possible, it would be good if we could use standard tools to generate the Java SEIs, and SDO-specific tools for the XSD to Java static SDO translation. I'm not sure how useful the SDO-based J2W is, however. There are a lot of ways to generate a WSDL and as long as the work Simon Nash is doing to do a J2W at runtime can handle SDOs it would seem the tool-time code could be abandoned. I'd like to get the runtime part working properly before I start looking at what is needed to make the same functionality available from the tools. In principle this seems like the right approach, but it might be quite a lot of work depending on environmental differences and how much flexibility we want to enable through different codegen options. For example, the runtime code introspects the contribution to locate the XSDs that correspond to SDO static types. At tool time, there would need to be command-line options to say where to find the XSDs. Another difference is that the runtime code code works by introspecting Java classes loaded into the current VM. It is considered bad practice for tools (e.g., rmic) to work in this way, because of potential interference between the classes being processed and the tool's own runtime. As an example, think of what would happen if a loaded class ran a constructor that went into a loop, or called System.exit(). Instead, these tools read class files and generate a "pure data" in-memory representation of the class information that is then processed. I suspect there will be a number of such differences. None will be insoluble, but all will require effort to design and implement. Simon On Wed, May 21, 2008 at 10:05 AM, ant elder <[EMAIL PROTECTED]> wrote: On Wed, May 21, 2008 at 2:53 PM, Mike Edwards < [EMAIL PROTECTED]> wrote: ant elder wrote: Do we really need these as they are today? Currently they contain copies of various Axis2 classes updated for Tuscany so its not a completely trivial upgrade to move to Axis2 1.4 and while looking at that I wondered what we really want them for. The Java2WSDL tool doesn't look like its actually used anywhere by any of the Tuscany samples or demos or anything. We have all the new runtime Java2WSDL code so ideally we'd move to that instead of using all the patched Java2WSDL classes. WSDL2Java is only used by one BPEL sample, the other samples needing that type of thing use the SDO tools directly to gen Java classes from XML schema. We've now changed all the runtime to use jaxb and jaxws so should we look at using the tools for those instead of the Axis2 WSDL2Java tool? Any one have any thoughts? ...ant Ant, Whoa there :-) One of the main points of having Tuscany tools in this area is to assist developers who are having to use WSDL and who want to use SDOs in their Java code. If we get rid of the Tuscany tools, how are developers supposed to handle this? Handle what exactly is what I'm asking. What are the use cases we want to support? Looking at the state of the code I'm not sure these tools actually are working properly today and its not that clear (to me) what it is we want them to do anyway. SDO has its own tools for dealing with WSDL which we use, eg, look at the bottom of the pom.xml in the wsdl itest [1]. ...ant [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/wsdl/pom.xml
NPE in BaseWireBuilderImpl with reference bindings that specify URIs
After some fun debugging today I realized that something has changed in how reference bindings are configured, breaking with an NPE on references with bindings that specify URIs, like follows: http://catalog"; name="catalog-mediation"> http://localhost:8105/MediatedVegetablesCatalog"/> Instead of seeing an EJB binding in the memory model representing the reference, I'm now seeing an SCA binding, with no URI, causing the following NPE: info: severe: SCA Node could not be created info: java.lang.reflect.InvocationTargetException info: at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) info: at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) info: at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) info: at java.lang.reflect.Constructor.newInstance(Constructor.java:513) info: at org.apache.tuscany.sca.node.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:297) info: at org.apache.tuscany.sca.node.launcher.NodeLauncher.createNode(NodeLauncher.java:60) info: at org.apache.tuscany.sca.node.launcher.NodeLauncher.main(NodeLauncher.java:122) info: Caused by: org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException info: at org.apache.tuscany.sca.node.impl.NodeImpl.(NodeImpl.java:155) info: at org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANode(NodeFactoryImpl.java:37) info: at org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.(NodeImplementationLauncherBootstrap.java:94) info: ... 7 more info: Caused by: java.lang.NullPointerException info: at org.apache.tuscany.sca.assembly.builder.impl.BaseWireBuilderImpl.createComponentReferenceTargets(BaseWireBuilderImpl.java:524) info: at org.apache.tuscany.sca.assembly.builder.impl.BaseWireBuilderImpl.connectComponentReferences(BaseWireBuilderImpl.java:599) info: at org.apache.tuscany.sca.assembly.builder.impl.BaseWireBuilderImpl.wireComponentReferences(BaseWireBuilderImpl.java:117) info: at org.apache.tuscany.sca.assembly.builder.impl.ComponentReferenceWireBuilderImpl.build(ComponentReferenceWireBuilderImpl.java:44) info: at org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:140) info: at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.buildComposite(ReallySmallRuntime.java:237) info: at org.apache.tuscany.sca.node.impl.NodeImpl.configureNode(NodeImpl.java:333) info: at org.apache.tuscany.sca.node.impl.NodeImpl.(NodeImpl.java:152) info: ... 9 more info: Exception in thread "main" org.apache.tuscany.sca.node.launcher.LauncherException: java.lang.reflect.InvocationTargetException info: at org.apache.tuscany.sca.node.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:330) info: at org.apache.tuscany.sca.node.launcher.NodeLauncher.createNode(NodeLauncher.java:60) info: at org.apache.tuscany.sca.node.launcher.NodeLauncher.main(NodeLauncher.java:122) info: Caused by: java.lang.reflect.InvocationTargetException info: at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) info: at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) info: at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) info: at java.lang.reflect.Constructor.newInstance(Constructor.java:513) info: at org.apache.tuscany.sca.node.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:297) info: ... 2 more info: Caused by: org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException info: at org.apache.tuscany.sca.node.impl.NodeImpl.(NodeImpl.java:155) info: at org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANode(NodeFactoryImpl.java:37) info: at org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.(NodeImplementationLauncherBootstrap.java:94) info: ... 7 more info: Caused by: java.lang.NullPointerException info: at org.apache.tuscany.sca.assembly.builder.impl.BaseWireBuilderImpl.createComponentReferenceTargets(BaseWireBuilderImpl.java:524) info: at org.apache.tuscany.sca.assembly.builder.impl.BaseWireBuilderImpl.connectComponentReferences(BaseWireBuilderImpl.java:599) info: at org.apache.tuscany.sca.assembly.builder.impl.BaseWireBuilderImpl.wireComponentReferences(BaseWireBuilderImpl.java:117) info: at org.apache.tuscany.sca.assembly.builder.impl.ComponentReferenceWireBuilderImpl.build(ComponentReferenceWireBuilderImpl.java:44) info: at org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:140) info: at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.buildComposite(ReallySmallRuntime.java:237) info: at org.apache.tuscany.sca.node.impl.NodeImpl.configureNode(NodeImpl.java:333) info: at org.apache.tuscany
Build failure in itest/contribution-classloader (monitor problem)
I just did a clean checkout and full build. It failed in itest/contribution-classloader with the following stack trace. The problem is caused by a null value in the "monitor" variable on line 124 of JavaInterfaceProcessor. This does not seem to happen for other tests. Any ideas? Simon Running org.apache.tuscany.sca.test.contribution.ContributionTestCase Created supplychain.customer.JavaCustomerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Customer.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Retailer.jar Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA contribution classloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contrib ution-test/target/contributions/Warehouse.jar Created supplychain.shipper.JavaShipperComponentImpl using: SCA contribution cla ssloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributio n-test/target/contributions/Shipper.jar Work thread Thread[Thread-2,5,main] - Order, submitted, fulfilled, shipped Created supplychain.customer.JavaCustomerComponentImpl using: java.net.URLClassL [EMAIL PROTECTED] Created supplychain.retailer.JavaRetailerComponentImpl using: java.net.URLClassL [EMAIL PROTECTED] Created supplychain.warehouse.JavaWarehouseComponentImpl using: java.net.URLClas [EMAIL PROTECTED] Created supplychain.shipper.JavaShipperComponentImpl using: java.net.URLClassLoa [EMAIL PROTECTED] Work thread Thread[Thread-4,5,main] - Order, submitted, fulfilled, shipped Created supplychain.illegal.JavaCustomerComponentImpl using: SCA contribution cl assloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributi on-test/target/contributions/IllegalCustomer.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Retailer.jar Created a retailer from Customer supplychain.retailer.JavaRetailerComponentImpl@ 3fac1e22 Created supplychain.customer.JavaCustomerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/CompleteSupplyChain.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/CompleteSupplyChain.jar Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA contribution classloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contrib ution-test/target/contributions/CompleteSupplyChain.jar Created supplychain.shipper.JavaShipperComponentImpl using: SCA contribution cla ssloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributio n-test/target/contributions/CompleteSupplyChain.jar Work thread Thread[Thread-6,5,main] - Order, submitted, fulfilled, shipped Created supplychain.customer.JavaCustomerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/CustomerImpl.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Retailer.jar Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA contribution classloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contrib ution-test/target/contributions/Warehouse.jar Created supplychain.shipper.JavaShipperComponentImpl using: SCA contribution cla ssloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributio n-test/target/contributions/Shipper.jar Work thread Thread[Thread-8,5,main] - Order, submitted, fulfilled, shipped Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.581 sec <<< FA ILURE! testIllegalStaticClassLoading1(org.apache.tuscany.sca.test.contribution.Contribu tionTestCase) Time elapsed: 0.219 sec <<< ERROR! java.lang.NullPointerException at org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.r esolveJavaInterface(JavaInterfaceProcessor.java:124) at org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.r esolve(JavaInterfaceProcessor.java:148) at org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.r esolve(JavaInterfaceProcessor.java:50) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProc essorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcess orExtensionPoint.java:320) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactP rocessor.resolve(ExtensibleS
Re: Running Tuscany/SCA in Google Android mobile platform
FYI, if you comment out the code that checks if a interface is remoteble, you could have a version of the calculator without any annotations, and the runtime would introspect the references for the multiple services. But note that, the introspection code will only be activated if there is no SCA annotations on the class. On Wed, May 21, 2008 at 1:21 AM, Adriano Crestani <[EMAIL PROTECTED]> wrote: > Ah, the expected exception should look like this on android emulator: > http://people.apache.org/~adrianocrestani/android_emulator.jpg > > On Tue, May 20, 2008 at 11:54 PM, Adriano Crestani < > [EMAIL PROTECTED]> wrote: > >> Hi Oscar, >> >> I was indeed using the sca modules not from the sandbox. As you suggested, >> I >> removed the tuscany-contribution-impl from my workspace and added the >> version you uploaded to the sandbox. Then, I uncommented the lines in >> >> >> org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator >> >> following the comments pointing out why those lines had been commented. I'm >> no longer getting the ClassNotFoundException. However, it's getting stuck >> somewhere else (before getting there I guess)...I think this is the case >> because before and after commenting the code I get the same error in the >> Android emulator, an InstantiationException [1]. >> >> Have you debugged to check exactly where this exception is being thrown? I >> have done the procedure I previously described again and I got it "running" >> as expected, which means, running till the expected exception is thrown. >> >> I also started tinkering with retrotranslator. First I tried doing it with >> Ant, but it seems that in order to build I have to include the whole >> tuscany >> projects in a way similar to how I now have in Eclipse. I also tried making >> a jar out of >> >> >> org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator >> >> and then feeding it to retrotranslator but unfortunately it's not >> translating anything, as shown below. >> >> Voyager-2:Retrotranslator-1.2 >> .6-bin ocastaneda$ java -jar >> retrotranslator-transformer-1.2.6.jar -srcjar >> JavaRuntimeModuleActivator.jar >> -target 1.5 -reflection safe -stripannot -classpath >> retrotranslator-android-1.2.6.jar >> Processing 136 file(s) in JavaRuntimeModuleActivator.jar. >> Transformed 0 file(s). >> >> There's also a maven plugin, so I might try that...but first I'll give Ant >> another go. Hopefully Google will release a new SDK soon, otherwise as you >> say...retrotranslator will have to be the workaround to proceed with our >> project ;-) >> >> Unfortunately the rumors say the new SDK version will not be released until >> july 28th :S. So, it's really good you have already started working on the >> retrotranslator, it will probably be the best workaround for the annotations >> problem till the next SDK release. >> >> I suggest you to forget about the build process right now, before, check if >> this retrotranslator works and if it really works on android platform. I´m >> really getting upset with Android, even its API methods does not work as >> expected :@. Anyway, try initially to compile a simple class (coded by you), >> which contains annotations, and access these annotations. If it works, make >> it more complex and test again, do it until you reach a scenario as complex >> as the SCA (a lot of external jars with annotated classes accessed by the >> other external jars and the Android app). Got it? : ) >> >> Regards, >> Adriano Crestani >> >> >> On Tue, May 20, 2008 at 1:53 PM, Oscar Castaneda < >> [EMAIL PROTECTED]> wrote: >> >>> Hi Adriano, >>> >>> I was indeed using the sca modules not from the sandbox. As you suggested, >>> I >>> removed the tuscany-contribution-impl from my workspace and added the >>> version you uploaded to the sandbox. Then, I uncommented the lines in >>> >>> >>> org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator >>> >>> following the comments pointing out why those lines had been commented. >>> I'm >>> no longer getting the ClassNotFoundException. However, it's getting stuck >>> somewhere else (before getting there I guess)...I think this is the case >>> because before and after commenting the code I get the same error in the >>> Android emulator, an InstantiationException [1]. >>> >>> I also started tinkering with retrotranslator. First I tried doing it with >>> Ant, but it seems that in order to build I have to include the whole >>> tuscany >>> projects in a way similar to how I now have in Eclipse. I also tried >>> making >>> a jar out of >>> >>> >>> org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator >>> >>> and then feeding it to retrotranslator but unfortunately it's not >>> translating anything, as shown below. >>> >>> Voyager-2:Retrotranslator-1.2.6-bin ocastaneda$ java -jar >>> retrotranslator-transformer-1.2.6.jar -srcjar >>> JavaRuntimeModuleActivator.jar >>> -target 1.5 -reflection safe -stripannot -classp
Graduation
"Special order 7B, Establish the Apache Tuscany Project, was approved by Unanimous Vote of the directors present." Congratulations guys! Matthieu
Re: Graduation
Hey, thanks for the good news. On Wed, May 21, 2008 at 2:14 PM, Matthieu Riou <[EMAIL PROTECTED]> wrote: > "Special order 7B, Establish the Apache Tuscany Project, was approved by > Unanimous Vote of the directors present." > > Congratulations guys! > > Matthieu > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
[jira] Created: (TUSCANY-2333) demos/samples/tutorials in "Java SCA Documentation" do not work (3 of them all fail, on Linux, at least)
demos/samples/tutorials in "Java SCA Documentation" do not work (3 of them all fail, on Linux, at least) Key: TUSCANY-2333 URL: https://issues.apache.org/jira/browse/TUSCANY-2333 Project: Tuscany Issue Type: Bug Components: Java SCA Documentation Affects Versions: Java-SCA-1.2 Environment: Fedora 9 Eclipse Europa EE version 3.3.2 java-1.6.0-openjdk-1.6.0.0 Reporter: Eric Herget On the Java SCA Document page (for version 1.2) the last 3 of the 4 links in the User Guide section point to tutorial/sample/demo documents that describes steps/sample/tutorial which fail to work as described. I didn't try the document behind the first link. The 3 other documents are identified below with specific issues in each listed. Based on the fact that none of the 3 documents I tried to use to help me learn more about Tuscany actually worked, I suspect there is a greater, underlying problem. That being that no one is keeping the sample/demo/tutorial docs in sync with new releases, or at least not checking that these documents describe steps that work on linux/Fedora/openjdk/java 1.6/eclipse3.3.2/etc The documents and their specific problems are: Getting Started with Tuscany using a Tuscany Distribution In Eclipse - it describes using version 1.1, not 1.2 of Tuscany - when creating ShoppingCartImpl, two imports from this package don't exist: org.apache.tuscany.sca.binding.feed.collection... there is no ...binding.feed... package, but there is ...binding.rss... and ...binding.atom... Getting Started with Tuscany using the Tuscany Eclipse plugin - is just a slightly modified version of the non-plugin document above - it says add "Tuscany Library" to project libraries (this is correct), but screen shot shows "TUSCANY" and not "Tuscany Library" (this is incorrect and probably left from original, non-eclipse document) - none of the org.apache.tuscany.sca.binding imports can be found - none of the com.sun.syndication... imports can be found First Steps - Building your first web services using Tuscany - In step where running helloworld.composite as Tuscany, console shows 2 different exceptions: -- first, early exception is "SEVERE: IOException while loading persisted sessions: java.io.EOFException -- later exception is (while trying to start helloworld composite) "SEVERE: Could not start composite org.osoa.sca.ServiceRuntimeException: javax.xml.stream.XMLStreamException: Non-default namespace can not map to empty URI (as per Namespace 1.0 # 2) in XML 1.0 documents -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2334) Tuscany plugin for Eclipse doesn't support alternative install locations
Tuscany plugin for Eclipse doesn't support alternative install locations Key: TUSCANY-2334 URL: https://issues.apache.org/jira/browse/TUSCANY-2334 Project: Tuscany Issue Type: Bug Components: Java SCA Documentation, Java SCA Tools Affects Versions: Java-SCA-1.2 Environment: Windows, Eclipse 3.3.2 Reporter: Lee Surprenant Priority: Minor I tried to run through the steps at http://archive.apache.org/dist/incubator/tuscany/java/sca/1.2-incubating/updatesite/, but hit an unusual problem. 1. Create a new update site and select the tuscany feature from http://archive.apache.org/dist/incubator/tuscany/java/sca/1.2-incubating/updatesite/ 2. Accept the license but install to a location other than the default (eg. use Add Location...). installation succeeds so restart eclipse. 3. Create a new java project and add the TUSCANY library as described 4. Note that the TUSCANY library does not show up in package explorer due to the fact it contains no jars/entries! When I tried this again and used the default eclipse plugins directory (C:/eclipse/plugins for me), things worked just fine. This is an inconvenience for folks like me who use multiple plugin locations for eclipse...although I mostly just wanted to capture/record the limitation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Graduation
Congratulations to all. -Original Message- From: Luciano Resende <[EMAIL PROTECTED]> Sent: Wednesday, May 21, 2008 2:19 PM To: tuscany-dev@ws.apache.org Subject: Re: Graduation Hey, thanks for the good news. On Wed, May 21, 2008 at 2:14 PM, Matthieu Riou <[EMAIL PROTECTED]> wrote: > "Special order 7B, Establish the Apache Tuscany Project, was approved by > Unanimous Vote of the directors present." > > Congratulations guys! > > Matthieu > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: Graduation
I'm excited to hear the great news. We finally graduate in the graduation season after a long journey! Cheers, Tuscany is now a TLP! Thanks, Raymond -- From: "Matthieu Riou" <[EMAIL PROTECTED]> Sent: Wednesday, May 21, 2008 2:14 PM To: "tuscany-dev" Subject: Graduation "Special order 7B, Establish the Apache Tuscany Project, was approved by Unanimous Vote of the directors present." Congratulations guys! Matthieu
Re: NPE in BaseWireBuilderImpl with reference bindings that specify URIs
Jean-Sebastien Delfino wrote: After some fun debugging today I realized that something has changed in how reference bindings are configured, breaking with an NPE on references with bindings that specify URIs, like follows: http://catalog"; name="catalog-mediation"> http://localhost:8105/MediatedVegetablesCatalog"/> Instead of seeing an EJB binding in the memory model representing the reference, I'm now seeing an SCA binding, with no URI, causing the following NPE: info: severe: SCA Node could not be created info: java.lang.reflect.InvocationTargetException info: at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) info: at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) info: at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) info: at java.lang.reflect.Constructor.newInstance(Constructor.java:513) info: at org.apache.tuscany.sca.node.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:297) info: at org.apache.tuscany.sca.node.launcher.NodeLauncher.createNode(NodeLauncher.java:60) info: at org.apache.tuscany.sca.node.launcher.NodeLauncher.main(NodeLauncher.java:122) info: Caused by: org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException info: at org.apache.tuscany.sca.node.impl.NodeImpl.(NodeImpl.java:155) info: at org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANode(NodeFactoryImpl.java:37) info: at org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.(NodeImplementationLauncherBootstrap.java:94) info: ... 7 more info: Caused by: java.lang.NullPointerException info: at org.apache.tuscany.sca.assembly.builder.impl.BaseWireBuilderImpl.createComponentReferenceTargets(BaseWireBuilderImpl.java:524) info: at org.apache.tuscany.sca.assembly.builder.impl.BaseWireBuilderImpl.connectComponentReferences(BaseWireBuilderImpl.java:599) info: at org.apache.tuscany.sca.assembly.builder.impl.BaseWireBuilderImpl.wireComponentReferences(BaseWireBuilderImpl.java:117) info: at org.apache.tuscany.sca.assembly.builder.impl.ComponentReferenceWireBuilderImpl.build(ComponentReferenceWireBuilderImpl.java:44) info: at org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:140) info: at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.buildComposite(ReallySmallRuntime.java:237) info: at org.apache.tuscany.sca.node.impl.NodeImpl.configureNode(NodeImpl.java:333) info: at org.apache.tuscany.sca.node.impl.NodeImpl.(NodeImpl.java:152) info: ... 9 more info: Exception in thread "main" org.apache.tuscany.sca.node.launcher.LauncherException: java.lang.reflect.InvocationTargetException info: at org.apache.tuscany.sca.node.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:330) info: at org.apache.tuscany.sca.node.launcher.NodeLauncher.createNode(NodeLauncher.java:60) info: at org.apache.tuscany.sca.node.launcher.NodeLauncher.main(NodeLauncher.java:122) info: Caused by: java.lang.reflect.InvocationTargetException info: at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) info: at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) info: at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) info: at java.lang.reflect.Constructor.newInstance(Constructor.java:513) info: at org.apache.tuscany.sca.node.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:297) info: ... 2 more info: Caused by: org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException info: at org.apache.tuscany.sca.node.impl.NodeImpl.(NodeImpl.java:155) info: at org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANode(NodeFactoryImpl.java:37) info: at org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.(NodeImplementationLauncherBootstrap.java:94) info: ... 7 more info: Caused by: java.lang.NullPointerException info: at org.apache.tuscany.sca.assembly.builder.impl.BaseWireBuilderImpl.createComponentReferenceTargets(BaseWireBuilderImpl.java:524) info: at org.apache.tuscany.sca.assembly.builder.impl.BaseWireBuilderImpl.connectComponentReferences(BaseWireBuilderImpl.java:599) info: at org.apache.tuscany.sca.assembly.builder.impl.BaseWireBuilderImpl.wireComponentReferences(BaseWireBuilderImpl.java:117) info: at org.apache.tuscany.sca.assembly.builder.impl.ComponentReferenceWireBuilderImpl.build(ComponentReferenceWireBuilderImpl.java:44) info: at org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:140) info: at org.apache.tuscany.sca.hos
How can we turn on/off Rampart conditionally for binding.ws over Axis2?
Hi, In the latest binding-ws-axis2 code, we always have module "rampart" activated in [1]. Consequently, rampart gets on the way for all Axis2 based binding.ws invocations. The worst part is that one of the rampart handlers try to read some data from the SOAP envelope and it forces the whole OMElement to be fully loaded before it is sent to the HTTP. This behavior pretty much defeats the performance optimization I'm working on to wrap JAXB objects into a SourcedOMElement so that the JAXB objects will only be serialized once when the message is sent to the HTTP connection. I understand rampart is configured to support WS-Security. But I don't think we should always pay the penalty in the cases where WS-Security is not required at all. Is there an option to turn on/off Rampart conditionally (maybe by some code in tuscany-policy-security-ws)? Thanks, Raymond [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/ws/axis2/engine/config/axis2.xml
[GSoC] Map-Reduce Integration with Tuscany
Hi everyone, I have been fleshing out a slightly more detailed plan for the upcoming weeks, and would like to share it with the community and get some feedback. For the first iteration I am planning to focus on Java implemented Map- Reduce (MR) applications. These apps interface directly with Hadoop's MR framework[1], as opposed to Hadoop Streaming[2] or Pipes[3]. I think the first priority should be to get a basic MR data flow working, and the three necessary entities of a basic MR application seem to be the Mapper, the Reducer, and a job configuration. I am planning on getting the functionality for these three parts implemented first. Going along with the original design in the proposal, I am planning to view the Mapper and the Reducer as implementation types, and the job configuration as part of a management layer in charge of the assembly and deployment of MR applications. Initially the management layer would be responsible for the configuration of MR jobs and the integration with Hadoop's MR framework, with the overall goal of eventually extending it into something more along the lines of what was described by Robert Donkin[4] and Jean-Sebastian (referred to as item 3)[5]. In this case, the layer could be used to manage the deployment of components over a Hadoop cluster itself. For the Mapper and Reducer, in the next couple of weeks I would like to outline the definition of these types and hopefully start implementing them. For the management layer, I could use some guidance on how to best fit it into the Tuscany architectural framework. Thoughts/Suggestions on any part of my plans are always greatly appreciated. Congrats to everyone for graduation! Thanks, Chris Trezzo [1] http://hadoop.apache.org/core/docs/r0.15.3/api/org/apache/hadoop/mapred/package-summary.html [2] http://hadoop.apache.org/core/docs/current/streaming.html [3] http://hadoop.apache.org/core/docs/r0.15.3/api/org/apache/hadoop/mapred/pipes/package-summary.html [4] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29711.html [5] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29720.html
Re: Graduation
Congratulations ! 2008/5/22, Haleh Mahbod <[EMAIL PROTECTED]>: > > Congratulations to all. > > -Original Message- > From: Luciano Resende <[EMAIL PROTECTED]> > Sent: Wednesday, May 21, 2008 2:19 PM > To: tuscany-dev@ws.apache.org > Subject: Re: Graduation > > Hey, thanks for the good news. > > On Wed, May 21, 2008 at 2:14 PM, Matthieu Riou <[EMAIL PROTECTED]> > wrote: > > "Special order 7B, Establish the Apache Tuscany Project, was approved by > > Unanimous Vote of the directors present." > > > > Congratulations guys! > > > > Matthieu > > > > > > -- > Luciano Resende > Apache Tuscany Committer > http://people.apache.org/~lresende > http://lresende.blogspot.com/ > >
Re: Graduation
This is an exciting news. Congratulations. Thanks, Feng Wang On 2008-05-22 05:15:30,Matthieu Riou <[EMAIL PROTECTED]> wrote: >"Special order 7B, Establish the Apache Tuscany Project, was approved by >Unanimous Vote of the directors present." > >Congratulations guys! > >Matthieu >
Re: Graduation
That's great news. ++Vamsi On Thu, May 22, 2008 at 2:44 AM, Matthieu Riou <[EMAIL PROTECTED]> wrote: > "Special order 7B, Establish the Apache Tuscany Project, was approved by > Unanimous Vote of the directors present." > > Congratulations guys! > > Matthieu >
Re: Graduation
Congratulations everyone! Paul On Thu, May 22, 2008 at 3:43 AM, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: > That's great news. > > ++Vamsi > > On Thu, May 22, 2008 at 2:44 AM, Matthieu Riou <[EMAIL PROTECTED]> > wrote: > >> "Special order 7B, Establish the Apache Tuscany Project, was approved by >> Unanimous Vote of the directors present." >> >> Congratulations guys! >> >> Matthieu >> > -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com
Re: Build failure in itest/contribution-classloader (monitor problem)
On Wed, May 21, 2008 at 9:33 PM, Simon Nash <[EMAIL PROTECTED]> wrote: > I just did a clean checkout and full build. It failed in > itest/contribution-classloader with the following stack trace. > > The problem is caused by a null value in the "monitor" variable > on line 124 of JavaInterfaceProcessor. This does not seem to > happen for other tests. Any ideas? > > Simon > > Running org.apache.tuscany.sca.test.contribution.ContributionTestCase > Created supplychain.customer.JavaCustomerComponentImpl using: SCA > contribution c > lassloader for : > file:/F:/tuscany70/sca/itest/contribution-classloader/contribut > ion-test/target/contributions/Customer.jar > Created supplychain.retailer.JavaRetailerComponentImpl using: SCA > contribution c > lassloader for : > file:/F:/tuscany70/sca/itest/contribution-classloader/contribut > ion-test/target/contributions/Retailer.jar > Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA > contribution > classloader for : > file:/F:/tuscany70/sca/itest/contribution-classloader/contrib > ution-test/target/contributions/Warehouse.jar > Created supplychain.shipper.JavaShipperComponentImpl using: SCA > contribution cla > ssloader for : > file:/F:/tuscany70/sca/itest/contribution-classloader/contributio > n-test/target/contributions/Shipper.jar > Work thread Thread[Thread-2,5,main] - Order, submitted, fulfilled, shipped > Created supplychain.customer.JavaCustomerComponentImpl using: > java.net.URLClassL > [EMAIL PROTECTED] > Created supplychain.retailer.JavaRetailerComponentImpl using: > java.net.URLClassL > [EMAIL PROTECTED] > Created supplychain.warehouse.JavaWarehouseComponentImpl using: > java.net.URLClas > [EMAIL PROTECTED] > Created supplychain.shipper.JavaShipperComponentImpl using: > java.net.URLClassLoa > [EMAIL PROTECTED] > Work thread Thread[Thread-4,5,main] - Order, submitted, fulfilled, shipped > Created supplychain.illegal.JavaCustomerComponentImpl using: SCA > contribution cl > assloader for : > file:/F:/tuscany70/sca/itest/contribution-classloader/contributi > on-test/target/contributions/IllegalCustomer.jar > Created supplychain.retailer.JavaRetailerComponentImpl using: SCA > contribution c > lassloader for : > file:/F:/tuscany70/sca/itest/contribution-classloader/contribut > ion-test/target/contributions/Retailer.jar > Created a retailer from Customer > supplychain.retailer.JavaRetailerComponentImpl@ > 3fac1e22 > Created supplychain.customer.JavaCustomerComponentImpl using: SCA > contribution c > lassloader for : > file:/F:/tuscany70/sca/itest/contribution-classloader/contribut > ion-test/target/contributions/CompleteSupplyChain.jar > Created supplychain.retailer.JavaRetailerComponentImpl using: SCA > contribution c > lassloader for : > file:/F:/tuscany70/sca/itest/contribution-classloader/contribut > ion-test/target/contributions/CompleteSupplyChain.jar > Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA > contribution > classloader for : > file:/F:/tuscany70/sca/itest/contribution-classloader/contrib > ution-test/target/contributions/CompleteSupplyChain.jar > Created supplychain.shipper.JavaShipperComponentImpl using: SCA > contribution cla > ssloader for : > file:/F:/tuscany70/sca/itest/contribution-classloader/contributio > n-test/target/contributions/CompleteSupplyChain.jar > Work thread Thread[Thread-6,5,main] - Order, submitted, fulfilled, shipped > Created supplychain.customer.JavaCustomerComponentImpl using: SCA > contribution c > lassloader for : > file:/F:/tuscany70/sca/itest/contribution-classloader/contribut > ion-test/target/contributions/CustomerImpl.jar > Created supplychain.retailer.JavaRetailerComponentImpl using: SCA > contribution c > lassloader for : > file:/F:/tuscany70/sca/itest/contribution-classloader/contribut > ion-test/target/contributions/Retailer.jar > Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA > contribution > classloader for : > file:/F:/tuscany70/sca/itest/contribution-classloader/contrib > ution-test/target/contributions/Warehouse.jar > Created supplychain.shipper.JavaShipperComponentImpl using: SCA > contribution cla > ssloader for : > file:/F:/tuscany70/sca/itest/contribution-classloader/contributio > n-test/target/contributions/Shipper.jar > Work thread Thread[Thread-8,5,main] - Order, submitted, fulfilled, shipped > Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.581 sec > <<< FA > ILURE! > > testIllegalStaticClassLoading1(org.apache.tuscany.sca.test.contribution.Contribu > tionTestCase) Time elapsed: 0.219 sec <<< ERROR! > java.lang.NullPointerException >at > org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.r > esolveJavaInterface(JavaInterfaceProcessor.java:124) >at > org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.r > esolve(JavaInterfaceProcessor.java:148) >at > org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.r > esolve(JavaInterfaceProcessor.java:50) >
Re: Graduation
On 5/22/08, Paul Fremantle <[EMAIL PROTECTED]> wrote: > Congratulations everyone! +1 Robert > > Paul > > On Thu, May 22, 2008 at 3:43 AM, Vamsavardhana Reddy > <[EMAIL PROTECTED]> wrote: >> That's great news. >> >> ++Vamsi >> >> On Thu, May 22, 2008 at 2:44 AM, Matthieu Riou <[EMAIL PROTECTED]> >> wrote: >> >>> "Special order 7B, Establish the Apache Tuscany Project, was approved by >>> Unanimous Vote of the directors present." >>> >>> Congratulations guys! >>> >>> Matthieu >>> >> > > > > -- > Paul Fremantle > Co-Founder and CTO, WSO2 > Apache Synapse PMC Chair > OASIS WS-RX TC Co-chair > > blog: http://pzf.fremantle.org > [EMAIL PROTECTED] > > "Oxygenating the Web Service Platform", www.wso2.com >
