Re: Endpoint registry and stopping/starting nodes
...snip > seems quite fragile, In what way? > if it wouldn't be more robust to do the earlier suggestion of just > having the sca binding look up the endpoint from the endpoint registry > on each invocation. No I don't think so. In distributed environments you will *always* have to deal with the error case. See fallacies 1 and 2 [1]. If you were to rely solely on the registry and the registry tells you that the endpoint hasn't change is this true or has the registry just not caught up with real changes out there. Simon [1] http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing
Re: Endpoint registry and stopping/starting nodes
> is simple and likely will have the same result. > The "same result" being that you need a strategy for dealing with errors. Simon
Re: Endpoint registry and stopping/starting nodes
personally I'd rather... Catch the error look to see if the registry has a new endpoint if it has use it if it hasn't throw the error However this is not a big piece of code so there is plenty of scope for us to experiment. I would go ahead and do whatever you prefer for the time being and at least we will have something to play with. Simon
Re: Contribution-JEE iTest erros, was Re: [1.x] Error building java-1.5.1 branch
Just done a 1.5.1 linux build (Sun JDK 1.6-07) and this is what I see... [INFO] Apache Tuscany SCA Store Tutorial Integration Test FAILED [18.309s] [INFO] [INFO] Error for project: Apache Tuscany SCA Gdata Binding Extension Runtime GSOC (during install) [INFO] [INFO] There are test failures. Please refer to /home/slaws/tuscany/sca-java-1.5.1/modules/binding-gdata-runtime/target/surefire-reports for the individual test results. [INFO] [INFO] Error for project: Apache Tuscany SCA iTest Domain Manager Callback Run Test (during install) [INFO] [INFO] There are test failures. Please refer to /home/slaws/tuscany/sca-java-1.5.1/itest/domainmgr/callback/runtest/target/surefire-reports for the individual test results. [INFO] [INFO] Error for project: Apache Tuscany SCA iTest JMS (during install) [INFO] [INFO] There are test failures. Please refer to /home/slaws/tuscany/sca-java-1.5.1/itest/jms/target/surefire-reports for the individual test results. [INFO] [INFO] Error for project: Apache Tuscany SCA Store Tutorial Integration Test (during install) [INFO] [INFO] There are test failures. Please refer to /home/slaws/tuscany/sca-java-1.5.1/tutorials/store/store-test/target/surefire-reports for the individual test results. Are you no now seeing any of these? Simon
Re: Contribution-JEE iTest erros, was Re: [1.x] Error building java-1.5.1 branch
The JMS problem is just a timing issues. The TimeToLive is set very short for one of the property tests and it's obviously behaving slightly differently on my Linux compared to Windows. Simon
Re: More selective building option
I agree with Mike's point. Given the code structure as it stands we should be doing a full build before checking changes is. This doesn't prevent any kind of profile being created for intermediate builds but on check in we need to ensure that everything works. You will of course say "but we don't do that sometimes" and I agree however the point is that we should do it. Now, could we do things differently? Firstly is there a way of getting maven to build a module and all the modules that depend on it (either directly or transitively)? If not can we generate build files for another system that will do incremental builds (I remember that we used to have an incremental builder at some point in the past but I don't know how good it was) Alternatively we have to take a manual approach. I see the code separated into a core and the extensions that the core supports. We could make some rules/profiles for the types of build you need to do depending on which files you change. For example, core change = build all while extension change = build the extension and its tests and samples. Alternatively, rely more heavily on the contract between core and extensions so that features can be built independently. None of this says anything about how the code is released b.t.w. That is a separate question. Simon
Re: Discovery-based SCA Domain for OSGi RFC 119
Can we leave them in for the time being. I'm finding it useful for testing at the moment. A central place where I can look at what endpoint references are active as I mess about with the builders. Simon
Re: More selective building option
> structure like that so IMHO what Giorgio is doing with a profile that > suits himself seems like a fine way to make a gradual start on this. Absolutely, this isn't about moving code about in the repository it's about understanding which profiles/tests/contracts support more granular builds. Simon
[2.x] split package in domain node
I note that the domain-node module defines the package... org.apache.tuscany.sca.node Which is also defined in node-api. Is this necessary? How about org.apache.tuscany.sca.domain.node I can't get my Eclipse PDE workspace to settle down with the latest 2.x code (I do get a clean maven build) and this isn't helping. regards Simon
Re: [2.x] split package in domain node
I'm also getting lots of manifest problems in the domain-node and endpoint-wrapper area. Are the manifests in svn intended to be correct? Simon
Re: [2.x] split package in domain node
Thanks Raymond > I'm seeing missing import-package headers too. The issue is far deeper than > just the split packages. It creates quite a few dependencies to the > "internal" implementation classes. We need to find better ways to handle > such things. +1 > > I fixed the obvious ones under r810317 and r810319. You beat me to the commit ;-) Simon
Re: [2.x] [DISCUSS] Backward compatibility
> I was having thinking about backward compatibility again and wonder if > there is another approach we've not mentioned yet which may be easier > - translate OSOA contributions to OASIS at runtime. At the simplest > level all that needs to be done is change the namespace in XML files > (eg in getName in the XMLStreamReader) and change the annotation > package name in Java implementation classes (eg using ASM in > BaseJavaImplementationImpl.setJavaClass), just those two changes would > get a lot of the 1.x samples running in 2.x, and with a bit more work > would be to do more complex transformations of composites to map > between OSOA and OASIS. There are some things we can't support, such > as conversations, but we should be able to get a lot of 1.x > contributions running on the 2.x runtime with that approach. > > WDYT, is this something worth having a go at? > > ...ant > I think Mark discussed this approach originally under the title of a migration tool. Given that we currently support OSOA and OASIS composites using separate runtimes then a migration tool would be useful. However I don't agree with the "at runtime" part. If we build a migration tool I think it should be under the control of the user as to when it runs. If they have a 1.0 composite then they can convert it to a 1.1 composite, take notice of any errors that are reported during the conversion and, once happy, run it on the 1.1 runtime. No magic required. Simon
Re: 2.0 M4 release?
On Tue, Sep 1, 2009 at 9:09 AM, ant elder wrote: > Its been nearly 6 weeks since the 2.0 M3 release so should we be > thinking about another release? We probably have enough content now - > the Assembly otests are nearly all passing, the're a new JSONP > binding, and the dynamic domain is starting to come together. So would > a M4 in a couple of weeks be doable? Or a bit longer to fit in more? > > ...ant > Excellent idea. I think we should update the CHANGES file and see how it looks. The SCAClient changes you mention on the other thread [1] sound useful to get in. Also I'd like to add the builder tidy and basic policy (not including external attachment) support to the list as these are in flight and have a chance of being done in the next couple of weeks. Simon [1] http://www.mail-archive.com/dev%40tuscany.apache.org/msg09208.html
Re: [1.x] Release 1.5.1 kicking the tyres
I didn't get much response to this directly but I notice that a number of problems have been identified and fixes are ongoing. I'm trying now to identify precisely which fixes we need to make in order to get the first real RC out for 1.5.1. If you've been trying to build 1.5.1 and are having problems can you please raise JIRA against the 1.5.1 category so we can track them. Also if you are doing general fixes please make sure that they go into the 1.x branch and not 1.5.1. We need to be trying to stabalize 1.5.1 without introducing more changes unless necessary. Thanks Simon
Re: [2.x] [DISCUSS] Backward compatibility
Sounds good, and we could awk (or similar) java files to replace OSOA package names with OASIS package names. Simon
Re: [1.5.1] Multiple test failures in contribution-jee iTests in Mac OS X environment
So this sounds Mac specific. Am I right? I'm not seeing this particular one on Windows or Linux. Simon
Re: Endpoint serialization and the distributed endpoint registry
On Fri, Sep 4, 2009 at 9:23 AM, ant elder wrote: > Whats the status of Endpoint serialization? I see there is some code > for this but I'm not sure how finished it is, and it doesn't look like > remote endpoints in the endpoint registry get much of their fields > deserialized yet. Is this something thats in progress by someone or > can i just start adding anything i need? > > ...ant > Not sure. I added code for the EndpointReference serialization we need in order to pass ServiceReferences when handling callbacks but I haven't really looked in detail at the Enpoint serialization itself other than to replicate the pattern it uses. I think Raymond was bringing it up though I'd say go ahead and improve it where you see deficiencies. Simon
Re: [1.x] Release 1.5.1 kicking the tyres
On Mon, Sep 7, 2009 at 12:21 PM, ant elder wrote: > On Thu, Sep 3, 2009 at 10:47 AM, Simon Laws wrote: >> I didn't get much response to this directly but I notice that a number >> of problems have been identified and fixes are ongoing. >> >> I'm trying now to identify precisely which fixes we need to make in >> order to get the first real RC out for 1.5.1. If you've been trying to >> build 1.5.1 and are having problems can you please raise JIRA against >> the 1.5.1 category so we can track them. >> >> Also if you are doing general fixes please make sure that they go into >> the 1.x branch and not 1.5.1. We need to be trying to stabalize 1.5.1 >> without introducing more changes unless necessary. >> >> Thanks >> >> Simon >> > > I get three failures on a full build of the 1.5.1 branch, haven't > looked in any detail at them yet, they are: > > [INFO] Error for project: Apache Tuscany SCA Gdata Binding Extension > Runtime GSOC (during install) > [INFO] > > [INFO] There are test failures. > > Please refer to > C:\Tuscany\SVN\1.5.1-brn\modules\binding-gdata-runtime\target\surefire-reports > for the individual test results. > [INFO] > > [INFO] Error for project: Apache Tuscany SCA iTest Domain Manager > Callback Run Test (during install) > [INFO] > > [INFO] There are test failures. > > Please refer to > C:\Tuscany\SVN\1.5.1-brn\itest\domainmgr\callback\runtest\target\surefire-reports > for the individual test results. > [INFO] > > [INFO] Error for project: Apache Tuscany SCA Store Tutorial > Integration Test (during install) > [INFO] > > [INFO] There are test failures. > > Please refer to > C:\Tuscany\SVN\1.5.1-brn\tutorials\store\store-test\target\surefire-reports > for the individual test results. > [INFO] > > > ...ant > I see the same. I'm looking at the DomainManager one atm. Simon
[1.x] domainmgr itests in 1.5.1 but not in 1.x
I notice there are some itests, specifically itest/domainmgr, that are in 1.5.1 and not in 1.x. This seems strange. Is there are good reason that this is the case? Simon
Re: [jira] Reopened: (TUSCANY-3164) Unable to build binding-gdata-runtime
I don't know the GData binidng. However it is working for me which would suggest that there is either an environment or timing issue when it gets down to deleting whatever resources have been created. Simon
Re: [1.x] Release 1.5.1 kicking the tyres
And additionally I'm seeing [INFO] Error for project: Apache Tuscany SCA Eclipse Tools Update Site (during i nstall) [INFO] [INFO] Failed to resolve artifact. No versions are present in the repository for the artifact with a range [3.2.0,4 .0.0) org.eclipse.equinox:registry:jar:null from the specified remote repositories: indiana (http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache.ws.zone (http://ws.zones.apache.org/repository2), central (http://repo1.maven.org/maven2), osuosl.org (http://ftp.osuosl.org/pub/eclipse/tools/emf/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository) But suspect this is some local environment problem. Simon
Re: [1.x] domainmgr itests in 1.5.1 but not in 1.x
Ah, ok. Thanks Simon Simon
Re: [jira] Reopened: (TUSCANY-3164) Unable to build binding-gdata-runtime
I've just now seen it on Linux. Don't remember seeing it on WinXP. Simon
[1.5.1/1.x] problem writing namespaces
I'm looking at TUSCANY-3264 where namespaces are missing from some
elements when a composite is written out. I don't have specific proof
but it seems to be realted in some way to TUSCANY-3212. Debugging the
code into the BaseStAXArtifactProcessor I note that the problem arises
when writing out in this code
protected void writeStart(XMLStreamWriter writer, String uri,
String name, XAttr... attrs) throws XMLStreamException {
String prefix = writeElementPrefix(writer, uri);
writer.writeStartElement(uri, name);
if (prefix != null){
writer.writeNamespace(prefix,uri);
}
writeAttributePrefixes(writer, attrs);
writeAttributes(writer, attrs);
}
writeElementPrefix returns non-null and hence writeNamespace() is not
called. This, I think, means that the stream thinks that it has
already written out this namespace. The written xml is as follows...
http://www.osoa.org/xmlns/sca/1.0";
xmlns:ns1="http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="http://store"name="store-supplier";>
http://tuscany.apache.org/xmlns/sca/1.0";
xmlns:widget="http://tuscany.apache.org/xmlns/sca/1.0";
location="uiservices/store.html" />
http://localhost:8103/ui"; />
...
So it has already written out wstxns1 but not in a scope that contains
binding.http.
Now I'm a bit reluctant to dive in and start fixing this as there's a
good chance I'll mess us something else by doing so. I'd like to walk
though this with someone who knows how the writers are supposed to
work. Raymond?
Simon
Re: [jira] Reopened: (TUSCANY-3164) Unable to build binding-gdata-runtime
Mine failed at 2000 also. Haven't tried a larger number yet. Simon
Re: [1.x] Release 1.5.1 kicking the tyres
On Wed, Sep 9, 2009 at 12:25 AM, Luciano Resende wrote: > I have finally gotten a success build from 1.5.1 in Linux environment > > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 29 minutes 39 seconds > [INFO] Finished at: Tue Sep 08 16:07:55 PDT 2009 > [INFO] Final Memory: 337M/970M > [INFO] > > > > > -- > Luciano Resende > http://people.apache.org/~lresende > http://lresende.blogspot.com/ > Hey Lucinao. Thanks for all you work on this. With a local change for TUSCANY-3270 (which I'm about to check in) I've finally got a clean Linux build also. Whoppeee. About time too. Widows is still running . Simon
Re: [1.x] Release 1.5.1 kicking the tyres
Hi Simon For 3165 are you still getting the same errors as reported? Th StringIndexOutOfBoundsException looks like the original problem we were having in openejb 3.0.1 reported here https://issues.apache.org/jira/browse/OPENEJB-1005 I believe the fix was targeted at 3.0.2. I see a snapshot of 3.0.2 at https://repository.apache.org/content/groups/snapshots/org/apache/openejb/ However I don't see are release so I think we need to try the snapshot and, assuming it works, ask the open ejb guys to release it for us. I'll flick my local contribution-jee-impl pom over and see what happens. I believe this is a Windows only problem hence the clean Linux build we have. Simon
Re: [1.x] Release 1.5.1 kicking the tyres
I moved up to open ejb 3.0.2 SNAPSHOT and it now works for me mostly. However I have seen it fail in a full build although it passes when I compile the test directly. Am trying to catch it in the debugger. Simon
Re: [1.x] domainmgr itests in 1.5.1 but not in 1.x
Great, thanks Simon Simon
Re: [1.x] Release 1.5.1 kicking the tyres
I know it does fail sometimes but I haven't had it trip over in the last few builds. As we (mostly) have the 1.5.1 build working I built another local distro and ran through the samples. See [1]. Not looking too bad TUSCANY-3271 - helloworld-reference/service-erlang fails and I'm tempted to remove erlang function from 1.5.1. It wasn't in 1.5.I think it should be in 1.6 TUSCANY-3272 - holder-ws-service falure ClassNotFoundException: org.example.orderservice.OrderServiceTestCase TUSCANY-3273 - query-xquery databinding exception TUSCANY-3274 - store-dojo/secure/webapp no build.xml. I'm minded to remove these samples unless someone already has these files TUSCANY-3275 - alert-aggregator-webapp failes to start, probably the generated build file. I haven't tried the store Tutorial or the update site and I know Luciano raised TUSCANY-3266 against the "Run As" function. Any and all help in fixing these is much appreciated. If we can knock a few of these off quickly I'd like to try and make our RC1 tomorrow if possible. Simon [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Release+-+Java+SCA+1.5.1
Re: Supporting latest schemas in the cpp runtime, was: Fixing SCA cpp build
Hey Sebastien > > I'm starting to look into supporting the latest SCDL schemas in the CPP > runtime. For now I've just copied the schemas from the Java assembly-xsd > module, and after trying a few changes to the ModelLoader, I'm starting to > think that it could be simplified a bit by using the libxml2 pull API to > read the composite files. Are you looking at the 1.x XSD or the 2.x XSD? I wonder if we should go straight to the OASIS schema in 2.x. Bigger change but where we want to be I guess. I also wonder if we could use the Java builders to drive the C++ runtime (A C++ node if you like) so that we don't have to repeat all the domain and builder support in C++. > > I've also started to put together a store sample modeled after the Java > store sample, to help experiment with the new SCDL. Cool. Simon
Will there be an OpenEJB 3.0.2 release?
Hi We came across a windows separator problem a while back (https://issues.apache.org/jira/browse/OPENEJB-1005) which was fixed at OpenEJB 3.0.2-SNAPSHOT. Our Tuscany 1.x code base currently depends on this snapshot. Looking at the JIRA the fix also went into 3.1.1 but we're not ready to move up to 3.1.1 just yet. Will there be a 3.0.2 release? Regards Simon
Re: Travel sample naming conventions
Thanks for the update Simon. I'll check the travel sample out over the next few days and give it a spin. Once the name changes have settled down we should start a thread about getting this into the 1.x codebase so that it's in a more obvious place. Simon
Re: Will there be an OpenEJB 3.0.2 release?
I'm of a mind to drop the failing tests out of our upcoming Tuscany 1.5.1 release as we don't actually ship anything that uses the JEE functionality just yet. However Vamsi is building a Geronimo/Tuscany plugin based on the JEE model and he can work round the specific failures we see on Windows. So to answer David's question, on this basis, there is no particular emergency. On Luciano's point. Luciano, Is this definitely an OpenEJB problem and, if so, is there an OpenEJB JIRA targeting 3.0.2? Simon
Re: Tuscany SCA HelloWorld application is up and running on Google App Engine!
Nice one Raymond! Simon
Anyone having problems with peo...@?
Am trying to copy the 1.5.1 RC1 artifacts up to my p.a.o account. I got some of them up there earlier on today but it stopped working and hasn't come back. I can't even get to public html pages with my browser. Is it just me? Simon
Re: Anyone having problems with peo...@?
Thanks for trying that for me Daniel. I've moved to a new network this morning and I can now get to p.o.a. I still can't access it either via ssh or http from my home broadband connection which is a bit odd. Same laptop in both cases. So a bit of digging required. Simon
Re: [2.x] Endpoint Interface and ExtensionPointRegistry
It seems that the registry is used by the RuntimeEndpointImpl in order to retrieve the serializer used to serialize endpoints. I expect the main use of this feature is currently the tribes version of the endpoint registry which is serializing endpoints in order to distribute the contents of the endpoint registry. I don't recall that we need to serialize endpoints anywhere else just at the moment. None of this suggests that there needs to be a "set" method on the interface though. However the comment against he method suggests that it is required when the endpoint is deserialized. In this case the registry of the node that is deserializing the endpoint will need to be set into the endpoint just in case the endpoint is serialized again. Do you have particular concerns about this set method? Regards Simon
[VOTE] Release Tuscany SCA Java 1.5.1 RC1
Please review and vote on RC1 of the Tuscany SCA Java 1.5.1 release. The distribution artifacts, RAT reports, and Maven staging repository are available for review at: http://people.apache.org/~slaws/tuscany/1.5.1-RC1 The release tag is at: http://svn.apache.org/repos/asf/tuscany/tags/java/sca/1.5.1-RC1 here's my +1 Simon
[2.x] assembly-xml unit testing dependencies
This is another dependency issue I'm afraid. While instigating the new model builders I notice that several of the assembly-xml unit tests now fail. This is because these tests use the builders but with invalid composites. The composites have many implementations and bindings that are/can not be referenced by assembly-xml. This leads to null implementations and empty binding collections that the builders are not expecting. I added some null checks to allow the tests to run and even then I have to comment out the policy promotion one (my null tests are not in precisely the same place as in the old builders). However this doesn't feel like the right approach to me. I'd rather have tests in assembly-xml that are designed to run there properly without needing special checks in the builders. Thoughts? Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC1
Hi Ram
Haven't tried with that version. Having looked at the code though
there does seem to be a rather suspicious "if" statement. The stop()
method of the DojoModuleActivator is as follows.
public void stop(ExtensionPointRegistry registry) {
Servlet servlet = servletHost.getServletMapping(dojoBaseUri);
if(servlet == null) {
servletHost.removeServletMapping(dojoBaseUri);
servletHost.removeServletMapping(dojoUri);
servletHost.removeServletMapping(tuscanyBaseUri);
servletHost.removeServletMapping(tuscanyUri);
}
servletHost = null;
}
Just by visual inspection it would seem that is should read
if(servlet != null). Is it possible for you to make this change
locally and give it a spin. If not I'll see if I can get a copy of the
JDK and try it here.
Regards
Simon
Re: [2.x] builder woes
An update on where I've got to with this
I've created a new class, called ModelBuilderImpl, in assembly to run
a new build process. You can turn this on by switching round the
comments in the file
modules\assembly\src\main\resources\META-INF\services\org.apache.tuscany.sca.assembly.builder.CompositeBuilder
This new builder does the following
try {
// Collect and fuse includes. Copy all of the components
// out of the included composite into the including composite
// and discards the included composite
compositeIncludeBuilder.build(composite, definitions, monitor);
// need to apply policy external attachment
// Expand nested composites. Clone any composite model that
// is acting as a component implementation and connects the cloned
// model to the component implementation in question
compositeCloneBuilder.build(composite, definitions, monitor);
// Process the implementation hierarchy by calculating the
component type
// for the top level implementation (composite). This has
the effect of
// recursively calculating component types and configuring the
// components that depend on them
compositeComponentTypeBuilder.createComponentType(composite);
// create the runtime model by updating the static model
we have just
// created. This involves things like creating
// component URIs
// binding URIs
// binding specific build processing
// callback references - currently done in static pass
// callback services - currently done in static pass
// Endpoints
// Endoint References
// Policies
// TODO - called here at the moment but we could have a
separate build phase
//to call these. Also we need to re-org these builders
bindingURIBuilder.configureBindingURIsAndNames(composite,
definitions, monitor);
componentServiceBindingBuilder.build(composite,
definitions, monitor); // binding specific build
componentReferenceBindingBuilder.build(composite,
definitions, monitor); // binding specific build
endpointBuilder.build(composite, definitions, monitor);
endpointReferenceBuilder.build(composite, definitions, monitor);
componentReferencePromotionBuilder.build(composite,
definitions, monitor); // move into the static build?
compositePolicyBuilder.build(composite, definitions,
monitor); // the rest of the policy processing?
} catch (Exception e) {
throw new CompositeBuilderException("Exception while
building model " + composite.getName(), e);
}
The important line here is compositeComponentTypeBuilder(...) which
calculates the component type for the composite it is given. It does
this by asking all child components to configure themselves based on
thier components type. Hence they aske for their component types to be
created, and so it goes. The component configuration code is in the
ComponentBuilder so there are two piece of code of interest.
CompositeComponentTypeBuilderImpl - create the component type of a composite
ComponentBuilderImpl - build a component based on its component type
Now each of these files is self contained. They have no base classes
and use no utilities. This is on purpose so please avoid the
temptation to "optimize" them if you can. At least for the time being.
If find it very comfortable to have all of the code for performing
these functions in the file that performs the function. This feels
like an improvement over the various different builders we had for
this and their associated base classes and utilites.
Now the next thing to sort out is the runtime building that follows
the creating of the component type. You will see that I've added back
in the steps that currently live in this section so that the Tuscany
build works. I also created new Enpoint and EndpointReference builders
so that I could see the wood for the trees in that area. However I'd
like to reorganize all of these builders. Thoughts to follow but any
comments are most welcome.
I haven't actually turned the new builder on just yet although I do
get a clean build. Just want to run the assembly otests before
flipping the switch and haven't go to that yet.
Regards
Simon
Re: [2.x] builder woes
I get the same results for the otests regardless of which version of the builders I use so as of r818033 I've switched over to the new ones. Very easy to revert if there are problems. Regards Simon
[2.x] otest structure - again
I've brought in the new otest structure from OASIS [1]. You can see how we currently handle it in svn here [2]. The structure is now... newlayout/ sca-assembly - the contents of [1] retrieved using svn:export tuscany-test-runner - the tuscany specific runner/properties overlayed with test files from sca-assembly using an ant based copy I'd like to get rid of the ant based copy of files out to the tuscany-test-runner but this is going to take a bit of research and negotiation with the OASIS team. In the mean time this gets us up and going and it's much simpler than it was before when we have to have all our own contribution directories also. I've left the "current" directory in place and unchanged for now but beware that this pulls old versions of the tests from OASIS so please us the "newlayout" version. I'll give it a few days and then remove "current" from Tuscany. There is an issue with the OASIS test directory as of today where the Test_Client build fails because it can't find a META-INF/MANIFEST.MF file. To get round this I just copied the file from the src/main/resource directory of the same project. I'll address this issue to OASIS> Running the tests gives 58 failures now which is about twice as many as we had a couple of weeks ago so we appear to have broken a few things. I'll look to see if something changes in the new test structure of if there is a problem in Tuscany itself. Regards Simon [1] http://tools.oasis-open.org/version-control/svn/sca-assembly/TestCases/ [2] http://svn.apache.org/repos/asf/tuscany/java/sca/otest/newlayout/
Re: [DISCUSS] Simplifying our current SVN Structure
I like the idea about being a bit more organized (goes for docs too but that is another thread). I have questions about the proposal > > - Create the following SVN sub-projects > --- SCA 1.x > --- SCA 2.x > --- DAS > --- SDO > --- CPP This seems a bit unbalanced. On one hand you have the projects split by programming model (SCA, SDO etc.). On the other you have them grouped by implementation technology (CPP). Is your proposal that SCA 1.x, SCA 2.x, DAS, SDO are Java projects? > > - Each sub-project will have the following basic SVN structure > -- Project > trunk > branches > tags > contrib What is the intention of contrib here? We discussed a while back the idea of having a contrib directory where people could check in and work on anything that is not yet ready for release so that we don't have to ask the "what should be in the release" question each time we do a release. Is this it? If so it should probably be inside trunk. > > - Contents from the current SVN structure (e.g tags, branches, contrib > folders, etc) will then be merged into the proposed SVN structure for > each sub-project > > - The following folders will not change > --- Maven > --- Site > --- Sanbox > > - The following folders does not seem to be in use currently > --- collaboration README says that this is a collaboration area for all ASF committers. > --- interop This was for interop testing between CPP and Java SDO.I imagine it's out of date but could be added to the CPP SDO project if you want to tidy it out of the way. > > - TBD > --- Maven plugins (continue as a sub-project ???) We'll it's Java but the plugins here are only relevant to the 2.x codebase > --- SDO CTS (part of SDO sub-project ???) It depends on what the top level split is intended to be. I'd be happy for this to remain as a separate Java project. Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC1
> This seems like a required fix, but while trying to generate a local > distro to test this, I keep getting the following exception... has > anyone seen this ? > > [java] Caused by: java.lang.ClassNotFoundException: > org.apache.tuscany.sca.web.javascript.dojo.DojoModuleActivator > [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:200) > [java] at java.security.AccessController.doPrivileged(Native Method) > [java] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:319) > [java] at > sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330) > > > -- > Luciano Resende > http://people.apache.org/~lresende > http://lresende.blogspot.com/ > Was this when you were trying to build from the top level? Which module failed? Needless to say I didn't see this when I built RC1. Do you only see it with the local changes you've made? Simon
Re: [2.x] builder woes
Thoughts on the runtime part of the build which involves... bindingURIBuilder I think this can stay as is as it's fairly isolated componentServiceBindingBuilder componentReferenceBindingBuilder binding specific builders. I think they have to come after the service binding URIs have been calculated. Not clear to me that service and reference need to remain separate. In the previous builders the componentReferenceBindingBuilder was called at the end after endpoint references were created. In OASIS though the reference either has a binding, in which case it has been manually configured, or it adopts the binding from the service, which will have already been configured by the service. I am tempted to combine these two and the bindingURIBuilder into a single bindingBuilder. endpointBuilder fairly isolated again endpointReferenceBuilder this is interesting as there is another endpointReferenceBuilder in the endpoint module. There are two things going on. 1/ creation of endpoint references based on the local composite configuration 2/ resolution/matching of cross composite endpoint references in the distributed case. The first builder does step 1 and the second builder does step 2. I would like to at least combine the code into one file and just call the separate phases from different places. I'd also like to do the runtime matching for those endpoints resolved in step 1 so that all local composite errors are reported are load time There is some rationalization we could do here by relying on the endpoint registry as the registry of available endpoints when endpoint references are actually created. The problem I have with this though is that endpoints are not added to the registry until the composite is activated and to populate it earlier would detract from this. So I'll leave this alone for now. componentReferencePromotionBuilder This currently deals in endpoint references and hence has to go here. However it's really a static model building phase so I'd like to rephrase this logic in terms of reference targets and bindings and move it into the componentype/componentConfig build process. compositePolicyBuilder This also currently deals in endpoints and endpoint references but is really static model configuration. So need to discuss if this could be moved back up to the static phase. I don't have a problem if it needs to stay here for whatever reason. I think all of these runtime builders could live outside of assembly and be called in a separate group by the node to allow for this move. This overlaps with Raymond's discussion about where the builders should be more generally. Simon
Re: [DISCUSS] Simplifying our current SVN Structure
On Wed, Sep 23, 2009 at 4:40 PM, Luciano Resende wrote: > On Wed, Sep 23, 2009 at 4:48 AM, Simon Laws wrote: >> I like the idea about being a bit more organized (goes for docs too >> but that is another thread). I have questions about the proposal >>> >>> - Create the following SVN sub-projects >>> --- SCA 1.x >>> --- SCA 2.x >>> --- DAS >>> --- SDO >>> --- CPP >> >> This seems a bit unbalanced. On one hand you have the projects split >> by programming model (SCA, SDO etc.). On the other you have them >> grouped by implementation technology (CPP). Is your proposal that SCA >> 1.x, SCA 2.x, DAS, SDO are Java projects? >> > > I didn't propose splitting the CPP because my understanding is that > they are very tight together at the moment, if this is not the case, > we could look into a different structure. IIRC CPP SCA depends on CPP SDO (but not the other way round). My unbalanced comment was that you didn't propose svn/ Java SCA 1.x SCA 2.x DAS SDO CPP SCA SDO DAS But put the Java projects at the top level. Was there a particular reason for that? > >>> >>> - Each sub-project will have the following basic SVN structure >>> -- Project >>> trunk >>> branches >>> tags >>> contrib >> >> What is the intention of contrib here? We discussed a while back the >> idea of having a contrib directory where people could check in and >> work on anything that is not yet ready for release so that we don't >> have to ask the "what should be in the release" question each time we >> do a release. Is this it? If so it should probably be inside trunk. >> > > We currently have verious projects in contrib, and they are not > grouped together (e.g 1.x branch is in branches and the contrib is in > main 2.x trunk).. so the idea was to have a contrib together with each > sub-project as needed, and mostly to accommodate the two sca contrib > contents. > > https://svn.apache.org/repos/asf/tuscany/java/sca-1.x-contrib/ > https://svn.apache.org/repos/asf/tuscany/java/sca-contrib/ OK, I see. If I remember rightly the sca-contrib stuff all came from the equinox branch or the trunk before the equinox branch was merged. This may not be that useful now as both 1.x and 2.x have moved on since then. > >>> >>> - Contents from the current SVN structure (e.g tags, branches, contrib >>> folders, etc) will then be merged into the proposed SVN structure for >>> each sub-project >>> >>> - The following folders will not change >>> --- Maven >>> --- Site >>> --- Sanbox >>> >>> - The following folders does not seem to be in use currently >>> --- collaboration >> README says that this is a collaboration area for all ASF committers. >> > > Yes, but since it's creation, nothing has been done here... do we > still need it ? I don't have any plans but it's not doing any harm. > >>> --- interop >> This was for interop testing between CPP and Java SDO.I imagine it's >> out of date but could be added to the CPP SDO project if you want to >> tidy it out of the way. >> > +1, works for me... > >>> >>> - TBD >>> --- Maven plugins (continue as a sub-project ???) >> >> We'll it's Java but the plugins here are only relevant to the 2.x codebase > > That's my thought as well, but I believe Ant had some concerns with > moving this back to 2.x... and I want be flexible and try to > accommodate everybody's need :) OK, I understand. Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC1
OK, It seems that this could be a useful fix to include. However I'd like some more people to review RC1 before I take the decision to re-spin. Simon
[1.x & 2.x] Generated WSDL not WS-I compliant in some cases?
I'm looking at WSDL generated by Tuscany. For a simple interface such as..
package service;
import org.osoa.sca.annotations.Service;
@Service(SomeService.class)
public class SomeServiceImpl implements SomeService {
public AnObject getUsingString(String stringParam) {
System.out.println("Param value:" + stringParam);
return getAnObject(stringParam);
}
private AnObject getAnObject(String stringParam) {
return new AnObject(stringParam + "123", 123);
}
public AnObject getUsingMoreComplexObject(MoreComplexObject
moreComplexParam) {
System.out.println("Param value:" + moreComplexParam.getStringParam());
return getAnObject(moreComplexParam.getStringParam());
}
}
Tuscany generates the WSDL types...
http://service/"; xmlns:tns="http://service/";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:SOAP11="http://schemas.xmlsoap.org/wsdl/soap/";>
http://www.w3.org/2001/XMLSchema";>
http://service/";
xmlns:xs="http://www.w3.org/2001/XMLSchema";>
However the wsgen JAXWS tooling generates the following schema for the WSDL...
http://service/";
xmlns:tns="http://service/";
xmlns:xs="http://www.w3.org/2001/XMLSchema";>
Note that difference is that the schema types anObject and
moreComplexObject are generated into a namespace for wsgen and not
for Tuscany.
Now looking back at various related specs...
WS-I [1] says...
R2105 All xsd:schema elements contained in a wsdl:types element of a
DESCRIPTION MUST have a targetNamespace attribute with a valid and
non-null value, UNLESS the xsd:schema element has xsd:import and/or
xsd:annotation as its only child element(s)
And JAX-WS 2.1 I believe is intended to be WS-I compliant.
The wrinkle then seems to be that the JAXB spec defines a default Java
to XSD mapping where types are not placed in a namespace unless you
configure the Java class with annotations. The spec does talk of
"customizations" and I guess this is what the wsgen tool is doing but
I can't find any explicit statement about what these customizations
might be other than those provided by code annotations. This page [3]
suggests that it's sneaking behind the public JAXB API to make this
happen.
I found that the subject of the JAXB mapping had been discussed
before, e.g. [2], and I do remember testing that the no namespace
schema inclusion was actually valid. However I can't put my finger on
anything to do with customizing the mapping that has been discussed
here and why we aren't doing it.
Anyone know how to get JAXB to generate schema that are WS-I compliant
in this case?
I note that Axis have witten their own generator but I remember a long
time ago we used the Axis code and the stopped using it in favour of
the JAXB code for some reason. Anyone remember why (am searching the
ML also of course).
Regards
Simon
[1] http://www.ws-i.org/Profiles/BasicProfile-1_2%28WGAD%29.html#WSDLTYPES
[2] https://issues.apache.org/jira/browse/TUSCANY-2531
[3] https://jaxb.dev.java.net/guide/Invoking_schemagen_programatically.html
Re: [1.x] binding.jms correlation ID for callback messages?
OK, fair enough Scott. Simon
Re: [2.x] builder woes
Hi Raymond. Replies in line... > There is one more static builder: PolicyAttachmentBuilder. This builder will > apply the @attachTo xpath of the policySets to the domain composite as well > as the composites used by implementation.composite. It should be called > right after the include/clone is finished on the domain composite. > >> Thoughts on the runtime part of the build which involves... >> >> bindingURIBuilder >> I think this can stay as is as it's fairly isolated > > Is BindingURIBuilder calculating the structural URIs? This could be merged > into the builder that set the component URI. We can name the builder > something like StructuralURIBuilder. If the @uri of a binding is not set, > the binding extension may choose to derive the protocol URI from the > structural URI. Where should this kind of behavior be plugged in? In the > component service/reference binding builder? Ok so I think this breaks down into two pieces then... 1/ Calculation of the structure URI for each reference or service in the static model 2/ Extend the binding specific builders to take the static uri and combine it with the binding specific endpoint configuration. The binding specific build phase comes next. If > >> >> componentServiceBindingBuilder >> componentReferenceBindingBuilder >> binding specific builders. I think they have to come after the >> service binding URIs have been calculated. Not clear to me that >> service and reference need to remain separate. In the previous >> builders the componentReferenceBindingBuilder was called at the end >> after endpoint references were created. In OASIS though the reference >> either has a binding, in which case it has been manually configured, >> or it adopts the binding from the service, which will have already >> been configured by the service. >> I am tempted to combine these two and the bindingURIBuilder into a >> single bindingBuilder. > > At this moment, the component service/reference binding builders just call > the BindingBuidler extensions. +1 to merge them. I'm also wondering if these > builders should work against the Endpoint/EndpointReference instead of > (Component/Contract/Binding tuples). If so, should we align them against the > EndpointReference/EndpointBuilder? It's related to the decision on whether > we treat Endpoint/EndpointReference as runtime model or static model. In my mind EndpointReferences are runtime artifacts. Endpoints feel more static as their configuration can be established and is stable while a composite is assigned to a node. Overall though I'd says this notion of static and runtime builders is just a convenience for giving some structure to the build process. It probably doesn't make that much material difference. It may make a difference in future dynamic scenarios where we want to be able to build and rebuild EndpointReferences independently of the static model. However we need to put all of our domain scenarios back on the table and review them before we put too much store in that. > >> >> endpointBuilder >> fairly isolated again >> >> endpointReferenceBuilder >> this is interesting as there is another endpointReferenceBuilder in >> the endpoint module. There are two things going on. >> 1/ creation of endpoint references based on the local composite >> configuration >> 2/ resolution/matching of cross composite endpoint references in >> the distributed case. >> >> The first builder does step 1 and the second builder does step 2. I >> would like to at least combine the code into one file and just call >> the separate phases from different places. >> I'd also like to do the runtime matching for those endpoints >> resolved in step 1 so that all local composite errors are reported are >> load time >> There is some rationalization we could do here by relying on the >> endpoint registry as the registry of available endpoints when endpoint >> references are actually created. The problem I have with this though >> is that endpoints are not added to the registry until the composite is >> activated and to populate it earlier would detract from this. So I'll >> leave this alone for now. > > Should we limit the builder responsibility to configuration only? The > resolution seems to be in a different phase than build. > In use cases like the SCA Domain Manager that provisions the composite > applications, no EndpointRegistry is available. A domain manager could be made a available as the model is build but I agree that it is probably useful to consider these as separate phases. If only because then we have the endpoint registry populated with deployed and active endpoints against which endpoint references can be resolved. > >> >> componentReferencePromotionBuilder >> This currently deals in endpoint references and hence has to go >> here. However it's really a static model building phase so I'd like to >> rephrase this logic in terms of reference targets and bindings and >> move it into the componentype/componentConfig build pr
Re: [1.x & 2.x] Generated WSDL not WS-I compliant in some cases?
Hi Scott I agree th's rule we want to follow. Without annotation wsgen places the types in the namespace generated from the service class' packages. I note that the other way to alter this mapping is with package-info.java. Another approach is to force any generated schema types with no namespace into the namespace of the WSDL after the xsd has been generated. The JAXB schema generation will already have taken account of any package-info information. I've opened TUSCANY-3283 to track this one. Simon
Re: [1.x & 2.x] Generated WSDL not WS-I compliant in some cases?
OK, I think I understand what's going on. With an empty name specified it's expecting to generate the type in line but we don't have the wrapper classes in the list of classes when we generate the schema so it's generating nothing. So maybe we can modify our code to add the wrapper classes in as well. Simon
Re: [1.x & 2.x] Generated WSDL not WS-I compliant in some cases?
Rather disappointingly. When I add a new type to my sample (that I'm
using to play with wsdl generation) as follows;
@XmlType(name="")
public class CBean {
protected String field1;
protected String field2;
public String getField1() {
return field1;
}
public void setField1(String field1) {
this.field1 = field1;
}
public String getField2() {
return field2;
}
public void setField2(String field2) {
this.field2 = field2;
}
}
Then JAXBContext.generateSchema() doesn't generate schema for it.
wsgen for the same interface does however generate schema for CBean
:-(. This JAXB library is just not playing ball.
Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC1
OK, thanks for the review Raymond. Luciano, did you get to a state where you were able to get past the error you saw and were able to look through it? Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC1
Thanks Luciano, I'll get set up ready to roll RC2 and we can get Ram's fix in and hopefully this tutorial fix also. Simon
Re: [2.x] Determining SCA wire validity with policies (TUSCANY-3242)
On Fri, Sep 25, 2009 at 7:10 PM, Raymond Feng wrote: > When I investigate TUSCANY-3242, I realized that the matching algorithm [2] > is NOT correct. The check against the size of the intents and policySets is > bogus. It's a fir point about the size of the collections. > > For an SCA wire, the endpoint reference and endpoint can be configured with > interaction policies. Some of the intents are realized by policySets while > the rest are natively supported by the bindings. Depending on the policy > language, there can be different cases to apply a policy. > > a. The policy can only be applied to references > b. The policy can only be applied to services > c. The policy can be applied to both references and services > c.1: The policies on both sides are coupled and have to be compatible > c.2: The policies on both sides can be enforced independently > > Two players should be involved to check the compatibility of the policy > configuration on the wired endpoint reference and enpoint: > * Binding (to handle the natively supported intents) > * Policy Language Provider (to check the compatibility of the policies in > case c.2) > > IMO, we should come up an ExtensionPoint that collects the Policy/Intent > mappers which can be contributed from binding and policy language > extensions. Thoughts? I put a comment in the code to this effect but didn't get to doing anything about it. It seems, for this post, that we need a binding extension to work out which intents and policy sets are actually in force and then a policy language extension to work out if the policy sets that are in force are compatible between reference and service. > > I'll comment out the code in [2] so that I can use itest/policies to > validate the policy builders I'm working. > ok Simon
Re: [1.x & 2.x] Generated WSDL not WS-I compliant in some cases?
Quick update I spent some time looking at whether we could modify the data type on the fly at the point at where the Tuscany data types are generated. However it turns out that the WSDL generation needs to be driven from the wrapper types and these seem to be generated directly of each Java method rather than based on the pre-parsed input and output type structures. So we can go in an re-write the type in question but it has no effect as the generated wrappers will still be referencing the unaltered Java type. Next thing I'm going to look at is to see if it's possible to change the schema later in the process, i.e. after JAXB has generated the schema. This looks messy though as we store a schema as a schema collection, as schema and a DOM all at the same time. I'm not sure how important these different representations are but I expect we have to merge them all. Anyone have any better ideas? Regards Simon
Re: [1.x & 2.x] Generated WSDL not WS-I compliant in some cases?
Hi Scott > > Are you saying that you tried modifying the parameter types .class > files (using ASM or something like that), and this still had "no > effect"? If you mean the .class files as they exist on disc then, no, I didn't try doing that. Or are you saying that modifying the DataType info built > from introspecting the Java had no impact? I was trying to modify the in memory version of the classes that JAXB uses to generate the WSDL. Even if this did work there is a potential problem that the classes in the JAXB context don't match the classes that the service interface is expecting which is probably a bad thing. Anyhow I was just trying to get my mind round this by trying a few things. None of those things have worked yet though :-(. I also had a go at modifying the classes as the wrapper code reads them in order to generate wrappers. That doesn't appear to have any effect either. I've maybe got my asm code wrong or in the wrong place. The databinding and WSDL gen code is sufficiently opaque that it's difficult to tell. Anyhow the next thing to try is the post processing schema merge I guess. But that looks pretty nasty. Simon
Re: [1.x & 2.x] Generated WSDL not WS-I compliant in some cases?
Well same here. I think we have to get pretty close to where the DOMs are generated by JAXB and before the DOMs start getting parsed by Tuscany. Simon
Re: [1.x & 2.x] Generated WSDL not WS-I compliant in some cases?
On Mon, Sep 28, 2009 at 4:14 PM, Simon Nash wrote: > Simon Laws wrote: >> >> Well same here. I think we have to get pretty close to where the DOMs >> are generated by JAXB and before the DOMs start getting parsed by >> Tuscany. >> >> Simon >> > Please take a look at my fix for TUSCANY-3267 (r813785). For this fix > I inserted code into Interface2WSDLGenerator to modify the schema at > the point where JAXB has generated the DOM but before it is loaded by > Tuscany. I think this would be the correct point to do other similar > post-processing modifications. > > Simon > > Yep, thanks for the heads up Simon. Am in there now. Simon
Re: [1.x & 2.x] Generated WSDL not WS-I compliant in some cases?
Ok, a bit more success now following the various exchanges. I made two changes to Interface2WSDLGenerator. 1/ I flipped a flag to run the JAXB schema generated against the wrappers instead of just against the wrapped types 2/ I wrote some code to merge the resulting DOMs if there is a no namespace. I'm extending the itest/wsdlgen scenario with a helloworld service that references types as follows src/main/java helloworld/ ABean.java - a plain POJO HelloworldService.java - WSDL will be in namspace ""http://helloworld/"; pacakge-info.java - force ABean into namespace "http://test"; anotherpackage BBean.java - a plain POJO CBean.java - has @XmlType(name="") This now gives rise to http://helloworld/"; xmlns:tns="http://helloworld/"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:SOAP11="http://schemas.xmlsoap.org/wsdl/soap/";> http://helloworld/"; version="1.0" xmlns:ns1="http://test"; xmlns:tns="http://helloworld/"; xmlns:xs="http://www.w3.org/2001/XMLSchema";> http://test"; /> http://helloworld/"; /> http://test"; version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema";> Still more work to do to update any reference from the merged schema that occur from anything but the default schema but at least i can see the light. Regards Simon
Re: [2.x] builder woes
Ok, Raymond. I'll update and take a look. Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC1
Thanks Luciano, I'll roll RC2 Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC1
Ok, Ram. If it's just the text of an error message, go ahead. Please let me know when you're done. Regards Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC1
ok, thanks Ram. Simon
[VOTE] Release Tuscany SCA Java 1.5.1 RC2
Please review and vote on RC2 of the Tuscany SCA Java 1.5.1 release. The distribution artifacts, RAT reports, and Maven staging repository are available for review at: http://people.apache.org/~slaws/tuscany/1.5.1-RC2 The release tag is at: http://svn.apache.org/repos/asf/tuscany/tags/java/sca/1.5.1-RC2 here's my +1 Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC2
Thanks Ram/Luciano I'll make RC3 directly to fix these problems. Regards Simon
Re: Binding name in the promotion case
Hi Raymond Prior to your changes the logic is pretty dumb. After the component type build the binding URI builder takes a second pass through the hierarchy and sets non-null binding names to the reference or service name as appropriate. In your case it you've copied a binding that is already named it will retain its old name. Now the spec says that, when binding names are not specified, the name is taken from the reference or service name. It's not explicit about what happens in the inheritance case but I would expect it to be "Service2" in your scenario. Firstly do you need the copied binding to be in place in order to do policy processing and does it need to be named If so we may need to enact the binding naming algorithm inside the composite component type and component configuration builders. Regards Simon
Re: [2.x] Replicating definitions for the federated EndpointRegistry within an SCA domain
Hi Raymond Just noticed this post from last week... Interesting thought. At the moment all the definitions in the domain are collected together into a system contribution which (in the 1.x way of thinking) would be passed to each node along with the contributions it needs to run with. Effectively each node has a copy of the whole domain's policy configuration. I think what you are suggesting is extending the endpoint registry more toward a domain registry so that you can ask about available policies and intents as well as configured endpoints. I.e. instead of each node asking for its complete configuration when it starts, it's able to look up information in the domain registry as and when required. I quite like this idea as it feels more likely to be able to support future dynamic scenarios than the one-shot approach we have in 1.x. However the flipside is increased network traffic and there will be a greater number of infrastrure service interfaces. I'd like to understand how various scenarios would work with a scheme like this. Not sure that that wider conversation belongs on this thread though it's really a summary of what was discussed on [1]. I'll post something as a followup to that. Regards Simon [1] http://www.mail-archive.com/dev@tuscany.apache.org/msg09220.html
[2.x] reviewing/summarizing domain operation - was: Re: Discovery-based SCA Domain for OSGi RFC 119
Apologies that this is a bit of a long post I''d like to review some of the (orthoganol) choices a user has to make based on what has been said on the referenced thread [1] and on what has be said elsewhere. Contributions === a1/ A single contribution a2/ Multiple dependent contributions where each contribution can be directories, jar, zip, bundle, war, ear... Composites (when one or more are present in a contribution) === b1/ one or more composite files but which are not listed in META-INF/sca-contribution.xml b2/ one or more composite files but which are listed in META-INF/sca-contribution.xml b3/ one or more composite files but which are present in META-INF/sca-deployables (is this still supported?) Nodes (where node = the wrapper for an instance of Tuscany runtime) === c1/ node(s) with contributions passed in on command line, programmatically, in node.xml or discovered from classpath c2/ node(s) with contributions pulled from domain manager (configuration is a URL) c3/ node(s) in a webapp c4/ node(s) as eclipse project(s) c5/ node(s) integrated into Tomcat and Geronimo plugin c6/ node(s) as OSGi service listeners? (is that the right term?) c7/ node(s) in cloud (what does this mean) One or more nodes may run in a single VM Scenarios (and implications for what the runtime has to do) === 1/ 1 node configured from command line, programmatically, in node.xml (c1) 1 or more contributions are described in a node configuration node is started with node configuration services are immediately accessible 2/ >1 node configured from command line, programmatically, in node.xml (c1) each node has separate node configuration detailing domain name and contributions each node is started with node configuration nodes exploit distributed registry to locate remote service endpoints in same domain during wire resolution 3/ 1 node packaged with webapp (c3) webapp is configured with a filter to run webapp contents as SCA application webapp deployed to unchanged container 4/ tomcat instance as a domain (c5) Webapp (jars/zips) equate to contributions tomcat extenstion runs contributions in nodes in single JVM nodes form domain using local version of registry in single JVM 5/ eclipse workspace as domain (c4) click on composite and start node nodes communicate using local registry (simplification of domain manager approach that is in 1.x) etc. As a review exercise can we correct/complete this list by getting all of the scenarios people have in their heads out on the table. I believe we have all imagined different scenarios. APIs (Resulting from above) === This is a TODO for this review. This is a mildly enhanced version of what we already have or have discussed at various times. Node Create with configuration Create with URL of configuration start stop Endpoint Registry (should this be domain registry now) Add/remove/query endpoints Add/remove/query domain policy (new) Domain Manager Add/Remove contribution Add/remove node Deploy/undeploy composite and associate with node Start/Stop node (do we need to maintain this in the domain manager?) Query (some work has been done on this but I've not tried it) (the domain manage is really made up of a number of service interfaces including these here and the endpoint registry) etc. If we can give some more shape to this I propose we record what we come up as an article on the 2.x documentation pages. In the short term we can combine with the information on the wiki at [2] Regards Simon [1] http://www.mail-archive.com/dev@tuscany.apache.org/msg09220.html [2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Domain
[VOTE] Release Tuscany SCA Java 1.5.1 RC3
Please review and vote on RC3 of the Tuscany SCA Java 1.5.1 release. The distribution artifacts, RAT reports, and Maven staging repository are available for review at: http://people.apache.org/~slaws/tuscany/1.5.1-RC3 The release tag is at: http://svn.apache.org/repos/asf/tuscany/tags/java/sca/1.5.1-RC3 here's my +1 Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC3
ok, thanks Ant ...snip > > One other thing missing that can be added without interrupting this > vote is that the site.xml in the eclipse update site needs an > associated .asc signature file. Infra have a script that scans the > distribution area for missing signatures so they'll send us reminder > emails to get that done. > Well remembered. I'll go ahead and add the missing signature. I'll add it to the "making a release" page also. Simon
Re: [2.x] otest structure - again
On my most recent 2.x svn up I notice that the OASIS team have now integrated the change to allow us to test for explicit error messages for the failure cases. This of course has the effect of making the majority of the negative tests fail. Just posting here as a heads up for now. I need some help to fix up the messages file with expected messages so that the tests pass but I'll post in a bit about the details (when I've worked them out). Regards Simon
[2.x] failure in itest/implementation.spring
I'm seeing... Caused by: java.io.FileNotFoundException: class path resource [context/multiple/META-INF/spring/SpringHelloWorld-context.xml] cannot be opened because it does not exist at org.springframework.core.io.ClassPathResource.getInputStream(ClassPathResource.java:142) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:336) ... 68 more in context.multiple.MultipleContextTestCase I know there have been changes here recently. Any ideas? Simon
Re: [2.x] otest structure - again
If you were to check that out the otest/newlayout directory you should get the new structure and all the latest code from OASIS. If you were to run it nearly all the negative tests will fail as we don't have the correct detailed tests recorded in the test message property file [1]. I'm just going to start the exercise of going through all the tests again to... 1/ review that the test is still passing correctly 2/ check that any JIRA that were raised previously [2] have now been closed correctly 3/ raise any new JIRA that are required due to new failures 4/ update the tuscany-oasis-sca-tests-errors.properties file [1] with the correct message for each negative test. Note that I've added a "pass 2" column to the table [2] to coordinate progress for this second pass. Any help is very much appreciated. Regards Simon [1] http://svn.apache.org/repos/asf/tuscany/java/sca/otest/newlayout/tuscany-test-runner/src/test/resources/tuscany-oasis-sca-tests-errors.properties [2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Conformance+Testing
Re: [2.x] failure in itest/implementation.spring
Thanks Ram Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC3
Hi Sebastien
Thanks for checking over the release candidate.
Quite a lot of these I wouldn't consider as blockers. But I'm
concerned about the samples that don't run. Needless to say they work
on my windows PC but my Linux dev environment is not working at the
moment. Can anyone with a unix style environment help take a look at
the failing samples. I need to reinstall my linux PC.
Simon
On Wed, Sep 30, 2009 at 9:34 PM, Jean-Sebastien Delfino
wrote:
> Luciano Resende wrote:
>>
>> +1
>>
>> On Wed, Sep 30, 2009 at 10:56 AM, Raymond Feng
>> wrote:
>>>
>>> +1 from me.
>>>
>>> Thanks,
>>> Raymond
>>>
>>> --
>>> From: "Simon Laws"
>>> Sent: Wednesday, September 30, 2009 5:35 AM
>>> To: "tuscany-dev"
>>> Subject: [VOTE] Release Tuscany SCA Java 1.5.1 RC3
>>>
>>>> Please review and vote on RC3 of the Tuscany SCA Java 1.5.1 release.
>>>>
>>>> The distribution artifacts, RAT reports, and Maven staging repository
>>>> are available for review at:
>>>>
>>>> http://people.apache.org/~slaws/tuscany/1.5.1-RC3
>>>>
>>>> The release tag is at:
>>>>
>>>> http://svn.apache.org/repos/asf/tuscany/tags/java/sca/1.5.1-RC3
>>>>
>>>> here's my +1
>>>>
>>>> Simon
>>
>
> I've reviewed apache-tuscany-sca-1.5.1.tar.gz and found a few issues in the
> samples:
>
> - Empty target/ directories in some samples.
>
> - samples/quote-xquery works but reports an XSD validation error:
>
> [java] SEVERE: XMLSchema validation error occured in: null ,line = 28,
> column = 5, Message = cvc-complex-type.2.4.a: Invalid content was found
> starting with element 'component'. One of
> '{WC[##other:"http://www.osoa.org/xmlns/sca/1.0"]}' is expected.
>
> - samples/simple-bigbank-spring fails for me with:
>
> [java] Caused by:
> org.apache.tuscany.sca.contribution.service.ContributionReadException: Error
> reading manifest inside the jar folder:
> [java] at
> org.apache.tuscany.sca.implementation.spring.introspect.SpringXMLComponentTypeLoader.getApplicationContextResource(SpringXMLComponentTypeLoader.java:772)
> [java] at
> org.apache.tuscany.sca.implementation.spring.introspect.SpringXMLComponentTypeLoader.loadFromXML(SpringXMLComponentTypeLoader.java:167)
> [java] at
> org.apache.tuscany.sca.implementation.spring.introspect.SpringXMLComponentTypeLoader.load(SpringXMLComponentTypeLoader.java:129)
> [java] at
> org.apache.tuscany.sca.implementation.spring.xml.SpringImplementationProcessor.resolve(SpringImplementationProcessor.java:213)
> [java] ... 18 more
> [java] Caused by: java.util.zip.ZipException: error in opening zip file
> [java] at java.util.zip.ZipFile.open(Native Method)
> [java] at java.util.zip.ZipFile.(ZipFile.java:131)
> [java] at java.util.jar.JarFile.(JarFile.java:150)
> [java] at java.util.jar.JarFile.(JarFile.java:87)
> [java] at
> org.apache.tuscany.sca.implementation.spring.introspect.SpringXMLComponentTypeLoader.getApplicationContextResource(SpringXMLComponentTypeLoader.java:749)
> [java] ... 21 more
> [java] Java Result: 1
>
> Also that simple-bigbank-spring README confused me a bit as it describes the
> bigger bigbank-spring sample.
>
> - binding-notification-producer fails with the following error:
>
> [java] java.lang.UnsupportedOperationException
> [java] at
> org.apache.tuscany.sca.implementation.notification.ImmutableMessage.setBody(ImmutableMessage.java:59)
> [java] at
> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:90)
> [java] at
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
> [java] at
> org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:55)
> [java] at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:346)
> [java] at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:193)
> [java] at $Proxy8.trafficNotification(Unknown Source)
> [java] at
> notification.producer.TrafficAdvisoryProducer.produceTrafficNotification(TrafficAdvisoryProducer.java:34)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [java] at
> sun.reflect.NativeMethodAc
Re: [2.x] otest structure - again
I just want to keep it around to a few more days. I'll remove the externals though to speed up the svn processing. Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC3
I managed to bring my linux PC back to life. V. old fedora install and Sun JDK 6. What I see is samples/calculator-implementation-policies - works so there seems to be some other platform thing going on. What are you running on Sebastien? binding-notification-producer - works once and then fails with the problem Sebastien reported samples/simple-bigbank-spring - fails as reported I'm not inclined to re-spin for the first two (just because they are not complete failures). I'm thinking about the spring one. Regards Simon
Re: [2.x] Refactor builders into a new tuscany-assembly-builder module
> Ok from all this can we look at some of the runtime modules, eg core, > core-spi, databinding, core-databinding, can we do any tidy up there? > > ...ant > With this kind of refactoring I'd rather we plan what we are going to do across the code base, agree it and then apply it. This incremental changing of the module structure keeps breaking me as I try to look at the tests and it's taking me (personally, maybe it's just me) a long time to recover from module moves. I also think we need to get all the requirements on the table as this is bound to overlap with our need to decide how to prevent the build getting out of hand and (our old favourite) of how to structure the features/downloads we actually ship. Nibbling away at it may back us into a corner. Can we start a new thread to get all of the refactoring/restructuring requirements out on the table. I'm happy to start the thread and give my 2c if people want me too. Regards Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC3
Thanks Luciano, I'll give it a spin Simon
Re: [2.x] Refactor builders into a new tuscany-assembly-builder module
As I'm distracted trying to get 1.5.1 I've lost track of what is being moved and why. I'd suggest doing whatever you need to do to get your workspace clean and we can take a step back before we do any more aesthetic refactoring to try and get as much of it done in one pass as we can. If we are all happy to commit a day or so to focus and discuss the subject I'm sure we can come to some conclusion. Regards Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC3
The change works on windows. I've looked into why it used to work on windows but not on linux The path coming into the piece of code that's changed is: file:/c:/ on windows file:/home on linux chopping the first 6 characters off this lead to c:/ on windows, which works home/ on linux, which doesn't Regards Simon
Re: [2.x] Calculating Endpoints to promoted services
Well we should either process it OR point out through a warning that it's being ignored. Silently ignoring it is what leads to confusion. What is the proposal to process? That we should assume that they configure the component references and services that they promote? >From the example given it would seem that this is a valid way to configure a component service. However explicit words were put into the spec to apparently discount this at the domain leve. I'd like to get a sounding from one of the spec team on the implications of definition of composite services and references at the domain level as currently defined in the OASIS specs. On a purely technical note (which is probably not that relevant yet) we host service and reference endpoints and endpoint references on components. Composite services and references form part of the component type of a component that uses the composite through implementation.composite and hence that's where the endpoint and endpoint references are dealt with. Simon
Re: [2.x] Calculating Endpoints to promoted services
On Fri, Oct 2, 2009 at 3:03 PM, ant elder wrote: > On Fri, Oct 2, 2009 at 2:56 PM, Simon Laws wrote: > >> However explicit words were put into >> the spec to apparently discount this at the domain leve. > > Are you referring to just the ones on line 3873 which Raymond pasted > in or are there other mentions somewhere else? > > ...ant > No, just the ones Raymond pointed out. However I do remember some discussion with the OSOA scheme for composite services/references at the domain level and some issues that it causes. I think along the lines of what I was talking about in terms of having to send configuration down the promotion hierarchy instead of up it in this one case. Am looking for mail on this list discussing it but no luck yet. Simon
Re: [2.x] "How To Guide" Converting Tuscany extensions from 1.x to 2.x
Hi Luciano Nice guide. I'd like to add an alternative 2.x Style which doesn't use the mysterious "getContributionLocation" call but just provides an absolute path. Shall I just go in and add a new one or add a commented out line (showing the alternative) to the existing one. Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC3
I've made an RC4 to include the changes I think we need. the fix for spring on linux the update to the date in the NOTICE files a small change to the simple-bigbank spring REAME to make it clearer that it's not so simple update the release date to October I haven't addressed samples/calculator-implementation-policies - this does work on my linux box so there is some smaller set of environments affected samples/binding-notification-producer - as this does at least work once quote-xquery - it sounds like this is the effect of not running the server/ I'm am going to propose we create a 1.5.2 branch to pick up from where this activity has left off. There are a few things to look at here and I've noticed a few other things that would be good to get out quickly without trying to get the full 1.x branch in shape, e.g. TUSCANY-3283. I'll create the branch shortly unless anyone is against this. I'll start the RC4 vote shortly. Simon
[VOTE] Release Tuscany SCA Java 1.5.1 RC4
Please review and vote on RC4 of the Tuscany SCA Java 1.5.1 release. The distribution artifacts, RAT reports, and Maven staging repository are available for review at: http://people.apache.org/~slaws/tuscany/1.5.1-RC4 The release tag is at: http://svn.apache.org/repos/asf/tuscany/tags/java/sca/1.5.1-RC4 here's my +1 Simon
Re: Making the 2.x build more modular
Ant Just wanted to bump this to the top and say that I did see you reference to this thread on the "builder structure" thread [1] and that I haven't forgotten. I want to get all my thoughts down in one go and it's taking me a little while. I think what might be a good approach is if we all try and get all our ideas in this area out on the table. They will all be different but we can at least then ask "why" and understand what implicit requirements we are carrying around in our heads.Then we can compare and contrast. Having a critique of a small part of each others mental model seems ineffective and is not, apparently, leading to happiness. Regards Simon [1] http://www.mail-archive.com/dev%40tuscany.apache.org/msg09660.html
Re: [2.x] "How To Guide" Converting Tuscany extensions from 1.x to 2.x
Thx, Luciano Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC4
Thanks for the diff Ant. Simon
Re: Slow RMI Host start up
Is there any security configured? I.e. is it doing some kind of security handshakes? You quote a plain SocketFactory so I wouldn't expect it to be firing up SSL but I don't know the innards well enough I'm afraid. Simon
[2.x] duplicate default definitions.xml
We have two copies of the default definitions information. C:\simon\tuscany\java-2.x\modules\assembly-xml\src\main\resources\META-INF\sca-policy-1.1-intents-definitions-cd02.xml C:\simon\tuscany\java-2.x\modules\assembly-xsd\src\main\resources\sca-policy-1.1-intents-definitions-cd02.xml For some reason this has started causing duplicate definitions errors in the otests. Only the one in assembly-xml seems to be configured to be loaded so not quite sure why it's started complaining. Whatever the reason it's confusing having two copies so I'm going to remove the one from assembly-xsd. Simon
Re: Slow RMI Host start up
It does ring a bell but it's working OK for me at the moment. Simon
Re: svn commit: r820460 - in /tuscany/java/sca/modules/builder/src/main/java/org/apache/tuscany/sca/builder/impl: ComponentBuilderImpl.java CompositeComponentTypeBuilderImpl.java ModelBuilderImpl.ja
Hi Raymond Why was it necessary to pass in the outer component? The property values are pushed down into the outer component's component type, if appropriate, when the component properties are reconciled with those of its component type. Hence they are available in the parent composite. Have I missed something else? Regards Simon
Re: [2.x] duplicate default definitions.xml
Not sure. The otests are working for me currently. I'll prod Mike and check. Thanks Simon
Re: [VOTE] Release Tuscany SCA Java 1.5.1 RC4
The vote passes with 6 +1s from Jean-Sebastien Delfino Ant Elder Raymond Feng Luciano Resende Ramkumar R Simon Laws Thanks everyone for the reviews. I'll get the artifacts published and announced. Regards Simon
Re: svn commit: r821834 - /tuscany/java/sca/modules/builder/src/main/java/org/apache/tuscany/sca/builder/impl/CompositeCloneBuilderImpl.java
The problem is, because the order of processing has been changed, at this stage the top level composite has no components in it. The top level, domain, composite simply has a set of includes and they haven't yet been flattened into the top leve composite. Therefore cloneCompositeImplementations has no effect as it was originally coded. The scneario I had problems with is as follows. Composite1 Component1 implementation.composite Composite2 property serviceName = service1 Component2 implementation.composite Composite2 property serviceName = service2 Component3 implementation.composite Composite2 property serviceName = service3 Composite2 property serviceName Component4 property serviceName = service1 When run all instances of Component4 has the propert serviceName set to service3. It turned out this was because all components referred to the same instance of Composite2. Regards Simon
