Re: svn commit: r394667 - in /incubator/tuscany/java/sca: containers/container.java/src/test/java/org/apache/tuscany/container/java/mock/ core/src/main/java/org/apache/tuscany/core/context/ core/src/m
I think we may need something like this again when we support nested
configuration...what do you think?
On Apr 17, 2006, at 6:37 AM, [EMAIL PROTECTED] wrote:
Author: jboynes
Date: Mon Apr 17 06:37:49 2006
New Revision: 394667
URL: http://svn.apache.org/viewcvs?rev=394667view=rev
Log:
refactor to remove ConfigurationContext.configure()
the only implementation is empty and all the action happens in build()
Modified:
incubator/tuscany/java/sca/containers/container.java/src/test/
java/org/apache/tuscany/container/java/mock/MockConfigContext.java
incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/context/ConfigurationContext.java
incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/context/impl/AbstractCompositeContext.java
incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/runtime/RuntimeContextImpl.java
incubator/tuscany/java/sca/core/src/test/java/org/apache/
tuscany/core/mock/MockConfigContext.java
Modified: incubator/tuscany/java/sca/containers/container.java/src/
test/java/org/apache/tuscany/container/java/mock/
MockConfigContext.java
URL: http://svn.apache.org/viewcvs/incubator/tuscany/java/sca/
containers/container.java/src/test/java/org/apache/tuscany/
container/java/mock/MockConfigContext.java?
rev=394667r1=394666r2=394667view=diff
==
--- incubator/tuscany/java/sca/containers/container.java/src/test/
java/org/apache/tuscany/container/java/mock/MockConfigContext.java
(original)
+++ incubator/tuscany/java/sca/containers/container.java/src/test/
java/org/apache/tuscany/container/java/mock/MockConfigContext.java
Mon Apr 17 06:37:49 2006
@@ -21,12 +21,10 @@
import org.apache.tuscany.core.builder.WireBuilder;
import org.apache.tuscany.core.builder.impl.AssemblyVisitorImpl;
import org.apache.tuscany.core.builder.impl.DefaultWireBuilder;
-import org.apache.tuscany.core.config.ConfigurationException;
import org.apache.tuscany.core.context.ConfigurationContext;
import org.apache.tuscany.core.context.ScopeContext;
import org.apache.tuscany.core.wire.ProxyFactory;
import org.apache.tuscany.model.assembly.AssemblyObject;
-import org.apache.tuscany.model.assembly.Extensible;
/**
* A mock configuration context
@@ -38,7 +36,7 @@
private ListContextFactoryBuilder builders;
private DefaultWireBuilder wireBuilder = new DefaultWireBuilder
();
-
+
public MockConfigContext(ListContextFactoryBuilder builders,
ListWireBuilder wireBuilders) {
this.builders = (builders == null) ? new ArrayList(1) :
builders;
if (wireBuilders != null){
@@ -48,16 +46,13 @@
}
}
-public void configure(Extensible model) throws
ConfigurationException {
-}
-
public void build(AssemblyObject model) throws
BuilderConfigException {
AssemblyVisitorImpl visitor = new AssemblyVisitorImpl
(builders);
visitor.start(model);
}
public void connect(ProxyFactory sourceFactory, ProxyFactory
targetFactory, Class targetType, boolean downScope,
-ScopeContext targetScopeContext) throws
BuilderConfigException {
+ScopeContext targetScopeContext) throws
BuilderConfigException {
wireBuilder.connect(sourceFactory, targetFactory,
targetType, downScope, targetScopeContext);
}
Modified: incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/context/ConfigurationContext.java
URL: http://svn.apache.org/viewcvs/incubator/tuscany/java/sca/core/
src/main/java/org/apache/tuscany/core/context/
ConfigurationContext.java?rev=394667r1=394666r2=394667view=diff
==
--- incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/context/ConfigurationContext.java (original)
+++ incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/context/ConfigurationContext.java Mon Apr 17 06:37:49
2006
@@ -15,8 +15,6 @@
import org.apache.tuscany.core.builder.ContextFactoryBuilder;
import org.apache.tuscany.core.builder.WireBuilder;
-import org.apache.tuscany.core.config.ConfigurationException;
-import org.apache.tuscany.model.assembly.Extensible;
/**
* Offers configuration services in the runtime. A
ConfigurationContext is able to configure a model and then build the
@@ -29,13 +27,4 @@
* @version $Rev$ $Date$
*/
public interface ConfigurationContext extends
ContextFactoryBuilder, WireBuilder {
-
-/**
- * Adds additional configuration information to a model object.
- *
- * @param model the model object to be configured
- * @throws ConfigurationException
- */
-public void configure(Extensible model) throws
ConfigurationException;
-
}
Modified: incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/context/impl/AbstractCompositeContext.java
URL:
Re: New Celtix binding in the sandbox
On Apr 20, 2006, at 4:31 AM, Daniel Kulp wrote: Jim, I think this is a really good start but before they get moved up I'd like to see some unit test coverage. Agreed. Normally, I wouldn't have even submitted a patch without some tests in place. That really bothers me. But I was also getting frustrated with the breakages so decided it would be a good thing to get in so you can refactor it as you do you work. This way, I can Yea for the sandbox that is absolutely fine. Also, it's pretty easy for me to do the refactorings (I probably should have suggested we do this, as it would have saved you the frustration). I guess I owe you a few beers :-) Are you out in the Bay Area for JavaOne? concentrate on creating tests, adding features (doc/lit and rpc/lit support are next), etc... without having to spend time each day trying to figure out why it's not compiling. :-) Related to unit testing: Do you guy use any sort of mock object framework for testing? For Celtix, we use easymock: http://www.easymock.org/ I don't want to start using it if you already started using something else. It's already in maven/ibiblio so it's easy to use with maven. We haven't chosen one yet. I'd be open to using Easy Mock. What do others think? Should we adopt it? Thanks! Dan I also think this is going to raise some interesting integration test issues. For example, I'd like to set up integration tests with Celtix and the Java container (maybe Javascript but I'm not sure if that is feasible in the short-term if there is a need to do data-transformation). What do people think is the best strategy for testing projects that do not have dependencies on one another (e.g. Celtix and Java)? This may tie into the continuum discussions. Jim On Apr 19, 2006, at 6:08 PM, Jeremy Boynes wrote: I committed the patches from Dan Kulp for a Celtix binding into the sandbox. They look good to me and both built out of the box. Please can others have a look and see if/when these should be moved into the main tree. Dan has been very patient with our recent refactorings breaking his code so I would ask everyone (Jim!) if they could include these modules into their IDEs when changing stuff even though they are still in the sandbox. -- Jeremy -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
system services
I noticed in system.module we are using qualified names for system services based on the full name of the implementation class. I'd prefer if we continue to use the dot notation, but shorten the names, e.g.: org.apache.tuscany.core.loader.WSDLDefinitionRegistry to system.loader.WSDLDefinitionRegistry Thoughts?
Re: system services
I was thinking we would reserve system for Tuscany things. This would be unique. Jim On Apr 20, 2006, at 3:20 PM, Jeremy Boynes wrote: Jim Marino wrote: I noticed in system.module we are using qualified names for system services based on the full name of the implementation class. I'd prefer if we continue to use the dot notation, but shorten the names, e.g.: org.apache.tuscany.core.loader.WSDLDefinitionRegistry to system.loader.WSDLDefinitionRegistry Thoughts? They are unwieldy but they are unique. I think we need some namespacing if we continue along the path of merging fragments into a single composite. This would go away if we switched to a composition model where the fragments become parts of the outer composition. -- Jeremy
Re: Support for asynchronous non-blocking calls available in the sandbox
great. I'll take a look today and tomorrow. I'm also interested in helping so let me know what you would like done. Jim On Apr 25, 2006, at 8:38 AM, Jean-Sebastien Delfino wrote: I checked a first implementation of support for async non-blocking calls in the sandbox. Directory sandbox/sebastien/java/sca/async contains the runtime code, sandbox/sebastien/java/samples/ helloworldasync contains an asynchronous variation of the helloworld sample. More details about how this code works are in http://issues.apache.org/jira/browse/TUSCANY-223. Could people in the group please take a look and see if you're (reasonably) happy with this initial implementation? If there's no objection I'd like to move this to the sca/core project in the next couple of days. There are still some limitations and temporary workarounds in this code, I'm probably going to need help to go from there and improve this initial implementation. I'm also looking for a better sample than helloworld to demonstrate the async capability... Anybody interested in helping with this? -- Jean-Sebastien
Re: Coding guidelines
Sure - it's already in the sandbox under jim/docs/ exception_handling.html. These were agreed to at the outset of the project (along with the IDE templates) and drafted by Sebastien, Jeremy, myself based on some guidelines donated by Mike Rowley. Jim On Apr 25, 2006, at 9:25 AM, haleh mahbod wrote: The last exchange on coding guideline was in this link http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200604.mbox/ [EMAIL PROTECTED] Jim, can you please send me the guideline that you are referring to in the above exchange? I am assuming that this has been agreed to on mailing list. I'd like to post it on the website. Thanks
Re: WS interop/intergation/functional testing
On Apr 25, 2006, at 6:28 AM, Jeremy Boynes wrote: Generally I like this approach - I do have a couple of small comments inline. On 4/25/06, ant elder [EMAIL PROTECTED] wrote: Create a new folder under testing called 'interop' . Interop may not be the best name, feel free to suggest alternatives. interop makes sense - +1 In testing/interop there will be two other folders, 'local', and 'remote'. testing/interop/remote will contain WS test clients that make WS invocations out to remote services on the Internet, so you'll need a network connection to run these and they'll probably be a little slow. client would also be an alternative to remote I assume these will be J2SE clients that can just be run with maven and that they use WS ExternalServices to talk to the remote services. Will there be multiple implementations of the test clients in different languages? Is there a reason you were thinking about why these wouldn't be JUnit- based or is that considered J2SE? testing/interop/local will include implementations of the WS services used by all the clients in the remote folder. It will also have clients to invoke those services but they'll just be extending the client code in the remote folder to override the endpoint used to be the local service but without requiring too much code duplication of the client code. Perhaps server as an alternative to local Will we have to implement these services or are there existing versions we can use? Are there other non-SCA clients that can be used to call them? Within the local and remote folders there will be separate projects for each set of tests, so projects for whitemesa, aspnetround3, amazon etc. These tests are using the actual SCA client APIs, they're not gong to be fudging things like the existing WS test in the tomcat integration tests. The testing/interop/local services need to be deployed and run in tomcat to work, so that will be done by the existing testing/tomcat stuff. I haven't quite though this part through yet, I guess that means having testing/tomcat get all the testing/interop/local sevices deployed and adding to testing/tomcat an interop test project which calls all the testcases in testing/interop/local. It doesn't seem perfect to require having testing/tomcat/interop as well as testing/interop, is there a better/easier way to do this? This should not depend on a special Tomcat installation but should be deployable to our normal Tomcat distribution (or any other distro we do) - that way we know the distro that users would actually download is being tested. +1 on this particularly as we add more host environments I'm not sure you really need the special clients here - just run the server and then run the real clients (from remote) against it. That way we know our real interop clients talk to our real server with no fudging. I also like this given that if we test against our own servers it's not interop So with that config you can run all the testing/interop/local tests to test out the Tuscany WS entryPoint and externalService function. Or you can run all the testing/interop/remote tests to verify interaction with real non-Tuscany systems. Interop is all about working with non-Tuscany systems. I think having the ability to run their clients against our server is very important. Ant or someone more familiar with Axis, I assume there are some mechanisms at Apache for setting this type of thing up? For now I wont even mention the question of when any of these tests should get run as part of a build process :-) Given the dependencies (e.g. on remote servers, other people's clients) then I don't think these should be run as part of the build. This should be done in a controlled environment on a periodic basis, and at least once with any release candidate. Any comments or suggestions? Thanks -- Jeremy
including celtix in refactor work and checkstyle
Just a friendly reminder to those working on the core or model to please include celtix in their refactorings. I accidentally forgot to check in my refactors (sandbox is separate) and run the checkstyle tests from celtix/binding.celtix resulting in Dan having a broken demo :-( Also, someone else modifying the loader forgot to include the project in their refactors (I fixed it)... Dan also proposed we adopt checkstyle as part of the build process. I would like to due this using lazy consensus with the caveat that the cut-over be done after the Java One release to avoid disruption and give people a chance to adjust code gradually. The checkstyle configuration is fairly rigorous and we will need to divide up the work to do so by project. Jim
Re: Support for asynchronous non-blocking calls available in the sandbox
+1 to move it Jim On Apr 25, 2006, at 8:38 AM, Jean-Sebastien Delfino wrote: I checked a first implementation of support for async non-blocking calls in the sandbox. Directory sandbox/sebastien/java/sca/async contains the runtime code, sandbox/sebastien/java/samples/ helloworldasync contains an asynchronous variation of the helloworld sample. More details about how this code works are in http://issues.apache.org/jira/browse/TUSCANY-223. Could people in the group please take a look and see if you're (reasonably) happy with this initial implementation? If there's no objection I'd like to move this to the sca/core project in the next couple of days. There are still some limitations and temporary workarounds in this code, I'm probably going to need help to go from there and improve this initial implementation. I'm also looking for a better sample than helloworld to demonstrate the async capability... Anybody interested in helping with this? -- Jean-Sebastien
Re: WS interop/intergation/functional testing
On Apr 25, 2006, at 5:58 PM, Jean-Sebastien Delfino wrote: Jim Marino wrote: On Apr 25, 2006, at 6:28 AM, Jeremy Boynes wrote: Generally I like this approach - I do have a couple of small comments inline. On 4/25/06, ant elder [EMAIL PROTECTED] wrote: Create a new folder under testing called 'interop' . Interop may not be the best name, feel free to suggest alternatives. interop makes sense - +1 In testing/interop there will be two other folders, 'local', and 'remote'. testing/interop/remote will contain WS test clients that make WS invocations out to remote services on the Internet, so you'll need a network connection to run these and they'll probably be a little slow. client would also be an alternative to remote I assume these will be J2SE clients that can just be run with maven and that they use WS ExternalServices to talk to the remote services. Will there be multiple implementations of the test clients in different languages? Is there a reason you were thinking about why these wouldn't be JUnit-based or is that considered J2SE? testing/interop/local will include implementations of the WS services used by all the clients in the remote folder. It will also have clients to invoke those services but they'll just be extending the client code in the remote folder to override the endpoint used to be the local service but without requiring too much code duplication of the client code. Perhaps server as an alternative to local Will we have to implement these services or are there existing versions we can use? Are there other non-SCA clients that can be used to call them? Within the local and remote folders there will be separate projects for each set of tests, so projects for whitemesa, aspnetround3, amazon etc. These tests are using the actual SCA client APIs, they're not gong to be fudging things like the existing WS test in the tomcat integration tests. The testing/interop/local services need to be deployed and run in tomcat to work, so that will be done by the existing testing/tomcat stuff. I haven't quite though this part through yet, I guess that means having testing/tomcat get all the testing/interop/local sevices deployed and adding to testing/tomcat an interop test project which calls all the testcases in testing/interop/local. It doesn't seem perfect to require having testing/tomcat/interop as well as testing/interop, is there a better/easier way to do this? This should not depend on a special Tomcat installation but should be deployable to our normal Tomcat distribution (or any other distro we do) - that way we know the distro that users would actually download is being tested. +1 on this particularly as we add more host environments I'm not sure you really need the special clients here - just run the server and then run the real clients (from remote) against it. That way we know our real interop clients talk to our real server with no fudging. I also like this given that if we test against our own servers it's not interop So with that config you can run all the testing/interop/local tests to test out the Tuscany WS entryPoint and externalService function. Or you can run all the testing/interop/remote tests to verify interaction with real non-Tuscany systems. Interop is all about working with non-Tuscany systems. I think having the ability to run their clients against our server is very important. Ant or someone more familiar with Axis, I assume there are some mechanisms at Apache for setting this type of thing up? For now I wont even mention the question of when any of these tests should get run as part of a build process :-) Given the dependencies (e.g. on remote servers, other people's clients) then I don't think these should be run as part of the build. This should be done in a controlled environment on a periodic basis, and at least once with any release candidate. Any comments or suggestions? Thanks -- Jeremy +1 from me on all of this. I am assuming that the client side tests are Junit tests. I like Jeremy's proposal to name these client / server. I agree that we need to run these tests on top of our actual distro. Two questions: - can we run this daily with continuum? - can we have a single client test suite and externalize the endpoints that it talks to, with a Maven configuration for example? (this would be simpler than the initial template that I had checked in, which had common test code but still required different test cases to talk to our server and the remote test server) I'd like to add that I think we need unit and integration testing run as part of the build which covers some of the expected interop behavior. In other words, we should have good enough coverage in our build where a basic interop test (e..g not serializing something properly) surprises us. I was thinking the integration
Re: Checkstyle enforcement proposal...
The only one I think we may not want is the TYPECAST. That said, I'm not fussy about line length as long as it is consistent, not too long, not too short. One thing I would like to change is throwing errors for when parameter names hide member variables since I think this is o.k. Dan, do you have an objection to removing that check? Ant, you -1 this stating that you weren't sure what this entails and that it was buried in another email. Now that Dan pulled it out and included a description of what checkstyle is, do you have specific concerns about the proposal? Others may have specific objections as well. Please speak up, for or against :-) Jim On Apr 26, 2006, at 6:39 AM, Daniel Kulp wrote: One more comment: One complaint I've heard from developers about enabling checkstyle is: It will (a) slow me down because (b) it doesn't match my style. a) Based on my experience on several projects where checkstyle was added, it's really not true in the long term. For the first week or so, it DOES slow people down a bit, but once developers started getting used to the style, got their IDE's setup, etc... it no longer is a problem. If you ask any of the Celtix developers, most of them don't even realize checkstyle is even there anymore. They've gotten used to the style so it's rare that they even hit it. Long term, and with larger teams (Celtix has about 14 active commiters and growing), it actually speeds up the development as debugging and tracing and reading other peoples code becomes much easier as it's all 100% consistent from a style standpoint. (there are still inconsistencies in algorithms and approaches and such, obviously, but I haven't found a tool for that yet. :-) b) That's the point. Consistency across an entire project is important as it speeds up the developers. See point (a). Your not conforming Anyway, I kind of relate enabling checkstyle to be similar to switching to a kinesis contoured keyboard or other ergo keyboard. (http://www.kinesis-ergo.com/contoured_usb.htm , highly recommended BTW) For the first week, you WILL be slower, but long term, there are a lot of good things that come out of it. Enjoy! Dan On Wednesday 26 April 2006 08:05, Daniel Kulp wrote: Copying out of Jim's message into an appropriate titled message to make sure it doesn't get lost: Dan also proposed we adopt checkstyle as part of the build process. I would like to due this using lazy consensus with the caveat that the cut-over be done after the Java One release to avoid disruption and give people a chance to adjust code gradually. The checkstyle configuration is fairly rigorous and we will need to divide up the work to do so by project. My information: I've attached the proposed checkstyle.xml.In there, there are links to checkstyles website that describes each of the checks. All of the checkstyle checks are listed in the file, but many are disabled. They are left in the file so people can see what is available and we can decide if we want them enabled or not. There may need to be an additional change. The beta version of the next Checkstyle eclipse plugin uses a beta version of checkstyle 4.2. It adds TYPECAST to the defaults for NoWhitespaceAfter. Thus, code like: Foo foo = (Foo) obj; is marked illegal with the newer version. (the current maven version is OK)I notice we do that in many places (although there are also a lot of typecasts without the space). Anyway, if we want to continue supporting both with and without spaces, that test would need to be updated to explicitly list the tokens we DO want. However, I personally feel we should leave it as is and remove the spaces, but that's my preference. Unfortunately, it would be hard to enforce until checkstyle 4.2. In general, the tests that require some discussion are: 1) AbstractClassName: what names should abstract classes have. Celtix has a couple. I haven't looked at tuscany much in this regard. 2) AvoidStarImport and ImportOrder - Celtix DOES allow star imports for some of the java packages (io, util, net, etc...) and junit. All others cannot have start imports. We also order them more like the old C ordering of system stuff first (java., javax. org.w3c., org.xml) followed by all other stuff, in alpha order. 3) Lengths always start good discussions. We limit LineLength to 110 (but the attached checkstyle is set to 115), Method Length to 150, number of parameters to a method to 7, and AnonymousInnerClasses set to 40 lines. (which seems high to me, but...) I'd ALSO like this discussion done for the SDO and SPEC projects as well as the generated code. But those can wait. Right now, those parts are COMPLETELY different than the rest of the tuscany code. It's a bit strange when debugging when you trace into that code as suddenly everything looks different. I guess the question is: are those parts
Re: EntryPoint name must match wired-to Service name?
Could you post a stack trace? Thanks, Jim On Apr 26, 2006, at 10:45 AM, Scott Kurz wrote: I'm observing an issue (running April 17th SVN contents) and I'm not sure if this is a bug or a limitation with the current Tuscany implementation or if this is working according to the 0.9 spec (in which case I'm not understanding it). The issue is that with a WS binding you currently need (unnecessarily in my opinion) to match the EntryPoint name with the name of the Service it is wired to via the references tag. So, for example, in the HelloWorld WS sample's sca.module file, you have: entryPoint name=HelloWorldService interface.wsdl interface= http:// helloworldaxis.samples.tuscany.apache.org#HelloWorldServiceImpl/ binding.ws port= http://helloworldaxis.samples.tuscany.apache.org#helloworld/ referenceHelloWorldServiceComponent/HelloWorldService/ reference /entryPoint It seems to me you should be able to rename the entryPoint as: entryPoint name=HelloWorldServiceEP but be able to keep the reference as: referenceHelloWorldServiceComponent/HelloWorldService/ reference I don't see that the spec requires that the two names be the same, but when I tried this recently in Tomcat I had this problem. Does anyone not think I should open a JIRA? I didn't see one for this issue. Thanks, Scott
Re: EntryPoint name must match wired-to Service name?
Nevermind, ' I just saw the JIRA. Thanks. Jim On Apr 26, 2006, at 12:31 PM, Jim Marino wrote: Could you post a stack trace? Thanks, Jim On Apr 26, 2006, at 10:45 AM, Scott Kurz wrote: I'm observing an issue (running April 17th SVN contents) and I'm not sure if this is a bug or a limitation with the current Tuscany implementation or if this is working according to the 0.9 spec (in which case I'm not understanding it). The issue is that with a WS binding you currently need (unnecessarily in my opinion) to match the EntryPoint name with the name of the Service it is wired to via the references tag. So, for example, in the HelloWorld WS sample's sca.module file, you have: entryPoint name=HelloWorldService interface.wsdl interface= http:// helloworldaxis.samples.tuscany.apache.org#HelloWorldServiceImpl/ binding.ws port= http://helloworldaxis.samples.tuscany.apache.org#helloworld/ referenceHelloWorldServiceComponent/HelloWorldService/ reference /entryPoint It seems to me you should be able to rename the entryPoint as: entryPoint name=HelloWorldServiceEP but be able to keep the reference as: referenceHelloWorldServiceComponent/HelloWorldService/ reference I don't see that the spec requires that the two names be the same, but when I tried this recently in Tomcat I had this problem. Does anyone not think I should open a JIRA? I didn't see one for this issue. Thanks, Scott
Re: Checkstyle enforcement proposal...
So if we do not have the space restriction, checks for parameter names, and run this only pre-commit, would you be o.k. with it? I would like to have this in since it is a nice check and should not be burdensome assuming people set the proper template in their IDE. On Apr 26, 2006, at 3:47 PM, Jeremy Boynes wrote: On 4/26/06, Daniel Kulp [EMAIL PROTECTED] wrote: My information: I've attached the proposed checkstyle.xml.In there, there are links to checkstyles website that describes each of the checks. All of the checkstyle checks are listed in the file, but many are disabled. They are left in the file so people can see what is available and we can decide if we want them enabled or not. -0 I like the idea in theory but have concerns with: a) the time it takes to run the plugin especially with the number of modules we have is there way it can be run pre-commit? b) failing the build due to a missing, insignificant space seems harsh especially when there are other more worrying issues like missing tests Call me naive but I would hope self-discipline (and reformat code in the IDE) would keep layout issues under control and that unit testing (backed by application of a large fish) would keep bugs under control. -- Jeremy
Re: Checkstyle enforcement proposal...
I agree poor test coverage is more important but this shouldn't be a big deal - I'll even do it for all of the packages myself. I think this is one of those incremental improvements that will make the code more consistent and easier for people to understand coming fresh into the project. I'm also proposing this for after JavaOne and many of the more important items. Jim On Apr 26, 2006, at 4:15 PM, Jeremy Boynes wrote: Jim Marino wrote: So if we do not have the space restriction, checks for parameter names, and run this only pre-commit, would you be o.k. with it? I would like to have this in since it is a nice check and should not be burdensome assuming people set the proper template in their IDE. Doing it that way would get me to +0 - I just think we're focusing a little much on layout and not enough on e.g. testing. I would like to hear what others have to say. -- Jeremy
Re: Moving the Celtix binding to the bindings/ directory, was: including celtix in refactor work and checkstyle
+1 Dan submitted a patch with testcases so I think it should go into the build process with that patch applied. Thanks Dan! Jim On Apr 26, 2006, at 11:42 AM, Jean-Sebastien Delfino wrote: Jim Marino wrote: Just a friendly reminder to those working on the core or model to please include celtix in their refactorings. I accidentally forgot to check in my refactors (sandbox is separate) and run the checkstyle tests from celtix/binding.celtix resulting in Dan having a broken demo :-( Also, someone else modifying the loader forgot to include the project in their refactors (I fixed it)... Dan also proposed we adopt checkstyle as part of the build process. I would like to due this using lazy consensus with the caveat that the cut-over be done after the Java One release to avoid disruption and give people a chance to adjust code gradually. The checkstyle configuration is fairly rigorous and we will need to divide up the work to do so by project. Jim Sorry for contributing to the break as well... when I did my latest refactoring I didn't have the Celtix binding included in my workspace either. What do people think about moving the Celtix binding to the main code stream under bindings/? It's getting in a good shape now, and this way we'll all include it in our refactoring, testing, it'll be loaded in our IDEs etc. Any thoughts? -- Jean-Sebastien
Re: Checkstyle enforcement proposal...
Yep, absolutely that makes sense. Jim On Apr 26, 2006, at 7:03 PM, Jean-Sebastien Delfino wrote: Jim Marino wrote: I agree poor test coverage is more important but this shouldn't be a big deal - I'll even do it for all of the packages myself. I think this is one of those incremental improvements that will make the code more consistent and easier for people to understand coming fresh into the project. I'm also proposing this for after JavaOne and many of the more important items. Jim On Apr 26, 2006, at 4:15 PM, Jeremy Boynes wrote: Jim Marino wrote: So if we do not have the space restriction, checks for parameter names, and run this only pre-commit, would you be o.k. with it? I would like to have this in since it is a nice check and should not be burdensome assuming people set the proper template in their IDE. Doing it that way would get me to +0 - I just think we're focusing a little much on layout and not enough on e.g. testing. I would like to hear what others have to say. -- Jeremy I'm +1 on the goal to enable checkstyle. I'm also +1 on Dan's initial proposal which was to do this *after* JavaOne. Since most of us are busy now with testing and/or critical fixes for our JavaOne release, I suggest that we try to sort out the details of the style, spacing, typecasting, checking for parameter names etc. after the release. Does that make sense? -- Jean-Sebastien
Re: Use of references with multiplicity *..n?
They should be working for Java types. Could you open a Jira and
post the two component classes (particularly the interfaces) you are
trying to wire together along with the SCDL? I'll try and take a look
this weekend.
Jim
On Apr 27, 2006, at 1:08 PM, Ignacio Silva-Lepe wrote:
Not sure whether references with multiplicity *..n are available
yet. If they're not I can wait. But in case they are, I am getting
the following exception:
Exception in thread main
org.apache.tuscany.core.builder.BuilderConfigException:
Incompatible source and target interface types for reference
[warehouses]
Context stack trace: [tuscany.root][supplychain][supplychain]
[RetailerComponent][WarehouseComponent1][tuscany.root]
at org.apache.tuscany.core.builder.impl.DefaultWireBuilder.connect
(DefaultWireBuilder.java:64)
at org.apache.tuscany.core.runtime.RuntimeContextImpl.connect
(RuntimeContextImpl.java:166)
at
org.apache.tuscany.core.context.impl.AbstractCompositeContext.connect(
AbstractCompositeContext.java:793)
at
org.apache.tuscany.core.context.impl.AbstractCompositeContext.wireSour
ce(AbstractCompositeContext.java:594)
at
org.apache.tuscany.core.context.impl.AbstractCompositeContext.start
(AbstractCompositeContext.java:165)
at
org.apache.tuscany.core.context.scope.CompositeScopeContext.registerFa
ctory(CompositeScopeContext.java:95)
at
org.apache.tuscany.core.context.impl.AbstractCompositeContext.register
Configuration(AbstractCompositeContext.java:474)
at
org.apache.tuscany.core.context.impl.AbstractCompositeContext.register
ModelObject(AbstractCompositeContext.java:421)
at org.apache.tuscany.core.client.BootstrapHelper.registerModule
(BootstrapHelper.java:133)
at org.apache.tuscany.core.client.TuscanyRuntime.init
(TuscanyRuntime.java:104)
at org.apache.tuscany.samples.supplychain.SupplychainClient.main
(SupplychainClient.java:43)
when I try to use the following component impl:
@Service(Retailer.class)
public class RetailerComponentImpl implements Retailer {
@Reference(name=warehouses, required=true)
private ListWarehouse warehouses;
public void submitOrder(String order) {
for (Warehouse warehouse : warehouses) {
warehouse.fulfillOrder(order + , submitted);
}
}
}
for the following set of definitions:
component name=RetailerComponent
implementation.java
class=org.apache.tuscany.samples.supplychain.RetailerComponentImpl/
references
v:warehousesWarehouseComponent1/v:warehouses
v:warehousesWarehouseComponent2/v:warehouses
/references
/component
component name=WarehouseComponent1
implementation.java
class=org.apache.tuscany.samples.supplychain.WarehouseComponentImpl/
references
v:shipperShipperComponent/v:shipper
/references
/component
component name=WarehouseComponent2
implementation.java
class=org.apache.tuscany.samples.supplychain.WarehouseComponentImpl/
references
v:shipperShipperComponent/v:shipper
/references
/component
Re: Support for asynchronous non-blocking calls available in the sandbox
Hi Ignacio, I'm planning to work on conversational support following JavaOne if you (or others are interested). This will involve a refactoring of the scope containers slightly to accommodate a persistent store. Let me know if you are interested in working on this together. Jim On Apr 27, 2006, at 7:43 AM, Ignacio Silva-Lepe wrote: Ok, I have a very simple, but a bit more realistic supply chain sample. The idea is to use it to test (in addition to the simple non-blocking call of the customer by the shipper) features like callbacks, passing references to call, and references with multiplicity *..n (as in a retailer with several warehouses to choose from) when they are available. For now it is just a straight chain with a hardwired reference from the shipper to the customer, and using a dummy order (which can also become more realistic, using an sdo, for instance). I'll keep working on adding the features that are available. I can send the zip file to Jean-Sebastien to add to the sandbox. Ignacio [snip] Great! Thanks for volunteering. We have an async variation of the helloworld sample under samples/helloworld/helloworldasync, but I'm not too happy with it as it's not very realistic. So any idea of a better sample to demonstrate the async programming model is welcome! We're just at the beginning of our async implementation so it's the right time to hop in, and help us improve it :) Thanks -- Jean-Sebastien [snip]
Re: Support for asynchronous non-blocking calls available in the sandbox
Cool. I have some work on a BigBank async sample done as part of the specification collaboration that I need to clear but once I do, we can discuss that as part of this topic. The scope containers may need to be refactored slightly (we can discuss) as well as I believe there may need to be a slight change in the spec regarding the way conversations and scopes are defined. We've started to go over this in the spec group already. Perhaps we could schedule a time to discuss on IRC so others interested may join in? We have a weekly IRC chat at 8.30PST on Mondays. We could bring this up then initially if you can make it. does that time work? If not, we could perhaps schedule another time? Also, any plans to be in the Bay area for JavaOne or at the Tuscany BoF? Jim On Apr 29, 2006, at 6:10 AM, Ignacio Silva-Lepe wrote: Hi Jim, Yes, I would be interested in working on conversational support, thanks for asking. We can sync up after JavaOne to coordinate. By then I hope I have a better understanding of the implementation details of scope containers, etc. Ignacio - Original Message - Hi Ignacio, I'm planning to work on conversational support following JavaOne if you (or others are interested). This will involve a refactoring of the scope containers slightly to accommodate a persistent store. Let me know if you are interested in working on this together. Jim
[RESULT]Re: Karma for Dan
Result of the vote for Dan Kulp as committer on Apache Tuscany: +1 jmarino,jboynes,antelder,dims,jsdelfino,rineholt No -1s Dan welcome to the Apache Tuscany community! We'll start the process of getting you karma. Jim On Apr 29, 2006, at 10:28 AM, Jim Marino wrote: I'd like to propose was make Dan a commiter since he's done a lot including: - Creating a binding that supports web services and will support JMS over the next couple of days - Fixed a host of compiler warnings in a number of projects - Has served as an excellent bridge to the Celtix community - Has demonstrated that he shares a philosophy towards design and coding that is consistent with the Tuscany group Also, more practically, there is outstanding work to move the Celtix binding to main and he has a fairly large commit coming. I for one would like to have Dan do it directly :-) So, could we vote on this proposal? +1 (obviously) from me. Jim
release naming scheme
Hi, I've noticed in JIRA we are naming our release .91. Is that just a JIRA thing (i.e. make it easier to organize stuff for us) or is it assumed that we would call the JavaOne binary a .91 release? I think we should discuss what we want to call the binary, so I'll throw my opinion in now... I think we should definitely not call it a .9X release as that denotes a fairly stable runtime, which we will not have. My proposal is to view this as a milestone release, so perhaps we should just call it M1 and avoid numbering altogether? Thoughts? Jim
inclusion of samples in the Java SCA build process
I noticed with the recent changes to move samples under /java/sca they are not built as part of the main developer build. I agree the samples should be moved there but not that they be built as part of the main developer build. I'm not sure whether this was a byproduct of the move but based on how the developer build worked in the past, they should not be included. Rather, they perhaps should be run with the build off /java? I'd like to better understand what the goals are for this change to the build process as I was unaware a decision was made to change it. Could someone please explain? Thanks in advance, Jim
Fwd: inclusion of samples in the Java SCA build process
Small clarification the first sentence should be: I noticed with the recent changes to move samples under /java/sca they are now built as part of the main developer build. Begin forwarded message: From: Jim Marino [EMAIL PROTECTED] Date: May 5, 2006 1:14:52 PM PDT To: tuscany-dev@ws.apache.org Subject: inclusion of samples in the Java SCA build process I noticed with the recent changes to move samples under /java/sca they are not built as part of the main developer build. I agree the samples should be moved there but not that they be built as part of the main developer build. I'm not sure whether this was a byproduct of the move but based on how the developer build worked in the past, they should not be included. Rather, they perhaps should be run with the build off /java? I'd like to better understand what the goals are for this change to the build process as I was unaware a decision was made to change it. Could someone please explain? Thanks in advance, Jim
Re: Groovy Container
Yes by all means. Could you post it to JIRA? Thanks! Jim On May 7, 2006, at 12:14 PM, meeraj kunnumpurath wrote: Hi, I have written a Groovy container for Tuscany. Is it worth submitting? Kind regards Meeraj -- ___ Search for businesses by name, location, or phone number. -Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/ default.asp?SRC=lycos10
Celtix 1.0
Congrats Dan! http://www.theserverside.com/news/thread.tss?thread_id=40320
Re: Maven artifactID for all samples to sample-xxxxx
This is the same in IntelliJ too so I think it is a good thing to do. +1 On May 10, 2006, at 6:32 AM, cr22rc2 wrote: I'd like to propose for all samples be it the yet undecided name for what BB is and the other technology samples to prepend to the maven artifactid sample-. I hate to be picky about things like this, but I think this would make it clearer that it's a sample. For Eclipse users it really adds a nice touch that if you import all the projects they would be grouped together. IDEAL? Just a request.
Re: [VOTE] Publish Tuscany M1 release
+1 On May 18, 2006, at 4:00 PM, Jean-Sebastien Delfino wrote: Hi! I created source and binary distributions of the latest Tuscany Milestone 1 release candidate level (SVN revision r407596) and placed them in my home directory: http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany- incubating-M1-src.tar.gz http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany- incubating-M1-src.zip http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany- incubating-M1.tar.gz http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany- incubating-M1.zip I also tagged this level of code as http://svn.apache.org/repos/asf/ incubator/tuscany/tags/java-M1-20060518. Solid progress has been made to produce this Milestone release, and I think it is in a good shape. The list of JIRA issues resolved and closed in this Milestone 1 release is here: http://issues.apache.org/jira/secure/IssueNavigator.jspa? reset=truepid=12310210fixfor=12311030fixfor=12311061version=12311 030version=12311061status=5status=6sorter/field=prioritysorter/ order=DESC Instructions on setting up your environment to use Tuscany and getting started with the Tuscany samples are in the README.txt and GettingStarted.htm files contained in the distributions. These files can also be downloaded from here: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java- M1-20060518/java/README.txt http://svn.apache.org/repos/asf/incubator/tuscany/tags/java- M1-20060518/java/GettingStarted.htm I tested the binary and source distributions in the following environments: Redhat Enterprise Linux 4 - Java JDK 5.0 update 06 - Maven 2.0.4 - Apache Ant 1.6.5 Windows XP SP2 - Java JDK 5.0 update 06 - Maven 2.0.4 - Apache Ant 1.6.5 Please vote to publish the Milestone 1 release distributions. Please take some time to download the distributions, review them and test them in your environment before voting. The vote is open for the next 72 hours, please vote by Sunday May 21, 4pm PDT. At least three +1 votes are required, and only the votes from Tuscany committers are binding. If the majority of all votes is positive, I will send a summary of that vote to the Incubator's general list to formally request the Incubator PMC to approve the Tuscany Milestone 1 release. For your reference the Incubator release policy guidelines are available at http:// incubator.apache.org/incubation/Incubation_Policy.html#Releases. -- Jean-Sebastien - 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: [jira] Updated: (TUSCANY-415) Add a Spring container to Tuscany so that Spring beans can be used as an implementation for SCA components
Hi Raymond, I took a look at the implementation and have a few observations: - It appears that a Spring application context is created for each method on a bean. Was this intentional, since I would have thought that a Spring application context would be created per composite? In other words, for a module, there would be one Spring application context with many Spring beans in it. This approach would allow an application developer to use Spring to wire their beans together. The per method approach won't allow for this type of wiring. - The above also leads to operations being dispatched to different bean instances, which complicates Spring semantics since it also has the concept of singleton, request and session scopes where operations are routed to particular instances. - I'm not sure we need a component type file (or at least it shouldn't be required). I believe most assembly information can be introspected from the Spring ApplicationContext, BeanContext, and BeanWrapper. In the spec group we have started to discuss Spring integration and have taken the approach of having a Spring application context modeled as a composite. Perhaps we could align around that? I'm happy to help out so if you want to commit it to the sandbox we can look at together. Jim On May 22, 2006, at 1:08 PM, Raymond Feng (JIRA) wrote: [ http://issues.apache.org/jira/browse/TUSCANY-415?page=all ] Raymond Feng updated TUSCANY-415: - Attachment: tuscany-container-spring.zip Here's a prototype which allows Tuscany consumes components implemented as a Spring bean. Add a Spring container to Tuscany so that Spring beans can be used as an implementation for SCA components - - Key: TUSCANY-415 URL: http://issues.apache.org/jira/browse/TUSCANY-415 Project: Tuscany Type: New Feature Versions: Java-Mx Reporter: Raymond Feng Assignee: Raymond Feng Fix For: Java-Mx Attachments: tuscany-container-spring.zip -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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: [jira] Updated: (TUSCANY-415) Add a Spring container to Tuscany so that Spring beans can be used as an implementation for SCA components
Hi Raymond, That won't be able to make that due to other calls. Would 11PST work for people to discuss Spring? Jim On May 23, 2006, at 9:25 AM, Raymond Feng wrote: Sorry, I meant to have the IRC chat at 8:30am PDT tomorrow. Hope it works for all. Yes, I'm looking into the refactored Groovy now. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, May 23, 2006 9:20 AM Subject: Re: [jira] Updated: (TUSCANY-415) Add a Spring container to Tuscany so that Spring beans can be used as an implementation for SCA components Hi Raymond, IRC is best. This morning I had the SCA spec meeting so this time wouldn't work. Also, it would be good if you could review the Groovy stuff prior. I'm around at 11PST or 1PST for those interested. On the IRC we can discuss some of the approach to Spring we have been thinking about for the spec. Jim On May 23, 2006, at 9:05 AM, Raymond Feng wrote: Good point. I propose that we have an IRC chat on this topic at 8:30am-9:30am PST. Does the time slot work for you? Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, May 23, 2006 8:49 AM Subject: Re: [jira] Updated: (TUSCANY-415) Add a Spring container to Tuscany so that Spring beans can be used as an implementation for SCA components I expect there will be a lot of people likely interested in this, both in Spring and also whats going on in the sandbox, so please could these discussion be done openly. Thanks, ...ant On 5/23/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Jim. Sure, I'll check out the refactored core/groovy container and try to upgrade the Spring prototype over with your help. I'm available tomorrow, do you prefer to have a face-to-face discussion or IRC? Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, May 23, 2006 12:19 AM Subject: Re: [jira] Updated: (TUSCANY-415) Add a Spring container to Tuscany so that Spring beans can be used as an implementation for SCA components Hi Raymond, Can you take a look at the groovy refactor I did in the sandbox under jboynes? I think we can use this as a starting point for integrating Spring into the refactored core. Ideally, I would like to have service and reference wires tied directly into the Spring AOP infrastructure so we can avoid a reflective hop as well as take advantage of their programming model. Also, I'd like to ditch the notion of component type so we can work with a pure Spring model. I should be around tomorrow to discuss. Jim On May 22, 2006, at 9:58 PM, Raymond Feng (JIRA) wrote: [ http://issues.apache.org/jira/browse/TUSCANY-415? page=all ] Raymond Feng updated TUSCANY-415: - Attachment: tuscany-container-spring-v2.zip Here's the updated version with the following changes: 1) Rebased to Spring 2.0-m4. 2) Added support to invoke SCA services from Spring using the extensible XML configuration Add a Spring container to Tuscany so that Spring beans can be used as an implementation for SCA components --- -- - Key: TUSCANY-415 URL: http://issues.apache.org/jira/browse/TUSCANY-415 Project: Tuscany Type: New Feature Versions: Java-Mx Reporter: Raymond Feng Assignee: Raymond Feng Fix For: Java-Mx Attachments: tuscany-container-spring-v2.zip, tuscany- container- spring.zip -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --- -- 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] --- -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail
Re: svn commit: r409076 - in /incubator/tuscany/sandbox/jboynes/sca/containers/container.spring: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/
Hi Raymond, Comments inline... On May 24, 2006, at 9:30 AM, Raymond Feng wrote: Hi, Jim/Jeremy. I don't see XXXImplementationLoader (except SystemImplementationLoader) any more in the sandbox code. Are they just not implmented or do we now have a new model to populate the implementation metadata based on the bean properties for the implementation class? Jeremy is working on this so I'll let him explain...basically there are some loaders in there but others need to be added. I don't see TuscanyRuntime either, what's the new way to bootstrap Tuscany? Jeremy has a tighter bootstrap and deployment mechanism. Again, I'll let him explain. Sorry to ask questions on the sandbox code, but it would be really helpful for me to understand the new contract. No need to say sorry - these are all good questions to be asking. I'm probably going to be more useful answering questions about the simplified extension model, scope containers, etc. so feel free to ask any questions as they arise. Jim Thanks, Raymond - Original Message - From: [EMAIL PROTECTED] To: tuscany-commits@ws.apache.org Sent: Tuesday, May 23, 2006 10:57 PM Subject: svn commit: r409076 - in /incubator/tuscany/sandbox/ jboynes/sca/containers/container.spring: ./ src/ src/main/ src/main/ java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/ org/apache/tuscany/ src/main/java/org/apache/tuscany/container/ src... Author: jmarino Date: Tue May 23 22:57:33 2006 New Revision: 409076 URL: http://svn.apache.org/viewvc?rev=409076view=rev Log: Spring integration strawman based on Raymond's implementation ported to core2 Added: incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ LICENSE.txt (with props) incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ README.txt (with props) incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ pom.xml (with props) incubator/tuscany/sandbox/jboynes/sca/containers/ container.spring/src/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/main/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/main/java/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/main/java/org/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/main/java/org/apache/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/main/java/org/apache/tuscany/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/main/java/org/apache/tuscany/container/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/main/java/org/apache/tuscany/container/spring/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/main/java/org/apache/tuscany/container/spring/ SpringCompositeContext.java incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/main/java/org/apache/tuscany/container/spring/SpringInvoker.java incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/main/resources/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/test/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/test/java/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/test/java/org/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/test/java/org/apache/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/test/java/org/apache/tuscany/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/test/java/org/apache/tuscany/container/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/test/java/org/apache/tuscany/container/spring/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/test/java/org/apache/tuscany/container/spring/ SpringInvocationTestCase.java incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/test/java/org/apache/tuscany/container/spring/ SpringReferenceTestCase.java incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/test/java/org/apache/tuscany/container/spring/mock/ incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/test/java/org/apache/tuscany/container/spring/mock/TestBean.java incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/test/java/org/apache/tuscany/container/spring/mock/ TestBeanImpl.java incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ src/test/resources/ Added: incubator/tuscany/sandbox/jboynes/sca/containers/ container.spring/LICENSE.txt URL: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/ jboynes/sca/containers/container.spring/LICENSE.txt? rev=409076view=auto = = --- incubator/tuscany/sandbox/jboynes/sca/containers/ container.spring/LICENSE.txt
Spring integration chat transcript
jmarino: so Raymond, I checked in some skeletal code last night [11:15am] rfeng: yes, I did a brief reading [11:16am] jmarino: k good .did you also have a chance to take a look at the Groovy extension? [11:16am] rfeng: so the basic idea is to model a set of spring beans as a composite? [11:16am] rfeng: yes [11:16am] ant_away is now known as ant_. [11:16am] jmarino: yes [11:16am] jmarino: the spring beans will be in a composite [11:17am] jmarino: Spring 2 has a namespace handler as well... [11:17am] rfeng: Can a SCA component wire to a spring bean in the composite? [11:17am] jmarino: this can be used to notify the SCA runtime to prepare a service or reference3 [11:17am] rfeng: yes, I added that support in the 2nd patch [11:17am] jmarino: reference [11:17am] jmarino: how does it work? [11:18am] jmarino: no an SCA component cannot wire directly to a bean.. that would violate SCA [11:18am] rfeng: basically, similar as our StaxElementLoader + ObjectFactory [11:18am] jmarino: can you walk me through that first? [11:18am] rfeng: sure [11:18am] jmarino: we can come back to the wiring question in a sec [11:19am] rfeng: ok, let's look at this bean def: [11:19am] rfeng: bean id=helloWorld1 class=helloworld.SpringHelloWorldImpl [11:19am] rfeng: property name=name [11:19am] rfeng: valueWorld/value [11:19am] rfeng: /property [11:19am] rfeng: /bean [11:19am] rfeng: tuscany:service id=helloWorld name=JavaHelloWorldComponent / [11:19am] rfeng: the 2nd one will be handled by a tuscany namespace handler [11:20am] jmarino: so what happens? [11:21am] rfeng: the registration is done by contributing to META-INF/ spring.handlers, spring.schemas [11:21am] rfeng: when somebody call beanFactory.getBean(id) [11:22am] rfeng: the namespace handler will be invoked to provide a bean def which can be the bean itself or a factory bean [11:22am] jmarino: why is SCA involved at this stage? [11:22am] rfeng: in this case, we allow Spring to call SCA services using its own PM [11:22am] jmarino: I assume they look up helloWorld1? [11:23am] rfeng: maybe we're looking into different aspects [11:23am] jmarino: service is entryPoint for me [11:23am] jmarino: that may be the problem [11:24am] jmarino: a reference is an external service [11:24am] jmarino: so let's take another example [11:24am] rfeng: ok, let's do this way [11:24am] jmarino: I have a foo Spring bean [11:24am] rfeng: 1) SCA talks to Spring [11:24am] rfeng: 2) Spring talks to SCA [11:24am] jmarino: yes so we are starting with 2 [11:25am] rfeng: ok [11:25am] jmarino: so I have a foo bean... [11:25am] jmarino: that is wired in spring to a reference (external service) [11:25am] rfeng: ok [11:25am] jmarino: when I do getBean(foo) *Spring* returns the foo bean [11:25am] jmarino: in the process, it needs to resolve the reference [11:25am] jmarino: to bar [11:25am] rfeng: say foo requires bar (ref) [11:25am] jmarino: yes [11:26am] jmarino: at that point the spring context needs to talk to something to get bar [11:26am] rfeng: and bar is a SCA service [11:26am] jmarino: bar is an SCA reference that may be wired to something [11:26am] jmarino: it is opaque to Spring [11:26am] rfeng: sure [11:27am] jmarino: there is an SCA composite that needs to return the reference [11:27am] jmarino: Spring sees this composite as a hierarchical application context [11:27am] jmarino: Spring delegates to it to get the bar reference [11:27am] rfeng: so in spring, foo -- bar, let's assume wire by id [11:28am] rfeng: it will try to resolve the ref by calling context.getBean(bar) [11:28am] jmarino: what is calling context.getBean(bar)? [11:29am] rfeng: Spring, calling appContext.getBean(bar), right? [11:29am] jmarino: internally maybe that is how it does the resolution (at some point it does do that) [11:29am] jmarino: but we don't need to worry about that [11:30am] jmarino: the Spring app context [11:30am] jmarino: foo is in will have a parent app context... [11:30am] jmarino: set by SCA... [11:30am] jmarino: that app context will be responsibly for returning bar [11:30am] jmarino: the app context is actually the SCA composite [11:30am] rfeng: I have a slight different view [11:31am] jmarino: k shoot [11:31am] rfeng: I thought the context is the regular spring context [11:31am] jmarino: what is bar, another bean? [11:31am] rfeng: and by using the extensible XML config, modeling bar as another bean [11:31am] rfeng: with the SCA ns [11:32am] rfeng: I'm open, just try to understand your view [11:32am] jmarino: yes I've seen that approach but I'm not sure that's what we want [11:32am] jmarino: that bean will then have to resolve out to SCA anyway [11:32am] rfeng: right [11:33am] jmarino: I don't think we need two things (one in Spring, one in SCA) [11:33am] rfeng: ok [11:33am] jmarino: makes changing things tricky... [11:33am] jmarino: also I want to do something a bit different...
Re: svn commit: r409076 - in /incubator/tuscany/sandbox/jboynes/sca/containers/container.spring: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/
On May 24, 2006, at 3:04 PM, Jeremy Boynes wrote: On 5/24/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Thanks for the explanations. I can help to port/develop the implementation/componentType loaders. As the first step, I'm trying JavaImplementationLoader and JavaComponentTypeLoader. Here're a few more questions/comments: 1) ComponentTypeLoader.load(...) should take DeploymentContext in addition to Implementation. Yes - it was late last night :-) 2) LoaderRegistry doesn't have an unregisterLoader() method to unregister ComponentTypeLoader. Is it automatically removed when the ImplementationLoader is delisted? No, we need to add unregister methods here (again it was late :-) ) and on the BuilderRegistry as well 3) What's the replacement for org/apache/tuscany/core/config/** which uses to host the class like Java5ComponentTypeIntrospector? Jim added a more general annotation processing framework into core in the trunk. The component type loaders should use that for introspecting the implementation. Yea the idea with that is it's visitor based which allows people to extend it with custom processors (i.e. the runtime doesn't know about any annotations). Jeremy mentioned he was going to plug this into the load process, so when that's done we can look at how that fits into the loader work. -- Jeremy - 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: Getting list of components in a module
Yea sorry got called into other things yesterday.
We definitely don't want to cast like that since
AbstractCompositeContext is not a public API and it involves touching
internal structures. This use case brings up an interesting set of
issues. It sounds as if what you need is a management API. Related to
this, I don't think we should allow arbitrary client code to dig
around into a composite context since it's not really part of the SCA
programming model and, probably more importantly, it's a potential
security concern. So, we will probably need to define some security
mechanism. Also, what we probably want is access to runtime
artifacts, not what's in a particular SCDL, since the latter may not
be in sync with the current runtime state.
Maybe we could use this to start a discussion of what type of
management API is needed?
Jim
On May 26, 2006, at 5:08 AM, ant elder wrote:
Never did get any answer on this. Having the class below in the rhino
container works as it uses the AbstractCompositeContext package
name, but it
seesm a bit hacky:
package org.apache.tuscany.core.context.impl;
public class ComponentNamesAccessor {
public static SetString getComponentNames(ModuleContext
moduleContext)
{
if (moduleContext instanceof AbstractCompositeContext) {
MapString, ScopeContext x = ((AbstractCompositeContext)
moduleContext).scopeIndex;
return x.keySet();
}
return null;
}
}
...ant
On 5/24/06, ant elder [EMAIL PROTECTED] wrote:
Jim, this would be unmanaged code, not in a component, so it
doesn't look
like there is any API for this. The idea of TUSCANY-417 is an
interactive
JavaScript shell along the lines of what Jeremy described as a
first-class
client environment for JavaScript.
...ant
On 5/24/06, Jim Marino [EMAIL PROTECTED] wrote:
Can you explain why you need the list of components? For managed
code
(i.e. in a component) the spec defines a way to get the metadata
associated with a module.
Jim
On May 24, 2006, at 1:30 AM, ant elder wrote:
I've a J2SE client that needs to get a list of all the components
defined in
the current module, is that possible? There used to be the
getMetaData
method but thats been removed now. If there is no easy way right
now could
i add something?
...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: Question about the annotation processor framework
Hi Raymond, Jeremy is in the process of moving the annotation processing framework from trunk to sandbox/core2, which involves some refactors to the processing rules it implements to better accommodate unannotated Pojos (this was an issue with M1). Jim On May 26, 2006, at 9:38 AM, Raymond Feng wrote: Hi, Jim/Jeremy. Is the annotation processor framework already in sandbox core or do we need to port it over from the trunk, or? Based on the previous thread below, I think I'm confused here. Are you saying the processor framework has already been in the trunk so that we need to copy them over to the sandbox? I need this feature to implement JavaComponentTypeLoader. Thanks, Raymond snip 3) What's the replacement for org/apache/tuscany/core/config/ ** which uses to host the class like Java5ComponentTypeIntrospector? Jim added a more general annotation processing framework into core in the trunk. The component type loaders should use that for introspecting the implementation. Yea the idea with that is it's visitor based which allows people to extend it with custom processors (i.e. the runtime doesn't know about any annotations). Jeremy mentioned he was going to plug this into the load process, so when that's done we can look at how that fits into the loader work. snip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing changes
On May 29, 2006, at 9:34 AM, Jeremy Boynes wrote: In M1 we do not have a consistent approach on how the component type information is derived for a component implemented by a Java class. This, combined with some poor wording in the spec itself (inconsistencies, fragmentation), led to a number of bugs in the run up to M1 and I think the probability of more lurking. In an effort to resolve this I think we should change the introspection process as follows: If a .componentType sidefile exists, it provides the definitive list of the implementation's services, references and properties. We probably need to clarify the spec here since side files overlay the introspected information in the Java CI spec. This makes sense since having part of the metadata in annotations and part in a side file doesn't really make sense, or is at least very prone to error. Every operation in every service must be mapped to a public method in the implementation. The implementation need not implement the service interface (although if the interface is defined in Java then we would recommend that it did). One use case where it maybe doesn't besides mediation is a mixin but that may be a bit esoteric for applications Every reference and property in the sidefile must be mapped to an injection site in the implementation. Sites will be located in the following order: 1) a public or protected method or field identified in the sidefile 2) a public or protected method annotated with the applicable annotation 3) a public or protected field annotated with the applicable annotation 4) a public or protected setter method with the same name 5) a public or protected field with the same name For @Reference and @Property we need to be careful to use the name attribute and preserve the mappings to method or field until the point of injection as this was the cause of bugs and hacks in M1. The method or field may be defined in the class or in any superclass. Private members are no longer valid injection sites (per resolution of issue-35 in the spec group). If no sidefile exists then the component type will be derived by introspection of the implementation class. If the class or any superclass has an @Service annotation then the services are explicitly defined by that annotation. The set of services exposed will be the union of all @Service annotations in the class hierarchy. If no @Service annotation is present then the services are defined by the interfaces that are implemented by the class or its superclass and any super-interfaces thereof. This follows from below but it may be worth pointing out. If no @Remotable is present, then all services will be local. Conversely, if only @Remotable is present, then the specified interfaces will be remotable. If any interface has an @Remotable or @Service annotation then the set of services is defined as the union of all such interfaces. If no interface is annotated, then the component type will define a single service comprising all public methods that are not reference or property injection sites. If that service can be exactly mapped to an interface implemented by the class then the service interface will be defined in terms of that interface. The class need not implement the specified interfaces (although we would recommend that it should) but all methods in all interfaces must be present. If the class or any superclass has a @Property or @Reference annotation on any public or protected field or setter method, then the properties and references of the component type are defined by those annotations; no un-annotated fields and properties will be included. In absense of any @Property or @Reference annotation, the properties and references will be defined by the public and protected fields and setter methods of the class and all superclasses as follows: 1) public setter methods that are not included in any service interface 2) protected setter methods 3) public or protected fields unless there is a setter method for the same name If the type associated with the member is an array or a java.util.Collection, then the basetype will be the element type of the array or the parameterized type of the Collection, otherwise the basetype will be the member type. If the basetype is an interface with an @Remotable or @Service annotation then the member will be defined as a reference, otherwise it will be defined as a property. Yes this is good. We should also propose this as modified language to the Java CI spec Again, private members are not considered per issue-35 In M1 we captured some of this information during introspection and included it as extension elements in the component type definition. For M2, I'm going to formalize this by creating a JavaComponentType model object that allows the mapping information for the Java class to be included in the model definition. We should also formalize a way to for extenders to have custom property injectors stored
Re: Getting list of components in a module
I'd prefer we come up with a management API as that is the only
solution that will work properly. More comments inline
On May 31, 2006, at 1:25 AM, ant elder wrote:
Coming up with a new management API sounds like it will take some
time, I'd
like to be able to get at the list of components today, and then
change the
code later when The Spec Group or whoever come up with an
official API.
Seems like there's three things that could be done:
1) Use the hack that casts to the internal AbstractCompositeContext
and get
the list from that
Besides being a horrible hack that we should not encourage users to
do, this is not going to work when we deploy to a managed environment
that enforces classloader visibility and security constraints
2) Put back the getMeteData method
Even if we did this, getMetaData will not accurately reflect the
state of the runtime
3) Add a new getServiceNames method to the
org.osoa.sca.ModuleContextinterface which returns a list of the names
that are valid for the
locateService method, and implement getServiceNames in
ModuleContextImpl.
I don't think we want to modify something in an official spec package
with additional proprietary extensions. Also, we should not put that
type of API on ModuleContext as it is not a typical thing application
code would do in the SCA programming model but should instead be
available through some other runtime API that is protected by
security mechanisms
Any comments on your preferred approach or alternative suggestions?
My preferred approach is to design a management API incrementally
Thanks,
...ant
On 5/26/06, Jim Marino [EMAIL PROTECTED] wrote:
Yea sorry got called into other things yesterday.
We definitely don't want to cast like that since
AbstractCompositeContext is not a public API and it involves touching
internal structures. This use case brings up an interesting set of
issues. It sounds as if what you need is a management API. Related to
this, I don't think we should allow arbitrary client code to dig
around into a composite context since it's not really part of the SCA
programming model and, probably more importantly, it's a potential
security concern. So, we will probably need to define some security
mechanism. Also, what we probably want is access to runtime
artifacts, not what's in a particular SCDL, since the latter may not
be in sync with the current runtime state.
Maybe we could use this to start a discussion of what type of
management API is needed?
Jim
On May 26, 2006, at 5:08 AM, ant elder wrote:
Never did get any answer on this. Having the class below in the
rhino
container works as it uses the AbstractCompositeContext package
name, but it
seesm a bit hacky:
package org.apache.tuscany.core.context.impl;
public class ComponentNamesAccessor {
public static SetString getComponentNames(ModuleContext
moduleContext)
{
if (moduleContext instanceof AbstractCompositeContext) {
MapString, ScopeContext x =
((AbstractCompositeContext)
moduleContext).scopeIndex;
return x.keySet();
}
return null;
}
}
...ant
On 5/24/06, ant elder [EMAIL PROTECTED] wrote:
Jim, this would be unmanaged code, not in a component, so it
doesn't look
like there is any API for this. The idea of TUSCANY-417 is an
interactive
JavaScript shell along the lines of what Jeremy described as a
first-class
client environment for JavaScript.
...ant
On 5/24/06, Jim Marino [EMAIL PROTECTED] wrote:
Can you explain why you need the list of components? For managed
code
(i.e. in a component) the spec defines a way to get the metadata
associated with a module.
Jim
On May 24, 2006, at 1:30 AM, ant elder wrote:
I've a J2SE client that needs to get a list of all the
components
defined in
the current module, is that possible? There used to be the
getMetaData
method but thats been removed now. If there is no easy way
right
now could
i add something?
...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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: support on WebLogic and WebSphere?
Hi John, Tuscany M1 should be able to run in any Servlet container. We have done a deep integration with Tomcat for an out-of-the-box experience. Moving forward, we plan to support additional platforms. If you really want to deploy to WebLogic or Websphere, the easiest mechanism would be to use Servlet filters. The tricky part is going to be placing third-party jars such as Axis in the right classloader. If you are interested in this, I could provide help to you on WebLogic or general J2EE things (others I am sure can help out on specific Websphere issues). Barring that, at some point we'll also provide easier deployment on Websphere and WebLogic in the future. Jim On Jun 1, 2006, at 8:41 AM, Langley, John wrote: This is a cross post from the tuscany-user mailing list... where it seemed to get no answer. I suspect the developers here would know off the top of their heads about the practicality of running Tuscany M1 release in either Weblogic 9.x or WebSphere 6.x Another interesting digression would be a brief comparison of how SCA is supported today in WebSphere with what Tuscany is providing. Thanks in advance, sorry if I missed these factoids somewhere else. Langley -Original Message- From: Langley, John [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 31, 2006 8:55 AM To: tuscany-user@ws.apache.org Subject: support on WebLogic and WebSphere? Hello, I'm a newbie who's quite interested in the potential of Tuscany but my constraints for adoption is that there is support on WebLogic and WebSphere servers. Has anyone gotten Tuscany code working on 9.x Weblogic or 6.x WebSphere? Thanks in advance for insights and opinions... Langley - 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]
Recursive core architectural overview
Hi, There has been some mention offline of Jeremy and I providing an overview of changes to the SCA specifications and related recursive core architecture work going on in the sandbox, perhaps Wednesday. I'm happy to do this, however, I'm a bit concerned that since this has not been brought up on the list interested people may not be able to attend on short notice. Also, a time has not been mentioned. I propose 9PST-11PST, using a combination of Web-Ex and toll-free dial- in, which will be provided later. If interested people cannot make that time, please speak up so we can arrange an alternate (please don't hesitate to do so, even if you are the only one). For the format, we will have an overview presentation which will cover the basics but we want to leave the majority of time open for questions and discussion. To facilitate this, please review the code (unit tests are a good place to start): http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ - The root location http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/spi/ - Defines the extension API for the runtime. There are different degrees of extension, the most common being found in the extensions package - The goal of this project is to clearly demarcate the runtime extension mechanism. Extensions themselves should reference these packages directly, as opposed to the runtime implementation (core2). http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ core2/ - The actual runtime implementation http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ containers/container.java/ - The Java CI model extension. There are other experimental Groovy and Spring extensions as well Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
Yes this would be appreciated. Can you make sure it's in a common graphic format - I'm too cheap to shell out the $$ for a UML tool ;-) Jim On Jun 5, 2006, at 12:29 PM, Jeremy Boynes wrote: Raymond Feng wrote: Hi, I have created some basic slides and UML diagrams when I looked into the sandbox code last week (I need to do some adjustments since more refactorings were checked in). I can upload them into the wiki and Jim/Jeremy can verify to see if it's helpful. Thanks - that would be appreciated. -- Jeremy - 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: Recursive core architectural overview
I'm out all next week so it sounds as if Friday is the best time for most people. Jim On Jun 6, 2006, at 10:42 AM, Rick wrote: I like to second all of what Ant wrote and also Ken Tam asked if it could not be delayed till next week. I'd like to be up to speed and just a few days more would help to digest it all to be more informed, but I'll go with Friday if that's what it is. ant elder wrote: I agree 100% with Ken, could you give just a little more information about whats going on here? That email just gives hints - there's been some SCA spec changes, there's some code in the the sandbox for recursive core architecture work and to clearly demarcate the runtime extension mechanism. What are the spec changes, are there any new spec documents people can review? Is there anything else that has changed from the M1 release code to whats in the sandbox? Whats the state of the sandbox code, does it work, are there any samples, does bigbank run? What is the intention for the future of the sandbox code? It sounds like we're being asked to just go look at some code in the sandbox and work all this out for ourselves. There's a lot of people listening who have no idea whats going on, so some more detailed background information would really help. Friday is bad for me I can't make anything much after 9am PDT, same for Mondays after 5:30BST, but i'll fit in with most times any other day. ...ant On 6/5/06, Kenneth Tam [EMAIL PROTECTED] wrote: I am very interested in this, but the short notice also concerns me. Can we push this out to at least the end of the week (say Friday?) or sometime next week so that more people on the list get a chance to find out about it and fit it into their schedules? Also, Jim Jeremy -- if you guys have anything in the way of explanatory material that you could circulate on the list/wiki before the presentation, I think that would be very useful.. certainly I could use a little more context to help with my own browsing. thanks, k On 6/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim Marino wrote: Hi, There has been some mention offline of Jeremy and I providing an overview of changes to the SCA specifications and related recursive core architecture work going on in the sandbox, perhaps Wednesday. I'm happy to do this, however, I'm a bit concerned that since this has not been brought up on the list interested people may not be able to attend on short notice. Also, a time has not been mentioned. I propose 9PST-11PST, using a combination of Web-Ex and toll-free dial- in, which will be provided later. If interested people cannot make that time, please speak up so we can arrange an alternate (please don't hesitate to do so, even if you are the only one). Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or after. -- Jeremy - 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] - 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: Recursive core architectural overview
Good question... In the spec group, one of the major changes we are currently undertaking is a move to a recursive model where components can either be leaf-types (atomic) or composite, in which case they may contain children. In previous versions of the spec we had a two-level model (module components and components which were leaf-types). The recursive model simplifies a great deal since it eliminates a number of unnecessary concepts. For example, components used to offer services and have references while module components offered entry points and had external services. Since there is a common type, component, we can dispense with the separate concepts of entry point and external service and just call them service (~entry point) and reference (~external service). I think this makes sense from a conceptual standpoint since a composite component may have a service bound to some protocol/transport combination such as SOAP/HTTP while a service on a POJO may be thought of as having a shared memory/by- reference binding. Besides making the implementation more concise, It also makes slideware easier since we have the same picture at different levels :-) In any event, this was one of the topics we were intending to cover on the call. I think this is a good question specifically because I believe the coordination between the spec collaboration and the Tuscany community could be a lot better. This partly arises from the fact that the people such as myself and Jeremy who wear both hats are swamped with work and things sometimes get delayed. Another reason for the less- than-ideal situation is that a collaboration model between the spec group and Tuscany has not been put in place. Regarding the latter, I believe there are some systemic improvements we can make such as not having to channel issues through Jeremy or myself as well as having more defined input mechanisms between the two groups. The spec group is aware of the issue as well so I think it would be fruitful for us to come up with some concrete proposals we could discuss with them. Ideas? Jim On Jun 6, 2006, at 2:18 PM, Paul Fremantle wrote: By the way can someone explain what the term Recursive Core Architecture means? Paul On 6/6/06, Jim Marino [EMAIL PROTECTED] wrote: It looks as if we have the choice of Thursday or Friday this week, or rescheduling for two weeks. I'd prefer we do it this week. Jim On Jun 6, 2006, at 1:28 PM, Paul Fremantle wrote: Next week would be better for me. I'm landing home from the US on Friday and 8-10PST is 4-6pm on Friday evening which aint popular in blighty :-) Paul On 6/6/06, Jim Marino [EMAIL PROTECTED] wrote: I'm out all next week so it sounds as if Friday is the best time for most people. Jim On Jun 6, 2006, at 10:42 AM, Rick wrote: I like to second all of what Ant wrote and also Ken Tam asked if it could not be delayed till next week. I'd like to be up to speed and just a few days more would help to digest it all to be more informed, but I'll go with Friday if that's what it is. ant elder wrote: I agree 100% with Ken, could you give just a little more information about whats going on here? That email just gives hints - there's been some SCA spec changes, there's some code in the the sandbox for recursive core architecture work and to clearly demarcate the runtime extension mechanism. What are the spec changes, are there any new spec documents people can review? Is there anything else that has changed from the M1 release code to whats in the sandbox? Whats the state of the sandbox code, does it work, are there any samples, does bigbank run? What is the intention for the future of the sandbox code? It sounds like we're being asked to just go look at some code in the sandbox and work all this out for ourselves. There's a lot of people listening who have no idea whats going on, so some more detailed background information would really help. Friday is bad for me I can't make anything much after 9am PDT, same for Mondays after 5:30BST, but i'll fit in with most times any other day. ...ant On 6/5/06, Kenneth Tam [EMAIL PROTECTED] wrote: I am very interested in this, but the short notice also concerns me. Can we push this out to at least the end of the week (say Friday?) or sometime next week so that more people on the list get a chance to find out about it and fit it into their schedules? Also, Jim Jeremy -- if you guys have anything in the way of explanatory material that you could circulate on the list/wiki before the presentation, I think that would be very useful.. certainly I could use a little more context to help with my own browsing. thanks, k On 6/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim Marino wrote: Hi, There has been some mention offline of Jeremy
Re: UML diagrams and a draft PDF document for the sandbox core are uploaded to Tuscany Wiki
Thanks Raymond for taking this on. I have made to refactors today so could you regenerate (I hope you didn't have to do the model by hand)? The two basic changes I did are: 1. Rename ScopeContext to ScopeContainer since it contains component implementation instances 2. Internalized InstanceWrapper (tracks implementation instance lifecycle) to the scope container implementations. This means that component type extensions will be able to implement one less class. As part of this refactor, I also renamed PojoImplementationWrapper to ImplementationWrapperImpl since it is generic and not specific to POJOs. Thanks, Jim On Jun 6, 2006, at 2:46 PM, Raymond Feng wrote: Hi, I uploaded a draft PDF document together with a set of UML class diagrams to Tuscany wiki @ http://wiki.apache.org/ws/Tuscany/ TuscanyJava/SandboxCore. Please note these documents are work in progress and not guaranteed to be accurate and complete. They are produced based on my understanding of the new core code developed by Jim and Jeremy in the sandbox. It's subject to review and revision. I hope it will be hopeful for you to understand the code. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
The IP is royalty free and the license is printed in the body of the specifications. The specifications can be found at members' sites,e.g. http://dev2dev.bea.com/pub/a/2005/11/sca.html. On membership, I'm copying Mike Edwards since he is better at explaining that process than myself. Jim On Jun 7, 2006, at 7:22 AM, Paul Fremantle wrote: Jim That's very interesting. It sounds similar to some work going on in Synapse where we have a recursive composition model. I think one of the key questions in forging greater links between Tuscany and the spec group is what the IP and membership regulations around the spec group? Is there a web page you can point me at that outlines those? Paul On 6/7/06, Jim Marino [EMAIL PROTECTED] wrote: Good question... In the spec group, one of the major changes we are currently undertaking is a move to a recursive model where components can either be leaf-types (atomic) or composite, in which case they may contain children. In previous versions of the spec we had a two-level model (module components and components which were leaf-types). The recursive model simplifies a great deal since it eliminates a number of unnecessary concepts. For example, components used to offer services and have references while module components offered entry points and had external services. Since there is a common type, component, we can dispense with the separate concepts of entry point and external service and just call them service (~entry point) and reference (~external service). I think this makes sense from a conceptual standpoint since a composite component may have a service bound to some protocol/transport combination such as SOAP/HTTP while a service on a POJO may be thought of as having a shared memory/by- reference binding. Besides making the implementation more concise, It also makes slideware easier since we have the same picture at different levels :-) In any event, this was one of the topics we were intending to cover on the call. I think this is a good question specifically because I believe the coordination between the spec collaboration and the Tuscany community could be a lot better. This partly arises from the fact that the people such as myself and Jeremy who wear both hats are swamped with work and things sometimes get delayed. Another reason for the less- than-ideal situation is that a collaboration model between the spec group and Tuscany has not been put in place. Regarding the latter, I believe there are some systemic improvements we can make such as not having to channel issues through Jeremy or myself as well as having more defined input mechanisms between the two groups. The spec group is aware of the issue as well so I think it would be fruitful for us to come up with some concrete proposals we could discuss with them. Ideas? Jim On Jun 6, 2006, at 2:18 PM, Paul Fremantle wrote: By the way can someone explain what the term Recursive Core Architecture means? Paul On 6/6/06, Jim Marino [EMAIL PROTECTED] wrote: It looks as if we have the choice of Thursday or Friday this week, or rescheduling for two weeks. I'd prefer we do it this week. Jim On Jun 6, 2006, at 1:28 PM, Paul Fremantle wrote: Next week would be better for me. I'm landing home from the US on Friday and 8-10PST is 4-6pm on Friday evening which aint popular in blighty :-) Paul On 6/6/06, Jim Marino [EMAIL PROTECTED] wrote: I'm out all next week so it sounds as if Friday is the best time for most people. Jim On Jun 6, 2006, at 10:42 AM, Rick wrote: I like to second all of what Ant wrote and also Ken Tam asked if it could not be delayed till next week. I'd like to be up to speed and just a few days more would help to digest it all to be more informed, but I'll go with Friday if that's what it is. ant elder wrote: I agree 100% with Ken, could you give just a little more information about whats going on here? That email just gives hints - there's been some SCA spec changes, there's some code in the the sandbox for recursive core architecture work and to clearly demarcate the runtime extension mechanism. What are the spec changes, are there any new spec documents people can review? Is there anything else that has changed from the M1 release code to whats in the sandbox? Whats the state of the sandbox code, does it work, are there any samples, does bigbank run? What is the intention for the future of the sandbox code? It sounds like we're being asked to just go look at some code in the sandbox and work all this out for ourselves. There's a lot of people listening who have no idea whats going on, so some more detailed background information would really help. Friday is bad for me I can't make anything much after 9am PDT, same for Mondays after 5:30BST, but i'll fit in with most times any other day
Re: UML diagrams and a draft PDF document for the sandbox core are uploaded to Tuscany Wiki
Great - thanks a bunch! On Jun 7, 2006, at 10:19 AM, Raymond Feng wrote: Hi, Jim. The UML diagrams on the wiki page (http://wiki.apache.org/ws/ Tuscany/TuscanyJava/SandboxCore) are now updated to reflect your changes. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, June 06, 2006 8:25 PM Subject: Re: UML diagrams and a draft PDF document for the sandbox core are uploaded to Tuscany Wiki Thanks Raymond for taking this on. I have made to refactors today so could you regenerate (I hope you didn't have to do the model by hand)? The two basic changes I did are: 1. Rename ScopeContext to ScopeContainer since it contains component implementation instances 2. Internalized InstanceWrapper (tracks implementation instance lifecycle) to the scope container implementations. This means that component type extensions will be able to implement one less class. As part of this refactor, I also renamed PojoImplementationWrapper to ImplementationWrapperImpl since it is generic and not specific to POJOs. Thanks, Jim On Jun 6, 2006, at 2:46 PM, Raymond Feng wrote: Hi, I uploaded a draft PDF document together with a set of UML class diagrams to Tuscany wiki @ http://wiki.apache.org/ws/Tuscany/ TuscanyJava/SandboxCore. Please note these documents are work in progress and not guaranteed to be accurate and complete. They are produced based on my understanding of the new core code developed by Jim and Jeremy in the sandbox. It's subject to review and revision. I hope it will be hopeful for you to understand the code. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
Paul, I'm going to ask others more versed in legalities to jump in regarding your questions...I do have a quick question though: how does Geronimo handle this as I believe the JCP IP rules are far more restrictive than those associated with the specs? Thanks, Jim On Jun 7, 2006, at 11:41 AM, Paul Fremantle wrote: Simon I'm have concerns about both these approaches. Regarding the first proposal, there might be IP or other requirements that joining the spec collaboration involves that might not be suitable for some Tuscany committers. I'm not clear what is involved in joining the spec group but I'm guessing based on your note that there are possibly non-disclosure agreements and IP agreements. I'm concerned that there might end up two classes of committers - those with access to the spec group and those without. Regarding the second proposal, this seems a little anti-thetical to the Apache approach... where generally everything is done in the open. I'm also concerned about the implications of committing code to Tuscany based on a private mailing list. The ICLA states: You represent that you are legally entitled to grant the above license. There are also other related clauses. What I'm concerned is that committers might be committing code that is based on things they learnt under a non-disclosure agreement. I'm sure none of these issues is insurmountable, but I think we need to have a clear approach before we try and exit incubation. It might also be worth consulting the legal team at Apache once we have a clearer idea of what the issues are. Paul On 6/7/06, Simon Nash [EMAIL PROTECTED] wrote: I can think of a couple of options that might work. 1. All Tuscany participants could join the spec collaboration and get first-hand information on issues and agreed changes. 2. Set up a private Apache mailing list on which non-public spec information could be distributed and discussions could take place. I think the second option is better, since it's probably easier for people not working for members of the collaboration to get on a private Apache list than to sign up as collaboration members. This will require agreement from the collaboration team, since it would open up access to this information to people who have not signed the formal collaboration agreement. Maybe there could be a lighter-weight open source version of the collaboration agreement designed for this purpose. Simon Jim Marino wrote: Good question... In the spec group, one of the major changes we are currently undertaking is a move to a recursive model where components can either be leaf-types (atomic) or composite, in which case they may contain children. In previous versions of the spec we had a two-level model (module components and components which were leaf-types). The recursive model simplifies a great deal since it eliminates a number of unnecessary concepts. For example, components used to offer services and have references while module components offered entry points and had external services. Since there is a common type, component, we can dispense with the separate concepts of entry point and external service and just call them service (~entry point) and reference (~external service). I think this makes sense from a conceptual standpoint since a composite component may have a service bound to some protocol/ transport combination such as SOAP/HTTP while a service on a POJO may be thought of as having a shared memory/by- reference binding. Besides making the implementation more concise, It also makes slideware easier since we have the same picture at different levels :-) In any event, this was one of the topics we were intending to cover on the call. I think this is a good question specifically because I believe the coordination between the spec collaboration and the Tuscany community could be a lot better. This partly arises from the fact that the people such as myself and Jeremy who wear both hats are swamped with work and things sometimes get delayed. Another reason for the less- than- ideal situation is that a collaboration model between the spec group and Tuscany has not been put in place. Regarding the latter, I believe there are some systemic improvements we can make such as not having to channel issues through Jeremy or myself as well as having more defined input mechanisms between the two groups. The spec group is aware of the issue as well so I think it would be fruitful for us to come up with some concrete proposals we could discuss with them. Ideas? Jim On Jun 6, 2006, at 2:18 PM, Paul Fremantle wrote: By the way can someone explain what the term Recursive Core Architecture means? Paul On 6/6/06, Jim Marino [EMAIL PROTECTED] wrote: It looks as if we have the choice of Thursday or Friday this week, or rescheduling for two weeks. I'd prefer we do it this week. Jim
Re: Recursive core architectural overview
On Jun 7, 2006, at 2:43 PM, Jeremy Boynes wrote: Paul Fremantle wrote: Jim Its a great question. I think the answer is that they stick to published specs, which is what I was expecting Tuscany to do given the closed nature of the spec group. I'll ask around to find out. Geronimo has private lists for stuff under NDA and has had various people on different expert groups (e.g. a couple of us were on JSR-220). In general, there are a lot of Apache projects that work with the JCP and deal with the closed nature of JSRs - Tomcat, Portal, Axis come to mind. Apache projects also provide functions over and above published specifications, features that are relevant to the users and developers of the project. Sometimes those innovations get picked up and included by specification bodies - open source shaping the future. We just had an example of this with Tuscany where thoughts on a recursive structure (which have been in mind since before we came to Apache) contributed to a significant change in the specification. Remember too that the SCA specifications are still preliminary - they could be compared to Community or Early Draft review stages in the JCP. The expectation should be that they will change - I actually expected changes would be happening faster than they are. As a project, we can continue to implement a now-obsolete draft from last year, or we can innovate, influence and track the specs to the greatest extent that we can. As additional background, there will be another spec refresh with the recursive model in a matter of weeks. I'd like to see us have support for that as soon as possible, particularly since many of the ideas were worked on here as far back as December. I'm participating here because I want to build some software that makes it easier to build and run applications in the new, complex, service-enabled world; I think the rest of the community has similar motives. The SCA spec contains a good codification of some of the challenges in this space and proposes solutions for them through its programming and assembly models. In the end though it's code that talks and whether we are successful will depend on what we as a community build rather than what the spec says. -- Jeremy - 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]
Friday SCA spec and recursive core update
Separating this into a new thread since the other one has a new ongoing topic... Some of the people are going to have trouble staying past 9.30PST for the call to cover the new spec changes and core design. So, we are going to have the meeting run from 7.30PST-9.30PST. I will circulate dial-in information tomorrow once I deal with a few logistical issues. Sorry to the left-coasters and people over in Europe...People are obviously welcome to dial-in late or leave early. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN Properties
I think Jeremy is being charitable in taking some of the blame; it was mostly my (new) machine. Thanks for fixing. Jim On Jun 8, 2006, at 4:31 PM, Jeremy Boynes wrote: I did a big checkin Saturday to fix problems with SVN properties that were incorrectly set due to incorrect configurations on some of Jim and my machines. I have a feeling we may not be alone so I would like ask folks to check their default settings, especially for svn:keywords which should be set to Rev Date and not Rev,Date (space not comma) Thanks -- Jeremy - 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]
Slide format for Today's call
Sorry I will post in a more accessible format ASAP. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slides for Today's call [PDF Format]
On Jun 9, 2006, at 7:42 AM, Jim Marino wrote: tuscany.architecture.v4.ppt - 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: Slides for Today's call [PDF Format]
Sorry - trouble this am my time :-) Now Attached. Jim On Jun 9, 2006, at 7:50 AM, Jim Marino wrote: On Jun 9, 2006, at 7:42 AM, Jim Marino wrote: tuscany.architecture.v4.ppt - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subject: SCA Spec Update and Recursive Core presentation
Hi, Thanks everyone who attended today's call. The slides have been checked into SVN at: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/doc We would appreciate any comments, questions, feedback, and suggestions on the session, and more importantly, the sandbox code at: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ Most importantly, we would appreciate help from those interested. There are a bunch of areas in particular that need a lot of work, including: - Model loading. Jeremy is working on annotations and bootstrapping. - Spring support. Ken is moving this along. - Binding integration. I'm looking at getting the Celtix stuff working. Raymond is working on SDO integration. - Component implementation types. There is a start of a Groovy implementation donated by Meeraj which has partially been ported - Transport binding integration. I checked in the skeleton of an HTTP Jetty transport. - Alternative host environments. I started a skeleton project for Equinox as a way to begin tackling OSGI deployment as well as the inevitable classloader problems we will encounter in restrictive container environments - Policy in general: transactions, security, etc. - Policy and wire optimization. I have started work here so please sync with me. - Less fun work includes Javadoc and testcases. Contributions building these areas out would be greatly appreciated; just knowing where we are lacking would be very valuable. - Integration test framework. We discussed having this in the past but not much work has been done. These are just the areas at the front of my mind. If you see other things you want to work on, jump on in. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Checkstyle sandbox commit review/thoughts....
Yea thanks for pointing this out. I stuck things there since I was having a bit of trouble getting checkstyle picked up by the lower projects and figured I wait for your help to sort it out :) One thing is a relaxed some of the checks (e.g. line length to 120, parameter names are allowed to mask field names). I'm also getting a bunch of these types of errors and can't figure out what setting it is: TuscanyRuntimeException.java:15:5: warning: The field 'identifier' must be declared final Any ideas? Some comments inline too... On Jun 10, 2006, at 12:43 AM, Daniel Kulp wrote: Jim, Couple notes about your checkstyle commit. (I know it's still early and you are just beginning to add it, but reviews are good anytime. :-) 1) You shouldn't need to put the tuscany-checkstyle.xml file into each directory.The purpose of the buildtools module is to create a jar that holds that file which we can then depend on in the other places it's needed. The checkstyle plugin should then be able to pull it from that jar. This method of doing it was taken from the maven checkstyle tips: http://maven.apache.org/plugins/maven-checkstyle-plugin/tips.html 2) Also, I had put it top level (in java, not sca) as I thought it would make sense to eventually get the ENTIRE tuscany project on one set of rules, including the specs and SDO projects.Not a huge deal though.I was just hoping to foster a more across the entire tuscany project type of thing. For the SCA specs I don't see problem doing this. For the others such as SDO and DAS, I think that is up to them. 3) The pmd plugin config could also be pushed into the pluginManagement section of the top pom. It would make for less copy/paste into each sub-pom.Actually, if it wasn't for eclipse, the .ruleset file could go into the buildtools module as tuscany-ruleset.xml and sucked in from there like checkstyle. I have a workaround for the eclipse issue by creating a special mvn -Psetup.eclipse profile that would need to be used instead of mvn eclipse:eclipse. Not sure we want that though. (basically, the profile would suck the tuscany-pmd-ruleset.xml file out of the buildtools jar and create the .ruleset on the fly. It can also create the .pmd and .checkstyle files on the fly so they aren't checked in in every directory. ) OK, A few notes, not a couple. :-) Thanks. I'm going to try and sort these out today if I get time, if not next week since I'm flying out tomorrow. I'll probably bug you when I get stuck. Nice job though. I'm glad to see the code becoming a bit cleaner and more consistent. Enjoy! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] - 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: Subject: SCA Spec Update and Recursive Core presentation
I also forgot one big area that needs work: Management. This is a topic that is starting to come up in the spec group and it would be great if we could propose some ideas to them. Jim On Jun 9, 2006, at 2:48 PM, Jim Marino wrote: Hi, Thanks everyone who attended today's call. The slides have been checked into SVN at: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/doc We would appreciate any comments, questions, feedback, and suggestions on the session, and more importantly, the sandbox code at: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ Most importantly, we would appreciate help from those interested. There are a bunch of areas in particular that need a lot of work, including: - Model loading. Jeremy is working on annotations and bootstrapping. - Spring support. Ken is moving this along. - Binding integration. I'm looking at getting the Celtix stuff working. Raymond is working on SDO integration. - Component implementation types. There is a start of a Groovy implementation donated by Meeraj which has partially been ported - Transport binding integration. I checked in the skeleton of an HTTP Jetty transport. - Alternative host environments. I started a skeleton project for Equinox as a way to begin tackling OSGI deployment as well as the inevitable classloader problems we will encounter in restrictive container environments - Policy in general: transactions, security, etc. - Policy and wire optimization. I have started work here so please sync with me. - Less fun work includes Javadoc and testcases. Contributions building these areas out would be greatly appreciated; just knowing where we are lacking would be very valuable. - Integration test framework. We discussed having this in the past but not much work has been done. These are just the areas at the front of my mind. If you see other things you want to work on, jump on in. Jim - 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: Checkstyle sandbox commit review/thoughts....
FYI Dan I switched awhile back from Eclipse (I was a long-time user) to IntelliJ and I love it. It takes a bit getting used to the key mappings but the refactoring capabilities are just awesome. I'm also amazed at the things it can catch from analyzing code. And even better, JetBrains offers free open source licenses so you can pick one up if you like it. Jim On Jun 10, 2006, at 2:44 PM, Daniel Kulp wrote: Jeremy, Dan, what's the Eclipse issue with ruleset? Is it a Eclipse extension thing or something that would impact the main build? The eclipse PMD plugin has some strange design flaws (IMO) that make it harder to use than it really should be. The main restriction is that there isn't really a way to set a global ruleset that can be referenced by the project. For example, with the Checkstyle plugin, in our workspace we can create a named set of checkstyle rules called Tuscany Checks that points to the tuscany-checkstyle.xml file. The .checkstyle file in each project is then very small, it just says use Tuscany Checks. That way, if the tuscany-checkstyle.xml changes, then all projects get the changes. PMD, on the otherhand, cannot do that. It only sets rules in one of two ways: 1) In the project, there is a .ruleset file that defines all the rules for that project. This means the .ruleset file needs to be copied to ALL directories and if you want to change the PMD rules, you need to re- copy to all directories. (although that does allow different directories to have different rules) 2) You configure a bunch of rules in the workspace, but each project then specifies which of those rules to use in their .pmd file. Thus, if you want to add a new rule, you need to modify the .pmd file in each directory. That sucks just as bad. The PMD maven plugin doesn't suffer the problem. It can use a single file defined elsewhere (in the buildtools jar) for all the projects. The workaround I mentioned was to create a setup.eclipse profile that unpacks the file from that jar and creates the .ruleset file from it. Thus, each directory doesn't have the .ruleset file checked into svn. It's created only if you need it for eclipse. The cool thing is the setup.eclipse profile can also generate the .checkstyle and .pmd files at the same time so those don't get checked in. (just FYI: we are NOT doing this in celtix yet. I just figured out how to do that workaround last week) PMD has some other problems as well: 1) The MAVEN PMD plugin cannot check the test sources. It can ONLY be configured to test src/main/java. I've already logged a bug on that. 2) The ECLIPSE PMD plugin cannot be configured to NOT check the generated sources. This is a real killer for projects that have generated artifacts. In general, generated artifacts rarely meet all the .pmd requirements unless the .pmd requirements aren't very strict. For Celtix, we use very few PMD rules so the JAXB generated code passes. 3) PMD is pretty slow. Checkstyle is about the same speed as Javac. If you configure a bunch of PMD rules, it can take a LONG time. However, because of (2), we don't configure many rules so it's not too bad. Anyway, those are all PMD issues, not Checkstyle. The checkstyle stuff works quite well. You can tell Checkstyle to check only ^src/**/*.java so the stuff in target/generated is ignored.You can use a named config file so each project doesn't need one. It's also relatively quick (compared to PMD). Or a somewhat related note, does anyone have any experience with the Jetstyle IDEA plugin (or another way of integrating this with IDEA)? Haven't tried it yet. I just started trying out IDEA on Wednesday. I'm investigating if it can help with some big Celtix refactorings that we're working on, but it hung when I tried to do a major refactor (change the package names for EVERYTHING). (That said, eclipse didn't fare much better) -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] - 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: Subject: SCA Spec Update and Recursive Core presentation
Hi Joel, Great. Do you have some specific areas you are interested in working on w.r.t to Tuscany? I started a skeleton project of getting Tuscany to deploy into Equinox. Also, there has been a thread on providing management capabilities for Tuscany (Jervis I beleive was looking into this). We can definitely use help in these areas as well as the other areas we outlined in the June 9 message from this same thread. Let me know and I can point you at things in more detail. Jim On Jun 12, 2006, at 6:24 AM, Hawkins, Joel wrote: Jim, My name is Joel Hawkins, and I'm working with the Apache Muse project on porting the IBM contribution for the new version of Muse to OSGi. I'm also working on a recently formed Eclipse project (the Corona project) - which has a goal of providing a manageable (using Muse's WSDM implementation) SCA-type environment (hopefully using Tuscany) for Eclipse. I've been following the Tuscany project for some time, and after sitting through the presentation of the latest spec update, I believe SCA has a very important role to play in moving OSGi's Declarative Services spec forward, and I'd be very interested in helping out in these areas. Cheers, Joel Hawkins -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Saturday, June 10, 2006 1:08 PM To: tuscany-dev@ws.apache.org Subject: Re: Subject: SCA Spec Update and Recursive Core presentation I also forgot one big area that needs work: Management. This is a topic that is starting to come up in the spec group and it would be great if we could propose some ideas to them. Jim On Jun 9, 2006, at 2:48 PM, Jim Marino wrote: Hi, Thanks everyone who attended today's call. The slides have been checked into SVN at: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ doc We would appreciate any comments, questions, feedback, and suggestions on the session, and more importantly, the sandbox code at: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ Most importantly, we would appreciate help from those interested. There are a bunch of areas in particular that need a lot of work, including: - Model loading. Jeremy is working on annotations and bootstrapping. - Spring support. Ken is moving this along. - Binding integration. I'm looking at getting the Celtix stuff working. Raymond is working on SDO integration. - Component implementation types. There is a start of a Groovy implementation donated by Meeraj which has partially been ported - Transport binding integration. I checked in the skeleton of an HTTP Jetty transport. - Alternative host environments. I started a skeleton project for Equinox as a way to begin tackling OSGI deployment as well as the inevitable classloader problems we will encounter in restrictive container environments - Policy in general: transactions, security, etc. - Policy and wire optimization. I have started work here so please sync with me. - Less fun work includes Javadoc and testcases. Contributions building these areas out would be greatly appreciated; just knowing where we are lacking would be very valuable. - Integration test framework. We discussed having this in the past but not much work has been done. These are just the areas at the front of my mind. If you see other things you want to work on, jump on in. Jim - 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] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - 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: Bootstrapping Tuscany runtime and locating a service with sandbox code
Hi Rashmi, Jeremy will be able to answer your question regarding bootstrapping. For how to locate services, the spec API is evolving to accommodate the new recursive API. I have some thoughts I have been working on in the sandbox under jboynes/spec/sca but they are very early which will be proposed to the spec group. If you want, you can have a look and let me know what you think. I plan to have these operational sometime towards the end of the week. Jim On Jun 12, 2006, at 11:53 PM, Rashmi Hunt wrote: I was trying to see how the client code looks like with the new APIs from the sandbox. With the new architecture, I don't see TuscanyRuntime, ModuleContext etc. I do see DefaultBootstrapper, RuntimeComponent, CompositeComponentExtension etc in the sandbox, But, need some help in understanding set of client APIs. Question, 1) Which API starts Tuscany runtime? 2) If I have a java component (e.g JobBankServiceComponent), which API to use for locating/invoking the service? 3) Is there a sample(preferably ported over from M1), which shows usage of the new APIs? (I couldn't find such a sample in the sandbox tree) Below snippet is my client code based on M1 driver. Mainly looking for APIs which will replace the below snippet. // Obtain Tuscany runtime TuscanyRuntime tuscany = new TuscanyRuntime(jobbank, null); // Start the runtime tuscany.start(); // Obtain SCA module context.ModuleContext moduleContext = CurrentModuleContext.getContext(); // Locate the JobBank service JobBankService jobBankService = (JobBankService) moduleContext.locateService (JobBankServiceComponent); jobBankService.postJobDescription(Principal Engineer); Help is appreciated. Regards Rashmi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bulding a sandbox / branch
The easiest solution to this is to check the sandbox code out and build it using the correct poms. Jim On Jun 13, 2006, at 7:29 AM, Scott Kurz wrote: How does one build sandbox code, for example Jeremy's sandbox (which he's moving to a branch) ? I tried extracting the sandbox and unzipping over M1, but the Maven build fails Project ID: null:tuscany-sca:pom:SNAPSHOT Reason: Cannot find parent: org.apache.tuscany:tuscany-project for project: null:tuscany-sca:pom:SNAPSHOT [INFO] -- -- [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.tuscany:tuscany-project for project: null:tuscany-sca:pom:SNAPSHOT at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:365) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.tuscany:tuscany-project for project: null:tuscany-sca:pom:SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage( DefaultMavenProjectBuilder.java:1161) The problem looks to me to be that the sandbox is looking for a SNAPSHOT version, while M1 is using incubating-M1. So I can try changing the sandbox pom.xml's over to use incubating- M1, but I didn't see any instructions so was curious if this was the recommended way. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bulding a sandbox / branch
You should not unzip the sandbox structure over the M1 structure. Just do an svn co of the sandbox and then mvn from there. All of the poms will come down as part of the checkout and dependencies will be downloaded as part of the maven build. Jim On Jun 13, 2006, at 8:58 AM, Scott Kurz wrote: OK.. doing a find-replace on the sandbox's poms seems to work... just making sure that was correct... thanks On 6/13/06, Jim Marino [EMAIL PROTECTED] wrote: The easiest solution to this is to check the sandbox code out and build it using the correct poms. Jim On Jun 13, 2006, at 7:29 AM, Scott Kurz wrote: How does one build sandbox code, for example Jeremy's sandbox (which he's moving to a branch) ? I tried extracting the sandbox and unzipping over M1, but the Maven build fails Project ID: null:tuscany-sca:pom:SNAPSHOT Reason: Cannot find parent: org.apache.tuscany:tuscany-project for project: null:tuscany-sca:pom:SNAPSHOT [INFO] - - -- [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.tuscany:tuscany-project for project: null:tuscany-sca:pom:SNAPSHOT at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:365) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.tuscany:tuscany-project for project: null:tuscany-sca:pom:SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage( DefaultMavenProjectBuilder.java:1161) The problem looks to me to be that the sandbox is looking for a SNAPSHOT version, while M1 is using incubating-M1. So I can try changing the sandbox pom.xml's over to use incubating- M1, but I didn't see any instructions so was curious if this was the recommended way. Thanks - 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: Building twice?
I've been seeing the same thing for a while and was also going to ask about it but never got around to it On Jun 13, 2006, at 9:07 AM, Jeremy Boynes wrote: I noticed that the build for the code in the sandbox builds each module twice - not sure when this started but it didn't use to. Is anyone else seeing this or is the m2 setup on my machine messed up? Thanks -- Jeremy - 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: Subject: SCA Spec Update and Recursive Core presentation
Sorry for the delay, I've been on vacation... On Jun 13, 2006, at 6:54 AM, Hawkins, Joel wrote: Hi Jim, My personal interest is in SCA-OSGi integration. I listened to your presentation on the new core architecture, and am going through the sandbox code trying to gain some understanding of how it all hangs together. I'd really like to be involved in this area, and would appreciate any suggestions you can make. That would be great. I checked in a skeleton OSGi project that uses Equinox. There are a number of items that we need to figure out, including: - The details on OSGi as a host environment. I was thinking the root runtime context would be loaded in an OSGi and registered as an OSGi service. Application composites (e.g. applications contributed from end users) would be loaded as separate bundles and they would reference the SCA OSGi service to register themselves with the Tuscany runtime. Likewise, system composites would register themselves in a similar way. - Related to the first point, deployment structure. I'd like to see us figure out specifics concerning the deployment process such as run levels - How to access OSGi services. I was thinking there would be an OSGi binding. The easiest way to proceed may be for you to start posting questions as you work through looking at how the sandbox code works. Once we do that, we can move to specifics on how to integrate with OSGi. Does that work for you? I've got a separate thread going with Jervis around the management capabilities. We (the Corona team) are currently working on a WSDM interface for the OSGi runtime - I would hope that the lessons learned would be directly applicable to a WSDM interface for SCA. O.K. that's great Thanks, Joel -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 4:38 PM To: tuscany-dev@ws.apache.org Subject: Re: Subject: SCA Spec Update and Recursive Core presentation Hi Joel, Great. Do you have some specific areas you are interested in working on w.r.t to Tuscany? I started a skeleton project of getting Tuscany to deploy into Equinox. Also, there has been a thread on providing management capabilities for Tuscany (Jervis I beleive was looking into this). We can definitely use help in these areas as well as the other areas we outlined in the June 9 message from this same thread. Let me know and I can point you at things in more detail. Jim On Jun 12, 2006, at 6:24 AM, Hawkins, Joel wrote: Jim, My name is Joel Hawkins, and I'm working with the Apache Muse project on porting the IBM contribution for the new version of Muse to OSGi. I'm also working on a recently formed Eclipse project (the Corona project) - which has a goal of providing a manageable (using Muse's WSDM implementation) SCA-type environment (hopefully using Tuscany) for Eclipse. I've been following the Tuscany project for some time, and after sitting through the presentation of the latest spec update, I believe SCA has a very important role to play in moving OSGi's Declarative Services spec forward, and I'd be very interested in helping out in these areas. Cheers, Joel Hawkins -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Saturday, June 10, 2006 1:08 PM To: tuscany-dev@ws.apache.org Subject: Re: Subject: SCA Spec Update and Recursive Core presentation I also forgot one big area that needs work: Management. This is a topic that is starting to come up in the spec group and it would be great if we could propose some ideas to them. Jim On Jun 9, 2006, at 2:48 PM, Jim Marino wrote: Hi, Thanks everyone who attended today's call. The slides have been checked into SVN at: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ doc We would appreciate any comments, questions, feedback, and suggestions on the session, and more importantly, the sandbox code at: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ Most importantly, we would appreciate help from those interested. There are a bunch of areas in particular that need a lot of work, including: - Model loading. Jeremy is working on annotations and bootstrapping. - Spring support. Ken is moving this along. - Binding integration. I'm looking at getting the Celtix stuff working. Raymond is working on SDO integration. - Component implementation types. There is a start of a Groovy implementation donated by Meeraj which has partially been ported - Transport binding integration. I checked in the skeleton of an HTTP Jetty transport. - Alternative host environments. I started a skeleton project for Equinox as a way to begin tackling OSGI deployment as well as the inevitable classloader problems we will encounter in restrictive container environments - Policy in general: transactions, security, etc. - Policy and wire optimization. I have started work here so please sync with me. - Less fun work includes Javadoc and testcases. Contributions building
Re: Sample Implementation and Binding extensions
Which code base are you intending to use: the M1 which implements the old .9 spec or the sandbox one which implements support for the new recursive model, or both? In terms of how to specifically improve the extensibility story, my opinions have been embodied in the sandbox code and presentation Jeremy and I gave the other week (there are several slides providing high-level overviews of how to extend things) :-) Comments on that approach would be appreciated. Jim On Jun 19, 2006, at 6:25 PM, Jean-Sebastien Delfino wrote: In order to better understand our extensibility story and how we can improve it for M2, I'd like to experiment a little with our extensibility APIs and try to develop two simple extensions: - a jruby implementation extension (I won't be starting from scratch, we already have an initial implementation, but I'll try to add support for properties, references, lifecycle management, and deployment maybe) - a simple TCP/IP (socket) binding implementation I'll bring any questions and issues I run into and improvement proposals on the mailing list and I'm thinking about keeping track of this on a Wiki page as well. I'm going to start with the component implementation extension. If anybody wants to help and start the TCP/IP binding extension, please let me know and we can coordinate (I think we'll find common techniques and patterns between the two). -- Jean-Sebastien - 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]
move of container.java to core2
In trying to eliminate reliance on core2 by container.java in the sandbox and have it only rely on the extensibility SPI, it occurred to me that this would mandate moving a lot of implementation classes from core2 into SPI. I believe having container.java as a separate project rely on core2 is the wrong approach. This leaves three options: - move the required classes to SPI - make container.java not dependent on core classes by duplicating them - merging container.java with core. I think moving the classes to SPI is not the best approach since they are implementations. Having duplicate classes does not seem to be the optimal approach either as that will result in a maintenance burden and a lot of code repetition. As background, the sharing of classes between core2 and container.java arises from the fact that the runtime uses a POJO model to assemble system services, and hence there is commonality between the two. I prefer to do the latter as it appears to be the cleanest. Also, java.container is not a very good example of how to extend the recursive core due to its advanced capabilities. I'd rather include a simple Java container geared to demonstrating how to extend the runtime. It would be helpful if people provide input over the next day...I plan to implement choice 3 tomorrow if there are no alternatives. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: move of container.java to core2
I'm leaning towards combining them because separating commonalities out into a third project is basically creating an SPI2. Also, most of the stuff that would be pulled out is related to injection and reflection which I don't think we want to expose as an API at this point. Jim On Jun 20, 2006, at 8:09 AM, Jeremy Boynes wrote: I definitely agree that we should not be putting implementation into spi. We've been down the duplication path before and it did not work - the system and java containers quickly started to skew from each other (e.g. autowire only works for system components). Is there a way in which we can factor implementation shared by the system and java containers into a separate module? That would provide a common basis for other containers based on a POJO IoC model; however, implementation dependencies may well pull in a lot more of core than appropriate. It would only be worth doing if we expected a lot more containers that can use that infrastructure - I'm not sure that will be the case as others are likely to have a different programming model. Given that I think the approach of merging them together combined with a example of a simple POJO container is the least worst option. -- Jeremy Jim Marino wrote: In trying to eliminate reliance on core2 by container.java in the sandbox and have it only rely on the extensibility SPI, it occurred to me that this would mandate moving a lot of implementation classes from core2 into SPI. I believe having container.java as a separate project rely on core2 is the wrong approach. This leaves three options: - move the required classes to SPI - make container.java not dependent on core classes by duplicating them - merging container.java with core. I think moving the classes to SPI is not the best approach since they are implementations. Having duplicate classes does not seem to be the optimal approach either as that will result in a maintenance burden and a lot of code repetition. As background, the sharing of classes between core2 and container.java arises from the fact that the runtime uses a POJO model to assemble system services, and hence there is commonality between the two. I prefer to do the latter as it appears to be the cleanest. Also, java.container is not a very good example of how to extend the recursive core due to its advanced capabilities. I'd rather include a simple Java container geared to demonstrating how to extend the runtime. It would be helpful if people provide input over the next day...I plan to implement choice 3 tomorrow if there are no alternatives. Jim - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: move of container.java to core2
yea sounds good except I'll abbreviate implementation to impl so the package names are reasonable. Jim On Jun 20, 2006, at 9:25 AM, Jeremy Boynes wrote: Jim Marino wrote: I'm leaning towards combining them because separating commonalities out into a third project is basically creating an SPI2. Also, most of the stuff that would be pulled out is related to injection and reflection which I don't think we want to expose as an API at this point. YAGNI? Fair enough. We have composite and system sub-packages in core that correspond to implementation types - are you going to add java as third? Should we add implementation as a parent package to all three? I.e add o.a.t.core.implementation.[system,composite,java] -- Jeremy - 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: move of container.java to core2
On Jun 20, 2006, at 10:37 AM, Jean-Sebastien Delfino wrote: Jim Marino wrote: In trying to eliminate reliance on core2 by container.java in the sandbox and have it only rely on the extensibility SPI, it occurred to me that this would mandate moving a lot of implementation classes from core2 into SPI. I believe having container.java as a separate project rely on core2 is the wrong approach. This leaves three options: - move the required classes to SPI - make container.java not dependent on core classes by duplicating them - merging container.java with core. I think moving the classes to SPI is not the best approach since they are implementations. Having duplicate classes does not seem to be the optimal approach either as that will result in a maintenance burden and a lot of code repetition. As background, the sharing of classes between core2 and container.java arises from the fact that the runtime uses a POJO model to assemble system services, and hence there is commonality between the two. I prefer to do the latter as it appears to be the cleanest. Also, java.container is not a very good example of how to extend the recursive core due to its advanced capabilities. I'd rather include a simple Java container geared to demonstrating how to extend the runtime. It would be helpful if people provide input over the next day...I plan to implement choice 3 tomorrow if there are no alternatives. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I would prefer another option: Define a clean SPI contract with just interfaces so that containers (component implementation extensions) do not have to depend on internal classes from the core project. I thought that it was the reason for having an SPI project separate from core. I think that the core runtime and the java container should be decoupled with clean interface-based contracts between the two. What are the technical issues preventing us from achieving that? That's exactly what we have, a clean SPI with mostly interfaces. Container.java and core, however, both use java Pojo's (system services, and Java CI components) so there are some common reflection and injection related classes. It doesn't make sense to duplicate those classes and related test cases and maintain exact replicas in two different projects of a significant amount of code. On the other hand, keeping container.java separate and referencing those core classes sends an unclear message to extension developers. The other option, putting the implementation classes in SPI is in my view also wrong for two reasons. First, they are implementation- related, Second, they are not things we want to expose in the SPI. So, to recap, we have a separate SPI extension package that does not require extension developers to reference the core implementation. Core, for example, is built on SPI. The issue I was bringing up in this thread is that as core and container.java share a significant amount of implementation, and container.java is central to both SCA and the Java Tuscany implementation, it makes sense to combine the two as opposed to duplicating the shared implementation. Jim -- Jean-Sebastien - 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: Sample Implementation and Binding extensions
You'll need t ask Jeremy on bootstrapping but you don't need to bootstrap the container to test you component extensions - the Spring and Groovy examples show how to do this. The Groovy issue was brought up on this list earlier and it's not related to Tuscany at all. It's a problem with the version of ASM it is using. I don't have the Tuscany thread right now but if you do a search, it involves deleting a version of ASM from you maven repo. If you can't find it, let me know and I'll look. Jim On Jun 20, 2006, at 12:59 PM, Jean-Sebastien Delfino wrote: Jim Marino wrote: Which code base are you intending to use: the M1 which implements the old .9 spec or the sandbox one which implements support for the new recursive model, or both? In terms of how to specifically improve the extensibility story, my opinions have been embodied in the sandbox code and presentation Jeremy and I gave the other week (there are several slides providing high-level overviews of how to extend things) :-) Comments on that approach would be appreciated. Jim On Jun 19, 2006, at 6:25 PM, Jean-Sebastien Delfino wrote: In order to better understand our extensibility story and how we can improve it for M2, I'd like to experiment a little with our extensibility APIs and try to develop two simple extensions: - a jruby implementation extension (I won't be starting from scratch, we already have an initial implementation, but I'll try to add support for properties, references, lifecycle management, and deployment maybe) - a simple TCP/IP (socket) binding implementation I'll bring any questions and issues I run into and improvement proposals on the mailing list and I'm thinking about keeping track of this on a Wiki page as well. I'm going to start with the component implementation extension. If anybody wants to help and start the TCP/IP binding extension, please let me know and we can coordinate (I think we'll find common techniques and patterns between the two). --Jean-Sebastien - 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] I'm starting with both. Interestingly most of the differences between the two sets of SPIs are not related to the spec changes to support recursive composition, I found this surprising. I'm also going to propose, in the form of prototypes, improvements to the SPIs, there are good (and less good) things in both code streams, and I'd like to try to combine the best of both. Right now I'm prototyping this with the head stream, as I don't see yet how to run a simple sample with the code in sandbox, I'm running into the following issues: - I cannot find TuscanyRuntime anymore, has this been removed? has the mechanism for a client to bootstrap the runtime changed? is there a sample anywhere? - I was counting on the groovy container that you pointed me to yesterday to understand better the new SPIs but I'm not able to build it, the test cases fail with: java.lang.NoSuchMethodError: org.objectweb.asm.ClassVisitor.visit (IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/ lang/String;)V at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass (AsmClassGenerator.java:317) at org.codehaus.groovy.control.CompilationUnit$7.call (CompilationUnit.java:690) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes (CompilationUnit.java:956) at org.codehaus.groovy.control.CompilationUnit.classgen (CompilationUnit.java:629) at org.codehaus.groovy.control.CompilationUnit.compile (CompilationUnit.java:464) at groovy.lang.GroovyClassLoader.parseClass (GroovyClassLoader.java:300) at groovy.lang.GroovyClassLoader.parseClass (GroovyClassLoader.java:262) at groovy.lang.GroovyClassLoader.parseClass (GroovyClassLoader.java:257) at groovy.lang.GroovyClassLoader.parseClass (GroovyClassLoader.java:233) at org.apache.tuscany.container.groovy.GroovyAtomicComponent.createInstan ce(GroovyAtomicComponent.java:77) -- Jean-Sebastien - 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: Tuscany SPI interfaces
In the new core2 API, component factory is no longer needed.
AtomicComponent contains the invocation chains and and is responsible
for creating invokers. Related to having WSDL or Java interface
types, one of the things we also did was separate proxy creation from
the wire so now you can invoke on RuntimeWire directly, while proxies
are created by a separate service. The presentation has some slides
on this that we didn't get to due to time constraints.
One issue that has come up is in both runtimes (core and core2) we
are using Method to represent invocations. This may cause issues
since a Java interface always has to be generated. One thing we could
look at is going to something more generic.
Jim
On Jun 21, 2006, at 2:07 AM, ant elder wrote:
+1
Where are you doing this and how can we start helping? A long time
ago I had
a go at something like this for the JavaScript component, the
interfaces it
had were along the lines of the ones below. probably a bit old now
with all
the other changes. One thing I found hard was having a nice way to
have
interfaces be either Java classes or WSDL portTypes particularly with
components invoking service references.
ComponentFactory {
Component createComponent(Component component);
}
Component {
ComponentDefinition getComponentDefinition();
Invoker createComponentInvoker(MapString, Object properties,
MapString, Reference references);
}
Invoker {
public Object invoke(String operationName, Object[] args);
}
ComponentDefinition {
Interface getInterface();
ListString getReferenceNames();
ListProperty getProperties();
String getInitOperationName();
String getDestroyOperationName();
}
Property {
String getName();
Object getDefaultValue();
boolean isRequired();
}
Reference {
Interface getInterface();
Object getProxy();
Invoker getInvoker();
}
Interface {
}
ClassInterface {
class[] getInterfaceClasses();
}
WSDLInterface {
String getNamespce();
String getPortTypeName();
Definition getDefinition();
}
...ant
On 6/21/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
I'm trying to implement the sample ruby extension and running into
some
issues.
I'm implementing an AtomicComponentContext (with the code in the head
stream) and also trying the equivalent AtomicComponent with some
of the
code in the sandbox. I want to be able to implement my extension
class
without having to depend on base Tuscany runtime implementation
classes,
so I'm just implementing the SPI interfaces.
Unless I missed something (and it's very possible since I don't
understand all the pieces yet) here's what I found:
- with the code in the head, my AtomicComponentContext needs to
implement 15 methods;
- with the code in the sandbox, I have to implement 25 methods.
And this is just one class, I'm not even implementing the builders or
invokers yet... I think that in both cases this is too much.
It looks like the experiment in the sandbox is attempting to
provide a
simpler programming model for these extensions by hiding some of the
complexity in base implementation classes, but I think it will be
better
to define a set of independent interfaces and make some of them
optional. In other words if my extension does not wish to
implement one
of the interfaces, then it just doesn't need to, and the runtime
should
assume some default behavior, instead of forcing me to implement
all the
25 methods...
Another thought is to allow the contract to be implemented with
multiple
objects specialized in each aspect instead of one big object with 25
methods.
As I'm going through the implementation of the ruby component
implementation extension, I'm trying to come up with a short list of
requirements and methods that I think we really need to implement,
and
with that list I'd like us to prototype simpler SPI interfaces. If
anybody is interested in helping, please feel free to jump in, it
would
really be great if we could do a binding extension in parallel,
and also
if the people who actually developed some of the existing extensions
could come up with the requirements they've seen in terms of SPI and
proposals to improve our extensibility story.
Thanks,
--
Jean-Sebastien
-
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: Any recursive composition sample?
On Jun 21, 2006, at 4:48 AM, cr22rc wrote: I'd like to help out on this and also the SPI analysis work you spoke of. Per the samples I had some thoughts that instead of just jumping straight to them is to add some more for baby steps in bring up. For example I'd like to see as starters in a J2SE environment the very simplest of composite with a Java component being loaded with the minimal amount of any wiring. I was wondering if I could use the initeager to somehow just have it instantiate a single instance that would you guessed it display hello world to console. I can take a look at doing this over the next few days in core2. Not sure if that is possible still learning some of this code. If we could get that to work first it would be great for all to use in a debugger to see the system boot strap it self. From there move on to converting the other samples. I think with bigbank we'll need to maybe think (brain storm) some on how to best exhibit the new recursive model. BigBank I think needs a re-write. When we originally wrote it in the spec group, the intention was to show the benefits and ease-of-use for SCA. Since then, it's kind of evolved into a petstore-type application that pulls in SDO and DAS. While I like those technologies, I'd like to see BigBank put on a diet so that there is a version people just interested in SCA can reference. Also, I'd like it to show more of the value-add around SCA as opposed to just invoking a web service since people outside of the SCA collaboration and Tuscany project have questioned me as to why Tuscany is needed if there are things like: http://seam.demo.jboss.com/home.seam. For me, the value in SCA is around assembly, policies and conversations, so showcase features could be: - dynamic re-wiring - switching transport protocols - conversations and non-blocking/async behavior - introduction of policy I think we'll want to show both composites being used as components and using composites through inclusion (aka fragments). I also think we need to eventually start showing some more examples with some interesting complex properties being set. Jean-Sebastien Delfino wrote: The last few weeks we've been talking about composites and recursive composition so much... and today I looked for a sample showing the new recursive composition model in our whole code base, including the head and our various sandboxes... and couldn't find any. I think it'll help all of us get our heads around this new model if we can see a few samples. Could somebody point me to a recursive composition sample if we have any and I missed it? Is anybody curious and interested in trying to port a few of our existing samples to the new recursive model? I guess the update of the SCA spec describing the recursive composition is not public yet, but the materials presented at JavaOne are public as far as I know, and should be sufficient to develop samples leveraging the new recursive composition model. If anybody is interested in developing sample scenarios that demonstrate the value of the recursive composition, please let me know, we can work together on this. I'd like to start this activity in parallel with the SPI analysis work that I'm currently doing. - 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: Any recursive composition sample?
Yea that sounds good in terms of the really simple samples. I'd like to have a slim BigBank that just shows SCA though since I think it is important that people realize they can pick and choose technologies. I probably imagine SDO and DAS would say the same thing about SCA too. Jim On Jun 21, 2006, at 7:55 AM, cr22rc wrote: I pretty much agree with most of this, but I like the general pattern of having the simplest of samples to show a particular technology or some aspect of a technology and then something that brings it all together which was for M1 BigBank. You may have a point that this is too much for one sample, but generally these three technologies look in the minds of people to be sort of separate and I still like the idea of a sample that shows them all coming together. Jim Marino wrote: On Jun 21, 2006, at 4:48 AM, cr22rc wrote: I'd like to help out on this and also the SPI analysis work you spoke of. Per the samples I had some thoughts that instead of just jumping straight to them is to add some more for baby steps in bring up. For example I'd like to see as starters in a J2SE environment the very simplest of composite with a Java component being loaded with the minimal amount of any wiring. I was wondering if I could use the initeager to somehow just have it instantiate a single instance that would you guessed it display hello world to console. I can take a look at doing this over the next few days in core2. Not sure if that is possible still learning some of this code. If we could get that to work first it would be great for all to use in a debugger to see the system boot strap it self. From there move on to converting the other samples. I think with bigbank we'll need to maybe think (brain storm) some on how to best exhibit the new recursive model. BigBank I think needs a re-write. When we originally wrote it in the spec group, the intention was to show the benefits and ease-of- use for SCA. Since then, it's kind of evolved into a petstore-type application that pulls in SDO and DAS. While I like those technologies, I'd like to see BigBank put on a diet so that there is a version people just interested in SCA can reference. Also, I'd like it to show more of the value-add around SCA as opposed to just invoking a web service since people outside of the SCA collaboration and Tuscany project have questioned me as to why Tuscany is needed if there are things like: http:// seam.demo.jboss.com/home.seam. For me, the value in SCA is around assembly, policies and conversations, so showcase features could be: - dynamic re-wiring - switching transport protocols - conversations and non-blocking/async behavior - introduction of policy I think we'll want to show both composites being used as components and using composites through inclusion (aka fragments). I also think we need to eventually start showing some more examples with some interesting complex properties being set. Jean-Sebastien Delfino wrote: The last few weeks we've been talking about composites and recursive composition so much... and today I looked for a sample showing the new recursive composition model in our whole code base, including the head and our various sandboxes... and couldn't find any. I think it'll help all of us get our heads around this new model if we can see a few samples. Could somebody point me to a recursive composition sample if we have any and I missed it? Is anybody curious and interested in trying to port a few of our existing samples to the new recursive model? I guess the update of the SCA spec describing the recursive composition is not public yet, but the materials presented at JavaOne are public as far as I know, and should be sufficient to develop samples leveraging the new recursive composition model. If anybody is interested in developing sample scenarios that demonstrate the value of the recursive composition, please let me know, we can work together on this. I'd like to start this activity in parallel with the SPI analysis work that I'm currently doing. - 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] - 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: Tuscany SPI interfaces
On Jun 21, 2006, at 1:30 PM, Raymond Feng wrote:
Hi,
I guess one of the concerns is that some of the base classes create
additional contracts which are not captured by the interfaces. It
ends up that the extension developers have to understand more.
Actually, I think they have to understand less. Using the base
classes, they do not need to worry about how to register and
deregister the loaders. Do you feel the loader extensions are too
complicated? If so, what would an easier one look like?
Let's use the StAXElementLoader and LoaderExtension as an
example. Interface StAXElementLoader only requires the load
method to be implemented while LoaderExtension defines a contract
on how a StAXElementLoader register/deregister with the
LoaderRegistry. This is achieved by java annotations.
For this particular case, I can see two ways to get an extension
picked up by the runtime: declarative or programmatic. Some further
questions will be:
1) Should the extension developers have a choice to use either java
annotations or external XML configuration?
2) Should the extension metadata (for example, the XML element name
that a loader can handle) be captured in a model and java
annotation is just a convenient way to supply the value?
We had decided the system service model would be based on annotations
a while back. I'm happy to revisit but I don't see any value in
allowing for external configuration of *component type* data. This is
also consistent with the SCA programming model which views external
component type metadata for Java CI POJOs to be primarily for
legacy code.
Thanks,
Raymond
- Original Message - From: Jean-Sebastien Delfino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, June 21, 2006 2:08 AM
Subject: Re: Tuscany SPI interfaces
Jim Marino wrote:
I think you missed something. With core2, most people will extend
from the helper abstract classes in the SPI extension package
(this was also the case with the previous core). For example:
I didn't miss this class, as I said that's exactly what I'm trying
to avoid. I want to implement the SPI interfaces without having to
extend base implementation classes.
public class FooAtomicComponent extends
AtomicComponentExtensionObject{
public FooAtomicComponent(String name, CompositeComponent?
parent, ScopeContainer scopeContainer, WireService wireService) {
super(name, parent, scopeContainer, wireService);
}
public Object getServiceInstance() throws TargetException {
return null;
}
public Object createInstance() throws ObjectCreationException {
return null;
}
public Object getServiceInstance(String name) throws
TargetException {
return null;
}
public ListClass? getServiceInterfaces() {
return null;
}
public TargetInvoker createTargetInvoker(String serviceName,
Method operation) {
return null;
}
}
I generally don't like to count methods without looking at what
they do (e.g. some could just be setter/getter types). The above
class contains 5 methods, which I believe are reasonable and we
don't want to separate out. Invoker is very simple too:
- Two methods to invoke, one for message invocations, and one
for raw payloads. Generally, the first will just pull the payload
and invoke the second
- A setter/getter pair for whether the invocation is cacheable
- A boolean if the invoker can be optimized away and the target
can be called through straight invocation without a proxy.
Generally false.
- A clone method
The Spring and Groovy samples in the sandbox demonstrate both of
these.
Jim
On Jun 21, 2006, at 1:37 AM, Jean-Sebastien Delfino wrote:
I'm trying to implement the sample ruby extension and running
into some issues.
I'm implementing an AtomicComponentContext (with the code in the
head stream) and also trying the equivalent AtomicComponent with
some of the code in the sandbox. I want to be able to implement
my extension class without having to depend on base Tuscany
runtime implementation classes, so I'm just implementing the SPI
interfaces.
Unless I missed something (and it's very possible since I don't
understand all the pieces yet) here's what I found:
- with the code in the head, my AtomicComponentContext needs to
implement 15 methods;
- with the code in the sandbox, I have to implement 25 methods.
And this is just one class, I'm not even implementing the
builders or invokers yet... I think that in both cases this is
too much.
It looks like the experiment in the sandbox is attempting to
provide a simpler programming model for these extensions by
hiding some of the complexity in base implementation classes,
but I think it will be better to define a set of independent
interfaces and make some of them optional. In other words if my
extension does not wish to implement one of the interfaces
Re: move of container.java to core2
Yes the commons option would have been ideal but unfortunately, It's more than just reflection and utility classes. It's also injection classes related to wiring and component-handling classes which depend on SPI. Having gone over the options, merging the two seems to be the lesser of two evils, the other approach being a lot of duplicate code. Jim On Jun 21, 2006, at 5:21 PM, Jean-Sebastien Delfino wrote: Jim Marino wrote: On Jun 20, 2006, at 10:37 AM, Jean-Sebastien Delfino wrote: Jim Marino wrote: In trying to eliminate reliance on core2 by container.java in the sandbox and have it only rely on the extensibility SPI, it occurred to me that this would mandate moving a lot of implementation classes from core2 into SPI. I believe having container.java as a separate project rely on core2 is the wrong approach. This leaves three options: - move the required classes to SPI - make container.java not dependent on core classes by duplicating them - merging container.java with core. I think moving the classes to SPI is not the best approach since they are implementations. Having duplicate classes does not seem to be the optimal approach either as that will result in a maintenance burden and a lot of code repetition. As background, the sharing of classes between core2 and container.java arises from the fact that the runtime uses a POJO model to assemble system services, and hence there is commonality between the two. I prefer to do the latter as it appears to be the cleanest. Also, java.container is not a very good example of how to extend the recursive core due to its advanced capabilities. I'd rather include a simple Java container geared to demonstrating how to extend the runtime. It would be helpful if people provide input over the next day...I plan to implement choice 3 tomorrow if there are no alternatives. Jim --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I would prefer another option: Define a clean SPI contract with just interfaces so that containers (component implementation extensions) do not have to depend on internal classes from the core project. I thought that it was the reason for having an SPI project separate from core. I think that the core runtime and the java container should be decoupled with clean interface-based contracts between the two. What are the technical issues preventing us from achieving that? That's exactly what we have, a clean SPI with mostly interfaces. Container.java and core, however, both use java Pojo's (system services, and Java CI components) so there are some common reflection and injection related classes. It doesn't make sense to duplicate those classes and related test cases and maintain exact replicas in two different projects of a significant amount of code. On the other hand, keeping container.java separate and referencing those core classes sends an unclear message to extension developers. The other option, putting the implementation classes in SPI is in my view also wrong for two reasons. First, they are implementation-related, Second, they are not things we want to expose in the SPI. So, to recap, we have a separate SPI extension package that does not require extension developers to reference the core implementation. Core, for example, is built on SPI. The issue I was bringing up in this thread is that as core and container.java share a significant amount of implementation, and container.java is central to both SCA and the Java Tuscany implementation, it makes sense to combine the two as opposed to duplicating the shared implementation. Jim --Jean-Sebastien - 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] If I understand correctly, container.java and core both share utility classes that handle reflection and handling of Java annotations. Since we are a Java runtime other extensions and contributions to Tuscany will probably need this kind of utilities so I'd like to propose that we package them in tuscany-common.jar. This way they won't get mixed up with the SPIs (I agree with you that putting implementation classes in the SPI JAR is not good, I think the SPI JAR should just contain interfaces), and we can keep the java implementation extension and the core separate, which I think is important. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Fwd: svn commit: r416930 - in /incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/org/osoa/sca: ./ annotations/
FYI
I've started migrating sandbox code to use the new recursive SCA API.
This API has been accepted with a bunch of changes including
Jeremy's constructor injection proposal. The intent is the Tuscany
SCA API jar will be donated to/used by the spec group. A quick
overview of what has changed includes:
- Substitution of Composite for Module
- Use of generics in locateService() with the following semantics:
package org.osoa.sca;
public interface CompositeContext {
…
T locateService(ClassT serviceType, String serviceName);
}
The locateService() method takes as its input argument the name of
the service and returns an object providing access to the service.
The returned object implements the Java interface the service is
typed with.
- serviceType is the Java type used to represent the target
service on the client name can take on one of the following forms:
- component-name/service-name
If the service-name is not provided, the name of the
serviceType sans package name will be used as the service-name
- reference-name
I've updated Rick's eagerinit sample to compile against the new APIs.
We have a few changes that will be proposed this week as well:
- Change session scope to conversational
- Move eager init from the scope to a class level annotation. This
will allow us to instantiate a component instance eagerly without
having to have an initializer method, which will come in handy with
constructor based injection.
Of course, if anyone has additional ideas, please propose them on the
list and we can send them off to the spec group for discussion.
Jim
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: June 24, 2006 8:17:49 AM PDT
To: tuscany-commits@ws.apache.org
Subject: svn commit: r416930 - in /incubator/tuscany/sandbox/
jboynes/spec/sca/src/main/java/org/osoa/sca: ./ annotations/
Reply-To: tuscany-dev@ws.apache.org
Author: jmarino
Date: Sat Jun 24 08:17:48 2006
New Revision: 416930
URL: http://svn.apache.org/viewvc?rev=416930view=rev
Log:
changes to accomodate spec updates
Added:
incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/org/
osoa/sca/CompositeContext.java (contents, props changed)
- copied, changed from r414225, incubator/tuscany/sandbox/
jboynes/spec/sca/src/main/java/org/osoa/sca/ComponentContext.java
incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/org/
osoa/sca/CurrentCompositeContext.java (contents, props changed)
- copied, changed from r414226, incubator/tuscany/sandbox/
jboynes/spec/sca/src/main/java/org/osoa/sca/
CompositeComponentLocator.java
incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/org/
osoa/sca/annotations/Constructor.java (contents, props changed)
- copied, changed from r416331, incubator/tuscany/sandbox/
jboynes/sca/spi/src/main/java/org/apache/tuscany/spi/annotation/
Constructor.java
Removed:
incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/org/
osoa/sca/ComponentContext.java
incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/org/
osoa/sca/CompositeComponent.java
incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/org/
osoa/sca/CompositeComponentLocator.java
incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/org/
osoa/sca/annotations/ComponentMetaData.java
Modified:
incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/org/
osoa/sca/SCA.java
incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/org/
osoa/sca/annotations/Context.java
incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/org/
osoa/sca/annotations/Scope.java
Copied: incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/
org/osoa/sca/CompositeContext.java (from r414225, incubator/tuscany/
sandbox/jboynes/spec/sca/src/main/java/org/osoa/sca/
ComponentContext.java)
URL: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/
spec/sca/src/main/java/org/osoa/sca/CompositeContext.java?
p2=incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/org/
osoa/sca/CompositeContext.javap1=incubator/tuscany/sandbox/jboynes/
spec/sca/src/main/java/org/osoa/sca/
ComponentContext.javar1=414225r2=416930rev=416930view=diff
==
--- incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/org/
osoa/sca/ComponentContext.java (original)
+++ incubator/tuscany/sandbox/jboynes/spec/sca/src/main/java/org/
osoa/sca/CompositeContext.java Sat Jun 24 08:17:48 2006
@@ -22,7 +22,7 @@
*
* @version $Rev: 388784 $ $Date: 2006-03-25 08:34:51 -0800 (Sat,
25 Mar 2006) $
*/
-public interface ComponentContext {
+public interface CompositeContext {
/**
* Returns the name of the parent composite.
Propchange: incubator/tuscany/sandbox/jboynes/spec/sca/src/main/
java/org/osoa/sca/CompositeContext.java
--
Eager Init sample r416952
I've add a simple temporary class that to the eagerinit sample - LifecycleDemonstration - that demonstrates component lifecycle management, eager initialization, and destruction. As soon as we get the SCDL loading connected to the builders, this class can go away and we will be able to demo an end-to-end scenario. In the meantime, I thought this would be helpful to show the relationship between atomic components, scope containers, and composites. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eager Init sample r416952
ok cool - I'm going to bed ;-) On Jun 25, 2006, at 2:12 PM, Jeremy Boynes wrote: I did a couple of tweaks to this in r417080 to start using the capabilities of the deployer. It's not quite done but I wanted to commit what I had (during a layover in ORD) as I think it will be easier to understand than the bare mechanics in Jim's example. For now I turned it into a system component so that I could use the primordial deployer - that should not have much of an example as the two containers are so close. I will switch this back once we have a default system configuration. Jim, as a heads up I'm going to tweak the composite startup code so that we don't need to leak the scope container to the deployer's client. I hope to get that done on the next leg :-) -- Jeremy On 6/24/06, Jim Marino [EMAIL PROTECTED] wrote: I've add a simple temporary class that to the eagerinit sample - LifecycleDemonstration - that demonstrates component lifecycle management, eager initialization, and destruction. As soon as we get the SCDL loading connected to the builders, this class can go away and we will be able to demo an end-to-end scenario. In the meantime, I thought this would be helpful to show the relationship between atomic components, scope containers, and composites. Jim - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Upgrade container.spring in Jeremy's sandbox to Spring 2.0-M5 level
Ken was working on this. Ken? Since he may be traveling, if we don't hear back, I'll apply it tomorrow. Jim On Jun 25, 2006, at 11:38 PM, Raymond Feng wrote: A gentle reminder: Is anyone looking into the patch? I just tried it with Spring 2.0 RC1 and here's a new one updated to 2.0 RC1 level. Thanks, Raymond - Original Message - From: Raymond Feng [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, June 08, 2006 5:53 PM Subject: Re: [PATCH] Upgrade container.spring in Jeremy's sandbox to Spring 2.0-M5 level Hi, Ken. Thank you for pointing it out. Maybe it won't accept files with extension patch? Anyway, here's the patch again. Raymond - Original Message - From: Kenneth Tam [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 08, 2006 5:47 PM Subject: Re: [PATCH] Upgrade container.spring in Jeremy's sandbox to Spring 2.0-M5 level I think the patch got lost :) On 6/8/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Here's a patch to upgrade the container.spring to Spring 2.0-M5 level. Please review and apply. Thanks, Raymond --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] spring-2.0-rc1-patch.txt - 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: Eager Init sample r416952
Hi Rick, Could you explain, it sounds as if there may have been a side conversation at some point where I'm missing context? Jim On Jun 26, 2006, at 5:50 AM, Rick wrote: Jermey, Would still like to get in touch to understand the classpath issues and not using core classes. Jeremy Boynes wrote: Yes, just got net so am about to check in some major changes to the demonstration. Rather than create the parent etc, it now uses the bootstrapper to create the runtime and deploy the scdl. To keep it simple, I left it as a system component so there is just one step in the bootstrap process. We could expand it further but I think that we'll basically end up duplicating the code that would be in the Launcher. Rick, weren't you looking at that? How is it going? -- Jeremy On 6/26/06, Jim Marino [EMAIL PROTECTED] wrote: Basically the runtime has two hierarchical trees, one for application composites and one for system composites. They are separate but contained by the runtime. The bootstrapper will be responsible for setting all of this up, including default system composites and services so end-users won't need to mess with this. Jeremy's been working on that part I believe on his trip now so hopefully he'll have something to show us soon :-) Jim On Jun 25, 2006, at 5:54 PM, Rick wrote: Just a question on this ... today the code creates a parent CompositeComponentImpl. Would this eventually be replaced by the Tuscany loaded system being the parent that is read in from system SCDL ? Or would these component trees be kept separate? Still trying to see how all the pieces fit, but I have to say this really helps. Jim Marino wrote: ok cool - I'm going to bed ;-) On Jun 25, 2006, at 2:12 PM, Jeremy Boynes wrote: I did a couple of tweaks to this in r417080 to start using the capabilities of the deployer. It's not quite done but I wanted to commit what I had (during a layover in ORD) as I think it will be easier to understand than the bare mechanics in Jim's example. For now I turned it into a system component so that I could use the primordial deployer - that should not have much of an example as the two containers are so close. I will switch this back once we have a default system configuration. Jim, as a heads up I'm going to tweak the composite startup code so that we don't need to leak the scope container to the deployer's client. I hope to get that done on the next leg :-) -- Jeremy On 6/24/06, Jim Marino [EMAIL PROTECTED] wrote: I've add a simple temporary class that to the eagerinit sample - LifecycleDemonstration - that demonstrates component lifecycle management, eager initialization, and destruction. As soon as we get the SCDL loading connected to the builders, this class can go away and we will be able to demo an end-to-end scenario. In the meantime, I thought this would be helpful to show the relationship between atomic components, scope containers, and composites. Jim --- -- 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] - 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] - 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] - 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: Creating multiple / smaller SPI projects
On Jun 26, 2006, at 4:20 PM, Jeremy Boynes wrote: On 6/26/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Here are a few thoughts and questions on our SPI story. I'd like to start a discussion on these items and get your thoughts. Cool. My first thought is that what you're describing here is very close to what we have in the sandbox - for example, common themes of modularity and removing complexity. I've added a few more detailed comments inline. We also tried to do this in terms of separating out various runtime capabilities as well. For example, Raymond's databinding approach could be a system service that is plugged into the core. The idea is the core performs a very limited set of specific tasks and the rest are delegated to extensions. Right now we have around 8,500+ lines of code in core. It would be great if we could limit it to say (arbitrarily) 25,000 lines max. A. I think we should create different projects for the various types of SPI we have, for example one project for the assembly model SPI, one project for the interaction/invocation related SPI, one project for the deployment SPI, one for the management SPI etc. This sounds good, especially when we deal with high level building blocks like management. One thing I think we need to be careful of though is breaking it down too far so that we force users to understand several different modules just to do something simple. I think we can address that with the right package structure in each module. One thing is we may be able to change the SPI packages around to improve clarity but I agree we have to pick the right level of granularity for our project structure. If these SPI go into a spec at some point this will allow us to publish them and evolve them independently. Agreed. We are actually leading the spec here which gives us a chance to influence the direction it is taking. However, when the spec actually adopts something the classes will move from the o.a.t namespace to the org.osoa one which will impact users and implementations. We can handle those changes for both separate modules and individual packages within a module. I also think that this allows to cut complexity, for example a contributor only interested in management will not get the other SPIs. More generally, somebody assembling/embedding a Tuscany runtime will be in a better position to pick a subset of selected pieces. Cutting complexity is good and we can help with that by making sure that things that naturally go together are bundled together. For example, someone writing an extension should not need to dig through several modules to figure out what they need to do. Finally this shows a clear path to people who want to extend the runtime, for example, if we put the java interface support in a different project, the WSDL interface support in another one, then somebody wanting to add ruby or javascript support will have a clear template to follow. I'm not sure what you mean here. This sounds like two implementations of a pluggable interface type SPI - one for Java interfaces, one for WSDL ones - which I think would be a good way to break this down. B. I'd like to separate interfaces and implementation classes or helpers in different projects. Wholeheartedly agree on the separation between interface and implementation. In M1 we did this but had both inside the same module which was confusing; one of the things we did in the sandbox was to move the interfaces into spi and leave the implementation in core. I think helpers can go either way. If they are useful (but optional) to any implementation of the interface, then we can reduce the complexity by including them with the SPI. An example of this would be the extension base classes that contain functionality to support an implementation but which (in general) don't implement the interface contracts. On the other hand, classes that support a specific implementation should just be part of it (directly or in the form of a library). For example the assembly model interfaces would go into one project, the Tuscany implementation of these interfaces in a different one. In M1 we have interfaces+implementation classes but they are in the same project, in the sandbox there's no interfaces anymore for this, can you guys tell me what motivated that change? Simplicity really. The model objects are really just data holders (set and get methods only) and don't contain significant implementation. Separate interfaces and implementation classes will allow us to swap different implementations (e.g. using different databindings, or integrated with tooling for example). It will also allow model extensions to not depend on Tuscany implementations classes (the extensions will only implement interfaces instead of extending implementation classes). C. I would like to change the project folder structure a little and introduce a plugins/ directory where contributors could
Re: SCA in OSGi - was SCA Spec Update and Recursive Core presentation
Yea that was my bad. Jeremy just cleaned it up so if you can sync that would work better. I imagine you are going to run into many sharp objects but since you mountain bike I imagine you're used to it :-). What is in the OSGi project is really bare bones. Jeremy and Rick are having an ongoing deployer discussion and I think it would be good to link up with them on the list since I think that will help bootstrap in Equinox. I'm generally around so when you run into questions, feel free to post them and we can work through the issues. Jim On Jun 26, 2006, at 11:43 AM, Hawkins, Joel wrote: Found the spec directory - never mind! -Original Message- From: Hawkins, Joel [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2006 1:54 PM To: tuscany-dev@ws.apache.org Subject: SCA in OSGi - was SCA Spec Update and Recursive Core presentation Turn about is fair play - just got back from vacation myself - 6 days of cycling in the Rockies. :-) I think this approach will work well for me. I've done an update on the sandbox code and am having troubles building. It appears that the sca-api jar has been updated with some new classes (org.osoa.sca.CompositeContext, for example), but the SNAPSHOT available to Maven hasn't been. Am I catching the code in an in between state? Any hints would be appreciated! My goal for the week is to get the simple composite example working, using the deployment you describe below. I'm sure I'll bump into lots of sharp objects, which will generate lots of questions. Looking forward to the journey. Cheers, Joel -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Sunday, June 18, 2006 3:58 PM To: tuscany-dev@ws.apache.org Subject: Re: Subject: SCA Spec Update and Recursive Core presentation Sorry for the delay, I've been on vacation... On Jun 13, 2006, at 6:54 AM, Hawkins, Joel wrote: Hi Jim, My personal interest is in SCA-OSGi integration. I listened to your presentation on the new core architecture, and am going through the sandbox code trying to gain some understanding of how it all hangs together. I'd really like to be involved in this area, and would appreciate any suggestions you can make. That would be great. I checked in a skeleton OSGi project that uses Equinox. There are a number of items that we need to figure out, including: - The details on OSGi as a host environment. I was thinking the root runtime context would be loaded in an OSGi and registered as an OSGi service. Application composites (e.g. applications contributed from end users) would be loaded as separate bundles and they would reference the SCA OSGi service to register themselves with the Tuscany runtime. Likewise, system composites would register themselves in a similar way. - Related to the first point, deployment structure. I'd like to see us figure out specifics concerning the deployment process such as run levels - How to access OSGi services. I was thinking there would be an OSGi binding. The easiest way to proceed may be for you to start posting questions as you work through looking at how the sandbox code works. Once we do that, we can move to specifics on how to integrate with OSGi. Does that work for you? I've got a separate thread going with Jervis around the management capabilities. We (the Corona team) are currently working on a WSDM interface for the OSGi runtime - I would hope that the lessons learned would be directly applicable to a WSDM interface for SCA. O.K. that's great Thanks, Joel -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 4:38 PM To: tuscany-dev@ws.apache.org Subject: Re: Subject: SCA Spec Update and Recursive Core presentation Hi Joel, Great. Do you have some specific areas you are interested in working on w.r.t to Tuscany? I started a skeleton project of getting Tuscany to deploy into Equinox. Also, there has been a thread on providing management capabilities for Tuscany (Jervis I beleive was looking into this). We can definitely use help in these areas as well as the other areas we outlined in the June 9 message from this same thread. Let me know and I can point you at things in more detail. Jim On Jun 12, 2006, at 6:24 AM, Hawkins, Joel wrote: Jim, My name is Joel Hawkins, and I'm working with the Apache Muse project on porting the IBM contribution for the new version of Muse to OSGi. I'm also working on a recently formed Eclipse project (the Corona project) - which has a goal of providing a manageable (using Muse's WSDM implementation) SCA-type environment (hopefully using Tuscany) for Eclipse. I've been following the Tuscany project for some time, and after sitting through the presentation of the latest spec update, I believe SCA has a very important role to play in moving OSGi's Declarative Services spec forward, and I'd be very interested in helping out in these areas. Cheers, Joel Hawkins -Original Message- From: Jim
Re: Making invokers/interceptors actual components
On Jun 26, 2006, at 5:10 PM, Jean-Sebastien Delfino wrote: I'm looking at the Invoker/interceptor contribution mechanism and I'd like to propose to make them actual components. Currently an interceptor is not a component, it's an object added to an invocation chain by a Builder component. I think that if an invoker or interceptor could just be a component then we would have a better continuity in terms of programming model between application components, mediation components, components implementing various business or system policies and interceptor components contributing runtime behavior. That's a good idea and kind of what we presumed in the core2 extension model. Basically, an interceptor can be something newed up by the builder or autowired as a component to it. I think it is a matter of individual style but (e.g. some interceptors do not need the overhead of being a component), as you said, having it as a component makes it open to management and monitoring. I'd like to make sure, though, we mention both ways are valid. Any thoughts? -- Jean-Sebastien - 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: Any recursive composition sample?
Thanks for volunteering! The Spring container that Ken is working on will demonstrate how composites function. However, just to be accurate, we do not have *any* samples in core2 yet - it's not just a question about recursion. If people want to develop them and help out that would be greatly appreciated. The reason we don't have them is because when I develop code I prefer writing test cases and using those instead. It's great if people want to volunteer their effort to create samples though. Jim On Jun 21, 2006, at 1:57 AM, Jean-Sebastien Delfino wrote: The last few weeks we've been talking about composites and recursive composition so much... and today I looked for a sample showing the new recursive composition model in our whole code base, including the head and our various sandboxes... and couldn't find any. I think it'll help all of us get our heads around this new model if we can see a few samples. Could somebody point me to a recursive composition sample if we have any and I missed it? Is anybody curious and interested in trying to port a few of our existing samples to the new recursive model? I guess the update of the SCA spec describing the recursive composition is not public yet, but the materials presented at JavaOne are public as far as I know, and should be sufficient to develop samples leveraging the new recursive composition model. If anybody is interested in developing sample scenarios that demonstrate the value of the recursive composition, please let me know, we can work together on this. I'd like to start this activity in parallel with the SPI analysis work that I'm currently doing. -- Jean-Sebastien - 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: Tuscany SPI interfaces
Why do you need to implement an interface as opposed to extend an
abstract class when most of the methods are simple getters/setter
pairs? This is a very common pattern in found in Servlets, Struts,
WebWork, Srping and Hibernate, to name just a few. It allows people
to progressively buy into an extension API, picking up complexity as
needed.
If one wants maximum control, I still think things are very simple,
and this is exactly why I don't like counting methods without going
through what they are intended to do:
public class FooAllAtomicComponent implements AtomicComponentObject {
public boolean isEagerInit() {
return false;
}
public void init(Object instance) throws TargetException {
}
public void destroy(Object instance) throws TargetException {
}
public Object createInstance() throws ObjectCreationException {
return null;
}
public Object getServiceInstance(String name) throws
TargetException {
return null;
}
public ListClass? getServiceInterfaces() {
return null;
}
public void addInboundWire(InboundWire wire) {
}
public InboundWire getInboundWire(String serviceName) {
return null;
}
public void addOutboundWire(OutboundWire wire) {
}
public void addOutboundWires(Class? multiplicityClass,
ListOutboundWire wires) {
}
public MapString, ListOutboundWire getOutboundWires() {
return null;
}
public TargetInvoker createTargetInvoker(String serviceName,
Method operation) {
return null;
}
public String getName() {
return null;
}
public CompositeComponent getParent() {
return null;
}
public Scope getScope() {
return null;
}
public Object getServiceInstance() throws TargetException {
return null;
}
public void prepare() {
}
public void publish(Event object) {
}
public void addListener(RuntimeEventListener listener) {
}
public void addListener(EventFilter filter, RuntimeEventListener
listener) {
}
public void removeListener(RuntimeEventListener listener) {
}
public int getLifecycleState() {
return 0;
}
public void start() throws CoreRuntimeException {
}
public void stop() throws CoreRuntimeException {
}
Going in order:
- init/destroy initialize and destroy an instance
- createInstance(), getServiceInstance(String name)
getServiceInterfaces(), createTargetInvoker() are the same as before
- addInboundWire(InboundWire wire) adds an inbound wire to the
component
- addOutboundWire(OutboundWire wire), addOutboundWires(Class?
multiplicityClass, ListOutboundWire wires) provide the outbound
wires to the component
- getOutboundWires() returns the outbound wire
- getName() returns the component name
- getParent() returns the composite parent
- getScope() returns the component scope
- getServiceInstance() returns a default service instance
- prepare() is a callback to signal that the component has been
configured and should prepare itself to receive invocations
- publish(Event object), addListener(RuntimeEventListener
listener), addListener(EventFilter filter, RuntimeEventListener
listener), removeListener(RuntimeEventListener listener) provide
listener services particularly useful to composites
- getLifecycleState() returns the state of the component, e.g.
initializing, etc.
- start() and stop() are callbacks issued by the runtime
All of these methods deal directly with a component and are very easy
to implement. I don't see the need to Balkanize the API. Which of
these methods do you think can be broken out?
Jim
On Jun 21, 2006, at 2:08 AM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
I think you missed something. With core2, most people will extend
from the helper abstract classes in the SPI extension package
(this was also the case with the previous core). For example:
I didn't miss this class, as I said that's exactly what I'm trying
to avoid. I want to implement the SPI interfaces without having to
extend base implementation classes.
public class FooAtomicComponent extends
AtomicComponentExtensionObject{
public FooAtomicComponent(String name, CompositeComponent?
parent, ScopeContainer scopeContainer, WireService wireService) {
super(name, parent, scopeContainer, wireService);
}
public Object getServiceInstance() throws TargetException {
return null;
}
public Object createInstance() throws ObjectCreationException {
return null;
}
public Object getServiceInstance(String name) throws
TargetException {
return null;
}
public ListClass? getServiceInterfaces() {
return null;
}
public TargetInvoker createTargetInvoker(String serviceName,
Method
Re: Status of databinding module in sandbox and DataMediation
Hi Raymond, I think this would be really good to get it into the sandbox. Can you point me to the latest patch and we'll get it in ASAP? Jim On Jun 28, 2006, at 9:36 AM, Raymond Feng wrote: Hi, Do you think if my prototype can be used as a seed to flush out a good data mediation story? If so, does it make sense that somebody commits it into the sandbox to get more people involved? I'll update the wiki page as I add more things. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 28, 2006 9:01 AM Subject: Re: Status of databinding module in sandbox and DataMediation On 6/28/06, Liu, Jervis [EMAIL PROTECTED] wrote: Hi, databinding module in sandbox is not included as part of build at the moment. Are we going to still have this module in the new core? I think so, yes. In Monday's IRC chat, Jeremy mentioned that we need to fix the version in the sdo databinding pom, is anyone working on this right now? I'm not. Raymond also had a patch for it that I should apply - it's just that it is related the the type helper hierarchy issue that we still need to resolve. Also SDOXMLHelper.java is missing from sdo databinding(java\sca \databinding\sdo\src\main\java\org\apache\tuscany\databinding\sdo \SDOXMLHelper.java in M1 repo). Is there any reason why it is not there? No - it could just be that the code was copied before it was added. I will need this class to do the conversion between xml stream and sdo object in Celtix binding. Or maybe, we are going to the DataMediation proposed by Raymond? I think we will do something like that. I've not fully grokked Yang's mail on this yet (the streaming one). -- Jeremy - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of databinding module in sandbox and DataMediation
I was thinking it would be a system service since it appears to be applicable to a wide variety of things in the runtime. Having it as a system service also allows it to be managed and autowired to other extension points (e.g. services, bindings, components that may want to use it). If it were a system service, we could also make the mediator itself extensible so people could plug in their own transformation code. It would be similar to the SCDL loader or builder registries where the transformation extensions would be system services that self- registered with the mediation registry. If this makes sense to do, having a transformation extension could involve writing the extension as a POJO and a SCDL component entry and dropping it into the runtime. I think it was Sebastien who mentioned it would be valuable to be able to drop any extension point into a specific runtime location and have it registered in the runtime. In a similar way, perhaps we could even eliminate the need to write SCDL and just have the class (or jar) deployable to the runtime directly. We could place restrictions such as without SCDL, the class would need to be decorated with @Service so arbitrary things don't get picked up (i.e. we may want to restrict arbitrary things on the classpath from being registered). What do people think? Ant has been dealing with E4X in JavaScript so perhaps that could be one of these mediation extensions. Raymond, was this similar to where you were thinking of taking the mediation layer? Jim On Jun 28, 2006, at 11:06 PM, Liu, Jervis wrote: Hi Raymond, I think the question to be answered is how this data mediation is supposed to be used. For example, shall I use this data mediation as a java util just same as how I use SDOXMLHelper.java before? In this way, the data mediation might look like a replacement or enhancement to SDOXMLHelper.java (and other similar helper classes). Or, as one email suggested, do not embed this into SCA core, instead make data mediation act as a pluggable system service, which can be used in a wilder context, such as content- based routing, data transformation etc. Cheers, Jervis -Original Message- From: Raymond Feng [mailto:[EMAIL PROTECTED] Sent: Thursday, June 29, 2006 12:37 AM To: tuscany-dev@ws.apache.org Subject: Re: Status of databinding module in sandbox and DataMediation Hi, Do you think if my prototype can be used as a seed to flush out a good data mediation story? If so, does it make sense that somebody commits it into the sandbox to get more people involved? I'll update the wiki page as I add more things. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 28, 2006 9:01 AM Subject: Re: Status of databinding module in sandbox and DataMediation On 6/28/06, Liu, Jervis [EMAIL PROTECTED] wrote: Hi, databinding module in sandbox is not included as part of build at the moment. Are we going to still have this module in the new core? I think so, yes. In Monday's IRC chat, Jeremy mentioned that we need to fix the version in the sdo databinding pom, is anyone working on this right now? I'm not. Raymond also had a patch for it that I should apply - it's just that it is related the the type helper hierarchy issue that we still need to resolve. Also SDOXMLHelper.java is missing from sdo databinding(java\sca\databinding\sdo\src\main\java\org\apache \tuscany\databinding\sdo\SDOXMLHelper.java in M1 repo). Is there any reason why it is not there? No - it could just be that the code was copied before it was added. I will need this class to do the conversion between xml stream and sdo object in Celtix binding. Or maybe, we are going to the DataMediation proposed by Raymond? I think we will do something like that. I've not fully grokked Yang's mail on this yet (the streaming one). -- Jeremy - 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] - 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: Status of databinding module in sandbox and DataMediation
be able to present the property value in the specified databinding type to the component implementations 5) Split the project into multiple ones: one for the framework and each per data binding 6) Add more data bindings Any feedback will be welcome. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 28, 2006 10:23 PM Subject: Re: Status of databinding module in sandbox and DataMediation Hi Raymond, I think this would be really good to get it into the sandbox. Can you point me to the latest patch and we'll get it in ASAP? Jim On Jun 28, 2006, at 9:36 AM, Raymond Feng wrote: Hi, Do you think if my prototype can be used as a seed to flush out a good data mediation story? If so, does it make sense that somebody commits it into the sandbox to get more people involved? I'll update the wiki page as I add more things. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 28, 2006 9:01 AM Subject: Re: Status of databinding module in sandbox and DataMediation On 6/28/06, Liu, Jervis [EMAIL PROTECTED] wrote: Hi, databinding module in sandbox is not included as part of build at the moment. Are we going to still have this module in the new core? I think so, yes. In Monday's IRC chat, Jeremy mentioned that we need to fix the version in the sdo databinding pom, is anyone working on this right now? I'm not. Raymond also had a patch for it that I should apply - it's just that it is related the the type helper hierarchy issue that we still need to resolve. Also SDOXMLHelper.java is missing from sdo databinding(java\sca \databinding\sdo\src\main\java\org\apache\tuscany\databinding \sdo \SDOXMLHelper.java in M1 repo). Is there any reason why it is not there? No - it could just be that the code was copied before it was added. I will need this class to do the conversion between xml stream and sdo object in Celtix binding. Or maybe, we are going to the DataMediation proposed by Raymond? I think we will do something like that. I've not fully grokked Yang's mail on this yet (the streaming one). -- Jeremy - 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] - 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] - 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: Status of databinding module in sandbox and DataMediation
- Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 28, 2006 10:23 PM Subject: Re: Status of databinding module in sandbox and DataMediation Hi Raymond, I think this would be really good to get it into the sandbox. Can you point me to the latest patch and we'll get it in ASAP? Jim On Jun 28, 2006, at 9:36 AM, Raymond Feng wrote: Hi, Do you think if my prototype can be used as a seed to flush out a good data mediation story? If so, does it make sense that somebody commits it into the sandbox to get more people involved? I'll update the wiki page as I add more things. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 28, 2006 9:01 AM Subject: Re: Status of databinding module in sandbox and DataMediation On 6/28/06, Liu, Jervis [EMAIL PROTECTED] wrote: Hi, databinding module in sandbox is not included as part of build at the moment. Are we going to still have this module in the new core? I think so, yes. In Monday's IRC chat, Jeremy mentioned that we need to fix the version in the sdo databinding pom, is anyone working on this right now? I'm not. Raymond also had a patch for it that I should apply - it's just that it is related the the type helper hierarchy issue that we still need to resolve. Also SDOXMLHelper.java is missing from sdo databinding(java\sca \databinding\sdo\src\main\java\org\apache\tuscany\databinding\sdo \SDOXMLHelper.java in M1 repo). Is there any reason why it is not there? No - it could just be that the code was copied before it was added. I will need this class to do the conversion between xml stream and sdo object in Celtix binding. Or maybe, we are going to the DataMediation proposed by Raymond? I think we will do something like that. I've not fully grokked Yang's mail on this yet (the streaming one). -- Jeremy --- -- 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] - 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] - 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: Support for callbacks
On Jun 28, 2006, at 7:13 AM, Ignacio Silva-Lepe wrote: I'd like to start working on providing support for callbacks, assuming the sandbox is a good place to do this. Great. In case you haven't seen it, we have some architecture slides in the sandbox under jboynes/sca/doc in tuscany.architecture.v4. In there is information on scopes and wires, among other things. Currently, I am focusing on local, stateless callbacks to begin with. Later, and assuming that conversational support is in place (which I am also keen on contributing to) I can work on stateful and remote callbacks. The first basic issue I see is how to incorporate callbacks as defined in the CI spec in particular, and bi-directional interfaces in general, into the Tuscany architecture. Depending on how closely a RuntimeWire is supposed to correspond to an SCA wire, it seems like one way to incorporate a callback is to extend InboundWire to include an OutboundInvocationChain, and OutboundWire to include an InboundInvocationChain. That is, a wire would include a 'reverse' pair of invocation chain ends to account for a callback.With that in place, it seems feasible to re-use WireInvocationHandler and TargetInvoker in a similar fashion to actually perform the callback invocation. Are there any subtle (or not so subtle) gotchas in this that I am overlooking? I was thinking there would be a couple of things: a system transport service and a conversational scope container. The system transport service would listen for callbacks. That service would dispatch and invoke a component, which in turn would ask its scope container for the component implementation instance to dispatch to. The conversational scope container could have a pluggable persistent store API (we could have a simple implementation which serialized to disk and eventually used a journaling mechanism such as HOWL http:// howl.objectweb.org/). Two other basic pieces are: (1) callback injection, and (2) implementation of ServiceReference. Callback injection may be simple enough and similar to reference injection for stateless callbacks, but it'll get more interesting for stateful callbacks (or stateful scopes), as it is not clear that a callback field or method will remain valid for the duration of the component instance, and may need to be re-injected. Couldn't we use a proxy for this to avoid reinjection? In terms of flow, it could possibly work as follows: 1. Client invokes, invocation is passed through a wire 2. Target is invoked. When the target is created (it could be at this point or before), a callback proxy is injected. During the invocation, a threadlocal context is set up which allows the proxy to dispatch back. 3. Target calls the callback and an invocation is dispatched back 4. The listener on the client end receives the calback and dispatches to the callback using a normal component invocation. ServiceReference requires support for RequestContext and includes support for sessions. Since neither of these seem to be implemented, I could take a stab at implementing enough of RequestContext to support ServiceReference, and I could stub out support for sessions for now. On the other hand, ServiceReference is not as critical as, say, the RuntimeWire issue, so I could do without it at a very first try. Thoughts? If it is ok with everyone, I'll create a JIRA to start with stateless callbacks and can someone assign it to me? I'll create the JIRA and get it over to you. Perhaps we could start with outlining a couple of scenarios with progressive difficulty? In order to get this all to work we will probably need to refactor some of things such as the scope extensibility mechanisms. If we have some scenarios, I can help with the refactoring. Let me know if this works fr you and when you have more questions. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
On Jun 29, 2006, at 1:47 PM, Ignacio Silva-Lepe wrote: - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, June 29, 2006 12:18 PM Subject: Re: Support for callbacks On Jun 28, 2006, at 7:13 AM, Ignacio Silva-Lepe wrote: I'd like to start working on providing support for callbacks, assuming the sandbox is a good place to do this. Great. In case you haven't seen it, we have some architecture slides in the sandbox under jboynes/sca/doc in tuscany.architecture.v4. In there is information on scopes and wires, among other things. Currently, I am focusing on local, stateless callbacks to begin with. Later, and assuming that conversational support is in place (which I am also keen on contributing to) I can work on stateful and remote callbacks. The first basic issue I see is how to incorporate callbacks as defined in the CI spec in particular, and bi-directional interfaces in general, into the Tuscany architecture. Depending on how closely a RuntimeWire is supposed to correspond to an SCA wire, it seems like one way to incorporate a callback is to extend InboundWire to include an OutboundInvocationChain, and OutboundWire to include an InboundInvocationChain. That is, a wire would include a 'reverse' pair of invocation chain ends to account for a callback.With that in place, it seems feasible to re-use WireInvocationHandler and TargetInvoker in a similar fashion to actually perform the callback invocation. Are there any subtle (or not so subtle) gotchas in this that I am overlooking? I was thinking there would be a couple of things: a system transport service and a conversational scope container. The system transport service would listen for callbacks. That service would dispatch and invoke a component, which in turn would ask its scope container for the component implementation instance to dispatch to. Not sure if I follow. Is the system transport service intended as an alternative for a reverse invocation chain pair? Yes. The system service would be a transport listener which would pick up the callback invocation off of a wire. The callback invocation would be sent from the proxy injected into the target as described below. Do you think it would help if we outlined several of scenarios, e.g. a stateless callback done in the same composite, a stateless callback done across remote boundaries, a stateful callback done in the same composite, and a stateful callback done across remote boundaries? I was thinking we could sketch out what happens and then map it down to the core. The conversational scope container could have a pluggable persistent store API (we could have a simple implementation which serialized to disk and eventually used a journaling mechanism such as HOWL http:// howl.objectweb.org/). Two other basic pieces are: (1) callback injection, and (2) implementation of ServiceReference. Callback injection may be simple enough and similar to reference injection for stateless callbacks, but it'll get more interesting for stateful callbacks (or stateful scopes), as it is not clear that a callback field or method will remain valid for the duration of the component instance, and may need to be re-injected. Couldn't we use a proxy for this to avoid reinjection? In terms of flow, it could possibly work as follows: 1. Client invokes, invocation is passed through a wire 2. Target is invoked. When the target is created (it could be at this point or before), a callback proxy is injected. During the invocation, a threadlocal context is set up which allows the proxy to dispatch back. 3. Target calls the callback and an invocation is dispatched back 4. The listener on the client end receives the calback and dispatches to the callback using a normal component invocation. ServiceReference requires support for RequestContext and includes support for sessions. Since neither of these seem to be implemented, I could take a stab at implementing enough of RequestContext to support ServiceReference, and I could stub out support for sessions for now. On the other hand, ServiceReference is not as critical as, say, the RuntimeWire issue, so I could do without it at a very first try. Thoughts? If it is ok with everyone, I'll create a JIRA to start with stateless callbacks and can someone assign it to me? I'll create the JIRA and get it over to you. Perhaps we could start with outlining a couple of scenarios with progressive difficulty? In order to get this all to work we will probably need to refactor some of things such as the scope extensibility mechanisms. If we have some scenarios, I can help with the refactoring. Let me know if this works fr you and when you have more questions. Jim - To unsubscribe, e-mail
core2 checkin reminder
Just a reminder (since it was buried in a previous email thread)...When doing checkins on the sandbox core2 implementation, please run: $ mvn -Psourcecheck This will execute PMD and Checkstyle as part of the build. Thanks, Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using scenarios, was: Proposed approach for M2
On Jul 1, 2006, at 12:07 AM, Jeremy Boynes wrote: Jean-Sebastien Delfino wrote: 1. Use scenarios to drive the M2 work Start a community discussion on the end to end scenarios that we want to support in M2. I'm thinking about concrete end to end scenarios that define the end user experience and the overall story going from development, build, package, deploy to runtime and administration of an SCA application. snip Here are a few ideas of scenarios to initiate the discussion: - a scenario building your average web app with SCA - a scenario showing how to aggregate multiple services into new ones - mediation and routing/exchange scenarios - an application using publish/subscribe - building a whole system of services on a network - integration with an AJAX UI - what else? any thoughts? On 6/30/06, Kevin Williams [EMAIL PROTECTED] wrote: Sebastien, This sounds great to me. You may have intended this but, I think that the scenarios should be implemented as we go resulting in new unit tests, samples or sample apps by the time we are ready to release M2. Also, I propose a scenario that involves data access and the transfer of a data graph between modules. A source module would get the graph using the DAS and pass it to a worker module. The graph would be modified by the worker and sent back to the source module with change history intact to be synchronized with the database. An inter-op scenario would be nice too. One the the things that came out at the BOF at ApacheConEU was that we are not doing a good job of communicating what SCA is all about. I think having a bunch of scenarios like this will help us do that. Another thing that came out was that it would help if we broke the distribution down into smaller pieces - for example, making SCA, SDO and DAS available as individual releases rather than bundling them all together which gave users the false impression that they were all tightly coupled. I think we need a lot more information on each scenario though - at least to the level of detail Kevin provided. For example, - a scenario building your average web app with SCA I'm not sure what your average web app is - are we talking JSP taglibs, working with a framework such as WebWork, or the integration with something like Spring? Are we talking about just accessing services, or both producing and consuming? Are we talking about accessing a remote service or wiring local application components with SCA? Are we talking portable web app with Tuscany bundled, or how it works in an SCA-enabled container? I'd like to suggest we capture these on the wiki in enough detail that a user new to the project would be able to understand what we are talking about. The scenarios can then become illustrative samples of what SCA is about and how it can be realized with Tuscany. I don't want the scenarios to become the be-all and end-all though. We tried that with M1 and IMO it failed miserably. We scrambled to implement features and ended up with a brittle codebase that cracked when we needed to make significant changes. Testing focused on seeing if a scenario worked and we ended up with poor coverage across the codebase. Instead I think we need to define additional, finer-grained scenarios that cover the components of the system. For example, different ones for SCA, SDO and DAS, and, digging deeper, different ones for web-services, Spring, static SDOs, non-relational DAS and so on. I think this is really important and it's a problem IMO not just with Tuscany but also how the specs are presented. A lot of the feedback I've been getting is that it appears all of these technologies are tightly coupled, i.e. if one wants to use SCA then they must buy into a bunch of other things, such as SDO or DAS. This could also be said in reverse: if one wants to use SDO or DAS, then they need to use an SCA runtime. Obviously this is not the case (the SCA specs do not require SDO and vice versa) and I believe we really need to push this a la cart approach. For example, if I want to use the core as an embedded runtime and bootstrap it directly with no extensions, I should be able to do it. Even SCA itself is a la cart. For example, I may want to use assembly with Spring and no policy. Basically, I'd like us from the SCA side to focus on scenarios which demonstrate SCA. We should have integration scenarios with other technologies such as SDO, DAS, JPA, JAXB, JSF, etc. but it would be nice if we could segment them so people can first get familiar with SCA and then choose the direction they want to go with ancillary technologies. My other more practical concern is by splitting things up, it makes it easier for new people to come on board and select an area to work in. Basically, there are a lot of different scenarios for SDO on its own, we don't need to matrix them all into SCA, just pick a few key ones that help illustrate SCA concepts. At the
Re: PMD problem?, was: core2 checkin reminder
I'd say change PMD.
On Jul 1, 2006, at 1:04 AM, Jeremy Boynes wrote:
On 6/30/06, Jim Marino [EMAIL PROTECTED] wrote:
Just a reminder (since it was buried in a previous email
thread)...When doing checkins on the sandbox core2 implementation,
please run:
$ mvn -Psourcecheck
This will execute PMD and Checkstyle as part of the build.
I ran into the same thing last night but was too tired to post to
the thread.
I think the code that is causing PMD to barf is:
protected static File findLoadLocation() {
String location ...
File locfile = new File(location);
return locfile.getParentFile();
}
which I don't have an issue with and which I think PMD is incorrectly
complaining about given the rule in question.
Is this a bug in PMD? If so, should we comment out the rule or
change our code?
I have to admit I'm not very keen on changing code to work around
defects in a code checking tool.
--
Jeremy
-
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: Support for callbacks
Hi Ignacio, Let's try IRC, perhaps Monday's chat? Other comments inline... On Jun 30, 2006, at 1:30 PM, Ignacio Silva-Lepe wrote: Apologies Jeremy, didn't mean to exclude people, just trying to expedite the discussion. The first basic issue I see is how to incorporate callbacks as defined in the CI spec in particular, and bi-directional interfaces in general, into the Tuscany architecture. Depending on how closely a RuntimeWire is supposed to correspond to an SCA wire, it seems like one way to incorporate a callback is to extend InboundWire to include an OutboundInvocationChain, and OutboundWire to include an InboundInvocationChain. That is, a wire would include a 'reverse' pair of invocation chain ends to account for a callback.With that in place, it seems feasible to re-use WireInvocationHandler and TargetInvoker in a similar fashion to actually perform the callback invocation. Are there any subtle (or not so subtle) gotchas in this that I am overlooking? I was thinking there would be a couple of things: a system transport service and a conversational scope container. The system transport service would listen for callbacks. That service would dispatch and invoke a component, which in turn would ask its scope container for the component implementation instance to dispatch to. Not sure if I follow. Is the system transport service intended as an alternative for a reverse invocation chain pair? Yes. The system service would be a transport listener which would pick up the callback invocation off of a wire. The callback invocation would be sent from the proxy injected into the target as described below. Do you think it would help if we outlined several of scenarios, e.g. a stateless callback done in the same composite, a stateless callback done across remote boundaries, a stateful callback done in the same composite, and a stateful callback done across remote boundaries? I was thinking we could sketch out what happens and then map it down to the core. If I understand correctly, would a system service transport use a low level communication mechanism, like a socket for instance? This does not seem like an appropriate approach for a local scenario, Right, for the local scenario, I was thinking the callback instance would be put on the thread local context and the proxy would access it from there as opposed to going out over a socket and back in through a listener. Basically, it would be an optimization of the remote case. I think we can further optimize things depending on scopes, e.g. if the callback scope is module, we could possibly avoid threadlocal storage and have the proxy hold on to an instance directly. but I am really guessing about how such a listener would pick up a callback invocation if it is not via the architected RuntimeWire/InvocationChain mechanism. On the other hand, you do say the listener would pick up the callback invocation off of a wire, which I'm not sure I follow either. In the remote case, the target proxy would perform the invocation over a particular transport, which the listener would be listening on. The callback invocation would then be handled like any component invocation. Admittedly, using a 'reverse' pair of invocation chains does not seem like a very orthodox approach, but given that the SCA architecture does not define separate reference and service elements for a callback (i.e., these seem to be bundled into the forward reference and service only in reverse), it looks like it is up to the Tuscany architecture to supply a sensible design. As an alternative, a separate RuntimeWire instance could be introduced for a callback, with corresponding outbound and inbound ends, but this would not correspond that closely to its SCA counterpart. I think part of the problem may be that wires in SCA are bidirectional while in Java a reference pointer is unidirectional. We could look to try and model this with the approach you are proposing since it may be closer to the bidirectional nature of wires. Maybe on IRC we can come up with the scenarios and then outline the two approaches (we can post the transcript)? If we have difficulty on IRC due to the complexity of the topic, we may have to do a call and we could post to the list a summary of what was discussed. My question about gotchas had more to do with trying to use a WireInvocationHandler (e.g., JDKOutboundInvocationHandler) as the object called by the callback proxy injected into the target. I'd like to talk about this more since I'm not sure I'm getting everything (email is difficult). At first glance, this seems feasible, even if we are performing an outbound invocation on an InboundWire and the corresponding inbound invocation of the client happens from an OutboundWire. Is this reversal the reason why a transport listener is a better approach in your
Re: PMD problem?, was: core2 checkin reminder
Yea sorry, comment out the rule. Jim On Jul 1, 2006, at 1:17 AM, Jeremy Boynes wrote: On 7/1/06, Jim Marino [EMAIL PROTECTED] wrote: I'd say change PMD. Do you mean comment out the rule or fix the bug? The latter is a better solution but I'm hoping you mean the first :-) -- Jeremy - 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: SPI modularity
On Jul 1, 2006, at 2:42 AM, Jeremy Boynes wrote: Jean-Sebastien Delfino wrote: - Modularity, building our runtime in a more modular way, with more but simpler modules, clean SPI modules with only interfaces, and decoupling the core and the Java component implementation type / container. - Simpler SPIs, covering all aspects of the cycle (development, build, deployment + install, runtime, admin etc.) There's several things here conflated together - I propose we tackle them separately. If you define runtime as a running SCA environment, I think we have a good start on a modular approach. There are bound to be tweaks but I think we are going in the right direction. We have a basic core with a well-defined SPI into which we can add extensions without needing any change to the core. We also have ways in which extensions can co-operate, providing new extension points themselves into which other things can plug. spi and core2 combined are about 12000 lines of code and the binary is just over 300K in size - this is not very big really. I believe a good portion of that 300K is related to the Geronimo WorkManager dependencies. Since WorkManager can be implemented as a thin facade over the JDK 5 concurrency libraries, we should look at implementing a simple one and eliminating the dependencies. Once we do that, I think we will only need StAX, which is slated to become part of the JDK anyway. Having said that, I agree that we can restructure the SPI module to make things a little clearer. I think some of the confusion now comes because it contains both runtime and deployment interfaces. We agreed a long time ago that we wanted the runtime to be self-contained and independent of the deployment mechanism used. Bearing that in mind, we should be able to separate the runtime part of the SPI from the deployment part. Taking a quick swag at the top-level packages in the SPI I would propose we create two new ones, deployment and runtime, and move things around as follows: runtime: bootstrap, component, event, host, monitor, policy, services, wire deployment: annotation, builder, deployer, loader, model What does annotation do? On a related note, I think we also have a POJO extension model for things like annotation processors. I don't think this can be easily factored into an SPI below core since it will drag in a whole bunch of things (either in the basic SPI package or a special POJO SPI package). Any ideas would be great...otherwise we may just say that type of extension is a low- level one done off core. Assuming this works and all dependencies point from deployment to runtime we could then split the SPI module into two. I'd like to re-evaluate before doing that though as I think a typical usage would always have both runtime and deployment code and would typically always need both modules. I don't see separating these into two projects is worth the added complexity. As long as we have a clear packaging structure, IMO it is much easier to deal with one extension jar. Making people deal with two things just seems like unneeded complexity. Finally, I think we need to be clear about what is an SPI and what is an API. To me, an SPI is something used by an system to expand its functionality, it's a view from the inside looking out; an API is used by something else to manipulate a system, it's a view from the outside looking in. With that in mind I think some of the SPIs you mention above are really APIs. Things like deployment, install, admin (and I'd add management, monitoring) are interfaces the runtime would provide to allow outside entities to manipulate it. This is a god point. I think it also entails a different design approach. For example, an SPI is intended for experienced, systems- level programmers and therefore can sacrifice a bit of complexity for power and flexibility. I'd propose that this may be a better way to slice up the current spi module. For example, we could consider splitting out the bootstrap and deployer packages into a new api module. The intention would be to provide interfaces used by external actors without exposing them to the mechanisms used to extend the runtime. -- Jeremy - 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: Which codebase?, was: Proposed approach for M2
On Jul 1, 2006, at 1:17 AM, Jeremy Boynes wrote: Oh look, there's an elephant in the sandbox. On 6/30/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: 2. Stage the assembly of our M2 runtime. I propose that we start a fresh stream for M2 and build the runtime through baby steps, in parallel with the scenario work. When I tried to make substantial changes to M1, I ran into a bunch of problems due to the fragility of its code - just look at AbstractCompositeContext for example (or if you want to hang on to breakfast, don't). To avoid those it was easier to start a fresh stream and pull in pieces from M1, refactoring along the way to reduce the fragility. Jim and then others joined in along the way leading to what we have now. The thought of starting over yet again is not very appealing. Probably not surprisingly I agree, as the thought of starting over is not very appealing, especially in a piecemeal fashion. I feel we are at serious risk of loosing momentum if we start from scratch, particularly since a number of things are already underway using core2 (e.g. Spring integration, the deployer, data transformation, the Celtix binding, support for conversations, OSGi integration, Groovy support). Also, I'm not clear on how we would merge M1 and core2. When we created core2, we pulled in pieces of M1 where appropriate. While some things could be brought over (e.g. parts of the invocation chain, annotation processing, some of the loaders, autowire, etc.) a lot just couldn't. For example, we pretty much re-wrote the scope containers and wound up with a much cleaner design. Starting over like this seems to me to be at least two months of work assuming people that have contributed to the core in the past and are familiar with it are willing to sign up for this. In contrast, I'd like to be in a position sometime this month where we are comfortable having a modular core release that people can build extensions with. Sebastien, perhaps you could outline which parts of M1 would be merged with core2 so I can understand this better? I'd much prefer we do what Jeremy suggested below and improve core2 directly. In terms of a codebase that others can get up to speed with, it seems to me the best way to do this is not by rewriting it piecemeal, but by having a lot of extensions and documentation that people can refer to and gradually work their way into core. I believe the core is no different than other middleware such as Spring, Geronimo, JBoss, Hibernate, etc. in that the nature of the problem itself is complex and that complexity is proportionally reflected in the architecture but not through to the end-user programming model. I also believe that this complexity is best dealt with through modularity and layers people can start with and gradually work into the core (assuming they even want to). Instead, I suggest we go ahead with what was suggested on IRC three weeks ago and move the code we have now out of the sandbox and into a branch. Or perhaps, given there has been no development on the trunk recently (since mid-May), go ahead and just replace trunk itself. That gives us something to start from making it easier to support the high-level scenarios that we come up with. We can incrementally improve on that code based on what we find using and working with it, starting by taking a look at the suggestions that you made. -- Jeremy - 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: SPI modularity
On Jul 1, 2006, at 9:28 AM, Jeremy Boynes wrote: On 7/1/06, Jim Marino [EMAIL PROTECTED] wrote: I believe a good portion of that 300K is related to the Geronimo WorkManager dependencies. Since WorkManager can be implemented as a thin facade over the JDK 5 concurrency libraries, we should look at implementing a simple one and eliminating the dependencies. Once we do that, I think we will only need StAX, which is slated to become part of the JDK anyway. The 300K was the size of the two Tuscany jars - I didn't factor in the size of dependencies. Hmm tI guess that is even more reason to limit external dependencies :-) I agree we should have another look at using Geronimo's implementation. I know it was my suggestion to use it but it pulls in quite a bit given what it does vs. what's in the JRE. What does annotation do? On a related note, I think we also have a POJO extension model for things like annotation processors. I don't think this can be easily factored into an SPI below core since it will drag in a whole bunch of things (either in the basic SPI package or a special POJO SPI package). Any ideas would be great...otherwise we may just say that type of extension is a low- level one done off core. I was thinking the annotation processing stuff would end up there and that would be part of deployment. Thinking more we would want the annotations used by components to decorate themselves to be some API package. Yea we may be able to that but it -- Jeremy - 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]
Java SCA scenarios wiki page
I've added a skeleton wiki page for scenarios people are working on or are interested in for the Java SCA runtime at : http://wiki.apache.org/ws/Tuscany/TuscanyJava/Scenarios?action=show Most of the content are placeholders so it would be great if those interested started to add more scenarios and detail. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using scenarios, was: Proposed approach for M2
On Jul 2, 2006, at 2:51 PM, Clemens Utschig - Utschig (Oracle) wrote: Comments linline ... Jim Marino wrote: On Jul 2, 2006, at 2:02 PM, Simon Nash wrote: My comments are inline below. Simon Jeremy Boynes wrote: Jean-Sebastien Delfino wrote: 1. Use scenarios to drive the M2 work Start a community discussion on the end to end scenarios that we want to support in M2. I'm thinking about concrete end to end scenarios that define the end user experience and the overall story going from development, build, package, deploy to runtime and administration of an SCA application. snip Here are a few ideas of scenarios to initiate the discussion: - a scenario building your average web app with SCA - a scenario showing how to aggregate multiple services into new ones - mediation and routing/exchange scenarios - an application using publish/subscribe - building a whole system of services on a network - integration with an AJAX UI - what else? any thoughts? On 6/30/06, Kevin Williams [EMAIL PROTECTED] wrote: Sebastien, This sounds great to me. You may have intended this but, I think that the scenarios should be implemented as we go resulting in new unit tests, samples or sample apps by the time we are ready to release M2. Also, I propose a scenario that involves data access and the transfer of a data graph between modules. A source module would get the graph using the DAS and pass it to a worker module. The graph would be modified by the worker and sent back to the source module with change history intact to be synchronized with the database. An inter-op scenario would be nice too. One the the things that came out at the BOF at ApacheConEU was that we are not doing a good job of communicating what SCA is all about. I think having a bunch of scenarios like this will help us do that. Another thing that came out was that it would help if we broke the distribution down into smaller pieces - for example, making SCA, SDO and DAS available as individual releases rather than bundling them all together which gave users the false impression that they were all tightly coupled. I think we need a lot more information on each scenario though - at least to the level of detail Kevin provided. For example, - a scenario building your average web app with SCA at the end it comes down to people seing the benefits (and these are not just core engineers) - so step by step tutorials, and I know this is a damn amount of work usually helps for attracting and more over making the concepts (that should be communicated) obvious I'm not sure what your average web app is - are we talking JSP taglibs, working with a framework such as WebWork, or the integration with something like Spring? Are we talking about just accessing services, or both producing and consuming? Are we talking about accessing a remote service or wiring local application components with SCA? Are we talking portable web app with Tuscany bundled, or how it works in an SCA-enabled container? I'd like to suggest we capture these on the wiki in enough detail that a user new to the project would be able to understand what we are talking about. The scenarios can then become illustrative samples of what SCA is about and how it can be realized with Tuscany. I don't want the scenarios to become the be-all and end-all though. We tried that with M1 and IMO it failed miserably. We scrambled to implement features and ended up with a brittle codebase that cracked when we needed to make significant changes. Testing focused on seeing if a scenario worked and we ended up with poor coverage across the codebase. Instead I think we need to define additional, finer-grained scenarios that cover the components of the system. For example, different ones for SCA, SDO and DAS, and, digging deeper, different ones for web-services, Spring, static SDOs, non-relational DAS and so on. Basically, there are a lot of different scenarios for SDO on its own, we don't need to matrix them all into SCA, just pick a few key ones that help illustrate SCA concepts. At the most detailed level, the scenarios become the unit test cases for packages and individual classes. I think the purpose of scenarios is not to serve as tests, but to define required functionality in terms that are meaningful from a user perspective. There seems to be a range there as well. For example, users vary from end-user application developers to systems extenders. I also think scenarios may not involve users directly at all in some cases, instead defining some kind of execution flow through the runtime. I've just added a scenarios page to the WIKI with some things that are important to me at: http://wiki.apache.org/ws/Tuscany/TuscanyJava/Scenarios?action=show Hopefully you and others can add ones that are important to you and we can work on implementing them. +1 Great, thanks
Re: Using scenarios, was: Proposed approach for M2
More comments inline... On Jul 2, 2006, at 2:02 PM, Simon Nash wrote: My comments are inline below. Simon Jeremy Boynes wrote: Jean-Sebastien Delfino wrote: 1. Use scenarios to drive the M2 work Start a community discussion on the end to end scenarios that we want to support in M2. I'm thinking about concrete end to end scenarios that define the end user experience and the overall story going from development, build, package, deploy to runtime and administration of an SCA application. snip Here are a few ideas of scenarios to initiate the discussion: - a scenario building your average web app with SCA - a scenario showing how to aggregate multiple services into new ones - mediation and routing/exchange scenarios - an application using publish/subscribe - building a whole system of services on a network - integration with an AJAX UI - what else? any thoughts? On 6/30/06, Kevin Williams [EMAIL PROTECTED] wrote: Sebastien, This sounds great to me. You may have intended this but, I think that the scenarios should be implemented as we go resulting in new unit tests, samples or sample apps by the time we are ready to release M2. Also, I propose a scenario that involves data access and the transfer of a data graph between modules. A source module would get the graph using the DAS and pass it to a worker module. The graph would be modified by the worker and sent back to the source module with change history intact to be synchronized with the database. An inter-op scenario would be nice too. One the the things that came out at the BOF at ApacheConEU was that we are not doing a good job of communicating what SCA is all about. I think having a bunch of scenarios like this will help us do that. Another thing that came out was that it would help if we broke the distribution down into smaller pieces - for example, making SCA, SDO and DAS available as individual releases rather than bundling them all together which gave users the false impression that they were all tightly coupled. I think we need a lot more information on each scenario though - at least to the level of detail Kevin provided. For example, - a scenario building your average web app with SCA I'm not sure what your average web app is - are we talking JSP taglibs, working with a framework such as WebWork, or the integration with something like Spring? Are we talking about just accessing services, or both producing and consuming? Are we talking about accessing a remote service or wiring local application components with SCA? Are we talking portable web app with Tuscany bundled, or how it works in an SCA-enabled container? I'd like to suggest we capture these on the wiki in enough detail that a user new to the project would be able to understand what we are talking about. The scenarios can then become illustrative samples of what SCA is about and how it can be realized with Tuscany. I don't want the scenarios to become the be-all and end-all though. We tried that with M1 and IMO it failed miserably. We scrambled to implement features and ended up with a brittle codebase that cracked when we needed to make significant changes. Testing focused on seeing if a scenario worked and we ended up with poor coverage across the codebase. Instead I think we need to define additional, finer-grained scenarios that cover the components of the system. For example, different ones for SCA, SDO and DAS, and, digging deeper, different ones for web-services, Spring, static SDOs, non-relational DAS and so on. Basically, there are a lot of different scenarios for SDO on its own, we don't need to matrix them all into SCA, just pick a few key ones that help illustrate SCA concepts. At the most detailed level, the scenarios become the unit test cases for packages and individual classes. I think the purpose of scenarios is not to serve as tests, but to define required functionality in terms that are meaningful from a user perspective. From the scenarios we should derive technical specifications, designs that implement those specifications, and tests that validate that the implementations match the specifications. Some of the tests should validate high-level user-visible functionality (functional verification) and some should validate correct functioning of lower-level components according to their specified contracts (unit tests). So I see tests as different from scenarios. Some higher-level tests will look quite similar to elements of a scenario. Lower-level tests won't look like scenarios, but will exercise building blocks of functionality that are needed to make the scenarios work. Finally, I don't think we should define scenarios in the context of M2 - we should define them in the context of what we want Tuscany to be. As we implement, at some point we can say that we think we have a useful, consistent set of features and then turn that into a release. When you combine this with the
