Re: Extending the runtime and domain models
I don't see any reason why you should not open them up a bit instead of duplicating code. Especially now that we associate various objects by interface types, opening them will help in reusing them by substituting different implementations for such associations. - Venkat On 7/3/07, Simon Laws <[EMAIL PROTECTED]> wrote: The runtime classes (ReallySmallRuntime and ReallySmallRuntimeBuilder) and the EmbeddedSCADomain implementation are pretty well locked down in terms of overriding their members and functions. I had to make copies of most of this function to create the distributed runtime and domain. Can we loosen this up a bit so that these classes can be extended? Simon
Re: StackOverflowException when mutual reference exist
Hi, I think it's legal to have references from both A->B and B->A. Please create a JIRA to track this issue. Thanks, Raymond - Original Message - From: "Huang Kai" <[EMAIL PROTECTED]> To: Sent: Wednesday, July 04, 2007 10:48 PM Subject: StackOverflowException when mutual reference exist When CompositeA has reference to CompositeB while CompositeB also has reference back to CompositeA, CompositeBuilderImpl.build(composite) seems went into endless loop. I'm not very sure whether it's a bug or this kind of reference is illegal? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
StackOverflowException when mutual reference exist
When CompositeA has reference to CompositeB while CompositeB also has reference back to CompositeA, CompositeBuilderImpl.build(composite) seems went into endless loop. I'm not very sure whether it's a bug or this kind of reference is illegal?
[jira] Created: (TUSCANY-1411) JDKInvocationHandler works wrong when a component references more than one WS
JDKInvocationHandler works wrong when a component references more than one WS - Key: TUSCANY-1411 URL: https://issues.apache.org/jira/browse/TUSCANY-1411 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: windows xp, java5 Reporter: 耿韶光 I extended ws-service and ws-reference sample with 2 services, original it has only one reference of web service which was referenced by a component. Up to now, I add a second service, then things go wrong: The original component implements a service interface, with "getService" method, the client got the instance(a proxy) of the service interface, then the client could invoke the method on the service interface. But now the component implements the second service interface, then the org.apache.tuscany.sca.core.invocation.JDKInvocationHandler seems could not recognize the right generic of the component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pruning committers and pmc members
Folks, Believe it or not! we have 230 people who have karma to our svn: https://svn.apache.org/repos/asf/webservices/ Out of these only about 74 people have made commits in the last 1 year. You can get this info by using the svn log: svn log -v --revision 2006-07-05:HEAD https://svn.apache.org/repos/asf/webservices/ I'd like to start a process of pruning both the committer list and the pmc members list. As am sure some of the pmc members have not been active recently either as i alluded to you in the prev email about the board report. Here's something i came up with. Basically i will add a text file in https://svn.apache.org/repos/asf/webservices/admin which will have the names of all the committers and an option right next to their name with Y/N and question being would you like to keep your commit rights. Example. dims [Y/N] I can pre-fill this to Y for everyone who have made commits in the last 1 year to reduce work for already active people. At the end of say 2 weeks from kicking off the process, we will collect the final tally and prune the svn karma to those who chose to edit the file. If someone missed the deadline or want to get back karma say in a couple of months, they can send a quick email to the pmc (private AT ws.apache.org) and one of us can add it right back. How about we use the same process for PMC members too? I can add another file for pmc members and here i will not prefill anyones option. All PMC members have to edit the file and modify the option next to their name. At the end, same 2 weeks, we can declare those who did not choose to be active as Emeritus. For PMC members, there is a higher threshold, if one of the Emeritus members want to get back into the game, they will have to drop an email and we will hold a vote. This is because, we need to notify the board for *every* pmc member change and there are legal implications and a higher threshold. Sounds good? comments? thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Updated DAS beta1 distros
After the great feedback you guys gave for the DAS Beta1 RC1 under [1], Adriano and I have fixed most of the issues and new distros were uploaded to [2]. Could you guys have a quick look at it, I'm mostly looking to see if the build issues and the need to copy the derby canned databases are fixed. After we confirm these issues are fixed, I'll produce a RC2. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19464.html [2] http://people.apache.org/~lresende/tuscany/das-beta1-distribution/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NoClassDefFoundError for DefaultContributionPostProcessorExtensionPoint
Sorry, I missed these other places. It's fixed under revision #553367. On 7/4/07, Simon Nash <[EMAIL PROTECTED]> wrote: This error was fixed in the section in revision 552945, but there are four more places in the section that also need changing. Simon Luciano Resende wrote: > I have already changed that under revision #552945 as part of the fix > for tuscany-1407 > > On 7/3/07, Simon Nash <[EMAIL PROTECTED]> wrote: > >> I found the problem eventually. There's a bad pom.xml file in >> samples/simple-callback-ws. Everywhere that >>0.90-incubating >> appears in this file, it needs to be changed to >>1.0-incubating-SNAPSHOT >> >>Simon >> >> Simon Nash wrote: >> > I'm getting the following error from the new simple-callback-ws sample >> > when I run a full top-level mvn build against my test codebase that has >> > the latest incarnation of the fix to TUSCANY-1341. The problem doesn't >> > occur when I run mvn from the samples directory, or when I run mvn from >> > the samples/simple-callback-ws directory. I haven't made any code >> > changes that seem like they could cause this error. Has anyone seen >> > this before, or are there any suggestions for debugging? >> > >> > Simon >> > >> > --- >> > T E S T S >> > --- >> > Running simplecallback.SimpleCallbackTestCase >> > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.381 >> > sec <<< FAILURE! >> > test(simplecallback.SimpleCallbackTestCase) Time elapsed: 0.311 sec >> > <<< ERROR! >> > java.lang.NoClassDefFoundError: >> > >> org/apache/tuscany/sca/contribution/processor/DefaultContributionPostProcessorExtensionPoint >> >> > >> > at >> > >> org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntimeBuilder.createContributionService(ReallySmallRuntimeBuilder.java:189) >> >> > >> > at >> > >> org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:113) >> >> > >> > at >> > >> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:86) >> >> > >> > at >> > >> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:229) >> >> > >> > at >> > >> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:68) >> >> > >> > at >> > >> simplecallback.SimpleCallbackTestCase.setUp(SimpleCallbackTestCase.java:34) >> >> > at junit.framework.TestCase.runBare(TestCase.java:132) >> > at junit.framework.TestResult$1.protect(TestResult.java:110) >> > at junit.framework.TestResult.runProtected(TestResult.java:128) >> > at junit.framework.TestResult.run(TestResult.java:113) >> > at junit.framework.TestCase.run(TestCase.java:124) >> > at junit.framework.TestSuite.runTest(TestSuite.java:232) >> > at junit.framework.TestSuite.run(TestSuite.java:227) >> > at >> > >> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) >> >> > >> > at >> > >> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) >> >> > >> > at >> > >> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) >> >> > >> > at >> > >> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) >> >> > >> > at org.apache.maven.surefire.Surefire.run(Surefire.java:132) >> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> > at >> > >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> >> > >> > at >> > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> >> > >> > at java.lang.reflect.Method.invoke(Method.java:585) >> > at >> > >> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) >> >> > >> > at >> > >> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) >> >> > >> > >> > >> > Results : >> > >> > Tests in error: >> > test(simplecallback.SimpleCallbackTestCase) >> > >> > >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Hi Jacek, The spec also says in 1.10.2.2. The contribution optionally contains a document that declares runnable composites, exported definitions and imported definitions. The document is found at the path of META-INF/sca-contribution.xml relative to the root of the contribution.I think that there are contradictions here in the spec :(. Regards Manu On 7/4/07, Manu George <[EMAIL PROTECTED]> wrote: Hi Jacek, Glad that you could join this discussion. Welcome :). We need more participants like you to join this dicussion to come out with the best approach. I have added my comments inline on my understanding on why we should be doing this. This is actually based on the JEE SCA integration whitepaper at OSOA and Sebastiens comments. On 7/4/07, Jacek Laskowski <[EMAIL PROTECTED]> wrote: > On 7/3/07, Manu George <[EMAIL PROTECTED]> wrote: > > > (a) I develop SCA components, assemble them in a composite, package them > > in an SCA contribution. I don't really know what a WAR or an EAR is, I'm > > just using the SCA programming model and packaging model. I deploy my > > SCA contribution to Geronimo and run it there. > > > > This will require a tuscany specific deployer that is installed as > > part of the plugin. Ususally deployers have access to a server > > specific deployment plan at some fixed path say > > (META-INF/geronimo-tuscany.xml). If this file is found then the > > deployer will know that the module that was supplied to it is a > > tuscany module. In case I am deploying a tuscany contribution using > > the sca packaging model then there will be a .composite file somewhere > > in the module and the deployer will have to search in the module for > > scdl files. For now the tuscany contributions will always be > > packaged as jars. > > I've been reading the SCA Assembly Model 1.0 spec and according to it > (1.10.2 Contributions - page 63): > > SCA expects certain characteristics of any packaging: > > * A directory resource should exist at the root of the hierarchy named META-INF > * A document should exist directly under the META-INF directory named sca- > contribution.xml which lists the SCA Composites within the > contribution that are runnable. > > So it's pretty clear that Geronimo should recognize SCA modules only > when the META-INF/sca-contribution.xml file exists, pass it to Tuscany Yes you are right. But if you see the Tuscany samples it supports SCA modules that don't have sca-contribution.xml and just a .composite file. So I was on two minds here whether to mandate sca-contribution.xml or not. > and...that leads to my next question below. > > I can't understand what the value of such a simple integration > described in (a) would be. What would be the value of deploying > composities with no access to runtime environment other than Tuscany > itself? You can very easily do that with packaging sca modules as part > of war file with Tuscany listener attached. > > Jacek > True with the Tuscany listener attached you can consume services in jsps easily but the current Tuscany listener integration only supports the first scenario. Another limitation with the listener based approach is that each application needs its own SCADomain instantiation and there cannot be cross consumption of application services atleast without considering them as remote services. Ultimately we should be able to have selected JEE artifacts exposed in the SCADomain as composites so that there can be reuse of the exisiting JEE components in SCA and SCA components should be usable in JEE. To enable this the first step would be (a) enable deployment of tuscany artifacts in geronimo. (b) Enable usage of tuscany related annotations like @Reference in web components likeservlets filters etc and expose the war as a composite to the SCADomain so that SCA can do the wiring of these references to other SCA services. Thus u can have DI of SCA services in the web components and u can access them in jsps as well. (c) Enable EJB modules and Enterprise applications to expose their functionality as SCA services and also consume other SCA Services deployed in the Tuscany runtimes. (d) There is no concept of applications in SCA. So there could be multiple applications that expose their services to one domain and another set of applications that expose theirs to another domain. (atleast thats my understanding as of now) (e) Tuscany services can have different scopes like session etc. We may need to map these scopes with the scopes of JEE artifacts when they are exposed. > -- > Jacek Laskowski > http://www.JacekLaskowski.pl > So what (a) and (b) are just the initial steps to a deeper integration. Of course this is just one way of looking at the integration that is based on the whitepaper. Since there are no specs I think we are in uncharted waters so there may be better approaches. Please share your thoughts and comments. P.S. I am putting the tuscany dev list in cc, so that they
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Hi Simon, In one of the previous mails Sebastien proposed two ways of how the SCADomain should exist in geronimo (a) one instance of SCADomain per component running on the server, loaded with a subset of the distributed SCA domain composite representing that component and enough information about its peer components for it to locate and wire to them. (b) a single SCADomain object per Geronimo server, loaded with all the components running on the server. This will save a little bit of memory, at the expense of more synchronization work. I'd suggest to start with option (a) as it's the model that needs to be supported when SCA components run on different physical machines as well, and I'm actually not sure that we'll get any real performance gain with (b) over (a) if we do (a) right. Point (a) looks very similar to the distributed domain concept you explained. First it should be distributed across different apps/classloaders. There will be different instances of SCADomain containing parts of the whole and the different domain instances should constitute a single domain, which is capable of wiring together the components in the different instances they should be able to wire. This looks exactly like the scenario u mentioned but only locally. Is this supported as of now. > As Raymond says, we do have limited support for the distributed SCADomain now. The APIs for driving it are not sorted out yet though. What happens now is that you provide all contributed resources to each node in the domain and then tell each node which component from a contribution it is responsible and it does the rest creating remote connections where appropriate. I am interested to understand how you might use a distributed domain in the Geronimo integration exercise, even if you use the single EmbeddedSCADomain in the first instance, as it could inform the design of the API. I didn't give much thought to this but at the high level two possibilities. a) If we have a single domain per server. Then that domain can span over multiple Geronimo instances and do wiring between JEE apps exposed as SCA services on both the server instances. b) If we have multiple domains in each server, then each of them can span over multiple instances. c) If in one server itself there are many instances constituting one domain, then there is a possibility that there are multiple instances in another server as well which also will be part of the same domain. d) What to do when we cluster geronimo instances? Will SCADomains be clustered too? I am not sure how much sense i am making and whatever I am saying is very general. This is all i can think off now. If there is anything else someone can think off pls jump in. Regards Manu Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Hi Raymond, Comments Inline On 7/4/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Please see my comments inline. Thanks, Raymond - Original Message - From: "Manu George" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: Sent: Tuesday, July 03, 2007 7:53 AM Subject: Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists) > Hi , >From Paul's mail I guess a Geronimo plugin would be > the way forward. I am going to list down a few more questions on the > scenarios that Sebastien has explained. The scenarios are given first > and then my understanding, approach and issues. I would be just > listing two of the scenarios and trying to implement them initially. > > (a) I develop SCA components, assemble them in a composite, package them > in an SCA contribution. I don't really know what a WAR or an EAR is, > I'm > just using the SCA programming model and packaging model. I deploy my > SCA contribution to Geronimo and run it there. > > This will require a tuscany specific deployer that is installed as > part of the plugin. Ususally deployers have access to a server > specific deployment plan at some fixed path say > (META-INF/geronimo-tuscany.xml). If this file is found then the > deployer will know that the module that was supplied to it is a > tuscany module. In case I am deploying a tuscany contribution using > the sca packaging model then there will be a .composite file somewhere > in the module and the deployer will have to search in the module for > scdl files. For now the tuscany contributions will always be > packaged as jars. I'm not a geronimo expert. My understanding is that the Tuscany deployer needs a way to recognize the archive is a SCA contribution. It could be an external deployment plan such as genronimo-tuscany.xml. If the deployment plan is not present, then a SCA "deployment descriptor" will be checked. The SCA assembly spec doesn't define a mandatory deployment descriptor. We might be able to use "META-INF/sca-contributions.xml" as a starting point. See Jaceks Mail in this mail chain > > This will mean that if the deployer finds this file then it will > handle the module as a tuscany module and if not found relinquish > control to other deployers. > The SCA contribution itself can be an EAR. I assume an archive can be processed by multiple deployers. I think the module can be processed only by a single builder that implements the ConfigurationBuilder interface. We cannot chain ConfigurationBuilder instances. We can have references to ModuleBuilders in our builder but i think that is not the approach to follow. So in case of a plugin approach i think we will need to write a deployment watcher i.e a gbean that implements the org.apache.geronimo.kernel.config.DeploymentWatcher interface. The interface has two methods void deployed(Artifact id); void undeployed(Artifact id); So whenever any module is deployed this will get called after deployment. And u can access and modify the configuration. This approach too has some disadvantages The biggest one is since serialized gbeans cannot be edited we will need to recreate the configuration. We can use also use some methods in EditableConfigurationManager but again its functionality is limited and also adds the info to config.xml > Now we come to the question of the Domain. This has been a vexing > question for me. I think that going for a single SCADomain for the > entire server would be a good place to start. > All the applications will have an application composite and that > composite will be deployed on the server wide SCADomain. What the > server wide SCADomain should provide is the ability to add and remove > composites at runtime. If I am not mistaken this will be supported by > the EmbeddedSCADomain. Can someone in the know comment on this. We can start with a local SCA domain for the Geronimo server. EmbeddedSCADomain is the right class and it can be extended to support the Geronimo host. > > The other logical approach would be to go for different partial > SCADomain instances per contribution. These different instances will > still have information about the other instances and will do the > wiring across the instances that constitute a complete SCADomain. > From what I could find, this type of an SCADomain is not > supported currently. There is work on an SCADomain spanning multiple > runtimes. This would be a simpler case of an SCADomain spanning > multiple classloaders or (configurations in Geronimo). > SCADomain can span multiple runtimes. Simon Laws from Tuscany is driving the support of distributed SCADomain. I'm a bit confused by the statement "different partial SCADomain instances per contribution". Can you clarify? I will be responding to Simon on this. Please see that mail. > The reason for not going with the second approach is that it is not > available in tuscany as of today. Please correct me if I am wrong. > > (b) This was p
Re: How does one specify a Property as containment property in XML Schema?
Or better yet would be to add the po: to the types where it's missing:
>
>
>
like this:
>
>
>
The problem is that XSDHelper.define() doesn't complain about errors like
this, it just treats type="USAddress" as an unknown type.
Frank.
[EMAIL PROTECTED] wrote on 07/03/2007 07:29:40 AM:
> Pinaki,
>
> there are errors in the schema you are using. If you remove the ":po"
from
> xmlns:po="http://www.example.com/PO"; and remove "po:" from the rest of
the
> file, when used in referencing type or element definitions, then your
test
> code succeeds.
>
> Regards,Kelvin.
>
>
> Regards, Kelvin.
>
> On 03/07/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:
> >
> > I switched to EMF core API. The same error. Looks like Tuscany SDO is
> > wrapping EMF core -- is that right?
> >
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -Original Message-
> > From: kelvin goodson [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, July 03, 2007 3:54 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: How does one specify a Property as containment property
in
> > XML Schema?
> >
> > Pinaki,
> > perfect, thanks (yes, the attachments are stripped by the list),
will
> > try them out soon.
> > Kelvin
> >
> > On 03/07/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:
> > >
> > > Are you not seeing the e-mail attachements TestSDO.java and po.xsd?
> > >
> > > In any case, here they are
> > > = TestSDO.java
> > > ==
> > >
> > > package test;
> > >
> > > import java.io.IOException;
> > > import java.io.InputStream;
> > > import java.io.OutputStream;
> > > import java.util.List;
> > >
> > > import javax.persistence.EntityManager; import
> > > javax.persistence.EntityManagerFactory;
> > > import javax.persistence.Persistence;
> > >
> > > import org.apache.tuscany.sdo.helper.HelperProviderImpl;
> > >
> > > import com.bea.jpa.SDOEntityManager;
> > > import com.bea.jpa.SDOEntityManagerFactory;
> > >
> > > import commonj.sdo.DataObject;
> > > import commonj.sdo.helper.DataFactory; import
> > > commonj.sdo.helper.XMLHelper; import commonj.sdo.helper.XSDHelper;
> > > import commonj.sdo.impl.HelperProvider;
> > >
> > > import junit.framework.TestCase;
> > >
> > > /**
> > > * JUnit Tests to read a meta-model from XML Schema and create
> > > instances
> > > * according to the meta-model.
> > > *
> > > * @author ppoddar
> > > *
> > > */
> > > public class TestSDO extends TestCase {
> > > private static final String RESOURCE_SDO_MODEL = "po.xsd";
> > > private static final String SDO_MODEL_NAMESPACE =
> > > "http://www.example.com/PO";;
> > >
> > > /**
> > > * Create a SDO MetaData Model from a XML Schema and
populate
> > > instances.
> > > * Assumes 'po.xsd' be available in classpath as resource.
> > > *
> > > */
> > > public void testCreateModel() {
> > > InputStream xsdInputStream =
> > > this.getClass().getClassLoader()
> > >
> > > .getResourceAsStream(RESOURCE_SDO_MODEL);
> > > assertNotNull(xsdInputStream);
> > >
> > > String schemaLocation = null;
> > > List/* */types =
> > > XSDHelper.INSTANCE.define(xsdInputStream,
> > > schemaLocation);
> > > assertTrue(types != null && !types.isEmpty());
> > > assertTrue(types.size() >= 2);
> > >
> > > DataObject purchaseOrder =
> > DataFactory.INSTANCE.create(
> > > SDO_MODEL_NAMESPACE,
> > > "PurchaseOrderType");
> > >
> > > purchaseOrder.setString("orderDate", "1999-10-20");
> > >
> > > DataObject shipTo =
> > > purchaseOrder.createDataObject("shipTo");
> > > shipTo.set("country", "US");
> > > shipTo.set("name", "Alice Smith");
> > > shipTo.set("street", "123 Maple Street");
> > > shipTo.set("city", "Mill Valley");
> > > shipTo.set("state", "CA");
> > > shipTo.setString("zip", "90952");
> > > DataObject billTo =
> > > purchaseOrder.createDataObject("billTo");
> > > billTo.set("country", "US");
> > > billTo.set("name", "Robert Smith");
> > > billTo.set("street", "8 Oak Avenue");
> > > billTo.set("city", "Mill Valley");
> > > billTo.set("state", "PA");
> > > billTo.setString("zip", "95819");
> > > purchaseOrder.set("comment", "Hurry, my lawn is
going
> > > wild!");
> > >
> > > DataObject items =
> > > purchaseOrder.createDataObject("items");
> > >
> > > DataObject item1 = items.createDataObject("item");
> > > item1.set("partNum", "872-AA");
> > > item1.set("productName", "Lawnmower"
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Hi Jacek, Glad that you could join this discussion. Welcome :). We need more participants like you to join this dicussion to come out with the best approach. I have added my comments inline on my understanding on why we should be doing this. This is actually based on the JEE SCA integration whitepaper at OSOA and Sebastiens comments. On 7/4/07, Jacek Laskowski <[EMAIL PROTECTED]> wrote: On 7/3/07, Manu George <[EMAIL PROTECTED]> wrote: > (a) I develop SCA components, assemble them in a composite, package them > in an SCA contribution. I don't really know what a WAR or an EAR is, I'm > just using the SCA programming model and packaging model. I deploy my > SCA contribution to Geronimo and run it there. > > This will require a tuscany specific deployer that is installed as > part of the plugin. Ususally deployers have access to a server > specific deployment plan at some fixed path say > (META-INF/geronimo-tuscany.xml). If this file is found then the > deployer will know that the module that was supplied to it is a > tuscany module. In case I am deploying a tuscany contribution using > the sca packaging model then there will be a .composite file somewhere > in the module and the deployer will have to search in the module for > scdl files. For now the tuscany contributions will always be > packaged as jars. I've been reading the SCA Assembly Model 1.0 spec and according to it (1.10.2 Contributions - page 63): SCA expects certain characteristics of any packaging: * A directory resource should exist at the root of the hierarchy named META-INF * A document should exist directly under the META-INF directory named sca- contribution.xml which lists the SCA Composites within the contribution that are runnable. So it's pretty clear that Geronimo should recognize SCA modules only when the META-INF/sca-contribution.xml file exists, pass it to Tuscany Yes you are right. But if you see the Tuscany samples it supports SCA modules that don't have sca-contribution.xml and just a .composite file. So I was on two minds here whether to mandate sca-contribution.xml or not. and...that leads to my next question below. I can't understand what the value of such a simple integration described in (a) would be. What would be the value of deploying composities with no access to runtime environment other than Tuscany itself? You can very easily do that with packaging sca modules as part of war file with Tuscany listener attached. Jacek True with the Tuscany listener attached you can consume services in jsps easily but the current Tuscany listener integration only supports the first scenario. Another limitation with the listener based approach is that each application needs its own SCADomain instantiation and there cannot be cross consumption of application services atleast without considering them as remote services. Ultimately we should be able to have selected JEE artifacts exposed in the SCADomain as composites so that there can be reuse of the exisiting JEE components in SCA and SCA components should be usable in JEE. To enable this the first step would be (a) enable deployment of tuscany artifacts in geronimo. (b) Enable usage of tuscany related annotations like @Reference in web components likeservlets filters etc and expose the war as a composite to the SCADomain so that SCA can do the wiring of these references to other SCA services. Thus u can have DI of SCA services in the web components and u can access them in jsps as well. (c) Enable EJB modules and Enterprise applications to expose their functionality as SCA services and also consume other SCA Services deployed in the Tuscany runtimes. (d) There is no concept of applications in SCA. So there could be multiple applications that expose their services to one domain and another set of applications that expose theirs to another domain. (atleast thats my understanding as of now) (e) Tuscany services can have different scopes like session etc. We may need to map these scopes with the scopes of JEE artifacts when they are exposed. -- Jacek Laskowski http://www.JacekLaskowski.pl So what (a) and (b) are just the initial steps to a deeper integration. Of course this is just one way of looking at the integration that is based on the whitepaper. Since there are no specs I think we are in uncharted waters so there may be better approaches. Please share your thoughts and comments. P.S. I am putting the tuscany dev list in cc, so that they can also participate in this discussion. Regards Manu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1410) DataHelperImpl.toCalendar() with null locale should use default locale
DataHelperImpl.toCalendar() with null locale should use default locale
--
Key: TUSCANY-1410
URL: https://issues.apache.org/jira/browse/TUSCANY-1410
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Reporter: Andy Grove
Priority: Minor
DataHelperImpl.toCalendar() currently returns null if the locale parameter is
null. However, according to the published SDO API javadoc comments, if locale
is null then the default locale should be used. To resolve this, the following
code can be added at the start of the method.
if (locale == null) {
locale = Locale.getDefault();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1409) Make OSGi instance creation thread-safe, and support @EagerInit
[ https://issues.apache.org/jira/browse/TUSCANY-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510175 ] Rajini Sivaram commented on TUSCANY-1409: - Thank you, Ant. - Rajini > Make OSGi instance creation thread-safe, and support @EagerInit > --- > > Key: TUSCANY-1409 > URL: https://issues.apache.org/jira/browse/TUSCANY-1409 > Project: Tuscany > Issue Type: Bug > Components: Java SCA OSGi Integration >Reporter: Rajini Sivaram >Priority: Minor > Attachments: tuscany-implementation-osgi-patch.txt > > > Patch with support for @EagerInit, and changes to make creation of OSGi > instances thread-safe. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1355) DAS-RDB does not support Oracle or SqlServer well
[
https://issues.apache.org/jira/browse/TUSCANY-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510173
]
Amita Vadhavkar commented on TUSCANY-1355:
--
This might be imcompatibility in SDO, not sure, will you please list here all
the sdo and das jars
(exact with versions) you are using?
Also, will you please check using RDB DAS beta1 binary distribution at
http://people.apache.org/~lresende/tuscany/das-beta1-distribution/ instead of
building it from scratch, please use all the same jars provided in there.
Regards
> DAS-RDB does not support Oracle or SqlServer well
> -
>
> Key: TUSCANY-1355
> URL: https://issues.apache.org/jira/browse/TUSCANY-1355
> Project: Tuscany
> Issue Type: Bug
> Components: Java DAS RDB
>Affects Versions: Java-DAS-M2
> Environment: DAS-RDB to access the database of Oracle
>Reporter: wangful
>
> I have used the following simple codes to use DAS to access an Oracle
> database.
> //String url =
> "jdbc:db2j:D:/RAD6/runtimes/base_v6/cloudscape/DAS";
> String url = "jdbc:oracle:thin:wcs/wcs1@//raptor08:1521/g10";
> String query = "select * from MYCUSTOMER";
> String query_result="";
> Connection conn = null;
> // Class.forName("com.ibm.db2j.jdbc.DB2jDriver").newInstance();
> DriverManager.registerDriver(new
> oracle.jdbc.driver.OracleDriver());
> conn = DriverManager.getConnection(url);
> conn.setAutoCommit(false);
>DAS das =
> DAS.FACTORY.createDAS(conn);
> Command readStores = das.createCommand(query);
> DataObject root = (DataObject)readStores.executeQuery();
> DataObject cus1 = root.getDataObject("MYCUSTOMER[1]");
>
> System.out.println(root.getInt("MYCUSTOMER[1]/ID"));
> System.out.println(root.getString("MYCUSTOMER[1]/NAME"));
> It will caused the following error:
> Exception in thread "main" java.lang.IllegalArgumentException: Class
> 'DataGraphRoot' does not have a feature named 'MYCUSTOMER'
> at
> org.apache.tuscany.sdo.util.DataObjectUtil.getOpenFeature(DataObjectUtil.java:1804)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:2367)
> at
> org.apache.tuscany.sdo.impl.DataObjectImpl.getProperty(DataObjectImpl.java:1287)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2054)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2161)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1940)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1860)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:744)
> at
> org.apache.tuscany.sdo.impl.DataObjectImpl.get(DataObjectImpl.java:216)
> at
> org.apache.tuscany.sdo.impl.DataObjectImpl.getDataObject(DataObjectImpl.java:326)
> at TestDAS.main(TestDAS.java:47)
> But the same code and same config will work well for cloudscape database.
> There are also some other problems for Oracle, seems DAS can't work for
> oracle.
> Will someone look into this problem?
> Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1409) Make OSGi instance creation thread-safe, and support @EagerInit
[ https://issues.apache.org/jira/browse/TUSCANY-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1409. -- Resolution: Fixed Applied, and the itests now look like they work fine so i'll add them to the build as well. Thanks for the patch Rajini. > Make OSGi instance creation thread-safe, and support @EagerInit > --- > > Key: TUSCANY-1409 > URL: https://issues.apache.org/jira/browse/TUSCANY-1409 > Project: Tuscany > Issue Type: Bug > Components: Java SCA OSGi Integration >Reporter: Rajini Sivaram >Priority: Minor > Attachments: tuscany-implementation-osgi-patch.txt > > > Patch with support for @EagerInit, and changes to make creation of OSGi > instances thread-safe. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1409) Make OSGi instance creation thread-safe, and support @EagerInit
[ https://issues.apache.org/jira/browse/TUSCANY-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1409: Attachment: tuscany-implementation-osgi-patch.txt > Make OSGi instance creation thread-safe, and support @EagerInit > --- > > Key: TUSCANY-1409 > URL: https://issues.apache.org/jira/browse/TUSCANY-1409 > Project: Tuscany > Issue Type: Bug > Components: Java SCA OSGi Integration >Reporter: Rajini Sivaram >Priority: Minor > Attachments: tuscany-implementation-osgi-patch.txt > > > Patch with support for @EagerInit, and changes to make creation of OSGi > instances thread-safe. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1409) Make OSGi instance creation thread-safe, and support @EagerInit
Make OSGi instance creation thread-safe, and support @EagerInit --- Key: TUSCANY-1409 URL: https://issues.apache.org/jira/browse/TUSCANY-1409 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Priority: Minor Patch with support for @EagerInit, and changes to make creation of OSGi instances thread-safe. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-1382) Minor fixes to OSGi declarative services support and additional tests
Ant, Thank you for applying the patches. The code that currently looks up OSGi services is not thread-safe, and hence the intermittent failures. I will submit a patch. Thank you... Regards, Rajini On 7/3/07, ant elder <[EMAIL PROTECTED]> wrote: The OSGi implementation and sample are building fine now so I've added them to the main Tuscany build. I've not yet added the itest to the main build as I'm getting intermittent failures when i run them. Mostly NPE's but its only sometimes and not always the same itest that fails so I'm not sure whats going on. Could others try a few times and see if they see any problems? Failures are things like: test(supplychain.wiring.DSWiring2TestCase) Time elapsed: 0.828 sec <<< ERROR! java.lang.NullPointerException at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiInstanceWrapper.getInstance( OSGiInstanceWrapper.java:73) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget (OSGiTargetInvoker.java:115) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke( OSGiTargetInvoker.java:164) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke( AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke ( JDKInvocationHandler.java:73) at $Proxy9.hasOutstandingOrders(Unknown Source) at supplychain.SupplyChainTestCase.test(SupplyChainTestCase.java :66) ...ant On 6/26/07, Rajini Sivaram (JIRA) wrote: > > > [ https://issues.apache.org/jira/browse/TUSCANY-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Rajini Sivaram updated TUSCANY-1382: > > > Attachment: itest-osgi-implementation.zip > sample-osgi-supplychain-patch.txt > tuscany-implementation-osgi-patch.txt > > tuscany-implementation-osgi-patch.txt contains patches to > modules/implementation-osgi. > > sample-osgi-supplychain-patch.txt contains patches to > samples/osgi-supplychain (modified for declarative services). > > itest-osgi-implementation.zip contains integration tests for > osgi-implementation. > > > Minor fixes to OSGi declarative services support and additional tests > > - > > > > Key: TUSCANY-1382 > > URL: > https://issues.apache.org/jira/browse/TUSCANY-1382 > > Project: Tuscany > > Issue Type: Improvement > > Components: Java SCA OSGi Integration > >Reporter: Rajini Sivaram > > Attachments: itest-osgi-implementation.zip, > sample-osgi-supplychain-patch.txt , > tuscany-implementation-osgi-patch.txt > > > > > > Attached are patches to osgi-implementation support. > > Changes include improved support for declarative services and > versioning and changes to the directory structure to make it in line with > implementation-java. > > Integration tests are included in the zip file. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: NoClassDefFoundError for DefaultContributionPostProcessorExtensionPoint
This error was fixed in the section in revision 552945, but there are four more places in the section that also need changing. Simon Luciano Resende wrote: I have already changed that under revision #552945 as part of the fix for tuscany-1407 On 7/3/07, Simon Nash <[EMAIL PROTECTED]> wrote: I found the problem eventually. There's a bad pom.xml file in samples/simple-callback-ws. Everywhere that 0.90-incubating appears in this file, it needs to be changed to 1.0-incubating-SNAPSHOT Simon Simon Nash wrote: > I'm getting the following error from the new simple-callback-ws sample > when I run a full top-level mvn build against my test codebase that has > the latest incarnation of the fix to TUSCANY-1341. The problem doesn't > occur when I run mvn from the samples directory, or when I run mvn from > the samples/simple-callback-ws directory. I haven't made any code > changes that seem like they could cause this error. Has anyone seen > this before, or are there any suggestions for debugging? > > Simon > > --- > T E S T S > --- > Running simplecallback.SimpleCallbackTestCase > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.381 > sec <<< FAILURE! > test(simplecallback.SimpleCallbackTestCase) Time elapsed: 0.311 sec > <<< ERROR! > java.lang.NoClassDefFoundError: > org/apache/tuscany/sca/contribution/processor/DefaultContributionPostProcessorExtensionPoint > > at > org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntimeBuilder.createContributionService(ReallySmallRuntimeBuilder.java:189) > > at > org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:113) > > at > org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:86) > > at > org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:229) > > at > org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:68) > > at > simplecallback.SimpleCallbackTestCase.setUp(SimpleCallbackTestCase.java:34) > at junit.framework.TestCase.runBare(TestCase.java:132) > at junit.framework.TestResult$1.protect(TestResult.java:110) > at junit.framework.TestResult.runProtected(TestResult.java:128) > at junit.framework.TestResult.run(TestResult.java:113) > at junit.framework.TestCase.run(TestCase.java:124) > at junit.framework.TestSuite.runTest(TestSuite.java:232) > at junit.framework.TestSuite.run(TestSuite.java:227) > at > org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) > > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) > > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) > > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) > > at org.apache.maven.surefire.Surefire.run(Surefire.java:132) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) > > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) > > > > Results : > > Tests in error: > test(simplecallback.SimpleCallbackTestCase) > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
