Re: svn commit: r533445 [1/4] - in /incubator/tuscany/java/sca: itest/contribution/src/test/java/org/apache/tuscany/sca/test/contribution/ modules/assembly-java-dsl/src/main/java/org/apache/tuscany/as
ant elder wrote: On 5/1/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] ant elder wrote: So now in the Axis2 binding the start method of the Axis2ModuleActivator it news up a whole lot of factories - DefaultAssemblyFactory, DefaultPolicyFactory, DefaultWebServiceBindingFactory, DefaultWSDLFactory, DefaultWSDLInterfaceIntrospector, and the WebServiceBindingProcessor What you're describing here is an assembly, described before in SCDL, now built in Java code. This is basically the role of a ModuleActivator: assemble the pieces required for a particular extension. This is not just for factories, WSDLInterfaceIntrospector, WebServiceBindingProcessor, JavaInterfaceIntrospector, JavaClassIntrospector, our default InterfaceContractMapper, the default databinding Mediator are all in the same category. They are newed up at the edges of our runtime, in SimpleRuntimeImpl or in the ModuleActivator of an extension, and assembled there. - none of those are used by the Axis2 binding and they tie the binding to the xml ws binding impl. Should binding.ws.xml have its own ModuleActivator that does all this? I would be fine with moving this assembly logic out of the Axis2ModuleActivator, but it needs to be done somewhere :) The work I did recently to push these assembly decisions to the edges should now make it easier to put this assembly logic anywhere we want, and should allow us to not be tied to a specific implementation of binding.ws for example and select it in the assembly - at the top of the stack - as opposed to having it hardcoded in the lower runtime layers like before. So how about I add a ModuleActivator to binding-ws-xml to do it seeing thats what the assembly is for? Or does it need another completely seperate module? Module binding-ws-xml does not depend on core-spi. The idea is to keep it independent of the rest of the core runtime to make it easier to reuse by other projects who will want to support the SCA assembly XML syntax, without necessarily integrating the Tuscany core runtime. To avoid tieing modules together this assembly code is probably better kept at the very edge/top of the stack. I understand that having to new up the factories in Axis2ModuleActivator extension is not great, but I think it's just a point in time limitation. There are many ways to change that: a) Move the assembly to an entirely different module. but it's still not great to hardcode the selection of factories, introspectors etc. there either b) Move the DefaultXyzFactory classes out of an impl package and into an SPI package, this is mostly cosmetics and does not really change the pattern c) Have XyzFactory abstract factory classes with a static newInstance() method to new up the DefaultXyzFactory d) Have the XyzFactory abstract factory classes externally configurable, allowing you to keep the factory selection out of the extension e) Have SimpleRuntimeImpl (which creates most factories) pass them to the constructor or some setter methods of the ModuleActivators f) Define a ModelFactory extension point and have the ModuleActivator do extensionPoint.getFactory(XyzFactoryInterface.class) to get a factory g) Use an IoC container to pass the factories to the ModuleActivators as a fancy way to do (e). I think we should give it a little bit of time before jumping to implement one of these patterns, and first observe what factories or other similar common objects are actually needed in most extension ModuleActivators over time. If you think that the current pattern (having to new up the factories and a few other objects in the ModuleActivators) is problematic, I'd suggest to implement options (e) or (f). One thing I don't like so much is all those default factories have .impl. in package name and that makes it look like you're not using the SPI properly, how about moving all the default factories up to the top level package in their module? Yes, good idea. How about renaming DefaultXyzFactory to XyzFactory, and having a newInstance() method on it. But there's already XyzFactory interfaces in the top level package so wont that clash, or am i missing what you're suggesting? Sorry I was not clear. We could do one of the following: - change XyzFactory to a XyzFactory class - change XyzFactory to an abstract class with XyzFactory.newInstance() creating a DefaultXyzFactory - have a configurable XyzFactory abstract class I also think that we need a way for the runtime bootstrap code to select some of these core pieces (a factory, an introspector, a mediator etc.) and have the extensions pick that selection instead of making their own selection... without turning it into a static singleton :) We can probably do this in a second step when we have a good view of what pieces are usually assembled by what kind of extension, and what falls under the responsiblity of the runtime or host assembler vs the extension developer. This may not be so relevant
Re: [C++] SDO overlapping annonymous types problem
On 5/1/07, Pete Robbins [EMAIL PROTECTED] wrote: I've checked in a fix to append 1, 2 etc to anonymous type names that clash. In your example you will get types Overlapping and Overlapping1. Cheers, On 01/05/07, Simon Laws [EMAIL PROTECTED] wrote: On 5/1/07, Pete Robbins [EMAIL PROTECTED] wrote: Simon, I'll take a look at this. It may be fairly simple to mirror what the Tuscany Java implementation does. On 01/05/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/30/07, Frank Budinsky [EMAIL PROTECTED] wrote: This is an open issue against the SDO specification. In Tuscany SDO-Java we automatically rename such duplicates: e.g., the second type would be named Overlapping1. The next version of the spec needs to define a standard way to handle this. Frank. Pete Robbins [EMAIL PROTECTED] wrote on 04/30/2007 09:30:34 AM: Is this a specification problem? I'm fairly sure the SDO spec states that the Type name for an anonymous type is taken from the enclosing element. In your example you have 2 types with the same name in the same namespace. Cheers, On 27/04/07, Simon Laws [EMAIL PROTECTED] wrote: I talking to a user of the PHP SDO implementatio about a problem they have where SDO fails to parse an XML file with the error: SDO_DAS_XML_ParserException - unknown element errors... Looking at the code what seems to be going on is that annonymous types are being overwritten when the annonymous types have the same element name, for example, If I have the schema: ?xml version=1.0 encoding=UTF-8? schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=http://www.example.org/AnnonTypes; xmlns:tns=http://www.example.org/AnnonTypes; elementFormDefault=qualified element name=Top complexType sequence element name=ElementA complexType sequence element name=Overlapping complexType sequence element name=ValueA type=string/ /sequence /complexType /element /sequence /complexType /element element name=ElementB complexType sequence element name=Overlapping complexType sequence element name=ValueB type=string/ /sequence /complexType /element /sequence /complexType /element /sequence /complexType /element /schema And the XML ?xml version=1.0 encoding=UTF-8? tns:Top xmlns:tns=http://www.example.org/AnnonTypes; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.example.org/AnnonTypes AnnonTypes.xsd tns:ElementA tns:Overlapping tns:ValueAtns:ValueA/tns:ValueA /tns:Overlapping /tns:ElementA tns:ElementB tns:Overlapping tns:ValueBtns:ValueB/tns:ValueB /tns:Overlapping /tns:ElementB /tns:Top I looked to see if this had been raised as a bug and It didn't look like it had. I'll go and do that but was just wondering if that was by design for some reason? To fix this we would have to construct a scoping mechanism for annonymous types based on the context in which they appear. Regards Simon -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ok thanks Frank/Pete. I checked the C++ spec and it does just say that the name of the annonymous type is the same as the name of the enclosing element declaration. So it's working as specified but we need to fix the spec. I recorded this as TUSCANY-1238 lest we forget. Regards Simon -- Pete Ok, thanks Pete. Simon -- Pete Cool. Thanks Pete. I'll give it a sping. Simon
SCA WS Axis binding
Hi,
I found a bug in Input2InputTransformer.java (179)
Object[] newArgs = new Object[source.length];
for (int i = 0; i source.length; i++) {
Object child = mediator.mediate(source[i],
sourceType.getLogical().get(i), targetType.getLogical().get(i),
context.getMetadata());
newArgs[i] = child;
}
When try parse a java to wsdl
My java interface method = public TimeSlot editReservation(int timeSlotID,
String requestedBy, String purpose, int[] resourcesID);
I have 4 input params
and my wsdl have 1 element with an type having 4 paramenters
When run this code whe have an IndexOutOfBoundsException
Exception in thread main java.lang.IndexOutOfBoundsException: Index: 1,
Size: 1
at java.util.ArrayList.RangeCheck(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at
org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.transform
(Input2InputTransformer.java:179)
at
org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.transform
(Input2InputTransformer.java:1)
at org.apache.tuscany.databinding.impl.MediatorImpl.mediate(
MediatorImpl.java:83)
at
org.apache.tuscany.core.databinding.wire.DataBindingInteceptor.transform(
DataBindingInteceptor.java:189)
at org.apache.tuscany.core.databinding.wire.DataBindingInteceptor.invoke
(DataBindingInteceptor.java:86)
at org.apache.tuscany.spi.wire.AbstractInvocationHandler.invoke(
AbstractInvocationHandler.java:91)
at
org.apache.tuscany.implementation.java.proxy.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:150)
Not to be that I must work with OMElement in my java interface.
--
Paulo Henrique Trecenti
[jira] Created: (TUSCANY-1239) Statement::executeQuery and Statement::execute should throw exception
Statement::executeQuery and Statement::execute should throw exception - Key: TUSCANY-1239 URL: https://issues.apache.org/jira/browse/TUSCANY-1239 Project: Tuscany Issue Type: Improvement Components: C++ DAS Affects Versions: Wish list Reporter: Adriano Crestani Fix For: Wish list Statement::executeQuery and Statement::execute should throw some kind of exception when the statement query is not successfully completed. -- 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]
Mais um jira criado
Nao lembro se vc disse q ainda iria fazer ou eskeceu oq estah descrito no jira [1], mas d qq forma criei um jira pra isso. Se fizer basta attachar o patch lah ; ) [1] https://issues.apache.org/jira/browse/TUSCANY-1239 Adriano Crestani
Re: Mais um jira criado
Sorry guys, This email was not inteded to the ML I committed a mistake and typed the ML address. Just ignore it! Sorry again :( Adriano Crestani On 5/2/07, Adriano Crestani [EMAIL PROTECTED] wrote: Nao lembro se vc disse q ainda iria fazer ou eskeceu oq estah descrito no jira [1], mas d qq forma criei um jira pra isso. Se fizer basta attachar o patch lah ; ) [1] https://issues.apache.org/jira/browse/TUSCANY-1239 Adriano Crestani
[jira] Commented: (TUSCANY-1171) SDO Java beta1 Release
[ https://issues.apache.org/jira/browse/TUSCANY-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493034 ] Kelvin Goodson commented on TUSCANY-1171: - Here's an example command I used to copy repository artifacts to the staging repository. Note that I copied these to local temporary copies out of the repository first because maven fails if you try to do it within the repository. C:\tempmvn deploy:deploy-file -DgroupId=commonj -DartifactId=sdo-api-r2.1 -Dfile=sdo-api-r2.1-1.0-incubating-beta1.jar -DrepositoryId=people.apache.org -Durl=scp://people.apache.org/home/kelvingoodson/home/public_html/repo -DpomFile=sdo-api-r2.1-1.0-incubating-beta1.pom -Dpackaging=jar SDO Java beta1 Release -- Key: TUSCANY-1171 URL: https://issues.apache.org/jira/browse/TUSCANY-1171 Project: Tuscany Issue Type: Task Components: Java SDO Implementation, Java SDO Samples, Java SDO Tools Reporter: Kelvin Goodson Assigned To: Kelvin Goodson Fix For: Java-SDO-beta1 Attachments: buildSDORelease.bat, rat_exceptions.txt, rat_report.zip, rat_report.zip -- 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: Next SCA release distributions
On 4/30/07, ant elder [EMAIL PROTECTED] wrote: Excellent thanks, thats type type feedback I was looking for! Comments in line... On 4/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip/ I have a few questions and suggestions. - tuscany-sca.jar contains .svn directories, I guess they should be removed from the JAR. I can't see these, i could just be blind or maybe its something different about our environments could you give an example of what the file names are? - Also 2 empty xsds at the root of the JAR and com.example packages, they must be coming from one of the examples? The com.example.* files are coming from the databinding-jaxb and databinding-sdo modules, we need to fix those modules but I'm not sure how. It looks like the jaxb and sdo plugins need to some way to say they're test resources. Any one know how to fix this? I can't see the 2 empty xsds, something different about our environments again? - I guess we're going to rename this to sca-1.0-beta1-incubating? Yes, the name should be being picked up from the pom, but i'll test it does change. (Using the current format the name would be 1.0-incubating-beta1, do we really want 1.0-beta1-incubating?) - Like you said above, we'll have to include the javadoc for our SPIs. Yes, I guess I can add that in now even though the SPIs aren't done by just including the tuscany-core-spi module javadoc. Is javadoc for just these two modules enough (sca-api and core-spi). I've added this now, are there other modules we want javadoc for? - How did you produce the single META-INF/services/...ModuleActivator file? is it generated? This is done in the java/sca/distribution/bundle project using the Maven Shade plugin, see in the pom.xml the shade config where a Shade AppendingTransformer is used to merge all the ModuleActivator files into one. No doc at all about the Shade plugin that I could find, I got this from looking at the CXF build and the Shade plugin source code. - We have two different servlet-api JARs, should we pick one? Fixed. The 6.0.10 one was coming from the http-tomcat module so i've added exclusions in that pom.xml. - Could we have, in the bin distro, a tuscany-sca-src.jar containing all the source code for the classes in tuscany-sca.jar? Thats a good idea, I'm not sure how though. The tuscany-sca.jar is built from all the dependency elements listed in the distribution/bundle/pom.xml, I could make a src jar by just zipping up everything in sca/modules but it may end up including more than is in the tuscany-sca.jar. Anyone have any better ideas on how to do this? - How about renaming tuscany-sca.jar to tuscany-sca-all.jar, or any name indicating that it's all the tuscany code? OK, done. - The NOTICE will have to be updated as it contains obsolete dependencies. Yep. Over the next days I'll trawl through all the license and notice files to make sure they're correct. - I think it would be great to have Ant build scripts for some of the samples, as not everybody is using Maven. Me too, I'll try to get one going today. Should we have all the samples have both maven and Ant build scripts, or just Ant, or some samples have Ant and others have Maven? - Pre-built sample JARs would be great too, but not as important if we have a simple Ant build for the samples. There are pre-built sample jars in the sample target directory, eg, samples\calculator\target\tuscany- sample-calculator-1.0-incubating-SNAPSHOT.jar I've updated the distribution build scripts with the above changes now. ...ant Hi I just this minute took a fresh update of sca to make ant scripts for the samples. I have some questions... - why does tuscany-sca-manifest.jar not have a version number? - What is intention of tuscany-sca-all I need a classpath with all tuscany jars on. Currently its in tuscany-sca-manifest but it doesn't pick up the dependencies in the modules directory as they are in ../modules - tuscany-rmi? Should this be a binding I've checked in a build.xml to the calculator sample that I'm playing with (I took it from M2). But thinking about this if we go with ant builds for this release it would be good if they work for the binary release and the src release. Even if its just the run target. So how to we construct the classpath to make this work. I'm just building th src distro to see if it creats a lib dir but we could do with something like tuscan-sca-manifest to keep the ant script simple. As I'm looking at the calculator sample I'm updating the readme.html. I plan to reinstate sca/doc/css if no one has any objections. Regards Simon
ant build scripts for SCA samples
I saw the following discussion in Monday's IRC chat log. (I couldn't attend the chat because I was on a plane.) [12:37] ant_ oh, so with the samples again, I guess we need Ant build scripts [12:37] ant_ lresende, it does right now and i think thats good to do [12:38] jsdelfino yes, +1 for the sample bins [12:38] lresende yes, i like that, but haven't looked into your distro strawman yet [12:38] slaws ant_ - a non maven build solution for samples would be useful [12:38] ant_ do we want mvn as well or just Ant? [12:39] jsdelfino what's the work required to have a mvn build for the samples? don't we already have bit? [12:39] jsdelfino I think we could keep the mvn build, but document the ant one [12:40] slaws if we have two we need to decide whether we maintain two or just fix up ant for releases [12:40] ant_ ok. i guess we just need to make sure the sample mvn's work in the build distro with an empty local repo [12:41] ant_ would anyone like to volunteer to create an Ant script for one of the samples? [12:42] jsdelfino anyone? it shouldn't be too hard, we even had this in M1... [12:42] slaws didn't someone already create some for a previous release that we can lift [12:42] halehM Maybe someone on the mailing list who is not on the IRC? [12:42] halehM post on mailing list? [12:43] ant_ ok, lets skip that one for now then I did some work on this for M2 but nothing was included in the release because of disagreements about some aspects of my proposal. The two main issues were how webapps get built and how dependencies are resolved. I'll look at this again based on the currently proposed release packaging. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Java SDO CTS] thoughts on structure
I'm inclined to agree that a blanket approach to this kind of testing is not
best. The more directed the tests are the better we can understand how
comprehensive the CTS is.
However, it's not clear to me whether we can now confirm the types are as
they should be through the metadata API alone, or whether there are still
requirements on an implementation to preserve elements of metadata that can
only be detected by the behaviour seen through the data API. However, if
it's purely some facets of XSD behaviour that we needed to test empirically
then that wouldn't require a parameterized approach.
I think this kind of parameterized testing is well suited to finding issues
that might not otherwise be found when exercising code that must handle
arbitrary graphs, but most of the tests we have in place are written with
tight preconditions on the inputs. So to run multiple graphs displaying
interesting facets through the EqualityHelper for instance might be a good
use of the technique. In that case the parameterized data sets would need to
include a description of the expected result. For the case of
EqualityHelper that would be easy {true|false}, but for say the XMLHelper's
serialization function it requires a bit more work, as the variability of
output is permitted in the XML literal space.
There is an argument in favour retaining at least some level of the current
mode parameterized testing, related to testing of static classes. The spec
doesn't cover static classes yet, but the parameterized infrastructure that
we have in place permits an implementation to augment the set of inputs with
some of its own. So for the case we currently have, where metadata has
been generated by the implementation independent CTS infrastructure from an
XSD and via the dynamic API, Tuscany for example could make use of the
call-out in BaseSDOParameterizedTest's data() method to add one or more
sets of data create from static classes and those would be run against the
tests.
I can to some extent see a theoretical/academic reason for having
implementation independent equality testing code in the CTS, but
practically this leads to a who tests the testers scenario. If we build
tests that make the assumption that the equality helper of the
implementation under tests is trusted, then we have to ensure that the suite
of tests applied to the equality helper itself warrants that trust.
+1 to simplifying the interface of the TestHelper.
Kelvin.
On 01/05/07, Frank Budinsky [EMAIL PROTECTED] wrote:
I think this approach sounds a little too brute force. Regardless of how
the metadata is defined, once instances are created in memory, they will
be exactly the same. Verifying this by repeating every possible test on
the exact same DataObjects, just created differently, sounds a little
inefficient. What I think we need instead is to have some set of
consistency tests that confirm that the types created in various ways are
in fact the same.
The parameterized tests approach might be a good way to
do that, but the tests that need to run to confirm this is a small subset
of all the functionality of SDO. Testing every API N times is definitely
overkill IMO.
Actually, it's probably sufficient to have a parameterized test that
simply walks through the metadata and confirms the types and properties
are as expected. All the DataObject tests do not need to be parameterized
at all.
I've noticed some overlap between the parameterized and non parameterized
tests. It also looks like the parameterized tests make a lot of
Tuscany-specific assumptions. I also wonder why ParameterizedTestUtil has
it's own equals code (instead of just using EqualityHelper). Maybe we
should just remove all these tests, and then resubmit/merge any unique
tests with the appropriate non parameterized tests.
One more thing, I noticed that the TestHelper is unnecessarily
complicated. Instead of having all kinds of getXXXHelper() methods, it
should just have one getHelperContext() method - that's the only method
that is implementation dependant. Other methods, e.g., createPropertyDef()
are also not implementation dependent, so they shouldn't be in the
TestHelper interface. I think we should clean this up and simplify it now,
before we have so many tests that we won't want to change it anymore.
Thoughts?
Frank.
Robbie Minshall [EMAIL PROTECTED] wrote on 05/01/2007 12:06:03 PM:
I agree that the tests should be structured in a way that is spec and
functionaly orientated. I have never really liked the split between
paramatized and non paramatized tests so getting rid of this is just
fine.
Other than that I think that the test cases are more or less organized
by API though I am sure some changes could be beneficial.
The idea behind the paramatized tests does indeed lean towards
consistency. In general the SDO API should apply regardless of the
creation means for the DataObject ( static, dynamic, mixed, the old
relational DB DAS or any other
Re: svn commit: r531727 - Bring up of helloworld-ws and helloworld-wsclient WS binding samples
This looks like its caused by the move up to Axis2 1.2 which has in its pom a dependeny on woodstox 3.2.1 where as Tuscany is using 3.2.0. I guess Maven is getting confused as there's two versions and the one that ends up getting used is environment dependent. I've added excludes for the 3.2.1 version to where we reference axis2-kernel, could you try again with the latest code and see if that fixes it for you? ...ant On 5/1/07, Matthew Sykes [EMAIL PROTECTED] wrote: Ant, FWIW, this still isn't working for me. I just did an update and a full build and I'm getting the following: Exception in thread main javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:72) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:178) at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:155) at org.apache.tuscany.core.runtime.AbstractRuntime.init( AbstractRuntime.java:103) at org.apache.tuscany.host.embedded.impl.SimpleRuntimeImpl.init( SimpleRuntimeImpl.java:85) at org.apache.tuscany.host.embedded.impl.DefaultSCARuntime.startup( DefaultSCARuntime.java:41) at org.apache.tuscany.host.embedded.SCARuntime.start(SCARuntime.java:153) at calculator.CalculatorClient.main(CalculatorClient.java:32) It looks like the manifest that is generated has stale data. In particular, wstx-asl-3.2.0.jar is referenced instead of the wstx-asl-3.2.1.jar that was collected into the distribution. I guess it seems a little odd to me that maven is smart enough to grab the right jars for the distribution but not smart enough to use them when building the manifest class path. Any ideas short of hand crafting my manifest? Thanks. ant elder wrote: Great! Thanks for taking the time to debug the issues. ...ant On 5/1/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: Ok, yes, could not right away tell whether the databinding NPE was caused by databinding code or not. I have rebuilt spec/sdo-api and sdo and the distribution and now the helloworld-ws and helloworld-wsclient run cleanly. Thanks On 5/1/07, ant elder [EMAIL PROTECTED] wrote: Ok thats good that its looking better! I'd guess that maybe the SDO version you have in your local repos isn't at the latest code level. SDO isn't getting built as part of the SCA build and I don't think an SDO snapshot has been published recently so you have to build this yourself. So with a latest checkout of tuscany/java/ run mvn in spec/sdo-api and then again in tuscany/java/sdo. This will be fixed when the SDO beta1 release is officially released which should be happening real soon now. ...ant On 5/1/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: Ok, so the good news is that things seem to be going according to your thought. I did a full update, mvn clean;mvn of java/sca and then of java/sca/distribution and after unzipping the distribution, the manifest does show axis2-kernel-1.2.jar now. The not-so-good news is that when I try to run the server sample I now get an NPE from databinding.sdo: http://rafb.net/p/UXXcbV34.html This seems to be completely unrelated to the previous issue but I bring it up since others may not be able to run the sample successfully either, unless I'm doing someting wrong ... Thanks On 5/1/07, ant elder [EMAIL PROTECTED] wrote: This could be as the move to Axis2 1.2 hadn't been completely finish and maybe things get added in a different order in different environments. I've moved everything I could find up to Axis2 1.2 and Axiom 1.2.4now, could you update again and see if that has fixed this and you end up with the Axis2 1.2 jar's in the manifest now? ...ant On 4/30/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: Ok, I looked at manifest.mf and for some reason, it lists axis2-kernel-1.1.1.jar, not axis2-kernel-1.2.jar. I downloaded your zip and looked at the manifest.mf there and it does list axis2-kernel-1.2.jar. And so, the sample runs in this case. Here's the contents of my manifest.mf: http://rafb.net/p/yeLmcf17.html Not sure what I am doing to make the difference. Thanks On 4/30/07, ant elder [EMAIL PROTECTED] wrote: The NoClassDefFoundError: org/apache/axis2/AxisFault indicates it can't find the axis2-kernel-1.2.jar, is that in the lib directory you get in the distribution? If so then is axis2-kernel-1.2.jar listed in the classpath enty of the manifest.mf file in the tuscany-sca-manifest.jarin the lib directory? On another tack, I've uploaded the zip that I get from building the distribution to :
Re: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)
It would be good to choose a name soon so we can start completing all the readme's and release notes etc, there doesn't seem much consensus on beta1 so how about 0.90? That sounds closer to 1.0 than M3 or alpha and still gives space for more releases before the final 1.0. ...ant On 5/1/07, Bert Lamb [EMAIL PROTECTED] wrote: I realize I'm a bit late to this conversation, I'm just now getting mostly unpacked from a move to Somerville, MA. I agree with Simon in that we should be careful what we call beta. I know that we all would like to get to beta quality code and features as soon as we can, but I don't think we are there yet nor will we be there by JavaOne. What we currently have in the trunk I think is a much more manageable code base but it actually has fewer features, if I'm not mistaken, than M2 had. So, my vote, if I had a binding one, would be for 3, with a name of M3 or maybe alpha. -Bert On 4/25/07, ant elder [EMAIL PROTECTED] wrote: On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote: snip/ So I think it comes down to whether it is more important to put something out by JavaOne (in which case I'd be hesitant to call it beta) or whether it is more important to attain a true beta level of quality even if that takes a little bit longer. I guess a lot comes down to everyones slightly different perceptions as to what the name beta implies, what do others think about this? Should we: 1) continue aiming for a beta1 release around JavaOne timeframe 2) continue with a beta1 release but take a bit more time 3) aim for a release around JavaOne timeframe but change to a non-beta release name, alpha-x or maybe a numeric like 0.90? I probably favor (2) as looking at things people have said they'd like to get done it seems unlikely to me we'll be ready by JavaOne anyway. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1240) Compilation warnings
Compilation warnings Key: TUSCANY-1240 URL: https://issues.apache.org/jira/browse/TUSCANY-1240 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: PHP, Linux AMD64, gcc Reporter: Caroline Maynard Priority: Trivial Compilation warnings: /home/cem/pecl-sdo-BUZZARD/commonj/sdo/PropertyImpl.cpp: In destructor `virtual commonj::sdo::PropertyImpl::~PropertyImpl()': /home/cem/pecl-sdo-BUZZARD/commonj/sdo/PropertyImpl.cpp:159: warning: deleting `void*' is undefined /home/cem/pecl-sdo-BUZZARD/commonj/sdo/PropertyImpl.cpp:163: warning: deleting `void*' is undefined These are not malignant, but should be fixed some time. -- 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: Next SCA release distributions
On 5/2/07, ant elder [EMAIL PROTECTED] wrote: On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/30/07, ant elder [EMAIL PROTECTED] wrote: Excellent thanks, thats type type feedback I was looking for! Comments in line... On 4/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip/ I have a few questions and suggestions. - tuscany-sca.jar contains .svn directories, I guess they should be removed from the JAR. I can't see these, i could just be blind or maybe its something different about our environments could you give an example of what the file names are? - Also 2 empty xsds at the root of the JAR and com.example packages, they must be coming from one of the examples? The com.example.* files are coming from the databinding-jaxb and databinding-sdo modules, we need to fix those modules but I'm not sure how. It looks like the jaxb and sdo plugins need to some way to say they're test resources. Any one know how to fix this? I can't see the 2 empty xsds, something different about our environments again? - I guess we're going to rename this to sca-1.0-beta1-incubating? Yes, the name should be being picked up from the pom, but i'll test it does change. (Using the current format the name would be 1.0-incubating-beta1 , do we really want 1.0-beta1-incubating?) - Like you said above, we'll have to include the javadoc for our SPIs. Yes, I guess I can add that in now even though the SPIs aren't done by just including the tuscany-core-spi module javadoc. Is javadoc for just these two modules enough (sca-api and core-spi). I've added this now, are there other modules we want javadoc for? - How did you produce the single META-INF/services/...ModuleActivator file? is it generated? This is done in the java/sca/distribution/bundle project using the Maven Shade plugin, see in the pom.xml the shade config where a Shade AppendingTransformer is used to merge all the ModuleActivator files into one. No doc at all about the Shade plugin that I could find, I got this from looking at the CXF build and the Shade plugin source code. - We have two different servlet-api JARs, should we pick one? Fixed. The 6.0.10 one was coming from the http-tomcat module so i've added exclusions in that pom.xml. - Could we have, in the bin distro, a tuscany-sca-src.jar containing all the source code for the classes in tuscany-sca.jar? Thats a good idea, I'm not sure how though. The tuscany-sca.jar is built from all the dependency elements listed in the distribution/bundle/pom.xml, I could make a src jar by just zipping up everything in sca/modules but it may end up including more than is in the tuscany-sca.jar. Anyone have any better ideas on how to do this? - How about renaming tuscany-sca.jar to tuscany-sca-all.jar, or any name indicating that it's all the tuscany code? OK, done. - The NOTICE will have to be updated as it contains obsolete dependencies. Yep. Over the next days I'll trawl through all the license and notice files to make sure they're correct. - I think it would be great to have Ant build scripts for some of the samples, as not everybody is using Maven. Me too, I'll try to get one going today. Should we have all the samples have both maven and Ant build scripts, or just Ant, or some samples have Ant and others have Maven? - Pre-built sample JARs would be great too, but not as important if we have a simple Ant build for the samples. There are pre-built sample jars in the sample target directory, eg, samples\calculator\target\tuscany- sample-calculator-1.0-incubating-SNAPSHOT.jar I've updated the distribution build scripts with the above changes now. ...ant Hi I just this minute took a fresh update of sca to make ant scripts for the samples. I have some questions... - why does tuscany-sca-manifest.jar not have a version number? - What is intention of tuscany-sca-all I need a classpath with all tuscany jars on. Currently its in tuscany-sca-manifest but it doesn't pick up the dependencies in the modules directory as they are in ../modules The idea is that tuscany-sca-manifest.jar is an easy way for users to be able to add tuscany-sca and all the dependencies to their classpath when they have the binary distribution. It only works when its in the same directory as all the other jars so its not distributed out side of the binary distro so i don't think it needs -incubating- in the name, and because its not distributed separately i left off a version number, not sure if thats good or not but it does make the name nice and short. Ok, fair point. The tuscany-sca-all-1.0-incubating-SNAPSHOT.jar is made from combining all the tuscany-sca modules into a single jar. It would get published to the maven repository so needs -incubating- and a version number in the name. The idea
Re: ant build scripts for SCA samples
On 5/2/07, Simon Nash [EMAIL PROTECTED] wrote: I saw the following discussion in Monday's IRC chat log. (I couldn't attend the chat because I was on a plane.) [12:37] ant_ oh, so with the samples again, I guess we need Ant build scripts [12:37] ant_ lresende, it does right now and i think thats good to do [12:38] jsdelfino yes, +1 for the sample bins [12:38] lresende yes, i like that, but haven't looked into your distro strawman yet [12:38] slaws ant_ - a non maven build solution for samples would be useful [12:38] ant_ do we want mvn as well or just Ant? [12:39] jsdelfino what's the work required to have a mvn build for the samples? don't we already have bit? [12:39] jsdelfino I think we could keep the mvn build, but document the ant one [12:40] slaws if we have two we need to decide whether we maintain two or just fix up ant for releases [12:40] ant_ ok. i guess we just need to make sure the sample mvn's work in the build distro with an empty local repo [12:41] ant_ would anyone like to volunteer to create an Ant script for one of the samples? [12:42] jsdelfino anyone? it shouldn't be too hard, we even had this in M1... [12:42] slaws didn't someone already create some for a previous release that we can lift [12:42] halehM Maybe someone on the mailing list who is not on the IRC? [12:42] halehM post on mailing list? [12:43] ant_ ok, lets skip that one for now then I did some work on this for M2 but nothing was included in the release because of disagreements about some aspects of my proposal. The two main issues were how webapps get built and how dependencies are resolved. I'll look at this again based on the currently proposed release packaging. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Simon, I checked a version of the calculator build.xml into the trunk and have been discussing some of the dependency issues here ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg17320.html) Simon
Re: Next SCA release distributions
On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote: On 5/2/07, ant elder [EMAIL PROTECTED] wrote: On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/30/07, ant elder [EMAIL PROTECTED] wrote: Excellent thanks, thats type type feedback I was looking for! Comments in line... On 4/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip/ I have a few questions and suggestions. - tuscany-sca.jar contains .svn directories, I guess they should be removed from the JAR. I can't see these, i could just be blind or maybe its something different about our environments could you give an example of what the file names are? - Also 2 empty xsds at the root of the JAR and com.example packages, they must be coming from one of the examples? The com.example.* files are coming from the databinding-jaxb and databinding-sdo modules, we need to fix those modules but I'm not sure how. It looks like the jaxb and sdo plugins need to some way to say they're test resources. Any one know how to fix this? I can't see the 2 empty xsds, something different about our environments again? - I guess we're going to rename this to sca-1.0-beta1-incubating? Yes, the name should be being picked up from the pom, but i'll test it does change. (Using the current format the name would be 1.0-incubating-beta1 , do we really want 1.0-beta1-incubating?) - Like you said above, we'll have to include the javadoc for our SPIs. Yes, I guess I can add that in now even though the SPIs aren't done by just including the tuscany-core-spi module javadoc. Is javadoc for just these two modules enough (sca-api and core-spi). I've added this now, are there other modules we want javadoc for? - How did you produce the single META-INF/services/...ModuleActivator file? is it generated? This is done in the java/sca/distribution/bundle project using the Maven Shade plugin, see in the pom.xml the shade config where a Shade AppendingTransformer is used to merge all the ModuleActivator files into one. No doc at all about the Shade plugin that I could find, I got this from looking at the CXF build and the Shade plugin source code. - We have two different servlet-api JARs, should we pick one? Fixed. The 6.0.10 one was coming from the http-tomcat module so i've added exclusions in that pom.xml. - Could we have, in the bin distro, a tuscany-sca-src.jar containing all the source code for the classes in tuscany-sca.jar? Thats a good idea, I'm not sure how though. The tuscany-sca.jar is built from all the dependency elements listed in the distribution/bundle/pom.xml, I could make a src jar by just zipping up everything in sca/modules but it may end up including more than is in the tuscany-sca.jar. Anyone have any better ideas on how to do this? - How about renaming tuscany-sca.jar to tuscany-sca-all.jar, or any name indicating that it's all the tuscany code? OK, done. - The NOTICE will have to be updated as it contains obsolete dependencies. Yep. Over the next days I'll trawl through all the license and notice files to make sure they're correct. - I think it would be great to have Ant build scripts for some of the samples, as not everybody is using Maven. Me too, I'll try to get one going today. Should we have all the samples have both maven and Ant build scripts, or just Ant, or some samples have Ant and others have Maven? - Pre-built sample JARs would be great too, but not as important if we have a simple Ant build for the samples. There are pre-built sample jars in the sample target directory, eg, samples\calculator\target\tuscany- sample-calculator-1.0-incubating-SNAPSHOT.jar I've updated the distribution build scripts with the above changes now. ...ant Hi I just this minute took a fresh update of sca to make ant scripts for the samples. I have some questions... - why does tuscany-sca-manifest.jar not have a version number? - What is intention of tuscany-sca-all I need a classpath with all tuscany jars on. Currently its in tuscany-sca-manifest but it doesn't pick up the dependencies in the modules directory as they are in ../modules The idea is that tuscany-sca-manifest.jar is an easy way for users to be able to add tuscany-sca and all the dependencies to their classpath when they have the binary distribution. It only works when its in the same directory as all the other jars so its not distributed out side of the binary distro so i don't think it needs -incubating- in the name, and because its not distributed separately i left off a version number, not sure if thats good or not but it does make the name nice and short. Ok, fair point. The
Re: [Java SDO CTS] thoughts on structure
I added a few comments in-line.
Thanks,
Frank.
kelvin goodson [EMAIL PROTECTED] wrote on 05/02/2007 06:38:28
AM:
I'm inclined to agree that a blanket approach to this kind of testing is
not
best. The more directed the tests are the better we can understand how
comprehensive the CTS is.
However, it's not clear to me whether we can now confirm the types are
as
they should be through the metadata API alone, or whether there are
still
requirements on an implementation to preserve elements of metadata that
can
only be detected by the behaviour seen through the data API. However,
if
it's purely some facets of XSD behaviour that we needed to test
empirically
then that wouldn't require a parameterized approach.
I think this is the case. The intersection of features that can be defined
in multiple ways wouldn't have anything hidden. Some of the
non-parameterized (e.g., XSD-specific) tests would test features that rely
on hidden information.
I think this kind of parameterized testing is well suited to finding
issues
that might not otherwise be found when exercising code that must handle
arbitrary graphs, but most of the tests we have in place are written
with
tight preconditions on the inputs. So to run multiple graphs displaying
interesting facets through the EqualityHelper for instance might be a
good
use of the technique. In that case the parameterized data sets would
need to
include a description of the expected result. For the case of
EqualityHelper that would be easy {true|false}, but for say the
XMLHelper's
serialization function it requires a bit more work, as the variability
of
output is permitted in the XML literal space.
There is an argument in favour retaining at least some level of the
current
mode parameterized testing, related to testing of static classes.
This is a good point. It would argue for making every test paramaterized,
so that we can optionally run them with statically generated classes. But,
on the other hand, I wonder if it wouldn't be simpler to just have a
simple subclass that registers the static classes. The subclass would
probably want to also add some static tests (i.e., ones that call the
generated methods) in addition to the dynamic tests that are provided in
the base class. It's not sufficient to simply test the dynamic behavior of
static data objects.
The spec
doesn't cover static classes yet, but the parameterized infrastructure
that
we have in place permits an implementation to augment the set of inputs
with
some of its own. So for the case we currently have, where metadata has
been generated by the implementation independent CTS infrastructure from
an
XSD and via the dynamic API, Tuscany for example could make use of the
call-out in BaseSDOParameterizedTest's data() method to add one or more
sets of data create from static classes and those would be run against
the
tests.
I can to some extent see a theoretical/academic reason for having
implementation independent equality testing code in the CTS, but
practically this leads to a who tests the testers scenario. If we
build
tests that make the assumption that the equality helper of the
implementation under tests is trusted, then we have to ensure that the
suite
of tests applied to the equality helper itself warrants that trust.
I assume that one of the test cases in the test suite will explicitly test
the EqualityHelper, after which it can be trusted.
+1 to simplifying the interface of the TestHelper.
Kelvin.
On 01/05/07, Frank Budinsky [EMAIL PROTECTED] wrote:
I think this approach sounds a little too brute force. Regardless of
how
the metadata is defined, once instances are created in memory, they
will
be exactly the same. Verifying this by repeating every possible test
on
the exact same DataObjects, just created differently, sounds a little
inefficient. What I think we need instead is to have some set of
consistency tests that confirm that the types created in various ways
are
in fact the same.
The parameterized tests approach might be a good way to
do that, but the tests that need to run to confirm this is a small
subset
of all the functionality of SDO. Testing every API N times is
definitely
overkill IMO.
Actually, it's probably sufficient to have a parameterized test that
simply walks through the metadata and confirms the types and
properties
are as expected. All the DataObject tests do not need to be
parameterized
at all.
I've noticed some overlap between the parameterized and non
parameterized
tests. It also looks like the parameterized tests make a lot of
Tuscany-specific assumptions. I also wonder why ParameterizedTestUtil
has
it's own equals code (instead of just using EqualityHelper). Maybe we
should just remove all these tests, and then resubmit/merge any unique
tests with the appropriate non parameterized tests.
One more thing, I noticed that the
Re: svn commit: r533445 [1/4] - in /incubator/tuscany/java/sca: itest/contribution/src/test/java/org/apache/tuscany/sca/test/contribution/ modules/assembly-java-dsl/src/main/java/org/apache/tuscany/as
On 5/2/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 5/1/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] ant elder wrote: So now in the Axis2 binding the start method of the Axis2ModuleActivator it news up a whole lot of factories - DefaultAssemblyFactory, DefaultPolicyFactory, DefaultWebServiceBindingFactory, DefaultWSDLFactory, DefaultWSDLInterfaceIntrospector, and the WebServiceBindingProcessor What you're describing here is an assembly, described before in SCDL, now built in Java code. This is basically the role of a ModuleActivator: assemble the pieces required for a particular extension. This is not just for factories, WSDLInterfaceIntrospector, WebServiceBindingProcessor, JavaInterfaceIntrospector, JavaClassIntrospector, our default InterfaceContractMapper, the default databinding Mediator are all in the same category. They are newed up at the edges of our runtime, in SimpleRuntimeImpl or in the ModuleActivator of an extension, and assembled there. - none of those are used by the Axis2 binding and they tie the binding to the xml ws binding impl. Should binding.ws.xml have its own ModuleActivator that does all this? I would be fine with moving this assembly logic out of the Axis2ModuleActivator, but it needs to be done somewhere :) The work I did recently to push these assembly decisions to the edges should now make it easier to put this assembly logic anywhere we want, and should allow us to not be tied to a specific implementation of binding.ws for example and select it in the assembly - at the top of the stack - as opposed to having it hardcoded in the lower runtime layers like before. So how about I add a ModuleActivator to binding-ws-xml to do it seeing thats what the assembly is for? Or does it need another completely seperate module? Module binding-ws-xml does not depend on core-spi. The idea is to keep it independent of the rest of the core runtime to make it easier to reuse by other projects who will want to support the SCA assembly XML syntax, without necessarily integrating the Tuscany core runtime. Ah, ok I'd forgotten that so all this makes a lot more sense to me now. Thanks for the long explanations. ...ant
[jira] Commented: (TUSCANY-1239) Statement::executeQuery and Statement::execute should throw exception
[ https://issues.apache.org/jira/browse/TUSCANY-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493090 ] Douglas Siqueira Leite commented on TUSCANY-1239: - Okay. I will do this. Statement::executeQuery and Statement::execute should throw exception - Key: TUSCANY-1239 URL: https://issues.apache.org/jira/browse/TUSCANY-1239 Project: Tuscany Issue Type: Improvement Components: C++ DAS Affects Versions: Wish list Reporter: Adriano Crestani Fix For: Wish list Statement::executeQuery and Statement::execute should throw some kind of exception when the statement query is not successfully completed. -- 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: ant build scripts for SCA samples
On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote: On 5/2/07, Simon Nash [EMAIL PROTECTED] wrote: I saw the following discussion in Monday's IRC chat log. (I couldn't attend the chat because I was on a plane.) [12:37] ant_ oh, so with the samples again, I guess we need Ant build scripts [12:37] ant_ lresende, it does right now and i think thats good to do [12:38] jsdelfino yes, +1 for the sample bins [12:38] lresende yes, i like that, but haven't looked into your distro strawman yet [12:38] slaws ant_ - a non maven build solution for samples would be useful [12:38] ant_ do we want mvn as well or just Ant? [12:39] jsdelfino what's the work required to have a mvn build for the samples? don't we already have bit? [12:39] jsdelfino I think we could keep the mvn build, but document the ant one [12:40] slaws if we have two we need to decide whether we maintain two or just fix up ant for releases [12:40] ant_ ok. i guess we just need to make sure the sample mvn's work in the build distro with an empty local repo [12:41] ant_ would anyone like to volunteer to create an Ant script for one of the samples? [12:42] jsdelfino anyone? it shouldn't be too hard, we even had this in M1... [12:42] slaws didn't someone already create some for a previous release that we can lift [12:42] halehM Maybe someone on the mailing list who is not on the IRC? [12:42] halehM post on mailing list? [12:43] ant_ ok, lets skip that one for now then I did some work on this for M2 but nothing was included in the release because of disagreements about some aspects of my proposal. The two main issues were how webapps get built and how dependencies are resolved. I'll look at this again based on the currently proposed release packaging. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Simon, I checked a version of the calculator build.xml into the trunk and have been discussing some of the dependency issues here ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg17320.html) Simon Just fyi, i've tried this calculator Ant build and it seems to work fine for me. ...ant
Change tuscany-itest-databindings-sdo to use 1.0-incubating-SNAPSHOT for the tuscany-sdo-plugin version?
I'm trying to change tuscany-itest-databindings-sdo pom.xml to use 1.0-incubating-SNAPSHOT for the tuscany-sdo-plugin version as its been changed to that from 1.0-incubator-SNAPSHOT but it keeps getting changed back, i guess this is done by the way the tests a generated but I can't see where the version is coming from. Anyone have any hints? ...ant
Could ServletHostExtension add/removeServletMapping take a URI instead of a host and mapping?
The ServletHostExtension currently uses methods like addServletMapping(int host, String mapping, Servlet servlet) so in the things that use this like the Axis2 binding you have to work out things like the host port, eg, see the Axis2ServiceBinding start and stop methods. Could ServletHostExtension add/removeServletMapping be changed to just take a URI and a Servlet and have the ServletHostExtension implementation do the best it can to get the servlet registered at the URI? ...ant
Re: ant build scripts for SCA samples
I can build the sample OK using this ant script, but ant run doesn't work. I'm using the pre-built distribution that Ant posted to http://people.apache.org/~antelder/tuscany/latest/ The problem is with the very long Class-Path attribute in MANIFEST.MF of tuscany-sca-manifest.jar. In Ant's pre-built distribution, this line is chopped up into small fixed-size chunks, producing the following error: E:\tuscanybin1\tuscany-sca-1.0-incubating-SNAPSHOT\samples\calculatorant run Buildfile: build.xml init: compile: run: [java] Failed to load Main-Class manifest attribute from [java] E:\tuscanybin1\tuscany-sca-1.0-incubating-SNAPSHOT\lib\tuscany-sca-manifest.jar [java] Java Result: 1 I tried editing the MANIFEST.MF file to put all the Class-Path information in a single line of 3861 characters. This produced the following error: E:\tuscanybin1\tuscany-sca-1.0-incubating-SNAPSHOT\samples\calculatorant run Buildfile: build.xml init: compile: run: [java] java.io.IOException: line too long [java] at java.util.jar.Attributes.read(Attributes.java:362) [java] at java.util.jar.Manifest.read(Manifest.java:167) [java] at java.util.jar.Manifest.init(Manifest.java:52) [java] at java.util.jar.JarFile.getManifestFromReference(JarFile.java:158) [java] at java.util.jar.JarFile.getManifest(JarFile.java:145) [java] Exception in thread main [java] Java Result: 1 Simon ant elder wrote: On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote: On 5/2/07, Simon Nash [EMAIL PROTECTED] wrote: I saw the following discussion in Monday's IRC chat log. (I couldn't attend the chat because I was on a plane.) [12:37] ant_ oh, so with the samples again, I guess we need Ant build scripts [12:37] ant_ lresende, it does right now and i think thats good to do [12:38] jsdelfino yes, +1 for the sample bins [12:38] lresende yes, i like that, but haven't looked into your distro strawman yet [12:38] slaws ant_ - a non maven build solution for samples would be useful [12:38] ant_ do we want mvn as well or just Ant? [12:39] jsdelfino what's the work required to have a mvn build for the samples? don't we already have bit? [12:39] jsdelfino I think we could keep the mvn build, but document the ant one [12:40] slaws if we have two we need to decide whether we maintain two or just fix up ant for releases [12:40] ant_ ok. i guess we just need to make sure the sample mvn's work in the build distro with an empty local repo [12:41] ant_ would anyone like to volunteer to create an Ant script for one of the samples? [12:42] jsdelfino anyone? it shouldn't be too hard, we even had this in M1... [12:42] slaws didn't someone already create some for a previous release that we can lift [12:42] halehM Maybe someone on the mailing list who is not on the IRC? [12:42] halehM post on mailing list? [12:43] ant_ ok, lets skip that one for now then I did some work on this for M2 but nothing was included in the release because of disagreements about some aspects of my proposal. The two main issues were how webapps get built and how dependencies are resolved. I'll look at this again based on the currently proposed release packaging. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Simon, I checked a version of the calculator build.xml into the trunk and have been discussing some of the dependency issues here ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg17320.html) Simon Just fyi, i've tried this calculator Ant build and it seems to work fine for me. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Webapp support in this release
There's been a few past questions about what we're doing to support webapp's in this release. I think the way the runtime is today webapp's should be able to work just like the standalone J2SE samples and all we need to do is make sure the all the tuscany dependency jars are included somewhere. So how about all we do is have a webapp calculator sample similar to the one from M2 but just use the standard Maven war plugin to create the WAR bundling all the required dependencies into the webapp lib directory? We could also have an alternative sample build that assumes all the required tuscany jars are already in the tomcat shared lib so doesn't include them in the sample WAR. (and provide some way to get all the jars needed to be put in the shared lib?) WDYT or any alternative suggestions? Anyone want to volunteer to try doing this? ...ant
Re: Could ServletHostExtension add/removeServletMapping take a URI instead of a host and mapping?
ant elder wrote: The ServletHostExtension currently uses methods like addServletMapping(int host, String mapping, Servlet servlet) so in the things that use this like the Axis2 binding you have to work out things like the host port, eg, see the Axis2ServiceBinding start and stop methods. Could ServletHostExtension add/removeServletMapping be changed to just take a URI and a Servlet and have the ServletHostExtension implementation do the best it can to get the servlet registered at the URI? ...ant Yes, I had come up with the initial signature but what you're proposing makes more sense. I'd suggest to pass a String uri (to not force all callers to create a URI object) and do the String/URI parsing inside the ServletHost. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Could ServletHostExtension add/removeServletMapping take a URI instead of a host and mapping?
On 5/2/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: The ServletHostExtension currently uses methods like addServletMapping(int host, String mapping, Servlet servlet) so in the things that use this like the Axis2 binding you have to work out things like the host port, eg, see the Axis2ServiceBinding start and stop methods. Could ServletHostExtension add/removeServletMapping be changed to just take a URI and a Servlet and have the ServletHostExtension implementation do the best it can to get the servlet registered at the URI? ...ant Yes, I had come up with the initial signature but what you're proposing makes more sense. I'd suggest to pass a String uri (to not force all callers to create a URI object) and do the String/URI parsing inside the ServletHost. Ok, i'll give that a go. ...ant
Throwable Input2InputTransformer.java (179) IndexOutOfBoundsException
Hi,
I found a small bug in Input2InputTransformer.java (179)
Object[] newArgs = new Object[source.length];
for (int i = 0; i source.length; i++) {
Object child = mediator.mediate(source[i],
sourceType.getLogical().get(i), targetType.getLogical().get(i),
context.getMetadata());
newArgs[i] = child;
}
When try parse a java to wsdl
My java interface method is public TimeSlot editReservation(int
timeSlotID, String requestedBy, String purpose, int[] resourcesID);
I have 4 input params
and my wsdl have 1 element with an type having 4 paramenters
When run this code whe have an IndexOutOfBoundsException
Exception in thread main java.lang.IndexOutOfBoundsException : Index: 1,
Size: 1
at java.util.ArrayList.RangeCheck(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at
org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.transform
(Input2InputTransformer.java :179)
at
org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.transform
(Input2InputTransformer.java:1)
at org.apache.tuscany.databinding.impl.MediatorImpl.mediate(
MediatorImpl.java:83)
at
org.apache.tuscany.core.databinding.wire.DataBindingInteceptor.transform(
DataBindingInteceptor.java:189)
at org.apache.tuscany.core.databinding.wire.DataBindingInteceptor.invoke
(DataBindingInteceptor.java:86)
at org.apache.tuscany.spi.wire.AbstractInvocationHandler.invoke(
AbstractInvocationHandler.java:91)
at
org.apache.tuscany.implementation.java.proxy.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:150)
Not to be that I must work with OMElement in my java interface.
--
Paulo Henrique Trecenti
Re: Next SCA release distributions
Hi, I believe that it is better to wait until having a more consistent version of what already it is. 2007/5/2, ant elder [EMAIL PROTECTED]: On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote: On 5/2/07, ant elder [EMAIL PROTECTED] wrote: On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/30/07, ant elder [EMAIL PROTECTED] wrote: Excellent thanks, thats type type feedback I was looking for! Comments in line... On 4/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip/ I have a few questions and suggestions. - tuscany-sca.jar contains .svn directories, I guess they should be removed from the JAR. I can't see these, i could just be blind or maybe its something different about our environments could you give an example of what the file names are? - Also 2 empty xsds at the root of the JAR and com.examplepackages, they must be coming from one of the examples? The com.example.* files are coming from the databinding-jaxb and databinding-sdo modules, we need to fix those modules but I'm not sure how. It looks like the jaxb and sdo plugins need to some way to say they're test resources. Any one know how to fix this? I can't see the 2 empty xsds, something different about our environments again? - I guess we're going to rename this to sca-1.0-beta1-incubating? Yes, the name should be being picked up from the pom, but i'll test it does change. (Using the current format the name would be 1.0-incubating-beta1 , do we really want 1.0-beta1-incubating?) - Like you said above, we'll have to include the javadoc for our SPIs. Yes, I guess I can add that in now even though the SPIs aren't done by just including the tuscany-core-spi module javadoc. Is javadoc for just these two modules enough (sca-api and core-spi). I've added this now, are there other modules we want javadoc for? - How did you produce the single META-INF/services/...ModuleActivator file? is it generated? This is done in the java/sca/distribution/bundle project using the Maven Shade plugin, see in the pom.xml the shade config where a Shade AppendingTransformer is used to merge all the ModuleActivator files into one. No doc at all about the Shade plugin that I could find, I got this from looking at the CXF build and the Shade plugin source code. - We have two different servlet-api JARs, should we pick one? Fixed. The 6.0.10 one was coming from the http-tomcat module so i've added exclusions in that pom.xml. - Could we have, in the bin distro, a tuscany-sca-src.jarcontaining all the source code for the classes in tuscany-sca.jar? Thats a good idea, I'm not sure how though. The tuscany-sca.jar is built from all the dependency elements listed in the distribution/bundle/pom.xml, I could make a src jar by just zipping up everything in sca/modules but it may end up including more than is in the tuscany-sca.jar. Anyone have any better ideas on how to do this? - How about renaming tuscany-sca.jar to tuscany-sca-all.jar, or any name indicating that it's all the tuscany code? OK, done. - The NOTICE will have to be updated as it contains obsolete dependencies. Yep. Over the next days I'll trawl through all the license and notice files to make sure they're correct. - I think it would be great to have Ant build scripts for some of the samples, as not everybody is using Maven. Me too, I'll try to get one going today. Should we have all the samples have both maven and Ant build scripts, or just Ant, or some samples have Ant and others have Maven? - Pre-built sample JARs would be great too, but not as important if we have a simple Ant build for the samples. There are pre-built sample jars in the sample target directory, eg, samples\calculator\target\tuscany- sample-calculator-1.0-incubating-SNAPSHOT.jar I've updated the distribution build scripts with the above changes now. ...ant Hi I just this minute took a fresh update of sca to make ant scripts for the samples. I have some questions... - why does tuscany-sca-manifest.jar not have a version number? - What is intention of tuscany-sca-all I need a classpath with all tuscany jars on. Currently its in tuscany-sca-manifest but it doesn't pick up the dependencies in the modules directory as they are in ../modules The idea is that tuscany-sca-manifest.jar is an easy way for users to be able to add tuscany-sca and all the dependencies to their classpath when they have the binary distribution. It only works when its in the same directory as all the
Re: Next SCA release distributions
[snip] Simon Laws wrote: - tuscany-rmi? Should this be a binding Yes, would be better as tuscany-binding-rmi. We already have a tuscany-binding-rmi module: the implementation of the RMI binding. The tuscany-rmi module defines an RMI hosting extension point, similar to how the tuscany-http module provides an HTTP host extension point. To make that clear, I'd suggest to rename tuscany-rmi to tuscany-host-rmi and tuscany-http to tuscany-host-http. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Interfaces for implementation/binding extensions to provide runtime behaviors
Hi, I have updated the interfaces for extension developers and you can find them at http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/core-spi/src/main/java/org/apache/tuscany/core/. Hopefully the javdoc is good enough for you to understand. I also switched the CRUD implementation sample to this new set of interfaces and you can play with the sample to see how the interfaces are used. http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/implementation-crud/ There are few other classes you might be interested to see how the runtime works: org.apache.tuscany.host.embedded.impl.MiniRuntimeImpl: The mini runtime that loads the contribution and add it to the SCA domain org.apache.tuscany.core.runtime.RuntimeActivatorImpl: The base class that bootstrap the runtime org.apache.tuscany.core.runtime.DefaultCompositeActivator: The replacement for DeployerImpl that activates a composite to the SCA domain All the changes was checked in under rev 534302. Please note I added the new things without changing much of the existing code so both paths are working at the moment. I'm porting the Java component type and EchoBinding sample over. They are now half-way through. BTW, Ant, I didn't have the chance to split the createInterceptor into two methods, maybe you can help. Please review and comment. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, May 01, 2007 3:22 AM Subject: Re: Interfaces for implementation/binding extensions to provide runtime behaviors On 4/27/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I have checked in the first cut of interfaces for implementation/binding extensions to provide runtime behaviors. ([1] [2]). The Activator interfaces can be implemented to control the lifecycle of components or reference/service bindings. The Provider interfaces can be implemented to create corresponding interceptor and get the effective interface contract for the endpoint. I was thinking of naming them as XXXInvokerFactory but there are methods in the interfaces don't quite fit. When we add an implementation or binding type to Tuscany, the implementation class of the Implementation/Binding model interface can optionally implement these interfaces to provide the logic for the runtime to drive the interactions from reference to service. Please review. Thanks, Raymond [1] http://svn.apache.org/viewvc?view=revrev=533222 [2] http://svn.apache.org/viewvc?view=revrev=533238 I'm having a bit of trouble understanding all this without seeing more code showing how these will be used, so comments may have to wait till the runtime uses them a bit more. One comment, how about the XxxProvider interfaces have a createCallbackInterceptor method instead of passing the boolean in on the createInterceptor method? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cross-composite locate service
Here is a concrete scenario ...
Two composites A, B in the SCA Domain
A has single component a
B has single component b
a provides a.service
b provides b.service
a_impl.service must delegate to b_impl.service
A provides no defined reference to b.service so a_impl will dynamically find
and invoke b.service
Based on Raymond's earlier comment in this thread
AImpl implements A {
service() {
ComponentContext context = SCARuntime.getComponentContext(b)
ServiceReferenceb service = context.createSelfReference(b.class)
BService bService = service.getService()
return bService.service
}
}
Will SCARuntime continue to provide getComponentContext or is some
domain-related-interface needed? Are there plans for the infrastructure
required to implement it?
Thanks,
--Kevin
On 5/1/07, Kevin Williams [EMAIL PROTECTED] wrote:
I am creating a test case for this and it seems that there is currently no
API for adding deployable composites. Is this work underway? I may be
able to help out here.
Thanks,
--Kevin
On 4/23/07, Kevin Williams [EMAIL PROTECTED] wrote:
Thanks Raymond. That may work for me. I'll try it out.
--
Kevin
On 4/20/07, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Kevin,
When one ore more deployable composites from a contribution are added
to the
SCA domain, all the components in the composite will become direct
children
of the SCA domain composite (the include semantics).
Then similar code as follows will fit your case. Am I right?
ComponentContext context =
SCARuntime.getComponentContext(CalculatorServiceComponent);
ServiceReferenceCalculatorService service =
context.createSelfReference(CalculatorService.class);
CalculatorService calculatorService = service.getService();
Thanks,
Raymond
- Original Message -
From: Kevin Williams [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Friday, April 20, 2007 2:03 PM
Subject: cross-composite locate service
I am interested in a way to dynamically find and invoke a service
within
the
Domain without having access to a pre-defined reference. This is
not
called
out in the 1.0 specification but it would be a very useful
capability. It
also seems that many of the pieces required to implement this may
soon be
in
place; especially with the work around runtime simplification and
Domain
proposed by Raymond in this thread:
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg16792.html
This also seems related to Scott's recent query regarding default
bindings
across top level composites:
* http://tinyurl.com/2xslxp*
Any thoughts on this? I would appreciate any pointers.
Thanks!
--Kevin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next SCA release distributions
On 5/2/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: - tuscany-rmi? Should this be a binding Yes, would be better as tuscany-binding-rmi. We already have a tuscany-binding-rmi module: the implementation of the RMI binding. The tuscany-rmi module defines an RMI hosting extension point, similar to how the tuscany-http module provides an HTTP host extension point. To make that clear, I'd suggest to rename tuscany-rmi to tuscany-host-rmi and tuscany-http to tuscany-host-http. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] You are right. I didn't spot that. I must be going blind. Agree with the move to using host in the name. Simon
Re: Change tuscany-itest-databindings-sdo to use 1.0-incubating-SNAPSHOT for the tuscany-sdo-plugin version?
On 5/2/07, ant elder [EMAIL PROTECTED] wrote: I'm trying to change tuscany-itest-databindings-sdo pom.xml to use 1.0-incubating-SNAPSHOT for the tuscany-sdo-plugin version as its been changed to that from 1.0-incubator-SNAPSHOT but it keeps getting changed back, i guess this is done by the way the tests a generated but I can't see where the version is coming from. Anyone have any hints? ...ant Yes, the pom is generated from resources/generate/pom.xml.vm. I just fixed it. Simon
[jira] Created: (TUSCANY-1241) Provide CTS Updates for HelperContext and a new DO creation mechanism
Provide CTS Updates for HelperContext and a new DO creation mechanism - Key: TUSCANY-1241 URL: https://issues.apache.org/jira/browse/TUSCANY-1241 Project: Tuscany Issue Type: Test Components: Java SDO Implementation Reporter: Brian Murray Priority: Minor My team has been using a separate branch of the CTS, and we have made some updates. I'd like to provide those changes back to Tuscany. Those changes include test case corrections and additions, the use of HelperContext, and the use of a new DataObjectFactory class . The DataObjectFactory class has Method and Object[] members that are populated via the constructor. The class has methods with void parameter lists to create different Types of DataObjects relevant to the test cases. In this way, the individual test cases need not be aware of the creation or definition mechanism of the DataObject being tested. I am opening this Jira simply as a mechanism to provide the patch containing our changes. (So that I may provide the required usage agreements with the patch.) Note that the patch is not complete. However, I'm aware that discussion has picked up and I want to provide my changes as quickly so as to avoid unnecessary merging. -- 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] Updated: (TUSCANY-1241) Provide CTS Updates for HelperContext and a new DO creation mechanism
[ https://issues.apache.org/jira/browse/TUSCANY-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Murray updated TUSCANY-1241: -- Attachment: cts.patch Attaching the patch. Provide CTS Updates for HelperContext and a new DO creation mechanism - Key: TUSCANY-1241 URL: https://issues.apache.org/jira/browse/TUSCANY-1241 Project: Tuscany Issue Type: Test Components: Java SDO Implementation Reporter: Brian Murray Priority: Minor Attachments: cts.patch My team has been using a separate branch of the CTS, and we have made some updates. I'd like to provide those changes back to Tuscany. Those changes include test case corrections and additions, the use of HelperContext, and the use of a new DataObjectFactory class . The DataObjectFactory class has Method and Object[] members that are populated via the constructor. The class has methods with void parameter lists to create different Types of DataObjects relevant to the test cases. In this way, the individual test cases need not be aware of the creation or definition mechanism of the DataObject being tested. I am opening this Jira simply as a mechanism to provide the patch containing our changes. (So that I may provide the required usage agreements with the patch.) Note that the patch is not complete. However, I'm aware that discussion has picked up and I want to provide my changes as quickly so as to avoid unnecessary merging. -- 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: Next SCA release distributions
Simon Laws wrote: On 5/2/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: - tuscany-rmi? Should this be a binding Yes, would be better as tuscany-binding-rmi. We already have a tuscany-binding-rmi module: the implementation of the RMI binding. The tuscany-rmi module defines an RMI hosting extension point, similar to how the tuscany-http module provides an HTTP host extension point. To make that clear, I'd suggest to rename tuscany-rmi to tuscany-host-rmi and tuscany-http to tuscany-host-http. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] You are right. I didn't spot that. I must be going blind. Agree with the move to using host in the name. Simon Ok, I'll do that rename some time later today then. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jetty server is always created
When bringing up the Tuscany core runtime with no usage of any extensions, a Jetty server is always created. AIUI, this should only happen when creating a service that has a Web services binding. The code that creates the Jetty server is in the start method of org.apache.tuscany.http.jetty.module.JettyRuntimeModuleActivator. This appears to be another symptom of the lifecycle-related problems that were introduced when the fine-grained lifecycle support based on AbstractLifecycle and AbstractSCAObject was changed to use the ModuleActivator approach. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Java SDO CTS] thoughts on structure
I have opened Tuscany-1241 to provide the changes my team has made to the CTS. As is mentioned in the Jira, the patch is not entirely complete in and of itself and further may not reflect some of the changes that have gone in recently. However, I'm aware that changes are being made to the CTS and wanted to provide the patch quickly to minimize the complexity of the merge. As per the above discussion, here is my two cents: Packaging: kgWe should be able to apply the parameterization feature of junit without it being so prominent in the source code structure./kg I agree and this seems to be a consensus. The Use of Paramaterized Tests: kgAs far as I can see our usage of the junit parameterized testing function is aimed at ensuring consistency between operations performed on graphs when the metadata has been produced a) from an xsd and b) by using the SDO API to create it dynamically. I propose to rehouse these under test.sdo21.consistency./kg rjmHowever, I don't think that this should be packaged under a consistency package - for me that has the same problems as being organized under paramatized where you do not get a feel for complete API coverage./rjm fbVerifying this by repeating every possible test on the exact same DataObjects, just created differently, sounds a little inefficient. What I think we need instead is to have some set of consistency tests that confirm that the types created in various ways are in fact the same./fb kgHowever, it's not clear to me whether we can now confirm the types are as they should be through the metadata API alone, or whether there are still requirements on an implementation to preserve elements of metadata that can only be detected by the behaviour seen through the data API. However, if it's purely some facets of XSD behaviour that we needed to test empirically then that wouldn't require a parameterized approach./kg My group has been running our version of the CTS and have located several instances of errors specific to one DataObject definiton/creation mechanism. Granted, these are generally specific to the static case. Given this experience, I agree with Kelvin that the running the parameterized tests on the DataObject API adds value. Creating tests that attempt to foresee such instances by working through the metadata API alone would seem to be another instance of testing the testers that Kelvin alluded to earlier. Miscellaneous: fbI also wonder why ParameterizedTestUtil has it's own equals code (instead of just using EqualityHelper). /fb Kelvin addressed this, and he correctly guessed my intent when adding the equal code to ParamaterizedTestUtil. fbI noticed that the TestHelper is unnecessarily complicated. Instead of having all kinds of getXXXHelper() methods, it should just have one getHelperContext() method - that's the only method that is implementation dependant./fb This will be addressed in the resubmission of the patch for Tuscany-1241. It had been addressed in our version of the CTS, but I see that in the first version of the patch provided that is not reflected.
Re: Webapp support in this release
I have started looking into this yesterday, trying to make the das-service web client working, but then decided to start simple as you are suggesting, and started looking at a simple calculator web-app. At the moment i have the sample web-app building Ok, with the necessary dependencies on the war, but when I try to deploy the application to TC it is complaining because the servlet-api jar is getting packaged in the application war. I'm trying to play with the scope of the servlet-api references to see if I can fix the issue. Once I get this done, we could discuss the M1 tomcat distribution approach, and the requirement for that. On 5/2/07, ant elder [EMAIL PROTECTED] wrote: There's been a few past questions about what we're doing to support webapp's in this release. I think the way the runtime is today webapp's should be able to work just like the standalone J2SE samples and all we need to do is make sure the all the tuscany dependency jars are included somewhere. So how about all we do is have a webapp calculator sample similar to the one from M2 but just use the standard Maven war plugin to create the WAR bundling all the required dependencies into the webapp lib directory? We could also have an alternative sample build that assumes all the required tuscany jars are already in the tomcat shared lib so doesn't include them in the sample WAR. (and provide some way to get all the jars needed to be put in the shared lib?) WDYT or any alternative suggestions? Anyone want to volunteer to try doing this? ...ant -- Luciano Resende http://people.apache.org/~lresende
svn commit: r534591 - Calculator web sample application available, was Re: Webapp support in this release
Hi All I have put together a simple web application based on the calculator sample we have. The client/jsp programming model is simple works same as in a J2SE application. The generated war file for the calculator-web app has all required dependencies on it, and should work on your app server of choice. On 5/2/07, Luciano Resende [EMAIL PROTECTED] wrote: I have started looking into this yesterday, trying to make the das-service web client working, but then decided to start simple as you are suggesting, and started looking at a simple calculator web-app. At the moment i have the sample web-app building Ok, with the necessary dependencies on the war, but when I try to deploy the application to TC it is complaining because the servlet-api jar is getting packaged in the application war. I'm trying to play with the scope of the servlet-api references to see if I can fix the issue. Once I get this done, we could discuss the M1 tomcat distribution approach, and the requirement for that. On 5/2/07, ant elder [EMAIL PROTECTED] wrote: There's been a few past questions about what we're doing to support webapp's in this release. I think the way the runtime is today webapp's should be able to work just like the standalone J2SE samples and all we need to do is make sure the all the tuscany dependency jars are included somewhere. So how about all we do is have a webapp calculator sample similar to the one from M2 but just use the standard Maven war plugin to create the WAR bundling all the required dependencies into the webapp lib directory? We could also have an alternative sample build that assumes all the required tuscany jars are already in the tomcat shared lib so doesn't include them in the sample WAR. (and provide some way to get all the jars needed to be put in the shared lib?) WDYT or any alternative suggestions? Anyone want to volunteer to try doing this? ...ant -- Luciano Resende http://people.apache.org/~lresende http://people.apache.org/%7Elresende -- Luciano Resende http://people.apache.org/~lresende
Tuscany runtime dependencies
Here is the complete list of dependencies loaded by the code in tuscany-sca-all-1.0-incubating-SNAPSHOT.jar when starting the Tuscany core runtime. (XML parsing) stax-api-1.0.1.jar wstx-asl-3.2.0.jar (SCA APIs) sca-api-1.0-incubating-SNAPSHOT.jar (used by JettyRuntimeModuleActivator) jetty-util-6.1.0.jar jetty-6.1.0.jar servlet-api-2.5.jar (used by SDOAxiomModuleActivator) axiom-api-1.2.4.jar sdo-api-r2.1-1.0-incubating-SNAPSHOT.jar (used by WSDLInterfaceRuntimeModuleActivator) wsdl4j-1.6.2.jar XmlSchema-1.3.1.jar (used by TomcatRuntimeModuleActivator) catalina-6.0.10.jar coyote-6.0.10.jar juli-6.0.10.jar (used by Axis2ModuleActivator) axis2-kernel-1.2.jar commons-logging-1.1.jar axiom-impl-1.2.4.jar (used by JAXBDataBindingModuleActivator) jaxb-api-2.0.jar I'm concerned about the large number of these. The first 3 cannot reasonably be eliminated. All the others should only be loaded when the extensions that need them are loaded, either based on runtime configuration settings or (preferably) on encountering SCDL that pulls them in. Has anyone been thinking about how to enable a more dynamic approach to optionally pulling in these dependencies? If not, I am happy to look into this further. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant build scripts for SCA samples
On 5/2/07, ant elder [EMAIL PROTECTED] wrote: On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote: On 5/2/07, Simon Nash [EMAIL PROTECTED] wrote: I saw the following discussion in Monday's IRC chat log. (I couldn't attend the chat because I was on a plane.) [12:37] ant_ oh, so with the samples again, I guess we need Ant build scripts [12:37] ant_ lresende, it does right now and i think thats good to do [12:38] jsdelfino yes, +1 for the sample bins [12:38] lresende yes, i like that, but haven't looked into your distro strawman yet [12:38] slaws ant_ - a non maven build solution for samples would be useful [12:38] ant_ do we want mvn as well or just Ant? [12:39] jsdelfino what's the work required to have a mvn build for the samples? don't we already have bit? [12:39] jsdelfino I think we could keep the mvn build, but document the ant one [12:40] slaws if we have two we need to decide whether we maintain two or just fix up ant for releases [12:40] ant_ ok. i guess we just need to make sure the sample mvn's work in the build distro with an empty local repo [12:41] ant_ would anyone like to volunteer to create an Ant script for one of the samples? [12:42] jsdelfino anyone? it shouldn't be too hard, we even had this in M1... [12:42] slaws didn't someone already create some for a previous release that we can lift [12:42] halehM Maybe someone on the mailing list who is not on the IRC? [12:42] halehM post on mailing list? [12:43] ant_ ok, lets skip that one for now then I did some work on this for M2 but nothing was included in the release because of disagreements about some aspects of my proposal. The two main issues were how webapps get built and how dependencies are resolved. I'll look at this again based on the currently proposed release packaging. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Simon, I checked a version of the calculator build.xml into the trunk and have been discussing some of the dependency issues here ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg17320.html) Simon Just fyi, i've tried this calculator Ant build and it seems to work fine for me. ...ant OK, thanks for trying that. I'll make some more. Simon
Re: ant build scripts for SCA samples
On 5/2/07, Simon Nash [EMAIL PROTECTED] wrote: I can build the sample OK using this ant script, but ant run doesn't work. I'm using the pre-built distribution that Ant posted to http://people.apache.org/~antelder/tuscany/latest/ The problem is with the very long Class-Path attribute in MANIFEST.MF of tuscany-sca-manifest.jar. In Ant's pre-built distribution, this line is chopped up into small fixed-size chunks, producing the following error: E:\tuscanybin1\tuscany-sca-1.0-incubating-SNAPSHOT\samples\calculatorant run Buildfile: build.xml init: compile: run: [java] Failed to load Main-Class manifest attribute from [java] E:\tuscanybin1\tuscany- sca-1.0-incubating-SNAPSHOT\lib\tuscany-sca-manifest.jar [java] Java Result: 1 I tried editing the MANIFEST.MF file to put all the Class-Path information in a single line of 3861 characters. This produced the following error: E:\tuscanybin1\tuscany-sca-1.0-incubating-SNAPSHOT\samples\calculatorant run Buildfile: build.xml init: compile: run: [java] java.io.IOException: line too long [java] at java.util.jar.Attributes.read(Attributes.java:362) [java] at java.util.jar.Manifest.read(Manifest.java:167) [java] at java.util.jar.Manifest.init(Manifest.java:52) [java] at java.util.jar.JarFile.getManifestFromReference( JarFile.java:158) [java] at java.util.jar.JarFile.getManifest(JarFile.java:145) [java] Exception in thread main [java] Java Result: 1 Simon ant elder wrote: On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote: On 5/2/07, Simon Nash [EMAIL PROTECTED] wrote: I saw the following discussion in Monday's IRC chat log. (I couldn't attend the chat because I was on a plane.) [12:37] ant_ oh, so with the samples again, I guess we need Ant build scripts [12:37] ant_ lresende, it does right now and i think thats good to do [12:38] jsdelfino yes, +1 for the sample bins [12:38] lresende yes, i like that, but haven't looked into your distro strawman yet [12:38] slaws ant_ - a non maven build solution for samples would be useful [12:38] ant_ do we want mvn as well or just Ant? [12:39] jsdelfino what's the work required to have a mvn build for the samples? don't we already have bit? [12:39] jsdelfino I think we could keep the mvn build, but document the ant one [12:40] slaws if we have two we need to decide whether we maintain two or just fix up ant for releases [12:40] ant_ ok. i guess we just need to make sure the sample mvn's work in the build distro with an empty local repo [12:41] ant_ would anyone like to volunteer to create an Ant script for one of the samples? [12:42] jsdelfino anyone? it shouldn't be too hard, we even had this in M1... [12:42] slaws didn't someone already create some for a previous release that we can lift [12:42] halehM Maybe someone on the mailing list who is not on the IRC? [12:42] halehM post on mailing list? [12:43] ant_ ok, lets skip that one for now then I did some work on this for M2 but nothing was included in the release because of disagreements about some aspects of my proposal. The two main issues were how webapps get built and how dependencies are resolved. I'll look at this again based on the currently proposed release packaging. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Simon, I checked a version of the calculator build.xml into the trunk and have been discussing some of the dependency issues here ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg17320.html) Simon Just fyi, i've tried this calculator Ant build and it seems to work fine for me. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Simon, I have some strange things going on with my distribution build which is affecting the way the manifests are build. Am investigating this now but have to drop off the network til the morning. Also, are you also building ant scripts also? I'm going to try and make a few more so let me know which ones you are doing if you are doing some. Simon
Re: Throwable Input2InputTransformer.java (179) IndexOutOfBoundsException
Hi,
Thank you for reporting this. Actually, the problem is not in the
Input2InputTransformer. It's related to how we map a java interface to a
WSDL portType.
For a wrapper style (please see WS-JAX spec for the definition) WSDL
operation with the following input wrapper element, we don't support it yet
if the child element such as resourcesID with maxOccurs1.
xs:complexType name=editReservation
xs:sequence
xs:element name=timeSlotID type=xs:int/
xs:element name=requestedBy type=xs:string minOccurs=0/
xs:element name=purpose type=xs:string minOccurs=0/
xs:element name=resourcesID type=xs:int maxOccurs=unbounded
minOccurs=0/
/xs:sequence
/xs:complexType
In line 382 of
org.apache.tuscany.interfacedef.wsdl.introspect.WSDLOperation.java, there is
a TODO :-).
Thanks,
Raymond
- Original Message -
From: Paulo Henrique Trecenti [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, May 02, 2007 7:42 AM
Subject: Throwable Input2InputTransformer.java (179)
IndexOutOfBoundsException
Hi,
I found a small bug in Input2InputTransformer.java (179)
Object[] newArgs = new Object[source.length];
for (int i = 0; i source.length; i++) {
Object child = mediator.mediate(source[i],
sourceType.getLogical().get(i), targetType.getLogical().get(i),
context.getMetadata());
newArgs[i] = child;
}
When try parse a java to wsdl
My java interface method is public TimeSlot editReservation(int
timeSlotID, String requestedBy, String purpose, int[] resourcesID);
I have 4 input params
and my wsdl have 1 element with an type having 4 paramenters
When run this code whe have an IndexOutOfBoundsException
Exception in thread main java.lang.IndexOutOfBoundsException : Index:
1,
Size: 1
at java.util.ArrayList.RangeCheck(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at
org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.transform
(Input2InputTransformer.java :179)
at
org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.transform
(Input2InputTransformer.java:1)
at org.apache.tuscany.databinding.impl.MediatorImpl.mediate(
MediatorImpl.java:83)
at
org.apache.tuscany.core.databinding.wire.DataBindingInteceptor.transform(
DataBindingInteceptor.java:189)
at
org.apache.tuscany.core.databinding.wire.DataBindingInteceptor.invoke
(DataBindingInteceptor.java:86)
at org.apache.tuscany.spi.wire.AbstractInvocationHandler.invoke(
AbstractInvocationHandler.java:91)
at
org.apache.tuscany.implementation.java.proxy.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:150)
Not to be that I must work with OMElement in my java interface.
--
Paulo Henrique Trecenti
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Throwable Input2InputTransformer.java (179) IndexOutOfBoundsException
Ok I can work in this task, because I need this.
Currently I am making one sample where I would like to donate for the
project sca tuscany, the Luciano Resende is helping me very in this.
Thanks.
2007/5/2, Raymond Feng [EMAIL PROTECTED]:
Hi,
Thank you for reporting this. Actually, the problem is not in the
Input2InputTransformer. It's related to how we map a java interface to a
WSDL portType.
For a wrapper style (please see WS-JAX spec for the definition) WSDL
operation with the following input wrapper element, we don't support it
yet
if the child element such as resourcesID with maxOccurs1.
xs:complexType name=editReservation
xs:sequence
xs:element name=timeSlotID type=xs:int/
xs:element name=requestedBy type=xs:string minOccurs=0/
xs:element name=purpose type=xs:string minOccurs=0/
xs:element name=resourcesID type=xs:int maxOccurs=unbounded
minOccurs=0/
/xs:sequence
/xs:complexType
In line 382 of
org.apache.tuscany.interfacedef.wsdl.introspect.WSDLOperation.java, there
is
a TODO :-).
Thanks,
Raymond
- Original Message -
From: Paulo Henrique Trecenti [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, May 02, 2007 7:42 AM
Subject: Throwable Input2InputTransformer.java (179)
IndexOutOfBoundsException
Hi,
I found a small bug in Input2InputTransformer.java (179)
Object[] newArgs = new Object[source.length];
for (int i = 0; i source.length; i++) {
Object child = mediator.mediate(source[i],
sourceType.getLogical().get(i), targetType.getLogical().get(i),
context.getMetadata());
newArgs[i] = child;
}
When try parse a java to wsdl
My java interface method is public TimeSlot editReservation(int
timeSlotID, String requestedBy, String purpose, int[] resourcesID);
I have 4 input params
and my wsdl have 1 element with an type having 4 paramenters
When run this code whe have an IndexOutOfBoundsException
Exception in thread main java.lang.IndexOutOfBoundsException : Index:
1,
Size: 1
at java.util.ArrayList.RangeCheck(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at
org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.transform
(Input2InputTransformer.java :179)
at
org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.transform
(Input2InputTransformer.java:1)
at org.apache.tuscany.databinding.impl.MediatorImpl.mediate(
MediatorImpl.java:83)
at
org.apache.tuscany.core.databinding.wire.DataBindingInteceptor.transform
(
DataBindingInteceptor.java:189)
at
org.apache.tuscany.core.databinding.wire.DataBindingInteceptor.invoke
(DataBindingInteceptor.java:86)
at org.apache.tuscany.spi.wire.AbstractInvocationHandler.invoke(
AbstractInvocationHandler.java:91)
at
org.apache.tuscany.implementation.java.proxy.JDKInvocationHandler.invoke
(
JDKInvocationHandler.java:150)
Not to be that I must work with OMElement in my java interface.
--
Paulo Henrique Trecenti
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paulo Henrique Trecenti
Re: Next SCA release distributions
On 5/2/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: - tuscany-rmi? Should this be a binding Yes, would be better as tuscany-binding-rmi. We already have a tuscany-binding-rmi module: the implementation of the RMI binding. The tuscany-rmi module defines an RMI hosting extension point, similar to how the tuscany-http module provides an HTTP host extension point. To make that clear, I'd suggest to rename tuscany-rmi to tuscany-host-rmi and tuscany-http to tuscany-host-http. +1 to changing to tuscany-host-rmi and tuscany-host-http But we also have a tuscany-host-spi and tuscany-host-embedded which have nothing to do with and aren't used by tuscany-host-rmi and tuscany-host-http, could these be renamed to something like tuscany-host-spi be tuscany-runtime-spi and tuscany-host-embedded be tuscany-runtime-embedded? If there's going to be any module name changes then the package name used withing the module will also have to be renamed right? So how about starting to change things to org.apache.tuscany.sca at the same time? And vaguely related, everywhere we have a dependency on tuscany-host-embedded we also have a dependency on tuscany-implementation-java-runtime, how about to simplify things (eg for the sample pom's) we add tuscany-implementation-java-runtime as a dependency in tuscany-host-embedded? ...ant
Re: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)
+1 on 0.90 On 5/2/07, ant elder [EMAIL PROTECTED] wrote: It would be good to choose a name soon so we can start completing all the readme's and release notes etc, there doesn't seem much consensus on beta1 so how about 0.90? That sounds closer to 1.0 than M3 or alpha and still gives space for more releases before the final 1.0. ...ant On 5/1/07, Bert Lamb [EMAIL PROTECTED] wrote: I realize I'm a bit late to this conversation, I'm just now getting mostly unpacked from a move to Somerville, MA. I agree with Simon in that we should be careful what we call beta. I know that we all would like to get to beta quality code and features as soon as we can, but I don't think we are there yet nor will we be there by JavaOne. What we currently have in the trunk I think is a much more manageable code base but it actually has fewer features, if I'm not mistaken, than M2 had. So, my vote, if I had a binding one, would be for 3, with a name of M3 or maybe alpha. -Bert On 4/25/07, ant elder [EMAIL PROTECTED] wrote: On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote: snip/ So I think it comes down to whether it is more important to put something out by JavaOne (in which case I'd be hesitant to call it beta) or whether it is more important to attain a true beta level of quality even if that takes a little bit longer. I guess a lot comes down to everyones slightly different perceptions as to what the name beta implies, what do others think about this? Should we: 1) continue aiming for a beta1 release around JavaOne timeframe 2) continue with a beta1 release but take a bit more time 3) aim for a release around JavaOne timeframe but change to a non-beta release name, alpha-x or maybe a numeric like 0.90? I probably favor (2) as looking at things people have said they'd like to get done it seems unlikely to me we'll be ready by JavaOne anyway. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)
why does it matter if we call it beta1 or beta .90? It is a variation of what we call beta. The fact that there is a number after Beta is an indication that there might be revisions of Beta anyway before 1.0 release is reached. On 5/2/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: +1 on 0.90 On 5/2/07, ant elder [EMAIL PROTECTED] wrote: It would be good to choose a name soon so we can start completing all the readme's and release notes etc, there doesn't seem much consensus on beta1 so how about 0.90? That sounds closer to 1.0 than M3 or alpha and still gives space for more releases before the final 1.0. ...ant On 5/1/07, Bert Lamb [EMAIL PROTECTED] wrote: I realize I'm a bit late to this conversation, I'm just now getting mostly unpacked from a move to Somerville, MA. I agree with Simon in that we should be careful what we call beta. I know that we all would like to get to beta quality code and features as soon as we can, but I don't think we are there yet nor will we be there by JavaOne. What we currently have in the trunk I think is a much more manageable code base but it actually has fewer features, if I'm not mistaken, than M2 had. So, my vote, if I had a binding one, would be for 3, with a name of M3 or maybe alpha. -Bert On 4/25/07, ant elder [EMAIL PROTECTED] wrote: On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote: snip/ So I think it comes down to whether it is more important to put something out by JavaOne (in which case I'd be hesitant to call it beta) or whether it is more important to attain a true beta level of quality even if that takes a little bit longer. I guess a lot comes down to everyones slightly different perceptions as to what the name beta implies, what do others think about this? Should we: 1) continue aiming for a beta1 release around JavaOne timeframe 2) continue with a beta1 release but take a bit more time 3) aim for a release around JavaOne timeframe but change to a non-beta release name, alpha-x or maybe a numeric like 0.90? I probably favor (2) as looking at things people have said they'd like to get done it seems unlikely to me we'll be ready by JavaOne anyway. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Tuscany SCA Native and Tuscany SDO C++ Milestone 3 Releases
The Apache Tuscany community is pleased to announce Milestone 3 releases of Service Component Architecture (SCA) Native and Service Data Objects (SDO) for C++. The Tuscany SCA Native release: http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Downloads The Tuscany SDO C++ release: http://cwiki.apache.org/confluence/display/TUSCANY/SDO+Downloads For further information, visit our web site at: http://incubator.apache.org/tuscany Release Summary = Tuscany SCA Native provides a runtime implementation for the Service Component Architecture Assembly Model specification version 0.96 and the Service Component Architecture Client and Implementation for C++ specification version 0.95. The Tuscany SCA Native M3 Release includes support for component implementations written in C++, Python and Ruby languages. It also includes support for interface bindings using webservices (using Axis2C) and REST. Tuscany SDO C++ is an implementation of the Service Data Objects 2.01 specification for C++ developers. The M3 release includes performance improvements (30-40%) along with improvements to robustness. Both SCA and SCA releases now support the Mac OS X operating system. For pointers to the specification documents, visit the Open Service Oriented Architecture (OSOA) collaboration website: http://osoa.org/display/Main/Home. Incubation Tuscany is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the Web Services PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. Please feel free to send any feedback to our mailing lists: tuscany-dev@ws.apache.org [EMAIL PROTECTED] Any contribution in the form of coding, testing, improving the documentation, and reporting bugs is always welcome. For more information on how to get involved with the development of Tuscany, visit our Get Involved page at: http://incubator.apache.org/tuscany/get-involved.html Thank you for your interest in Apache Tuscany! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant build scripts for SCA samples
Simon Laws wrote: Simon, I have some strange things going on with my distribution build which is affecting the way the manifests are build. Am investigating this now but have to drop off the network til the morning. Also, are you also building ant scripts also? I'm going to try and make a few more so let me know which ones you are doing if you are doing some. In the ant scripts I made for M2, I used a slightly different pattern for the compile step that eliminates the two copy steps that you are using. This pattern uses fileset and metainf elements within the jar task. I have tested this pattern within your script and it works fine. I suggest that you use this pattern in the new scripts that you are making. Here's an example of this pattern: target name=compile depends=init javac srcdir=src/main/java destdir=target/classes debug=on source=1.5 target=1.5 classpath pathelement location=../../lib/tuscany-sca-all-1.0-incubating-SNAPSHOT.jar/ pathelement location=../../lib/sca-api-1.0-incubating-SNAPSHOT.jar/ /classpath /javac jar destfile=target/sample-calculator.jar basedir=target/classes fileset dir=src/main/resources/ metainf dir='.' includes=LICENSE.txt,NOTICE.txt/ manifest attribute name=Main-Class value=calculator.CalculatorClient/ /manifest /jar /target Note the different classpath from the one that you used. I could not get tuscany-sca-manifest.jar to work for me either at compile time or at runtime. I may have been doing something wrong, but I'm not sure what. For the run target, because of my problems with tuscany-sca-manifest.jar, I needed to use the following: target name=run depends=compile java classname=calculator.CalculatorClient fork=true classpath pathelement location=target/sample-calculator.jar/ pathelement location=../../lib/tuscany-sca-all-1.0-incubating-SNAPSHOT.jar/ pathelement location=../../lib/sca-api-1.0-incubating-SNAPSHOT.jar/ pathelement location=../../lib/axiom-impl-1.2.4.jar/ pathelement location=../../lib/jetty-util-6.1.0.jar/ pathelement location=../../lib/commons-logging-1.1.jar/ pathelement location=../../lib/sdo-api-r2.1-1.0-incubating-SNAPSHOT.jar/ pathelement location=../../lib/jaxb-api-2.0.jar/ pathelement location=../../lib/XmlSchema-1.3.1.jar/ pathelement location=../../lib/jetty-6.1.0.jar/ pathelement location=../../lib/catalina-6.0.10.jar/ pathelement location=../../lib/wsdl4j-1.6.2.jar/ pathelement location=../../lib/stax-api-1.0.1.jar/ pathelement location=../../lib/axis2-kernel-1.2.jar/ pathelement location=../../lib/wstx-asl-3.2.0.jar/ pathelement location=../../lib/servlet-api-2.5.jar/ pathelement location=../../lib/coyote-6.0.10.jar/ pathelement location=../../lib/juli-6.0.10.jar/ pathelement location=../../lib/axiom-api-1.2.4.jar/ /classpath /java /target I'd like to resolve the problems with tuscany-sca-manifest.jar before I make any more of these. The above code doesn't feel good to me. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)
I thought Ant's suggestion was just 0.90 and not beta anything. I can live with this. I don't think we are ready yet to call it beta 1.0 or beta1 1.0. Simon haleh mahbod wrote: why does it matter if we call it beta1 or beta .90? It is a variation of what we call beta. The fact that there is a number after Beta is an indication that there might be revisions of Beta anyway before 1.0 release is reached. On 5/2/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: +1 on 0.90 On 5/2/07, ant elder [EMAIL PROTECTED] wrote: It would be good to choose a name soon so we can start completing all the readme's and release notes etc, there doesn't seem much consensus on beta1 so how about 0.90? That sounds closer to 1.0 than M3 or alpha and still gives space for more releases before the final 1.0. ...ant On 5/1/07, Bert Lamb [EMAIL PROTECTED] wrote: I realize I'm a bit late to this conversation, I'm just now getting mostly unpacked from a move to Somerville, MA. I agree with Simon in that we should be careful what we call beta. I know that we all would like to get to beta quality code and features as soon as we can, but I don't think we are there yet nor will we be there by JavaOne. What we currently have in the trunk I think is a much more manageable code base but it actually has fewer features, if I'm not mistaken, than M2 had. So, my vote, if I had a binding one, would be for 3, with a name of M3 or maybe alpha. -Bert On 4/25/07, ant elder [EMAIL PROTECTED] wrote: On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote: snip/ So I think it comes down to whether it is more important to put something out by JavaOne (in which case I'd be hesitant to call it beta) or whether it is more important to attain a true beta level of quality even if that takes a little bit longer. I guess a lot comes down to everyones slightly different perceptions as to what the name beta implies, what do others think about this? Should we: 1) continue aiming for a beta1 release around JavaOne timeframe 2) continue with a beta1 release but take a bit more time 3) aim for a release around JavaOne timeframe but change to a non-beta release name, alpha-x or maybe a numeric like 0.90? I probably favor (2) as looking at things people have said they'd like to get done it seems unlikely to me we'll be ready by JavaOne anyway. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetty server is always created
Comments inline. Simon Nash wrote: When bringing up the Tuscany core runtime with no usage of any extensions, a Jetty server is always created. AIUI, this should only happen when creating a service that has a Web services binding. The creation of an instance of our JettyServer class should only happen if you've decided to include that module in your environment. Most of our samples do not have it on their classpath, and they shouldn't if they're not running at all as a server. How are you running your application? I am running the calculator sample an I don't see a JettyServer created. Or are you using the tuscany-all JAR? I just checked it and I think that the distribution build script puts too much in it... as it contains both the http-jetty and http-tomcat modules, two web servers are probably too much :), and we should actually probably keep these out of this JAR anyway. The code that creates the Jetty server is in the start method of org.apache.tuscany.http.jetty.module.JettyRuntimeModuleActivator. This appears to be another symptom of the lifecycle-related problems that were introduced when the fine-grained lifecycle support based on AbstractLifecycle and AbstractSCAObject was changed to use the ModuleActivator approach. There may be a little bit of confusion here. We have not really replaced AbstractLifecycle by ModuleActivator. Here are the various lifecycle handling points: 1. ModuleActivator.getExtensionPoints() - invoked first when the runtime starts and finds the available modules, gives an opportunity to a module to contribute extension points 2. ModuleActivator.start()/stop() - invoked when the runtime starts and gives an opportunity to modules to register extensions 3. Implementation/ReferenceBinding/ServiceBindingActivator.start()/stop() - invoked when a component gets started/stopped to give component implementations, reference and service bindings an opportunity to start/stop. 4. ImplementationProvider.createInstance() and the interaction with the scope container is the last level of lifecycle management. It looks like Raymond is in the middle of porting some of the core runtime to the newer interfaces so some code may still reference AbstractLifecycle, newer code may already reference the new interfaces. Going back to the JettyServer case, here's how I think it works: 1. SCARuntime starts. 2. All modules configured in your environment are started with ModuleActivator.getExtensionPoints() and then start(). JettyServer gets registered as a ServletHost extension, but a Jetty Server instance is not created and not started at this point. 3. Composites are loaded, a WS binding is found, Axis2ServiceBinding instances get created and register their servlets with a URI into ServletHost. 4. ServletHost delegates to JettyServer to register each servlet, the Jetty Server actually starts at this point Ant, Ignacio and myself had discussions on this list to see how to handle multiple HTTP ports / connectors and I think that Ant has started to look into that. 5. Axis2ServiceBinding.start() should be called next on each service/reference with a WS binding - this is probably not happening yet as I believe that the Axis2ServiceBinding has not been ported to the latest interfaces yet. When everything is ported over to the new interfaces the registration of the servlet (and the start of the Jetty instance) will happen in step 5 instead of 4, which actually won't really change much in terms of timing... Comparing this with what we had in the past: - in the environment we had in the integration branch, a Jetty server was started - as a system composite scoped component instead of a module - in step 2 if I remember correctly - before that, we were running on top of Tomcat, and Tomcat was always started as well, first even before SCA, in step 0 :) Hope this helps. Simon -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RMI Binding reactivated on the trunk
Hi Venkat, are the RMI samples working now (calculator-rmi-reference and calculator-rmi-service)? Just checking as they were not added into the samples pom, so they could be built during regular builds. On 4/28/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I have added a couple of samples now - one to demonstrate RMI Binding as reference binding and another to demonstrate RMI Binding as service binding. I have also added a readme.html to these samples. Thanks. - Venkat On 4/27/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Sebastien, thanks for taking a look. The testcase in there... maybe its actually a itest, show how it works, but then it combines the rmi reference and service into one test. So I agree that we must have a sample and will work on that. - Venkat On 4/27/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, I have got the RMI Binding going on the trunk now. This is implemented with two modules Java RMI Binding and Java RMI Host Extension Point. For now I have combined the processor, model and runtime parts of the RMI Binding into a single module but under distinct packages. As we whet our SPIs, I shall split them into separate modules. Thanks - Venkat Great, Thanks! I took a look and built it, it looks good. I just reformatted the pom.xml a little as it contained tabs and added an svn:ignore properties setting. I think it would be nice to have a simple sample showing how to use the binding under java/sca/samples. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende http://people.apache.org/~lresende
Quick Guide for SCA
Hi, I have started working on Java SCA user guide [1] and Quick overview guide for SCA[2]. I am assuming that Quick overview guide will be generic and can be used for both native SCA and Java. Please jump in and help if you are interested or provide comments/feedback. We can use some good diagrams :) Thanks, Haleh [1] http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+User+Guide [2] http://cwiki.apache.org/confluence/display/TUSCANY/Quick+Guide+to+SCA
Re: Tuscany runtime dependencies
Simon Nash wrote: Here is the complete list of dependencies loaded by the code in tuscany-sca-all-1.0-incubating-SNAPSHOT.jar when starting the Tuscany core runtime. (XML parsing) stax-api-1.0.1.jar wstx-asl-3.2.0.jar (SCA APIs) sca-api-1.0-incubating-SNAPSHOT.jar (used by JettyRuntimeModuleActivator) jetty-util-6.1.0.jar jetty-6.1.0.jar servlet-api-2.5.jar (used by SDOAxiomModuleActivator) axiom-api-1.2.4.jar sdo-api-r2.1-1.0-incubating-SNAPSHOT.jar (used by WSDLInterfaceRuntimeModuleActivator) wsdl4j-1.6.2.jar XmlSchema-1.3.1.jar (used by TomcatRuntimeModuleActivator) catalina-6.0.10.jar coyote-6.0.10.jar juli-6.0.10.jar (used by Axis2ModuleActivator) axis2-kernel-1.2.jar commons-logging-1.1.jar axiom-impl-1.2.4.jar (used by JAXBDataBindingModuleActivator) jaxb-api-2.0.jar I'm concerned about the large number of these. The first 3 cannot reasonably be eliminated. All the others should only be loaded when the extensions that need them are loaded, either based on runtime configuration settings or (preferably) on encountering SCDL that pulls them in. Has anyone been thinking about how to enable a more dynamic approach to optionally pulling in these dependencies? If not, I am happy to look into this further. Simon Simon, I agree with you that we shouldn't always load all extensions and their dependencies. What you're seeing is a side effect of tuscany-sca-all.jar and tuscany-sca-manifest.jar. Tuscany-sca-all.jar is a brute force approach as it munges all the Tuscany code in one JAR and declares the activation of all our extensions in a single file under META-INF/services generated by the build. The result is what you're seeing, all extensions activated at runtime start. If you run applications like we have configured the samples in our regular build, you won't run into that issue at all. I think there's many ways to handle this: a) document how to configure the runtime's classpath with the correct dependencies, depending on which bindings and component implementation types you are planning to run on this runtime. b) come up with 3 or 4 more targeted JARs, smaller than tuscany-sca-all, for use in a client, a web server, with or without our most popular bindings and component implementation types. c) move the META-INF/services/...ModuleActivator file out of the JAR, allowing the system administrator to control what gets activated d) generate that file from the contents of the composites that a given runtime is supposed to be running (this is equivalent to what our Maven WAR plugin was doing before) e) remove the 3 lines of code that aggressively start all modules in AbstractRuntime.java:157 and make a small change to ModuleActivator and SimpleRuntimeImpl to only start a module as necessary. I wanted to do (e) later as an optimization but didn't think that it was really necessary right now. We could do it now, if we decide to continue with tuscany-sca-all.jar. However, after having experimented a little more with this today, I would actually favor option (b) now. I started to prefer option (b) after having loaded some of the samples from the distro in Eclipse (to see what the developer experience was going to be and the steps to do it), and I'm not sure I really like to have the big tuscany-sca-all JAR plus all its dependencies loaded in all my Eclipse projects... Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
