Re: Versioning of Tuscany
I think this is one of those discussions where there is no 'right' answer. I wonder if we can start with an initial, fairly crude, approach and refine it as we learn from experience. I like to have faith in folks doing the right thing until they demonstrate otherwise, so having version ranges of [current version, next major version) seems like the right place to start. As we identify libraries which don't respect compatibility within a major version, then we can perhaps add them to our 'black list' and give them narrower version ranges. Perhaps I'm just too optimistic, but it would be good if we could agree on a place to start, so we can learn. Regards, Graham. 2008/6/12 Rajini Sivaram <[EMAIL PROTECTED]>: > On 6/12/08, Simon Nash <[EMAIL PROTECTED]> wrote: > >> I am very pleased to see this discussion happening. My thoughts below. >> >> Simon >> >> Rajini Sivaram wrote: >> >>> On 6/12/08, Graham Charters <[EMAIL PROTECTED]> wrote: >>> >>> Hi Rajini, I think your summary on the wiki is great. I have a couple >>>> of comments: >>>> >>>> 1. I believe SpringSource try to create sensible version ranges based >>>> on the versioning governance of the project, such as that of Apache >>>> [1]. I have no doubt this takes quite a bit of effort and there are a >>>> number of examples which do not follow guidelines, but it seems like a >>>> sensible place to start. >>>> >>> >>> >>> "Sensible" is quite difficult to define. Here is example of one of the >>> SpringSource versioned jars - Axiom 1.2.5 (this is on Apache License): >>> >>> The versions going upto infinity are those provided by the Java SDK. For >>> the >>> others, the minimum versions are similar to the minimum versions that we >>> would generate using maven-bundle-plugin in Tuscany (based on current >>> versions), and the maximum versions (at least in this example) go upto the >>> maximum within the major version range. I have only looked at a few, but >>> the >>> ones I looked at follow this pattern. >>> >>> javax.activation [1.1.0, 2.0.0) >>> javax.mail [1.4.0, 2.0.0) >>> javax.mail.internet [1.4.0, 2.0.0) >>> javax.xml.namespace [0.0.0,infinity) >>> javax.xml.stream [1.0.1, 2.0.0) >>> junit.framework[3.8.2, 4.0.0) >>> org.apache.commons.logging [1.1.1, 2.0.0) >>> org.jaxen [1.1.1, 2.0.0) >>> org.jaxen.saxpath [1.1.1, 2.0.0) >>> org.jaxen.util [1.1.1, 2.0.0) >>> org.w3c.dom [0.0.0,infinity) >>> org.xml.sax [0.0.0,infinity) >>> org.xml.sax.helpers[0.0.0,infinity) >>> >>> Whenever we import a package using a version other than the currently >>> implemented and tested versions, we are making an assumption about being >>> future-proof. IMHO, that is hardly ever the case. eg. If Tuscany 1.2.1 was >>> released with Axis version 1.3, and Axis version 1.4 was not available for >>> testing at the time, can we really assume that Tuscany 1.2.1 will work >>> with >>> Axis 1.4 when it comes out just because the major version has not changed? >>> By choosing the version range [1.3.0,2.0.0) for Tuscany imports, we are >>> making that assumption. Now this does not matter as long as the user wants >>> to use Tuscany out of the box and does not install Axis version 1.4 into >>> the >>> OSGi runtime. But what happens when the user does install Axis 1.4 to use >>> it >>> with another application? Tuscany could fall over in spite of the fact >>> that >>> there is an Axis 1.3 present in the runtime, because Tuscany will be wired >>> to 1.4 since it believed that it would work with any version beyond 1.3. I >>> do agree that SpringSource provides a good starting point, since a lot of >>> work has already gone into it. But I would expect that some level of fine >>> tuning will be required for Tuscany beyond that. >>> >>> I think this is a serious problem and we do need to take into account >> that users will install higher levels of Tuscany dependencies such as >> Axis2. >> >> We could guard against Tuscany breaking in this case by specifying the >> Axis2 dependency as a narrower range such as (1.3.0, 1.4.0) instead of >> (1.3.0, 2.0.0). This would mean that if Axis2 1.4 is installed, Tuscany >> will still use Axis2 1.3 even though other code is us
Re: Versioning of Tuscany
Hi Rajini, I think your summary on the wiki is great. I have a couple of comments: 1. I believe SpringSource try to create sensible version ranges based on the versioning governance of the project, such as that of Apache [1]. I have no doubt this takes quite a bit of effort and there are a number of examples which do not follow guidelines, but it seems like a sensible place to start. At least this approach is not arbitrary and therefore, IMO, stands a chance of working in most situations. Arbitrary schemes will be difficult to explain and defend when issues arise. I dislike the idea of narrow or broad ranges for the reasons you state. 2. You asked if we should be able to work with bundles from other projects (e.g. ServiceMix, SpringSource Application Platform). I wonder if we're able to learn from these projects to seed our versioning. The SpringSource repository, for example, seems to allow this, although I'm no legal expert [2]. Regards, Graham. [1] http://commons.apache.org/releases/versioning.html [2] http://www.springsource.com/repository/app/faq;jsessionid=3F9467729AC282FE4E08199FDCE40863#q6 2008/6/11 Rajini Sivaram <[EMAIL PROTECTED]>: > Following on from the discussion on OSGi-enabling third party libraries ( > http://markmail.org/message/snltdk2yovr6maq5), this thread addresses the > options for versioning Tuscany bundles and 3rd party libraries distributed > with Tuscany and the implications of choosing these options. I have put > together some notes on the wiki ( > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Versioning) > > There were two outstanding questions from Simon Nash in the previous > discussion which I will summarize here to ensure that they are not lost in > this discussion. > > 1. Why can't we generate import constraints which will suit all > applications? > 2. *I'm concerned by the assumption here that Tuscany's versions of 3rd > party bundles will be used both by Tuscany and by applications. An > application may be using other software as well as Tuscany, and this other > software may include its own versions of bundles for javax.servlet or jaxb. > If Tuscany requires its versions of these bundles to be used, and the other > software requires its versions to be used, this requires the application > developer to understand how to resolve any conflicts.* > > The answer to 1) relates to how broad (or narrow) version ranges in imports > are. Broad ranges prevent isolation and reduce scope for side-by-side > execution, narrow ranges prevent class sharing and upgrading to newer > versions. There is more detail with examples on the wiki. > > Question 2) is addressed first on the wiki (Figure 1 and Figure 2 show these > scenarios). I would personally like to follow OSGi best practice and enable > maximum sharing. There are some cases where we have no choice but to share > (eg. SDO). I don't believe we can eliminate conflicts altogether - but > following standard practice will make it less complicated for OSGi > developers to resolve conflicts. > > Thoughts? > > > Thank you... > > Regards, > > Rajini >
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
+1 from me also. We shouldn't confuse modularity purely with versioning or whether something can be used on its own. It's also about being able to make different combinations of modules to fit different deployment profiles. I think it was Ant who first brought up the distinction between what make sense in terms of modularity and what makes sense from a user's perspective. I think having 1 bundle per Tuscany module and third-party jar is fine so long as we provide some way of aggregating those in ways that make sense for how users will consume them. For example, I as a user might want to think in terms of a core runtime + implementation type X and binding Y. That's three concepts to me, not 123 bundles. Hope this make sense. Regards, Graham. 2008/6/12 Jean-Sebastien Delfino <[EMAIL PROTECTED]>: > Raymond Feng wrote: >> >> Hi, >> >> There are a few patterns we use to determine if a maven module is >> required. Let's take the contribution stuff as an example. >> >> 1) contribution contains the interfaces for the contribution model and >> default implementation classes, SPIs and extension points >> 2) contribution-xml deals with the reading/writing the xml document for >> the sca-contribution.xml >> 3) contribution-java, contribution-namspace, contribution-resource deal >> with a specific perspective of the contribution, for example, namespace, >> java, resource >> 4) contribution-osgi, contribution-groovy support specific packaging >> schemes of the SCA contributions. >> >> Please note there is a tree-like dependency graph. I don't think it makes >> sense to merge the siblings into one module. Since an ancestor (for example >> contribution) are shared by mulitple children (-xml, -osgi, etc), it also >> not desirable to merge the common ancestor with other modules. >> >> For databinding related modules, we have a similar strcuture: >> 1) databinding: The base model, SPIs and transformers for various XML >> technologies >> 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The >> individual databinding technologies >> 3) core-databinding: A set of hook code that leverage the databinding >> framework in the invocation chains (data transformation interceptors) >> >> We can use 1 as the data transformation utility in binding/implementation >> or even 3rd party code without 3. We can also pick one or more modules from >> 2. >> >> What I'm trying to point out is that our maven module structure reflects >> the nature of the feature units and dependencies fairly well. IMO, each >> module maps well into an OSGi bundle. IMHO, both the maven module and OSGi >> bundle follow the same principles and the results should be consistent. >> >> Thanks, >> Raymond >> > > +1 to all that, makes a lot of sense to me! > > -- > Jean-Sebastien >
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Hi Rajini, couple of comments below 2008/6/11 Rajini Sivaram <[EMAIL PROTECTED]>: > On 6/11/08, Graham Charters <[EMAIL PROTECTED]> wrote: >> >> If we assume one bundle per Tuscany module for developers, perhaps >> there's a need for a separate concept that provides a simplified view >> for users? The SpringSource Application Platform has the concept of a >> library, which has caused much debate in the OSGi world (it has its >> own manifest header). A library is a collection of bundles which >> gives the developer a single 'thing' on which to depend. At runtime >> the concept goes away and just results in Import/Export-Package >> statements created through manifest re-writing (the library does not >> affect package visibility). I'm not suggesting we use the same >> approach, but it just highlights that others a felt the need for an >> 'aggregation' concept. >> >> I wonder if a bundle repository might also provide such a capability, >> but I'm not too familiar with things like OBR at the moment. > > > OBR does provide similar capability, but IMO the problem with all these > approaches (OBR, SpringSource library) is that none of them is a standard. I > just hope we dont invent yet another one. > RFC 112 covers the design for a Bundle Repository (inspired by OBR) so is some way along the path to being a standard. This might make the OBR approach a safer bet. > On the subject of the ExtensionRegistry. This is not a standard OSGi >> feature, but I've been told the Equinox implementation should run on >> any standard OSGi implementation (e.g. Felix). Is there any reason >> why we wouldn't just use the standard service registry? It has all >> the features required to manage the lifecycle of new extensions being >> installed/uninstalled, etc. > > > You have probably read this already, but others may find Neil Bartlett's > discussion useful: > http://www.eclipsezone.com/articles/extensions-vs-services/ > I dont actually have an opinion, just pointing to the docs. > Yes, but thanks for the pointer. It's an excellent article. My comment was less about the technical pros/cons of each approach and more about the standards aspect, although the technical aspects need to be considered. > Regards, Graham. >> >> 2008/6/11 ant elder <[EMAIL PROTECTED]>: >> > On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram < >> > [EMAIL PROTECTED]> wrote: >> > >> > >> > >> > If we are anyway going to require a "launcher" of some form, >> >> wouldn't it be just as easy to maintain one-bundle-per-module? >> >> >> > >> > I agree, if we go back to requiring a launcher that changes a lot how >> we'd >> > could put this together. I'm not at all against requiring a launcher as >> that >> > does make things easier in some respects, but lets remember why we did >> used >> > to do this and then chucked it out in the 0.90 rewrite ;) >> > >> > ...ant >> > >> > > > > -- > Thank you... > > Regards, > > Rajini >
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
2008/6/11 ant elder <[EMAIL PROTECTED]>: > On Wed, Jun 11, 2008 at 2:31 PM, Rajini Sivaram < > [EMAIL PROTECTED]> wrote: > > ,snip> > > >> >> You have probably read this already, but others may find Neil Bartlett's >> discussion useful: >> http://www.eclipsezone.com/articles/extensions-vs-services/ >> > > Great article, thanks for the link. Thats over a year old now so has much > changed eg in relation to comments like "The "delayed" services feature > requires some small tweaks to the basic Equinox runtime, and these tweaks > have not been implemented yet in the released version 3.2. They do not > appear at all yet (at the time of writing) in the other open source OSGi > runtimes, Apache Felix and Knopflerfish."? > > ...ant > The delayed services feature is supported in Equinox. The equinox implementation was improved by a contribution from Prosyst. Felix has DS support and documentation mentions the "immediate" attribute used to control delayed services, so I'm guessing it is also supported in that project. I've not looked at Knopflerfish. Regards, Graham
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
If we assume one bundle per Tuscany module for developers, perhaps there's a need for a separate concept that provides a simplified view for users? The SpringSource Application Platform has the concept of a library, which has caused much debate in the OSGi world (it has its own manifest header). A library is a collection of bundles which gives the developer a single 'thing' on which to depend. At runtime the concept goes away and just results in Import/Export-Package statements created through manifest re-writing (the library does not affect package visibility). I'm not suggesting we use the same approach, but it just highlights that others a felt the need for an 'aggregation' concept. I wonder if a bundle repository might also provide such a capability, but I'm not too familiar with things like OBR at the moment. On the subject of the ExtensionRegistry. This is not a standard OSGi feature, but I've been told the Equinox implementation should run on any standard OSGi implementation (e.g. Felix). Is there any reason why we wouldn't just use the standard service registry? It has all the features required to manage the lifecycle of new extensions being installed/uninstalled, etc. Regards, Graham. 2008/6/11 ant elder <[EMAIL PROTECTED]>: > On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram < > [EMAIL PROTECTED]> wrote: > > > > If we are anyway going to require a "launcher" of some form, >> wouldn't it be just as easy to maintain one-bundle-per-module? >> > > I agree, if we go back to requiring a launcher that changes a lot how we'd > could put this together. I'm not at all against requiring a launcher as that > does make things easier in some respects, but lets remember why we did used > to do this and then chucked it out in the 0.90 rewrite ;) > > ...ant >
Re: OSGi-enable 3rd party libraries in Tuscany
FWIW, I agree with Sebastien and Rajini. I don't believe it's a coincidence that both SpringSource and ServiceMix went the route of adding manifests to the thirdparty jars. It keeps things simple and gives a better experience from an OSGi perspective. If we're serious about supporting OSGi we should try to do the right thing by the technology. Whilst not necessarily an argument against virtual bundles, I also agree that we should have properly authored dependencies. This view is supported by the discussion Rajini is having in Jira 2343. I know for a fact that SpringSource work very hard to ensure the version ranges on their dependencies are sensible (e.g. match the rules governing version increments for each project). I don't believe we can completely do away with virtual bundles in the short term, but we should only use them where necessary (e.g for signed jars and jars which require code extensions to function in OSGi). Regards, Graham. 2008/5/29 Jean-Sebastien Delfino <[EMAIL PROTECTED]>: > Rajini Sivaram wrote: > >> There is no technical reason why we can't store 3rd party jars separately >> and merge them at runtime to create "virtual bundles", rather than >> distribute "real bundles" containing these manifests. I think the issues >> are: >> >> 1. The build will be harder and messier since existing tools are not >> geared to do this >> 2. The distribution will be messier from an OSGi perspective > > Agreed. How about keeping things simple and clean?? > >> 3. OSGi will continue to remain a peripheral feature of Tuscany, never >> properly integrated since this is not really mainstream. > > Agreed. > >> 4. Real bundles provide more flexibility to OSGi users in terms of >> substituting 3rd party jars with newer or patched versions of these, as >> well >> as avoiding classloading conflicts resulting from version constraints. >> > > Good point too. > > My 2c: Generating bundles automatically from JARs is useless. If you want to > leverage OSGi you need to make authoring / fine tuning your imports/exports > a first class part of your development process. > > I'm starting to feel like a broken record, so I'm going to say it one last > time, for the record. I think we should just follow a simple approach and > add proper (authored) OSGi entries to our JARs and 3rd party dependency > JARs. This doesn't multiply distros, doesn't duplicate JARs, does not > complicate the build. It just makes simple sense IMHO, and other projects > with experience with OSGi are on that path too. > > -- > Jean-Sebastien >
[jira] Commented: (TUSCANY-2330) Calculator sample running in OSGi
[ https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599389#action_12599389 ] Graham Charters commented on TUSCANY-2330: -- Hi Rajini, sorry for taking so long to respond. Please go ahead and check the code in with your update. Changing it to use Felix is fine by me. I tested it with both and there was little discernible difference in performance. Thanks, Graham. > Calculator sample running in OSGi > - > > Key: TUSCANY-2330 > URL: https://issues.apache.org/jira/browse/TUSCANY-2330 > Project: Tuscany > Issue Type: Wish > Components: Java SCA Samples >Affects Versions: Java-SCA-Next > Environment: All >Reporter: Graham Charters > Fix For: Java-SCA-Next > > Attachments: calculator-osgi-sample.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > It would help with preserving OSGi support if an OSGi sample were run as a > matter of course, rather than only by a small number of developers. This > wish is to add the smallest sample possible based on existing Tuscany module > dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2330) Calculator sample running in OSGi
[ https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598616#action_12598616 ] Graham Charters commented on TUSCANY-2330: -- Hi Rajini, I think what you're suggesting make sense. I won't be able to look at this until Friday. Thanks for the offer of help, I'll let you know if I need some. Regards, Graham. > Calculator sample running in OSGi > - > > Key: TUSCANY-2330 > URL: https://issues.apache.org/jira/browse/TUSCANY-2330 > Project: Tuscany > Issue Type: Wish > Components: Java SCA Samples >Affects Versions: Java-SCA-Next > Environment: All >Reporter: Graham Charters > Fix For: Java-SCA-Next > > Attachments: calculator-osgi-sample.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > It would help with preserving OSGi support if an OSGi sample were run as a > matter of course, rather than only by a small number of developers. This > wish is to add the smallest sample possible based on existing Tuscany module > dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2330) Calculator sample running in OSGi
[ https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Charters updated TUSCANY-2330: - Attachment: calculator-osgi-sample.patch > Calculator sample running in OSGi > - > > Key: TUSCANY-2330 > URL: https://issues.apache.org/jira/browse/TUSCANY-2330 > Project: Tuscany > Issue Type: Wish > Components: Java SCA Samples >Affects Versions: Java-SCA-Next > Environment: All >Reporter: Graham Charters > Fix For: Java-SCA-Next > > Attachments: calculator-osgi-sample.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > It would help with preserving OSGi support if an OSGi sample were run as a > matter of course, rather than only by a small number of developers. This > wish is to add the smallest sample possible based on existing Tuscany module > dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Small OSGi sample for the main build?
I've submitted a patch to add the sample (Jira 2330). 2008/5/20 ant elder <[EMAIL PROTECTED]>: > Sounds good to me. > > ...ant > > On Mon, May 19, 2008 at 9:50 PM, Graham Charters <[EMAIL PROTECTED]> > wrote: > >> Hi, >> >> I now have the Calculator sample running using all the great work >> Rajini did to use Equinox, 1 bundle per third-party library, and >> absolute jar paths. It results in 119 bundles, uses 19MB and takes >> about 50 seconds to run. If folks are ok with this, I will create a >> Jira and submit it as a patch for inclusion in the samples main build. >> >> Regards, Graham. >> >> 2008/5/19 Graham Charters <[EMAIL PROTECTED]>: >> > Hi Rajini, >> > >> > 2008/5/18 Rajini Sivaram <[EMAIL PROTECTED]>: >> >> Graham, >> >> >> >> Is there any reason you didn't switch over to one-bundle-per-3rdparty >> jar? >> >> >> > >> > I couldn't get the itest/osgi-tuscany tests to pass and ran out of >> > time :-( . I've tried with the latest and most are now passing, but I >> > still have 6 or 7 failures (varies). >> > >> >> I have replaced the manifest.jar file in itest/osgi-tuscany with an >> >> osgi-installer.jar which accepts both absolute and relative pathnames >> for >> >> jar files. The tests generate and use absolute pathnames, avoiding jar >> >> copying. If we add this to the distribution, we can continue to use >> relative >> >> pathnames to make the file portable. >> >> >> > >> > That's great, thanks! I'll take a look and give it a go with the >> > Calculator sample. >> > >> >> Now itest/osgi-tuscany typically takes around 5.5 minutes to run on my >> T61, >> >> and uses 50MB disk space for around 190 bundles. itest/osgi-tuscany >> >> currently runs around 28 samples using OSGi bundle contributions for the >> >> samples, and reruns 16 of these using non-OSGi contributions (ie, URL >> >> classloaders for the contributions, OSGi classloaders for Tuscany). For >> the >> >> calculator sample, I imagine the lowest that you can bring the time down >> to >> >> may be around 30 seconds (down from 1 minute that you are currently able >> to >> >> get). Apart from removing the manifest as Simon suggested (which will >> >> improve both timing and disk usage), I am not sure it is worth putting >> too >> >> much time into performance of the sample at this stage. You should be >> able >> >> to use the osgi-installer from itest/osgi-tuscany as is, if you are >> happy to >> >> use one-bundle-per-3rdparty jar. >> >> >> > >> > I agree about the performance point. I think 1 minute is a small >> sacrifice. >> > >> >> BTW, I had switched itest/osgi-tuscany to running under Equinox by >> default a >> >> few days ago since Felix performance was degrading too much as we added >> more >> >> and more bundles. >> >> >> > >> > I noticed you'd switched over. I'll try the same. >> > >> >> >> >> On 5/16/08, Simon Nash <[EMAIL PROTECTED]> wrote: >> >>> >> >>> Graham Charters wrote: >> >>> >> >>>> Below are a couple of runs, one taking 2 mins 50s and the second >> >>>> taking 1 min 8s. Both were done after mvn cleans so the difference is >> >>>> maybe due to my machine being under spec and paging. >> >>>> >> >>>> [INFO] >> >>>> >> >> >>>> [INFO] Reactor Summary: >> >>>> [INFO] >> >>>> >> >> >>>> [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for >> >>>> Calculator Sample SUCCESS [1:06.859s] >> >>>> [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator >> >>>> Sample SUCCESS [31.297s] >> >>>> [INFO] Calculator Sample Running in an OSGi Framework SUCCESS >> >>>> [1:07.594s] >> >>>> [INFO] Calculator Sample Running in an OSGi Framework SUCCESS >> >>>> [4.687s] >> >>>> [INFO] >> >>>> >>
[jira] Created: (TUSCANY-2330) Calculator sample running in OSGi
Calculator sample running in OSGi - Key: TUSCANY-2330 URL: https://issues.apache.org/jira/browse/TUSCANY-2330 Project: Tuscany Issue Type: Wish Components: Java SCA Samples Affects Versions: Java-SCA-Next Environment: All Reporter: Graham Charters Fix For: Java-SCA-Next It would help with preserving OSGi support if an OSGi sample were run as a matter of course, rather than only by a small number of developers. This wish is to add the smallest sample possible based on existing Tuscany module dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Small OSGi sample for the main build?
Hi, I now have the Calculator sample running using all the great work Rajini did to use Equinox, 1 bundle per third-party library, and absolute jar paths. It results in 119 bundles, uses 19MB and takes about 50 seconds to run. If folks are ok with this, I will create a Jira and submit it as a patch for inclusion in the samples main build. Regards, Graham. 2008/5/19 Graham Charters <[EMAIL PROTECTED]>: > Hi Rajini, > > 2008/5/18 Rajini Sivaram <[EMAIL PROTECTED]>: >> Graham, >> >> Is there any reason you didn't switch over to one-bundle-per-3rdparty jar? >> > > I couldn't get the itest/osgi-tuscany tests to pass and ran out of > time :-( . I've tried with the latest and most are now passing, but I > still have 6 or 7 failures (varies). > >> I have replaced the manifest.jar file in itest/osgi-tuscany with an >> osgi-installer.jar which accepts both absolute and relative pathnames for >> jar files. The tests generate and use absolute pathnames, avoiding jar >> copying. If we add this to the distribution, we can continue to use relative >> pathnames to make the file portable. >> > > That's great, thanks! I'll take a look and give it a go with the > Calculator sample. > >> Now itest/osgi-tuscany typically takes around 5.5 minutes to run on my T61, >> and uses 50MB disk space for around 190 bundles. itest/osgi-tuscany >> currently runs around 28 samples using OSGi bundle contributions for the >> samples, and reruns 16 of these using non-OSGi contributions (ie, URL >> classloaders for the contributions, OSGi classloaders for Tuscany). For the >> calculator sample, I imagine the lowest that you can bring the time down to >> may be around 30 seconds (down from 1 minute that you are currently able to >> get). Apart from removing the manifest as Simon suggested (which will >> improve both timing and disk usage), I am not sure it is worth putting too >> much time into performance of the sample at this stage. You should be able >> to use the osgi-installer from itest/osgi-tuscany as is, if you are happy to >> use one-bundle-per-3rdparty jar. >> > > I agree about the performance point. I think 1 minute is a small sacrifice. > >> BTW, I had switched itest/osgi-tuscany to running under Equinox by default a >> few days ago since Felix performance was degrading too much as we added more >> and more bundles. >> > > I noticed you'd switched over. I'll try the same. > >> >> On 5/16/08, Simon Nash <[EMAIL PROTECTED]> wrote: >>> >>> Graham Charters wrote: >>> >>>> Below are a couple of runs, one taking 2 mins 50s and the second >>>> taking 1 min 8s. Both were done after mvn cleans so the difference is >>>> maybe due to my machine being under spec and paging. >>>> >>>> [INFO] >>>> >>>> [INFO] Reactor Summary: >>>> [INFO] >>>> >>>> [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for >>>> Calculator Sample SUCCESS [1:06.859s] >>>> [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator >>>> Sample SUCCESS [31.297s] >>>> [INFO] Calculator Sample Running in an OSGi Framework SUCCESS >>>> [1:07.594s] >>>> [INFO] Calculator Sample Running in an OSGi Framework SUCCESS >>>> [4.687s] >>>> [INFO] >>>> >>>> >>>> [INFO] >>>> >>>> [INFO] Reactor Summary: >>>> [INFO] >>>> >>>> [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for >>>> Calculator Sample SUCCESS [35.406s] >>>> [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator >>>> Sample SUCCESS [7.281s] >>>> [INFO] Calculator Sample Running in an OSGi Framework SUCCESS >>>> [24.172s] >>>> [INFO] Calculator Sample Running in an OSGi Framework SUCCESS >>>> [0.969s] >>>> [INFO] >>>> >>>> >>>> From the above, it seems that the major time cost is the building of >>> the manifest bundles. Graham's earlier not
Re: Small OSGi sample for the main build?
Hi Rajini, 2008/5/18 Rajini Sivaram <[EMAIL PROTECTED]>: > Graham, > > Is there any reason you didn't switch over to one-bundle-per-3rdparty jar? > I couldn't get the itest/osgi-tuscany tests to pass and ran out of time :-( . I've tried with the latest and most are now passing, but I still have 6 or 7 failures (varies). > I have replaced the manifest.jar file in itest/osgi-tuscany with an > osgi-installer.jar which accepts both absolute and relative pathnames for > jar files. The tests generate and use absolute pathnames, avoiding jar > copying. If we add this to the distribution, we can continue to use relative > pathnames to make the file portable. > That's great, thanks! I'll take a look and give it a go with the Calculator sample. > Now itest/osgi-tuscany typically takes around 5.5 minutes to run on my T61, > and uses 50MB disk space for around 190 bundles. itest/osgi-tuscany > currently runs around 28 samples using OSGi bundle contributions for the > samples, and reruns 16 of these using non-OSGi contributions (ie, URL > classloaders for the contributions, OSGi classloaders for Tuscany). For the > calculator sample, I imagine the lowest that you can bring the time down to > may be around 30 seconds (down from 1 minute that you are currently able to > get). Apart from removing the manifest as Simon suggested (which will > improve both timing and disk usage), I am not sure it is worth putting too > much time into performance of the sample at this stage. You should be able > to use the osgi-installer from itest/osgi-tuscany as is, if you are happy to > use one-bundle-per-3rdparty jar. > I agree about the performance point. I think 1 minute is a small sacrifice. > BTW, I had switched itest/osgi-tuscany to running under Equinox by default a > few days ago since Felix performance was degrading too much as we added more > and more bundles. > I noticed you'd switched over. I'll try the same. > > On 5/16/08, Simon Nash <[EMAIL PROTECTED]> wrote: >> >> Graham Charters wrote: >> >>> Below are a couple of runs, one taking 2 mins 50s and the second >>> taking 1 min 8s. Both were done after mvn cleans so the difference is >>> maybe due to my machine being under spec and paging. >>> >>> [INFO] >>> >>> [INFO] Reactor Summary: >>> [INFO] >>> >>> [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for >>> Calculator Sample SUCCESS [1:06.859s] >>> [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator >>> Sample SUCCESS [31.297s] >>> [INFO] Calculator Sample Running in an OSGi Framework SUCCESS >>> [1:07.594s] >>> [INFO] Calculator Sample Running in an OSGi Framework SUCCESS >>> [4.687s] >>> [INFO] >>> >>> >>> [INFO] >>> >>> [INFO] Reactor Summary: >>> [INFO] >>> >>> [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for >>> Calculator Sample SUCCESS [35.406s] >>> [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator >>> Sample SUCCESS [7.281s] >>> [INFO] Calculator Sample Running in an OSGi Framework SUCCESS >>> [24.172s] >>> [INFO] Calculator Sample Running in an OSGi Framework SUCCESS >>> [0.969s] >>> [INFO] >>> >>> >>> From the above, it seems that the major time cost is the building of >> the manifest bundles. Graham's earlier note said that the third-party >> manifest bundle consumes 17.5MB of disk space. >> >> Could the time and space overheads be reduced by building virtual >> bundles (or a single virtual bundle) for the third-party libraries? >> As I understand it, this would save 17.5MB of disk space (as the >> third party libraries are already in my maven repo), and it would >> presumably take less time as nothing would need to be written to disk. >> >> Simon >> >> >>> 2008/5/16 Simon Laws <[EMAIL PROTECTED]>: >>> >>>> On Fri, May 16, 2008 at 1:05 PM, Simon Laws <[EMAIL PROTECTED]> >>>> wrote: >>>> >>>> >>>>> On Fri, May 16, 2008
Re: Small OSGi sample for the main build?
Below are a couple of runs, one taking 2 mins 50s and the second taking 1 min 8s. Both were done after mvn cleans so the difference is maybe due to my machine being under spec and paging. [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [1:06.859s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [31.297s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [1:07.594s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [4.687s] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [35.406s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [7.281s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [24.172s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [0.969s] [INFO] 2008/5/16 Simon Laws <[EMAIL PROTECTED]>: > On Fri, May 16, 2008 at 1:05 PM, Simon Laws <[EMAIL PROTECTED]> > wrote: > >> >> >> On Fri, May 16, 2008 at 12:44 PM, Graham Charters < >> [EMAIL PROTECTED]> wrote: >> >>> Hi, >>> >>> Regarding Mike's build breaking comment, one of the reasons for >>> including this in the main build is to have it break to flag when new >>> dependencies are being introduced. This will help us focus on >>> improving Tuscany modularity, but also help us preserve the support >>> for running in OSGi. It will also give us a place to focus on keeping >>> the core small. >>> >>> I now have what I think is the smallest subset of modules, based on >>> current dependencies. My previous attempt took the approach of >>> cutting down a distribution, but the latest was created by adding to >>> the dependencies of the basic Calculator. The net result is 47 >>> bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes >>> about 2.5 mins to build and run which does not seem like a big delta >>> over and above the time taken to do a full Tuscany build and run all >>> the samples. >>> >>> The sca modules which are installed are: >>> >>> tuscany-assembly-2.0-incubating-SNAPSHOT.jar >>> tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar >>> tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar >>> tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar >>> tuscany-contribution-2.0-incubating-SNAPSHOT.jar >>> tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar >>> tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar >>> tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar >>> tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar >>> tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar >>> tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar >>> tuscany-core-2.0-incubating-SNAPSHOT.jar >>> tuscany-core-spi-2.0-incubating-SNAPSHOT.jar >>> tuscany-databinding-2.0-incubating-SNAPSHOT.jar >>> tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar >>> tuscany-definitions-2.0-incubating-SNAPSHOT.jar >>> tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar >>> tuscany-domain-2.0-incubating-SNAPSHOT.jar >>> tuscany-domain-api-2.0-incubating-SNAPSHOT.jar >>> tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar >>> tuscany-extensibility-2.0-incubating-SNAPSHOT.jar >>> tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar >>> tuscany-host-http-2.0-incubating-SNAPSHOT.jar >>> tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar >>> tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar >>> tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar >>> tuscany-interface-2.0-incubating-SNAPSHOT.jar >>> tuscany-interface-java-2.0-incubating-SNAPSHOT.jar >>> tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar >>> tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar >>> tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar >>> tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar >>> tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar >>
Re: Small OSGi sample for the main build?
Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being introduced. This will help us focus on improving Tuscany modularity, but also help us preserve the support for running in OSGi. It will also give us a place to focus on keeping the core small. I now have what I think is the smallest subset of modules, based on current dependencies. My previous attempt took the approach of cutting down a distribution, but the latest was created by adding to the dependencies of the basic Calculator. The net result is 47 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes about 2.5 mins to build and run which does not seem like a big delta over and above the time taken to do a full Tuscany build and run all the samples. The sca modules which are installed are: tuscany-assembly-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar tuscany-contribution-2.0-incubating-SNAPSHOT.jar tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar tuscany-core-2.0-incubating-SNAPSHOT.jar tuscany-core-spi-2.0-incubating-SNAPSHOT.jar tuscany-databinding-2.0-incubating-SNAPSHOT.jar tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar tuscany-definitions-2.0-incubating-SNAPSHOT.jar tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar tuscany-domain-2.0-incubating-SNAPSHOT.jar tuscany-domain-api-2.0-incubating-SNAPSHOT.jar tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar tuscany-extensibility-2.0-incubating-SNAPSHOT.jar tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar tuscany-host-http-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar tuscany-monitor-2.0-incubating-SNAPSHOT.jar tuscany-node-2.0-incubating-SNAPSHOT.jar tuscany-node-api-2.0-incubating-SNAPSHOT.jar tuscany-node-impl-2.0-incubating-SNAPSHOT.jar tuscany-osgi-runtime-2.0-incubating-SNAPSHOT.jar tuscany-policy-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-ws-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-ws-2.0-incubating-SNAPSHOT.jar tuscany-sca-api-2.0-incubating-SNAPSHOT.jar The third-party jars (currently installed in a single bundle) are: activation-1.1.jar addressing-1.3.mar annogen-0.1.0.jar avalon-framework-4.1.3.jar axiom-api-1.2.5.jar axiom-dom-1.2.5.jar axiom-impl-1.2.5.jar axis2-adb-1.3.jar axis2-adb-codegen-1.3.jar axis2-codegen-1.3.jar axis2-java2wsdl-1.3.jar axis2-kernel-1.3.jar axis2-mtompolicy-1.3.jar backport-util-concurrent-2.2.jar bcprov-jdk15-132.jar cglib-nodep-2.1_3.jar commons-codec-1.3.jar commons-collections-3.1.jar commons-discovery-0.2.jar commons-fileupload-1.1.1.jar commons-httpclient-3.0.1.jar commons-io-1.2.jar commons-logging-1.1.jar geronimo-activation_1.1_spec-1.0-M1.jar geronimo-commonj_1.1_spec-1.0.jar geronimo-javamail_1.4_spec-1.0-M1.jar geronimo-jms_1.1_spec-1.1.jar httpcore-4.0-alpha5.jar httpcore-nio-4.0-alpha5.jar httpcore-niossl-4.0-alpha5.jar jaxb-api-2.1.jar jaxb-impl-2.1.6.jar jaxb2-reflection-2.1.4.jar jaxen-1.1-beta-9.jar jaxws-api-2.1.jar jettison-1.0.jar json-rpc-1.0.jar jsr181-api-1.0-MR1.jar jsr250-api-1.0.jar junit-4.2.jar log4j-1.2.12.jar logkit-1.0.1.jar mail-1.4.jar neethi-2.0.2.jar opensaml-1.1.jar org.apache.felix.bundlerepository-1.1.0-SNAPSHOT.jar org.apache.felix.framework-1.1.0-SNAPSHOT.jar org.apache.felix.main-1.1.0-SNAPSHOT.jar org.apache.felix.shell-1.1.0-SNAPSHOT.jar org.apache.felix.shell.tui-1.1.0-SNAPSHOT.jar org.osgi.core-1.0.0.jar rampart-core-1.3.jar rampart-policy-1.3.jar rampart-trust-1.3.jar saaj-api-1.3.jar servlet-api-2.4.jar stax-api-1.0-2.jar stax-api-1.0.1.jar woden-1.0-incubating-M7b.jar wsdl4j-1.6.2.jar wss4j-1.5.3.jar wstx-asl-3.2.1.jar xalan-2.7.0.jar xercesImpl-2.8.1.jar xml-apis-1.3.03.jar XmlSchema-1.3.2.jar xmlsec-1.4.0.jar Let me know what you think? Regards, Graham. 2008/5/15 Mike Edwards <[EMAIL PROTECTED]>: > Graham Charters wrote: >> >> Hi, >> >> I've been working on a small sample to act as an
Small OSGi sample for the main build?
Hi, I've been working on a small sample to act as an OSGi "sniff test" for Tuscany running in OSGi. It's basically a cut-down version of what Rajini has done in itest/osgi-tuscany and only runs the most basic Calculator sample. I still have some work to do to exclude all the things which aren't required and also perhaps move it to use the latest "1 manifest per 3rd party jar" approach. Currently the sample takes ~3 mins to build and run and uses 56MB. The main space usage is 17.5MB for the third-party dependencies and 35MB for the Felix bundle cache (61 bundles in total). The full Tuscany (itest/osgi-tuscany) using the same third-party library approach is 151 bundles and 133MB total. I'd like to understand whether people feel this would be useful and whether it is approaching the kind of overhead that would be acceptable for it to be included in the main build? Regards, Graham.
Re: Need some help
+1 to the SCA and PHP integration. If you're interested, I would be more than happy to help smooth the way with the associated SCA_SDO project on PECL (http://pecl.php.net/package/SCA_SDO). Regards, Graham. 2008/5/8 Simon Nash <[EMAIL PROTECTED]>: > > Simon Laws wrote: > > > On Thu, May 8, 2008 at 8:48 PM, Charuka Jayarathna > <[EMAIL PROTECTED]> > > wrote: > > > > > > > Dear all, > > > > > > I am a Masters student in Georgia State University, and hope to work > > > on my Theses with some contribution to Tuscany. My adviser is fine > > > with my suggestion to take over a Tuscany project and work on that as > > > for my theses. He advises me to take over a project which has enough > > > intellectual contribution as well as it should be a novel idea > > > resulting a publishable paper at the end. I appreciate if you can help > > > me finding some potential areas having above requirements fulfilled. > > > > > > Thank you > > > Charuka > > > > > > > > > > Hi Charuka, welcome to Tuscany! > > > > We'd love to have you work with us on a Tuscany project. As it happens we > > went through a process a couple of months ago to come up with project > ideas > > for Google Summer of Code this year. See the list we came up with here [1] > > as a starting point. Some of these projects are already being done by GSoC > > students. See the selected project proposals on this page [2]. It's > probably > > not a good idea to take on one that is already being done. > > > > What we need is a new page listing all the current project ideas we have > > that people aren't working on. Luciano may have done this already and I'm > > sure he will point us to it if he has. If not this is just the kind of > > motivation we need to go and create one ;-) > > > > I'm sure we can come up with lots of other ideas so take a look at the > list > > that's there and I'm sure people will post with new things here in due > > course. > > > > Regards > > > > Simon > > > > [1] > > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Google+Summer+of+Code+%282008%29 > > [2] > > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Google+Summer+of+Code+%282008%29+Applications > > > > > There was a proposal for SCA and PHP integration. It was added > quite late and I don't believe anyone has taken it on. Is this > of any possible interest? > > Simon >
Re: build failure in store-test
I updated this morning and also saw the Segmentation Fault. I've since re-run and now only see the Exception. Further up on the build there's also the following SQL Exception: INFO: Starting node: http://localhost:9990/node-config/StoreClientNode Connecting to database: jdbc:derby:directory:C:\Tuscany\java\sca\tutorial\store- test/../store-supplier/target/cart-db 06-May-2008 15:44:59 org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet /ShoppingCart/Cart/* threw exception SQL Exception: Failed to start database 'directory:C:\Tuscany\java\sca\tutorial\ store-test/../store-supplier/target/cart-db', see the next exception for details . at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source ) at org.apache.derby.impl.jdbc.EmbedConnection.newSQLException(Unknown So urce) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(Unknown Sourc e) at org.apache.derby.impl.jdbc.EmbedConnection.(Unknown Source) at org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Unknown Source) at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source) at java.sql.DriverManager.getConnection(DriverManager.java:562) at java.sql.DriverManager.getConnection(DriverManager.java:186) at services.db.ShoppingCartTableImpl.init(ShoppingCartTableImpl.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.MethodEventInvo ker.invokeEvent(MethodEventInvoker.java:43) at org.apache.tuscany.sca.implementation.java.context.ReflectiveInstance Wrapper.start(ReflectiveInstanceWrapper.java:46) at org.apache.tuscany.sca.core.scope.StatelessScopeContainer.getWrapper( StatelessScopeContainer.java:39) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementat ionInvoker.invoke(JavaImplementationInvoker.java:89) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.i nvoke(PassByValueInterceptor.java:103) at org.apache.tuscany.sca.binding.atom.provider.AtomBindingListenerServl et.doDelete(AtomBindingListenerServlet.java:527) at javax.servlet.http.HttpServlet.service(HttpServlet.java:733) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce ss(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoin t.java:354) at org.apache.tuscany.sca.core.work.Jsr237Work.run(Jsr237Work.java:61) at org.apache.tuscany.sca.core.work.ThreadPoolWorkManager$DecoratingWork .run(ThreadPoolWorkManager.java:219) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec utor.java:665) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:690) at java.lang.Thread.run(Thread.java:803) 06-May-2008 15:44:59 org.apache.tuscany.sca.node.impl.NodeImpl stop INFO: Stopping node: http://localhost:9990/node-config/StoreSupplierNode 06-May-2008 15:44:59 org.apache.tuscany.sca.node.impl.NodeImpl stop INFO: Stopping node: http://localhost:9990/node-config/CatalogsNode 06-May-2008 15:44:59 org.apache.tuscany.sca.node.impl.NodeImpl stop INFO: Stopping node: http://localhost:9990/node-config/StoreClientNode 06-May-2008 15:44:59 org.apache.coyote.http11.Http11Protocol destroy INFO: Stopping Coyote HTTP/1.1 on http-9990 Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 56.703 sec <<< F AILURE! testShop(test.StoreSupplierTestCase) Time elapsed: 56.625 sec <<< ERROR! org.osoa.sca.ServiceRuntimeException: HTTP status code:
[jira] Updated: (TUSCANY-2285) Make sca-api automatically build as an OSGi bundle
[ https://issues.apache.org/jira/browse/TUSCANY-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Charters updated TUSCANY-2285: - Attachment: sca-api-bundle-2.patch The following patch logically results in the same changes as the previous patch. The key difference is it only uses maven bundle plugin to create the manifest and then uses maven jar plugin to build the jar file (previously maven bundle plugin was also being used to build the jar). > Make sca-api automatically build as an OSGi bundle > -- > > Key: TUSCANY-2285 > URL: https://issues.apache.org/jira/browse/TUSCANY-2285 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core Runtime, Java SCA OSGi Integration >Affects Versions: Java-SCA-Next > Environment: All >Reporter: Graham Charters >Priority: Minor > Fix For: Java-SCA-Next > > Attachments: sca-api-bundle-2.patch, sca-api-bundle.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Itest/osgi-tuscany creates an OSGi bundle for the sca-api module. As a step > towards providing better support for OSGi, it has been suggested on the > dev-list that we simply make sca-api automatically build as an OSGi bundle. > This does not preclude it being used as a normal jar. > I have a patch which I will attached shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Improving support for running in OSGi
Hi Rajini, FWIW, I agree with starting with 1. I missed your earlier note saying you'd be happy to contribute code to do this. Please let me know what I can do to help. I'm particularly interested in the 'virtual bundle' idea. I took a look at the way the samples are run in itest/osgi-tuscany and now I have a better understanding, I agree, it's not as much work as I first thought (fear of the unknown ;-) ). I think the challenge will be in finding the right design to enable it for third-party libraries so it's usable and flexible enough. Perhaps you already have thoughts on this? I was a little surprised you didn't suggest 3 as a stepping stone towards 4 (I guess the '"half-hearted" comment was a bit of a give-away ;-) ). I agree it's not ideal from a modularity perspective but it does have the advantage that I think it could be introduced a lot sooner than 4 and would therefore accelerate sensitizing folks to the issues. Regards, Graham. 2008/5/2 Rajini Sivaram <[EMAIL PROTECTED]>: > On 5/1/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > > Graham Charters wrote: > > > > > It would seem that the fine-grained/coarse-grained thoughts have > > > people divided. Rajini's note (aside from the fact she has a tonne of > > > experience having done most, if not all, of the OSGi work in Tuscany) > > > paints a picture where the two are not mutually exclusive. I don't > > > typically like doing two options because that seems like indecision, > > > but in this case they do appear to complement each other. > > > > > > Based on what I've seen in this thread, I'm hoping this briefly > > > summarizes the collection of thoughts on how we might proceed: > > > > > > Tuscany Running in OSGi > > > > > > 1. Add bundle manifests to all the Tuscany modules (using maven > > > bundle plugin). This will ensure the most fine-grained decomposition > > > works and therefore coarser-grained distributions will also work. > > > 2. Add a distribution which creates bundles around manageable > > > collections of Tuscany modules aligned with how we see the runtime > > > being extended/subsetted/replaced. Have this build and test on > > > Continuum. > > > 3. Create 'virtual bundles' for third-party libraries to avoid > > > licensing and disk space issues (based on Rajini's suggestions, which > > > I need to better understand). > > > 4. Provide guidance on the wiki on how to avoid breaking OSGi. > > > > > > There's also the suggestion that implementation.osgi relate to > > > Distributed OSGi (RFC 119), which shouldn't be lost. > > > > > > Have I missed anything? > > > > > > It sounds like a staging of 1 & 3 first, followed by 2 would work (and > > > 4 if things keep breaking :-( ). I'd be concerned if we didn't get to > > > 2, and as part of 1&3, we need to make sure these are regularly tested > > > under osgi. > > > > > > > > Sounds good to me, with the following comments: > > > > When you have (1) + (3) you can already run a continuum OSGi build, before > > attacking (2). I'd actually suggest to start building on continuum as soon > > as we have (1). > > > > - I'm not clear on what you meant by 'use the Maven bundle plugin'. Will > > we write something like this for example: > > > > ... > > bundle > > ... > > > >org.apache.felix > >maven-bundle-plugin > >true > > > > > >org.apache.tuscany.sca.foo > >org.apache.tuscany.sca.bar > >org.apache.tuscany.sca.impl.* > > > > > > > > ... > > > > I think we have four options on how we start bundle-izing Tuscany modules, > using maven-bundle-plugin. > > > 1. Use the manifest goal to generate the manifest entry in all module jars, > with * and > *, which export all the packages from the > module and import everything used by the module. The Export-Package and > Import-Package statements in the generated manifest will use explicit > package import/exports like: > > Import-Package: > > javax.xml.namespace,javax.xml.parsers,org.apache.tuscany.sca.contribution.resolver,... > Export-Package: > > org.apache.tuscany.sca.implementation.osgi;version="2.0";uses:="o.a.t.s.assembly",/... > > > The analysis of Import/Export will be
Re: [jira] Commented: (TUSCANY-2285) Make sca-api automatically build as an OSGi bundle
Hi Raymond, I've modified the pom to follow the approach you suggested. I need to do a full Tuscany rebuild so will submit an updated patch when I know it works. I agree with Rajini that it would be good to understand the bundle goal problem so we can fix it (or get it fixed). Regards, Graham. 2008/5/2 Rajini Sivaram (JIRA) : > > > [ > https://issues.apache.org/jira/browse/TUSCANY-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593731#action_12593731 > ] > > Rajini Sivaram commented on TUSCANY-2285: > - > > Raymond, > > Was the issue with maven-bundle-plugin and SDO related to building on JDK > 1.4 (which is not supported with Tuscany-SCA)? If not, could you describe the > problem and/or how to recreate it? We can use the manifest goal for sca-api, > but we may want to use bundle/bundleall goals to generate the high-level > combinations for distribution. I am sure the Felix team will help to fix the > problem if we can identify what the issue was. > > Thank you... > > > > Make sca-api automatically build as an OSGi bundle > > -- > > > > Key: TUSCANY-2285 > > URL: https://issues.apache.org/jira/browse/TUSCANY-2285 > > Project: Tuscany > > Issue Type: Improvement > > Components: Java SCA Core Runtime, Java SCA OSGi Integration > >Affects Versions: Java-SCA-Next > > Environment: All > >Reporter: Graham Charters > >Priority: Minor > > Fix For: Java-SCA-Next > > > > Attachments: sca-api-bundle.patch > > > > Original Estimate: 0.5h > > Remaining Estimate: 0.5h > > > > Itest/osgi-tuscany creates an OSGi bundle for the sca-api module. As a > step towards providing better support for OSGi, it has been suggested on the > dev-list that we simply make sca-api automatically build as an OSGi bundle. > This does not preclude it being used as a normal jar. > > I have a patch which I will attached shortly. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: Improving support for running in OSGi
It would seem that the fine-grained/coarse-grained thoughts have people divided. Rajini's note (aside from the fact she has a tonne of experience having done most, if not all, of the OSGi work in Tuscany) paints a picture where the two are not mutually exclusive. I don't typically like doing two options because that seems like indecision, but in this case they do appear to complement each other. Based on what I've seen in this thread, I'm hoping this briefly summarizes the collection of thoughts on how we might proceed: Tuscany Running in OSGi 1. Add bundle manifests to all the Tuscany modules (using maven bundle plugin). This will ensure the most fine-grained decomposition works and therefore coarser-grained distributions will also work. 2. Add a distribution which creates bundles around manageable collections of Tuscany modules aligned with how we see the runtime being extended/subsetted/replaced. Have this build and test on Continuum. 3. Create 'virtual bundles' for third-party libraries to avoid licensing and disk space issues (based on Rajini's suggestions, which I need to better understand). 4. Provide guidance on the wiki on how to avoid breaking OSGi. There's also the suggestion that implementation.osgi relate to Distributed OSGi (RFC 119), which shouldn't be lost. Have I missed anything? It sounds like a staging of 1 & 3 first, followed by 2 would work (and 4 if things keep breaking :-( ). I'd be concerned if we didn't get to 2, and as part of 1&3, we need to make sure these are regularly tested under osgi. 2008/5/1 Mike Edwards <[EMAIL PROTECTED]>: > > Simon Laws wrote: > > > On Thu, May 1, 2008 at 10:03 AM, Rajini Sivaram < > > [EMAIL PROTECTED]> wrote: > > > > > > > On 5/1/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > > > > My 2c: > > > > > > > > +1 to promote OSGi to a first class Tuscany runtime environment > > > > > > > > +1 for an OSGi continuum build (thinking about a build profile that'll > > > > > > > run > > > > > > > the Tuscany itest suite in an OSGi environment, similar to the > profiles > > > > > > > we > > > > > > > have for Web containers for example) > > > > > > > > Here's what I imagined we'd do: > > > > 1. add OSGi entries to each of our JAR manifests > > > > 2. have developers maintain them and pay attention to imports/exports > > > > 3. use the OSGi build to detect API and SPI import/export violations > > > > 4. find the best way to OSGi-enable 3rd party dependency JARs > > > > > > > > I realize that my suggestion [1] is not very popular and most people > on > > > > this list would prefer to come up with bigger bundles grouping several > > > > > > > of > > > > > > > our JARs/modules. I don't think that the 'bigger aggregate bundle' > > > > > > > approach > > > > > > > will work, but I'll be happy to watch people try it :) if they want > to. > > > > > > > > With respect to [4] I find rather funny to see many projects out there > > > > claim OSGi enablement without having OSGified their 3rd party > > > > > > > dependencies. > > > > > > > I wonder how that works, can an OSGi-enabled project really leverage > the > > > > OSGi classloader isolation and versioning capabilities when 99% of the > > > > > > > JARs > > > > > > > it requires are not OSGi bundles? I must be missing something... and I > > > > > > > hope > > > > > > > we can do better in Tuscany with a real end-to-end OSGi enablement > story > > > > > > > :) > > > > > > > -- > > > > Jean-Sebastien > > > > > > > > > > > > > > I agree with Sebastien's suggestions1-4. But I would like to suggest a > > > slight variation to the first suggestion. > > > > > > > > > 1. Use maven-bundle-plugin to introduce OSGi manifest entries into all > > > the Tuscany modules, with auto-generated import/export statements. > > > Modify > > > itest/osgi-tuscany to run these modules under OSGi, with all 3rd party > > > jars > > > installed into OSGi using virtual bundles created on the fly. > > > > > > This step will provide a version of osgi-tuscany tests that is less > prone > > > to > > > breakage than the one we have today. It will also help fix any remaining > > > classloading issues that we have left in Tuscany (and hopefully help > > > in maintaining the classloader isolation). This is not a big piece of > work > > > since this is just bringing together the different pieces that we > already > > > have. I will be happy to contribute the code towards this first step, so > > > others can concentrate on what we really want to achieve in terms of > > > modularity, distribution etc. We can also use this step to explore > > > versioning - in particular about having multiple extensions referring to > > > different versions of 3rd party libraries. This will be very useful for > 4. > > > > > > Suggestions 2-3 are not requirements for OSGi, but these are clearly > cases > > > where OSGi technology can help Tuscany improve modularity. If we want to > > > have explicitly hard-coded import/export statements in the m
[jira] Updated: (TUSCANY-2285) Make sca-api automatically build as an OSGi bundle
[ https://issues.apache.org/jira/browse/TUSCANY-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Charters updated TUSCANY-2285: - Attachment: sca-api-bundle.patch The patch does the following: Updates the sca-api pom to build that module as a bundle. Removes sca-api from itest/osgi-tuscany. Updates itest/osgi-tuscany to use the bundle from modules/sca-api. You will need to do a 'mvn clean' in itest/osgi-tuscany in order to clear out the felix cache, otherwise you may get problems with bundle symbolic name and version not being unique (because the old one is still in the cache). > Make sca-api automatically build as an OSGi bundle > -- > > Key: TUSCANY-2285 > URL: https://issues.apache.org/jira/browse/TUSCANY-2285 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core Runtime, Java SCA OSGi Integration >Affects Versions: Java-SCA-Next > Environment: All >Reporter: Graham Charters >Priority: Minor > Fix For: Java-SCA-Next > > Attachments: sca-api-bundle.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Itest/osgi-tuscany creates an OSGi bundle for the sca-api module. As a step > towards providing better support for OSGi, it has been suggested on the > dev-list that we simply make sca-api automatically build as an OSGi bundle. > This does not preclude it being used as a normal jar. > I have a patch which I will attached shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2285) Make sca-api automatically build as an OSGi bundle
Make sca-api automatically build as an OSGi bundle -- Key: TUSCANY-2285 URL: https://issues.apache.org/jira/browse/TUSCANY-2285 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime, Java SCA OSGi Integration Affects Versions: Java-SCA-Next Environment: All Reporter: Graham Charters Priority: Minor Fix For: Java-SCA-Next Itest/osgi-tuscany creates an OSGi bundle for the sca-api module. As a step towards providing better support for OSGi, it has been suggested on the dev-list that we simply make sca-api automatically build as an OSGi bundle. This does not preclude it being used as a normal jar. I have a patch which I will attached shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Improving support for running in OSGi
Hi Raymond, thanks for your comments. I've added some more below. Regards, Graham. 2008/4/30 Raymond Feng <[EMAIL PROTECTED]>: > More comments inline. > > Thanks, > Raymond > ------ > From: "Graham Charters" <[EMAIL PROTECTED]> > Sent: Wednesday, April 30, 2008 9:43 AM > > To: > Subject: Re: Improving support for running in OSGi > > > > 2008/4/30 Raymond Feng <[EMAIL PROTECTED]>: > > > > > "Enforcing" the modularity via OSGi is a good way to validate our > > > modularity/extensibility story in Tuscany. I think we already have a > fairly > > > well organized module structure in Tuscany (from the maven dependency > > > perspective). To be consistent, should we consider directly mapping our > > > module structure into OSGi bundles (one bundle per existing Tuscany > module)? > > > > > > > > > > I wonder if that might be too fine-grained and unmanageable. > > Personally, I'd prefer an approach which took into consideration how > > we see folks extending or sub-setting the runtime (e.g. the things > > Yang referred to - implementation types, etc.). > > > > > > IMHO, big bundles lead to defeat modularity and increase coupling. It also > become difficult to embed subset of the Tuscany runtime. But anyway, we can > adjust the scheme over time as the picture becomes clearer. > > To a certain extent I agree with you, but there's also a school of thought that says when adopting OSGi it's best to start with big modules and then decompose as understanding grows. I think the thought processes we go through will ensure we end up with the right modules that match the requirements, such as runtime subsetting. > > > > > > There may be different levels for the OSGi enablement. > > > > > > 1) Add OSGi entries to the META-INF/MANIFEST.MF so that Tuscany jars > can be > > > consumed as OSGi bundles > > > 2) Run Tuscany bundles with an OSGi runtime (using OSGi as the > > > modularization mechanism for the Tuscany runtime, system level) > > > > > > > I think we need this step to occur regularly and frequently to stop > > the support decaying. I've fixed these kinds of issues twice in the > > last week, which occur because new modules are added to Tuscany, but > > not the OSGi support (not surprising since the OSGi support is outside > > the main build). > > > > > > Is there a checklist we can use to make sure new modules or changes won't > break the OSGi support? If not, can we produce one and post it to the > Tuscany wiki? > > I think we could produce a checklist to help folks. It would also be nice to make it easier for people to get things right without it. The idea of updating the module structure to reflect the bundles we create is interesting. I guess if the number of bundles is changing rapidly then this might be a bit painful. We could also have the bundles build on continuum so we find problems earlier. Having everyone build the bundles might not be acceptable. > > > > > > 3) Support OSGi bundles as SCA contributions (application level, how > does > > > the OSGi import/export relate to the sca-contributions.xml?). > > > > > > The other interesting issue is how we deal with the 3rd party jars, > most of > > > which are not OSGi bundles. To support the case that different Tuscany > > > extensions may require different versions of the same 3rd party jar, we > need > > > to figure out a good way to "turn" 3rd party jars into OSGi bundles. > > > > > > > > > > This is a knotty problem. It's not a new problem and is discussed > > here: https://mail.osgi.org/pipermail/jsr-291-eg/2006-March/23.html > > > > Licensing and signing can prevent us from adding information to the > > jars, which leaves us with three options, I think: > > > > 1. Create wrapper bundles which contain the jars, which raises > > concerns about disk space. > > 2. Use a non-OSGi mechanism to refer to jars outside a bundle > > (Equinox allows this). > > 3. Devise a new mechanism to create 'virtual bundles' on the fly (see > > https://www.osgi.org/members/bugzilla/show_bug.cgi?id=277). > > > > > > Unfortunately, the URL requires a log-in. Is it possible to post the > content here? > My apologies, I hadn't realized this was a member bug and therefore required access (I must have already been logged in when I tested it). I can't paste in the details, but I can summ
Re: Improving support for running in OSGi
2008/4/30 Raymond Feng <[EMAIL PROTECTED]>: > "Enforcing" the modularity via OSGi is a good way to validate our > modularity/extensibility story in Tuscany. I think we already have a fairly > well organized module structure in Tuscany (from the maven dependency > perspective). To be consistent, should we consider directly mapping our > module structure into OSGi bundles (one bundle per existing Tuscany module)? > I wonder if that might be too fine-grained and unmanageable. Personally, I'd prefer an approach which took into consideration how we see folks extending or sub-setting the runtime (e.g. the things Yang referred to - implementation types, etc.). > There may be different levels for the OSGi enablement. > > 1) Add OSGi entries to the META-INF/MANIFEST.MF so that Tuscany jars can be > consumed as OSGi bundles > 2) Run Tuscany bundles with an OSGi runtime (using OSGi as the > modularization mechanism for the Tuscany runtime, system level) I think we need this step to occur regularly and frequently to stop the support decaying. I've fixed these kinds of issues twice in the last week, which occur because new modules are added to Tuscany, but not the OSGi support (not surprising since the OSGi support is outside the main build). > 3) Support OSGi bundles as SCA contributions (application level, how does > the OSGi import/export relate to the sca-contributions.xml?). > > The other interesting issue is how we deal with the 3rd party jars, most of > which are not OSGi bundles. To support the case that different Tuscany > extensions may require different versions of the same 3rd party jar, we need > to figure out a good way to "turn" 3rd party jars into OSGi bundles. > This is a knotty problem. It's not a new problem and is discussed here: https://mail.osgi.org/pipermail/jsr-291-eg/2006-March/23.html Licensing and signing can prevent us from adding information to the jars, which leaves us with three options, I think: 1. Create wrapper bundles which contain the jars, which raises concerns about disk space. 2. Use a non-OSGi mechanism to refer to jars outside a bundle (Equinox allows this). 3. Devise a new mechanism to create 'virtual bundles' on the fly (see https://www.osgi.org/members/bugzilla/show_bug.cgi?id=277). 3 might be the best solution longer term, but is the most work. > Thanks, > Raymond > > -- > From: "Yang Lei" <[EMAIL PROTECTED]> > Sent: Tuesday, April 29, 2008 9:09 PM > To: > Subject: Re: Improving support for running in OSGi > > > > > > I think enabling OSGI can help modularity with a clear definition of > > package visibility, so we can have a much cleaner "module" > > dependencies through osgi bundle import/export on package. I think > > it will help Tuscany adopters a lot in the scenarios such as: when > > implementing new implementation type, binding type, or data binding > > types, there is clear indication which set of packages can be used > > (exported API/SPI ). So upgrading to new Tuscany level can be as > > simple as plug and play if there is no API/SPI changes, and version > > control (multiple version co-existence) can also be made available > > through OSGI capabilities. > > > > Regards, > > > > Yang > > > > On Tue, Apr 29, 2008 at 1:49 PM, Konradi, Philipp (CT) > > <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > > > I'd like to get people's thoughts on whether the idea of 'promoting' > > > > OSGi is a good one, > > > IMHO support of OSGi is very important and I glad to see increasing > interest of the community here. > > > > > > > and get ideas on how best to proceed. > > > I personally have currently not a very deep insight into implementation > details yet, but we are currently prototyping and have there also OSGi > services. > > > What I could offer today is only to feed our findings about limitations > and rooms for improvement back. > > > Another important thing which I see on the horizon, is the ongoing > standardization of Distributed OSGi (RFC119) and the benefit to support that > standard in Tuscany's OSGi bits. So from mid-term perspective I suggest to > keep an eye on that as well. > > > > > > Regards, > > > Philipp > > > > > > -Ursprüngliche Nachricht- > > > Von: Graham Charters [mailto:[EMAIL PROTECTED] > > > Gesendet: Montag, 28. April 2008 09:48 > > > An: tuscany-dev@ws.apache.org > > > Betreff: Improving support for running in OSGi > > > > > > >
Re: Improving support for running in OSGi
Irrespective of the versioning question, the current 5 module breakdown does not go as far as individual implementation types, binding types and so on. I'm presuming here that the goal would be to be able to add/remove/replace things at that level rather than requiring the entire 'extensions' bundle to be refreshed, for example? 2008/4/30 Simon Nash <[EMAIL PROTECTED]>: > Yang Lei wrote: > > > I think enabling OSGI can help modularity with a clear definition of > > package visibility, so we can have a much cleaner "module" > > dependencies through osgi bundle import/export on package. I think > > it will help Tuscany adopters a lot in the scenarios such as: when > > implementing new implementation type, binding type, or data binding > > types, there is clear indication which set of packages can be used > > (exported API/SPI ). So upgrading to new Tuscany level can be as > > simple as plug and play if there is no API/SPI changes, and version > > control (multiple version co-existence) can also be made available > > through OSGI capabilities. > > > > > +1 for the benefits to modularity. For versioning, I see the value > more in terms of allowing multiple versions of third-party dependencies > to coexist, rather than having multiple versions of some parts of > Tuscany loaded at the same time. Are there any scenarios that would > require the latter? > > Simon > > > > > > Regards, > > > > Yang > > > > On Tue, Apr 29, 2008 at 1:49 PM, Konradi, Philipp (CT) > > <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > > > > > > I'd like to get people's thoughts on whether the idea of 'promoting' > > > > OSGi is a good one, > > > > > > > IMHO support of OSGi is very important and I glad to see increasing > interest of the community here. > > > > > > > > > > and get ideas on how best to proceed. > > > > > > > I personally have currently not a very deep insight into implementation > details yet, but we are currently prototyping and have there also OSGi > services. > > > What I could offer today is only to feed our findings about limitations > and rooms for improvement back. > > > Another important thing which I see on the horizon, is the ongoing > standardization of Distributed OSGi (RFC119) and the benefit to support that > standard in Tuscany's OSGi bits. So from mid-term perspective I suggest to > keep an eye on that as well. > > > > > > Regards, > > > Philipp > > > > > > -Ursprüngliche Nachricht- > > > Von: Graham Charters [mailto:[EMAIL PROTECTED] > > > Gesendet: Montag, 28. April 2008 09:48 > > > An: tuscany-dev@ws.apache.org > > > Betreff: Improving support for running in OSGi > > > > > > > > > Hi All, > > > > > > I'd like to get more involved in the OSGi support in Tuscany (both the > > > modularity work (itest/osgi-tuscany) and the implementation.osgi). I > > > recently started looking at the work to run Tuscany in OSGi, embodied > > > in itest/osgi-tuscany and described in the thread entitled > > > "Classloading in Tuscany". I've noticed a couple of others on the > > > list also interested in Tuscany running in OSGi and wondered if it > > > might be worth considering making this a "first-class" option. At the > > > moment the five bundles are only built by folks who want the OSGi > > > support and go into the itest/osgi-tuscany directory to create it. > > > This can result in any problems being discovered late, but also could > > > create the impression that OSGi is considered a second-class > > > environment (which I don't believe is the case). > > > > > > Aside from the obvious benefits to OSGi users in doing this, I think > > > there's a potential for Tuscany to use the OSGi build as a test-bed > > > for highlighting and working through modularity issues, which would > > > also benefit Tuscany in general, not just in an OSGi runtime. > > > > > > I'd like to get people's thoughts on whether the idea of 'promoting' > > > OSGi is a good one, and get ideas on how best to proceed. We could > > > then start discussing what some of the issues might be (e.g. size of > > > builds, time to build, etc...). > > > > > > Regards, > > > > > > Graham. > > > > > > > > > > > > > >
Re: Improving support for running in OSGi
Hi Philipp, thanks for your comments. I think any feedback/findings you have would be very valuable input. I think the the Distributed OSGi angle is interesting from the perspective of implementation.osgi. Regards, Graham. 2008/4/29 Konradi, Philipp (CT) <[EMAIL PROTECTED]>: > Hi, > > > > I'd like to get people's thoughts on whether the idea of 'promoting' > > OSGi is a good one, > IMHO support of OSGi is very important and I glad to see increasing interest > of the community here. > > > > and get ideas on how best to proceed. > I personally have currently not a very deep insight into implementation > details yet, but we are currently prototyping and have there also OSGi > services. > What I could offer today is only to feed our findings about limitations and > rooms for improvement back. > Another important thing which I see on the horizon, is the ongoing > standardization of Distributed OSGi (RFC119) and the benefit to support that > standard in Tuscany's OSGi bits. So from mid-term perspective I suggest to > keep an eye on that as well. > > Regards, > Philipp > > -Ursprüngliche Nachricht- > Von: Graham Charters [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 28. April 2008 09:48 > An: tuscany-dev@ws.apache.org > Betreff: Improving support for running in OSGi > > > > Hi All, > > I'd like to get more involved in the OSGi support in Tuscany (both the > modularity work (itest/osgi-tuscany) and the implementation.osgi). I > recently started looking at the work to run Tuscany in OSGi, embodied > in itest/osgi-tuscany and described in the thread entitled > "Classloading in Tuscany". I've noticed a couple of others on the > list also interested in Tuscany running in OSGi and wondered if it > might be worth considering making this a "first-class" option. At the > moment the five bundles are only built by folks who want the OSGi > support and go into the itest/osgi-tuscany directory to create it. > This can result in any problems being discovered late, but also could > create the impression that OSGi is considered a second-class > environment (which I don't believe is the case). > > Aside from the obvious benefits to OSGi users in doing this, I think > there's a potential for Tuscany to use the OSGi build as a test-bed > for highlighting and working through modularity issues, which would > also benefit Tuscany in general, not just in an OSGi runtime. > > I'd like to get people's thoughts on whether the idea of 'promoting' > OSGi is a good one, and get ideas on how best to proceed. We could > then start discussing what some of the issues might be (e.g. size of > builds, time to build, etc...). > > Regards, > > Graham. >
[jira] Updated: (TUSCANY-2279) itest/osgi-tuscany broken (policy-ws missing)
[ https://issues.apache.org/jira/browse/TUSCANY-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Charters updated TUSCANY-2279: - Attachment: Jira-2279-policy-ws-missing.patch The following add tuscany-policy-security-ws to the extensions dependencies fixing the problem with the bundles created in itest/osgi-tuscany. > itest/osgi-tuscany broken (policy-ws missing) > - > > Key: TUSCANY-2279 > URL: https://issues.apache.org/jira/browse/TUSCANY-2279 > Project: Tuscany > Issue Type: Bug > Components: Java SCA OSGi Integration >Affects Versions: Java-SCA-Next > Environment: All >Reporter: Graham Charters >Priority: Minor > Fix For: Java-SCA-Next > > Attachments: Jira-2279-policy-ws-missing.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Looks like there's a new policy-ws module which has not been added to > itest/osgi-tuscany so the dependency is missing, which results in the package > not being available. > I have a fix which I will attach shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2279) itest/osgi-tuscany broken (policy-ws missing)
itest/osgi-tuscany broken (policy-ws missing) - Key: TUSCANY-2279 URL: https://issues.apache.org/jira/browse/TUSCANY-2279 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-Next Environment: All Reporter: Graham Charters Priority: Minor Fix For: Java-SCA-Next Looks like there's a new policy-ws module which has not been added to itest/osgi-tuscany so the dependency is missing, which results in the package not being available. I have a fix which I will attach shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Improving support for running in OSGi
Hi Simon, 2008/4/28 Simon Laws <[EMAIL PROTECTED]>: > On Mon, Apr 28, 2008 at 1:15 PM, Graham Charters <[EMAIL PROTECTED]> > > > wrote: > > > Hi Ant, > > > > Thanks for the pointer to the earlier discussion. I can empathise > > with the problems Rajini was trying to address by having > > itest/osgi-tuscany built regularly and automatically. As for the > > sca-api, yes we could add the bundle manifest automatically and that > > would be very low hanging fruit. We can do this because it happens to > > match one of the five bundles created in itest/osgi-tuscany. My > > concern would be that this doesn't seem to address the main issues > > which Rajini originally raised. We would need to do something > > different for the other 4 bundles (or however many we might build in > > the future). > > > > > > Regards, > > > > Graham. > > > > On 28/04/2008, ant elder <[EMAIL PROTECTED]> wrote: > > > On Mon, Apr 28, 2008 at 8:48 AM, Graham Charters < > > [EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > Hi All, > > > > > > > > I'd like to get more involved in the OSGi support in Tuscany (both > > the > > > > modularity work (itest/osgi-tuscany) and the implementation.osgi). I > > > > recently started looking at the work to run Tuscany in OSGi, embodied > > > > in itest/osgi-tuscany and described in the thread entitled > > > > "Classloading in Tuscany". I've noticed a couple of others on the > > > > list also interested in Tuscany running in OSGi and wondered if it > > > > might be worth considering making this a "first-class" option. At > > the > > > > moment the five bundles are only built by folks who want the OSGi > > > > support and go into the itest/osgi-tuscany directory to create it. > > > > This can result in any problems being discovered late, but also could > > > > create the impression that OSGi is considered a second-class > > > > environment (which I don't believe is the case). > > > > > > > > Aside from the obvious benefits to OSGi users in doing this, I think > > > > there's a potential for Tuscany to use the OSGi build as a test-bed > > > > for highlighting and working through modularity issues, which would > > > > also benefit Tuscany in general, not just in an OSGi runtime. > > > > > > > > I'd like to get people's thoughts on whether the idea of 'promoting' > > > > OSGi is a good one, and get ideas on how best to proceed. We could > > > > then start discussing what some of the issues might be (e.g. size of > > > > builds, time to build, etc...). > > > > > > > > Regards, > > > > > > > > Graham. > > > > > > > > > > > > > Sounds good to me - having you get more involved in Tuscany, making OSGi > > > support a more first class part of Tuscany, using that to help improve > > > Tuscany modularity - they all seem like fine things. I agree it would > > be > > > good to promote Tuscany using OSGi, there's growing interest in using > > OSGi > > > and having good Tuscany OSGi integration can only help improve adoption > > and > > > our user base. > > > > > > As a small step in this direction how about making the Tuscany sca-api > > > module a proper OSGi bundle as discussed here - > > > http://apache.markmail.org/message/hf5ekr3dpnlzrrcn > > > > > > > > >...ant > > > > > > > Graham > > Sounds like a good idea to me too. Also just doing the sca-api in the first > case, as Ant suggests, starts us off down the road of testing > multi-classloader configurations. I'm assuming that some of the osgi-tuscany > testing can be used to make sure it does work. I'm not sure how much this really helps. We can build the bundle by default, but will still need to do the other bundles in order to test. > > Thinking about the wider generation of bundles. IMHO to make this work the > association of modules with bundles needs to be business as usual rather and > an extra pom to edit as it is now, e.g. could be through reorganizing > modules into a new directory structure or associating some parameter with a > module which indicates which bundle it is in. This needs som
Re: Improving support for running in OSGi
Hi Ant, Thanks for the pointer to the earlier discussion. I can empathise with the problems Rajini was trying to address by having itest/osgi-tuscany built regularly and automatically. As for the sca-api, yes we could add the bundle manifest automatically and that would be very low hanging fruit. We can do this because it happens to match one of the five bundles created in itest/osgi-tuscany. My concern would be that this doesn't seem to address the main issues which Rajini originally raised. We would need to do something different for the other 4 bundles (or however many we might build in the future). Regards, Graham. On 28/04/2008, ant elder <[EMAIL PROTECTED]> wrote: > On Mon, Apr 28, 2008 at 8:48 AM, Graham Charters <[EMAIL PROTECTED]> > wrote: > > > > Hi All, > > > > I'd like to get more involved in the OSGi support in Tuscany (both the > > modularity work (itest/osgi-tuscany) and the implementation.osgi). I > > recently started looking at the work to run Tuscany in OSGi, embodied > > in itest/osgi-tuscany and described in the thread entitled > > "Classloading in Tuscany". I've noticed a couple of others on the > > list also interested in Tuscany running in OSGi and wondered if it > > might be worth considering making this a "first-class" option. At the > > moment the five bundles are only built by folks who want the OSGi > > support and go into the itest/osgi-tuscany directory to create it. > > This can result in any problems being discovered late, but also could > > create the impression that OSGi is considered a second-class > > environment (which I don't believe is the case). > > > > Aside from the obvious benefits to OSGi users in doing this, I think > > there's a potential for Tuscany to use the OSGi build as a test-bed > > for highlighting and working through modularity issues, which would > > also benefit Tuscany in general, not just in an OSGi runtime. > > > > I'd like to get people's thoughts on whether the idea of 'promoting' > > OSGi is a good one, and get ideas on how best to proceed. We could > > then start discussing what some of the issues might be (e.g. size of > > builds, time to build, etc...). > > > > Regards, > > > > Graham. > > > > > Sounds good to me - having you get more involved in Tuscany, making OSGi > support a more first class part of Tuscany, using that to help improve > Tuscany modularity - they all seem like fine things. I agree it would be > good to promote Tuscany using OSGi, there's growing interest in using OSGi > and having good Tuscany OSGi integration can only help improve adoption and > our user base. > > As a small step in this direction how about making the Tuscany sca-api > module a proper OSGi bundle as discussed here - > http://apache.markmail.org/message/hf5ekr3dpnlzrrcn > > >...ant >
Improving support for running in OSGi
Hi All, I'd like to get more involved in the OSGi support in Tuscany (both the modularity work (itest/osgi-tuscany) and the implementation.osgi). I recently started looking at the work to run Tuscany in OSGi, embodied in itest/osgi-tuscany and described in the thread entitled "Classloading in Tuscany". I've noticed a couple of others on the list also interested in Tuscany running in OSGi and wondered if it might be worth considering making this a "first-class" option. At the moment the five bundles are only built by folks who want the OSGi support and go into the itest/osgi-tuscany directory to create it. This can result in any problems being discovered late, but also could create the impression that OSGi is considered a second-class environment (which I don't believe is the case). Aside from the obvious benefits to OSGi users in doing this, I think there's a potential for Tuscany to use the OSGi build as a test-bed for highlighting and working through modularity issues, which would also benefit Tuscany in general, not just in an OSGi runtime. I'd like to get people's thoughts on whether the idea of 'promoting' OSGi is a good one, and get ideas on how best to proceed. We could then start discussing what some of the issues might be (e.g. size of builds, time to build, etc...). Regards, Graham.
[jira] Updated: (TUSCANY-2254) Test failures in itest/osgi-tuscany (monitor missing)
[ https://issues.apache.org/jira/browse/TUSCANY-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Charters updated TUSCANY-2254: - Attachment: osgi-tuscany-patch.patch The following adds tuscany-monitor to the tuscany-runtime bundle and tuscany-monitor-logging to the tuscany-extensions bundle, built by itest/osgi-tuscany. > Test failures in itest/osgi-tuscany (monitor missing) > - > > Key: TUSCANY-2254 > URL: https://issues.apache.org/jira/browse/TUSCANY-2254 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core Runtime >Affects Versions: Java-SCA-Next > Environment: Found on Windows, but affects all. >Reporter: Graham Charters >Priority: Minor > Fix For: Java-SCA-Next > > Attachments: osgi-tuscany-patch.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > The newly added monitor modules, tuscany-monitor and tuscany-monitor-logging > ,cause itest/osgi-tuscany to fail because they have not been added to the > dependencies for the tuscany osgi bundles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2254) Test failures in itest/osgi-tuscany (monitor missing)
Test failures in itest/osgi-tuscany (monitor missing) - Key: TUSCANY-2254 URL: https://issues.apache.org/jira/browse/TUSCANY-2254 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Found on Windows, but affects all. Reporter: Graham Charters Priority: Minor Fix For: Java-SCA-Next The newly added monitor modules, tuscany-monitor and tuscany-monitor-logging ,cause itest/osgi-tuscany to fail because they have not been added to the dependencies for the tuscany osgi bundles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ApacheCon US submissions
Hi Simon, what you describe is exactly what I had in mind :-) Regards, Graham. On 01/04/2008, Simon Nash <[EMAIL PROTECTED]> wrote: > Graham Charters wrote: > > Hi All, > > > > Is anyone thinking of submitting an abstract to ApacheCon US? FYI: > > The deadline is Thursday April 3rd (see > > http://www.us.apachecon.com/us2008/). > > > > A quick search for "SOA" or "Tuscany" on the current submissions gave > > no hits, so I'm assuming there aren't any so far. I was thinking of > > submitting one talking about the use of Apache Felix for modularizing > > of Apache Tuscany (lesson learned from applying modularity after the > > fact...)...giving LOTS of credit to Rajini!! > > > > For a succcessful submission it's necessary to have a topic that's > of broad appeal, which generally means it should provide practical > hands-on information that people can use. So you'ld need to use > the Tuscany/Felix experience to draw out practical lessons and best > practices for modularity that people can apply to their own projects. > If this is what you have in mind, I think it's a good candidate for > submission. > > >Simon > > > > > Regards, Graham. > > > > - > > 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]
ApacheCon US submissions
Hi All, Is anyone thinking of submitting an abstract to ApacheCon US? FYI: The deadline is Thursday April 3rd (see http://www.us.apachecon.com/us2008/). A quick search for "SOA" or "Tuscany" on the current submissions gave no hits, so I'm assuming there aren't any so far. I was thinking of submitting one talking about the use of Apache Felix for modularizing of Apache Tuscany (lesson learned from applying modularity after the fact...)...giving LOTS of credit to Rajini!! Regards, Graham. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2068) itest/osgi-implementation is broken due to recent changes
[ https://issues.apache.org/jira/browse/TUSCANY-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Charters updated TUSCANY-2068: - Attachment: implementation.osgi.txt This patch fixes the passbyreference (using the new DataExchangeSemantics interface) and callback problems in implementation.osgi. All implementation.osgi unit tests should pass once applied. > itest/osgi-implementation is broken due to recent changes > - > > Key: TUSCANY-2068 > URL: https://issues.apache.org/jira/browse/TUSCANY-2068 > Project: Tuscany > Issue Type: Bug > Components: Java SCA OSGi Integration >Reporter: Rajini Sivaram >Assignee: Rajini Sivaram > Fix For: Java-SCA-1.2 > > Attachments: implementation.osgi.txt > > > Recent changes related to Pass-by-value and callbacks have broken many of the > itest/osgi-implementationt tests. The tests need to be added back to the > itest pom to ensure that breakages are caught earlier. -- 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-1632) Serialization of xsd:token allows invalid content in SDO C++
Serialization of xsd:token allows invalid content in SDO C++ Key: TUSCANY-1632 URL: https://issues.apache.org/jira/browse/TUSCANY-1632 Project: Tuscany Issue Type: Bug Components: C++ SDO Reporter: Graham Charters Priority: Minor I can define an SDO based on an xml schema which uses the type xsd:token. This is mapped to a String SDO type. I can then create an SDO based off this model and set the string value of that property to something like "foo bar ". This is invalid against the schema (xsd:token), but valid against the SDO model (string), so I wouldn't necessarily expect an error or warning at this point. I can then write out the SDO as XML and it writes out the string value "foo bar" which is not valid against the xml schama. I would expect the data to either be modified to be serialized out following the schema (e.g. "foo bar"), or some kind of warning/error to be generated. -- 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-1631) Support Decimal in SDO C++
Support Decimal in SDO C++ -- Key: TUSCANY-1631 URL: https://issues.apache.org/jira/browse/TUSCANY-1631 Project: Tuscany Issue Type: Improvement Components: C++ SDO, C++ Specification Reporter: Graham Charters Priority: Minor The SDO C++ spec does not address Decimal. The current Tuscany implementation uses String to represent Decimal to avoid loss of precision. It does not internally know that the type is Decimal nor surface any APIs (e.g. set/getDecimal) and therefore there is no validation that the values provided are correct. This can cause problems when a schema defines an xsd:decimal type. An SDO based on that schema will allow an application to set the data to any string and this value can then be serialized out and is invalid against the schema. -- 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: Intermittent exception from itest\osgi-implementation suite
Apologies for the lack of response on this. Rajini is out on vacation for a few weeks and I'm still getting up to speed on the code. I'll let you know as soon as we get to the bottom of it. Regards, Graham. On 13/07/07, Luciano Resende <[EMAIL PROTECTED]> wrote: I've temporarily removed the module from the build under revision #555903. On 7/12/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > I see the following exception thrown from the itest\osgi-implementation > suite intermittently. It seems to be a timing issue. Can somebody take a > look? > > Thanks, > Raymond > > Work thread Thread[main,5,main] - Order, submitted (play.com), fulfilled, > shippe > d (ParcelForce) > Test complete > Deactivated OSGiShipperComponentImpl bundle > Deactivated OSGiShipperComponentImpl bundle > Deactivated OSGiRetailerComponentImpl bundle > Deactivated OSGiRetailerComponentImpl bundle > Deactivated OSGiCustomerComponentImpl bundle > --- Exception with component : Unexpected problem executing task --- > java.lang.IllegalStateException: Service already unregistered. > at > org.apache.felix.framework.ServiceRegistrationImpl.unregister(Service > RegistrationImpl.java:105) > at > org.apache.felix.scr.AbstractComponentManager.unregisterComponentServ > ice(AbstractComponentManager.java:503) > at > org.apache.felix.scr.AbstractComponentManager.deactivateInternal(Abst > ractComponentManager.java:369) > at > org.apache.felix.scr.AbstractComponentManager.access$200(AbstractComp > onentManager.java:55) > at > org.apache.felix.scr.AbstractComponentManager$3.run(AbstractComponent > Manager.java:176) > at > org.apache.felix.scr.ComponentActorThread.run(ComponentActorThread.ja > va:81) > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5 sec > > > - > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of C++ code generation
Hi Pete, sounds good to me. On 17/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote: Graham, so if we move these methods to DataObjectImpl you should still be able to use them by casting your DataObjectPtr to the impl? I think we should do this in SDO HEAD along with the other 2.1 spec changes. There should be only a small amount of rework required when you move the PHP code up to use a 2.1 spec SDO. Cheers, On 17/07/07, Graham Charters <[EMAIL PROTECTED]> wrote: > Hi Andy/Pete, > > Yes, we do use this method in the PHP SDO code - thanks for remembering us :-) > > I think we need to draw a distinction between SDO C++ for applications > and SDO C++ as an embeddable library. The SDO C++ spec covers the > former and therefore does not talk about get/setUserData. The library > role of SDO C++ enables us to more easily write native SDO > implementations for other languages (PHP, Ruby, etc...) and is IMO > very important (I guess I would say that :-) ). > > Get/setUserData is used by SDO PHP to manage the relationship between > the PHP SDO Objects and C++ SDO Objects. Earlier versions of the PHP > Extension tried to manage this separately, but this solution was > complex and prone to problems. > > I hope this helps. > > Regards, > > Graham. > > > On 17/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote: > > Andy, the static code generation was an old experiment and is not > > used.I have been meaning to remove it for some time as it is confusing > > being there. > > > > The get/setUserData was actually put in there at the request of the > > PHP-SDO team. I'm not sure of the details but I think they use this to > > maintain a correlation between the C++ SDO objects and PHP objects??? > > This code is not used anywhere within Tuscany SDO (or SCA) code. > > > > This may be a case where a real life application has shown up a > > limitation in the spec and that we should take a proposal to the spec > > group. I'll try and find out how essential this function is and if > > there is another way to work around this to enable a spec compliant > > api in Tuscany > > > > Cheers, > > > > On 17/07/07, Andy Grove <[EMAIL PROTECTED]> wrote: > > > I'm currently looking at some of the issues that my collegaue, Michael > > > Yoder, raised regarding the use of propietary methods in the SDO header > > > files. In particular, I'm looking at the setUserData / getUserData > > > methods in DataObject.h [TUSCANY-1370]. These methods could easily be > > > moved to the DataObjectImpl.h header instead. The methods are only > > > referenced in code generated static client code (generated by > > > DataFactoryImpl::generateInterface). > > > > > > However, I'm nervous about making the change because the current sdotest > > > suite does not excercise the static code generated classes enough to > > > call these methods. For instance, if I change the code generator to call > > > a non-existant method "foo" instead of getUserData or setUserData then > > > the current tests still pass. > > > > > > What is the status of the code generator? The Tuscany web site > > > (http://incubator.apache.org/tuscany/sdo-cpp-faq.html) states that there > > > are no plans to support this feature. Is this correct? > > > > > > Thanks, > > > > > > Andy. > > > > > > > > > -- > > Pete > > > > - > > 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] > > -- Pete - 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 C++ code generation
Hi Andy/Pete, Yes, we do use this method in the PHP SDO code - thanks for remembering us :-) I think we need to draw a distinction between SDO C++ for applications and SDO C++ as an embeddable library. The SDO C++ spec covers the former and therefore does not talk about get/setUserData. The library role of SDO C++ enables us to more easily write native SDO implementations for other languages (PHP, Ruby, etc...) and is IMO very important (I guess I would say that :-) ). Get/setUserData is used by SDO PHP to manage the relationship between the PHP SDO Objects and C++ SDO Objects. Earlier versions of the PHP Extension tried to manage this separately, but this solution was complex and prone to problems. I hope this helps. Regards, Graham. On 17/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote: Andy, the static code generation was an old experiment and is not used.I have been meaning to remove it for some time as it is confusing being there. The get/setUserData was actually put in there at the request of the PHP-SDO team. I'm not sure of the details but I think they use this to maintain a correlation between the C++ SDO objects and PHP objects??? This code is not used anywhere within Tuscany SDO (or SCA) code. This may be a case where a real life application has shown up a limitation in the spec and that we should take a proposal to the spec group. I'll try and find out how essential this function is and if there is another way to work around this to enable a spec compliant api in Tuscany Cheers, On 17/07/07, Andy Grove <[EMAIL PROTECTED]> wrote: > I'm currently looking at some of the issues that my collegaue, Michael > Yoder, raised regarding the use of propietary methods in the SDO header > files. In particular, I'm looking at the setUserData / getUserData > methods in DataObject.h [TUSCANY-1370]. These methods could easily be > moved to the DataObjectImpl.h header instead. The methods are only > referenced in code generated static client code (generated by > DataFactoryImpl::generateInterface). > > However, I'm nervous about making the change because the current sdotest > suite does not excercise the static code generated classes enough to > call these methods. For instance, if I change the code generator to call > a non-existant method "foo" instead of getUserData or setUserData then > the current tests still pass. > > What is the status of the code generator? The Tuscany web site > (http://incubator.apache.org/tuscany/sdo-cpp-faq.html) states that there > are no plans to support this feature. Is this correct? > > Thanks, > > Andy. > -- Pete - 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: Build problems
Thanks, Luciano, I think this is the same problem. Renaming the 2.2.2 version to 2.2.3 seems to get me through the build :-) . The other build problems I've encountered over the past day or so appear to have gone away now as well. Thanks for your help. Graham. On 10/07/07, Luciano Resende <[EMAIL PROTECTED]> wrote: You might be hitting the same issue as reported by Simon Laws [1]. But I'm not sure what is the solution at the moment. Maybe remove the package from your local repo or try to mvn -U. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19676.html On 7/10/07, Graham Charters <[EMAIL PROTECTED]> wrote: > Hi Raymond, > > Thanks for the quick response. I tried "mvn clean install" and I'm > still seeing the problem caused by the bad codegen-ecore-2.2.3.jar. It > results in lots of errors to do with missing package > org.eclipse.emf.codegen.ecore.genmodel. > > Regards, Graham. > > On 10/07/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Please run "mvn clean install". > > > > Thanks, > > Raymond > > - Original Message - > > From: "Graham Charters" <[EMAIL PROTECTED]> > > To: "tuscany-dev" > > Sent: Tuesday, July 10, 2007 8:56 AM > > Subject: Build problems > > > > > > > Hi, > > > > > > I'm trying to build Tuscany Java and have hit a couple of problems. > > > I've started with a clean repository, and checked out the latest from > > > svn (a few times throughout July 9th/10th). When I do mvn at the top > > > level, I get a test case failure with the following exception: > > > > > > testTransformation(org.apache.tuscany.sca.databinding.xml.JavaBean2XMLStreamReaderTestCase) > > > Time elapsed: 0.031 sec <<< ERROR! > > > java.lang.IncompatibleClassChangeError: > > > org/apache/tuscany/sca/databinding/impl/SimpleTypeMapperImpl.getXMLType(Ljava/lang/Class;)Lorg/apach > > > e/tuscany/sca/interfacedef/util/TypeInfo; > > >at > > > org.apache.tuscany.sca.databinding.xml.BeanUtil.isSimpleType(BeanUtil.java:49) > > >at > > > org.apache.tuscany.sca.databinding.xml.BeanUtil.getXMLStreamReader(BeanUtil.java:100) > > >at > > > org.apache.tuscany.sca.databinding.xml.BeanUtil.getXMLStreamReader(BeanUtil.java:184) > > >at > > > org.apache.tuscany.sca.databinding.javabeans.JavaBean2XMLStreamReader.transform(JavaBean2XMLStreamReader.java:35) > > >at > > > org.apache.tuscany.sca.databinding.xml.JavaBean2XMLStreamReaderTestCase.testTransformation(JavaBean2XMLStreamReaderTestCase.java: > > > 43) > > >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > >at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > > >at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > >at java.lang.reflect.Method.invoke(Method.java:615) > > >at junit.framework.TestCase.runTest(TestCase.java:168) > > >at junit.framework.TestCase.runBare(TestCase.java:134) > > >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:64) > > >at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > >at java.lang.reflect.Method.invoke(Method.java:615) > > >
Re: Build problems
Hi Raymond,
Thanks for the quick response. I tried "mvn clean install" and I'm
still seeing the problem caused by the bad codegen-ecore-2.2.3.jar. It
results in lots of errors to do with missing package
org.eclipse.emf.codegen.ecore.genmodel.
Regards, Graham.
On 10/07/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
Please run "mvn clean install".
Thanks,
Raymond
- Original Message -
From: "Graham Charters" <[EMAIL PROTECTED]>
To: "tuscany-dev"
Sent: Tuesday, July 10, 2007 8:56 AM
Subject: Build problems
> Hi,
>
> I'm trying to build Tuscany Java and have hit a couple of problems.
> I've started with a clean repository, and checked out the latest from
> svn (a few times throughout July 9th/10th). When I do mvn at the top
> level, I get a test case failure with the following exception:
>
>
testTransformation(org.apache.tuscany.sca.databinding.xml.JavaBean2XMLStreamReaderTestCase)
> Time elapsed: 0.031 sec <<< ERROR!
> java.lang.IncompatibleClassChangeError:
>
org/apache/tuscany/sca/databinding/impl/SimpleTypeMapperImpl.getXMLType(Ljava/lang/Class;)Lorg/apach
> e/tuscany/sca/interfacedef/util/TypeInfo;
>at
> org.apache.tuscany.sca.databinding.xml.BeanUtil.isSimpleType(BeanUtil.java:49)
>at
>
org.apache.tuscany.sca.databinding.xml.BeanUtil.getXMLStreamReader(BeanUtil.java:100)
>at
>
org.apache.tuscany.sca.databinding.xml.BeanUtil.getXMLStreamReader(BeanUtil.java:184)
>at
>
org.apache.tuscany.sca.databinding.javabeans.JavaBean2XMLStreamReader.transform(JavaBean2XMLStreamReader.java:35)
>at
>
org.apache.tuscany.sca.databinding.xml.JavaBean2XMLStreamReaderTestCase.testTransformation(JavaBean2XMLStreamReaderTestCase.java:
> 43)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
>at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:615)
>at junit.framework.TestCase.runTest(TestCase.java:168)
>at junit.framework.TestCase.runBare(TestCase.java:134)
>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:64)
>at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:615)
>at
>
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
>at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)
>
> When I try to build Eclipse projects using "mvn -Peclipse
> eclipse:eclipse" I get the following exception:
>
> [INFO] [tuscany-sdo:generate {execution: generate-po-sdo}]
> [INFO] Generating SDO interfaces from
>
C:\temp\LAMP\Eclipse-3.2.1\eclipse\workspaces\osgi\Tuscany\sca\modules\databinding-sdo\src\test\resour
> ces\ipo.xsd
> [INFO]
> [ERROR] FATAL ERROR
> [INFO]
> [INFO] org.eclipse.emf.codegen.ecore.genmodel.GenModelFactory
> [INFO]
> [INFO] Trace
> java.lang.NoClassDefFoundError:
> org.eclipse.emf.codegen.ecore.genmodel.GenModelFactory
>at
>
org.apache.tuscany.sdo.generate.JavaGenerator.ecore2GenModel(JavaGenerator.java:540)
>at
>
org.apache.tuscany.sdo.generate.JavaGenerator.createGenPackages(JavaGenerator.java:438)
>at
>
org.apache.tuscany.sdo.generate.JavaGenerator.generatePackages(JavaGenerator.java:394
Build problems
Hi,
I'm trying to build Tuscany Java and have hit a couple of problems.
I've started with a clean repository, and checked out the latest from
svn (a few times throughout July 9th/10th). When I do mvn at the top
level, I get a test case failure with the following exception:
testTransformation(org.apache.tuscany.sca.databinding.xml.JavaBean2XMLStreamReaderTestCase)
Time elapsed: 0.031 sec <<< ERROR!
java.lang.IncompatibleClassChangeError:
org/apache/tuscany/sca/databinding/impl/SimpleTypeMapperImpl.getXMLType(Ljava/lang/Class;)Lorg/apach
e/tuscany/sca/interfacedef/util/TypeInfo;
at
org.apache.tuscany.sca.databinding.xml.BeanUtil.isSimpleType(BeanUtil.java:49)
at
org.apache.tuscany.sca.databinding.xml.BeanUtil.getXMLStreamReader(BeanUtil.java:100)
at
org.apache.tuscany.sca.databinding.xml.BeanUtil.getXMLStreamReader(BeanUtil.java:184)
at
org.apache.tuscany.sca.databinding.javabeans.JavaBean2XMLStreamReader.transform(JavaBean2XMLStreamReader.java:35)
at
org.apache.tuscany.sca.databinding.xml.JavaBean2XMLStreamReaderTestCase.testTransformation(JavaBean2XMLStreamReaderTestCase.java:
43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
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:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)
When I try to build Eclipse projects using "mvn -Peclipse
eclipse:eclipse" I get the following exception:
[INFO] [tuscany-sdo:generate {execution: generate-po-sdo}]
[INFO] Generating SDO interfaces from
C:\temp\LAMP\Eclipse-3.2.1\eclipse\workspaces\osgi\Tuscany\sca\modules\databinding-sdo\src\test\resour
ces\ipo.xsd
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] org.eclipse.emf.codegen.ecore.genmodel.GenModelFactory
[INFO]
[INFO] Trace
java.lang.NoClassDefFoundError:
org.eclipse.emf.codegen.ecore.genmodel.GenModelFactory
at
org.apache.tuscany.sdo.generate.JavaGenerator.ecore2GenModel(JavaGenerator.java:540)
at
org.apache.tuscany.sdo.generate.JavaGenerator.createGenPackages(JavaGenerator.java:438)
at
org.apache.tuscany.sdo.generate.JavaGenerator.generatePackages(JavaGenerator.java:394)
at
org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:187)
at
org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:153)
at
org.apache.tuscany.sdo.plugin.GeneratorMojo.execute(GeneratorMojo.java:270)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:896)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:739)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:510)
at
org.apache.mav
Re: Contribute to SCA-OSGi integration
Hi Nicole, I've inlined some comments below. On 20/06/07, Wengatz, Nicole <[EMAIL PROTECTED]> wrote: Hi Graham, I'm still not sure if the proposal is consistent. Let my explain my concerns: Every OSGi container provides an OSGi registry. In the OSGi enterprise expert group we are currently discussing that proxies for other services (e.g. EJB stateless Bean which is accessible via IIOP) will be created and registered in the OSGi registry. From this point of view, your proposal for the implementation.osgi is consistent. I think it would be nice if OSGi didn't have to care how the service was implemented, and this is what can be achieved with SCA. But do we want to have different behaviour for different SCA implementations types? This is exactly what we don't want. The implementation.osgi approach registers in the OSGi registry whatever proxies SCA gives it. These proxies can be for other implementation types or remote bindings. Their behaviour is consistent. Do you expect for example that an implementation.ejb adds remote proxies to the JNDI service? Or what about implementation.net or implementation.c, do we need now a registry for all implementation types? We shouldn't have to care. If implementation.ejb/c/.net are supported in the SCA runtime, then we will get these for free. It's up to SCA to give us the right proxy which we then make available in the OSGi registry. I still think that explicit bindings are better. I still think both approaches are valid and it depends on what you're trying to achieve :-) . If you're trying to include OSGi bundles in your SCA domain, the only way to do this is with implementation.osgi. If you're trying to create a peer environment where you interoperate with OSGi bundles but they are not managed by SCA, then binding.osgi makes sense. What do the others on the list think? Thanks Nicole P.S.: Graham, Tim told me today that you are going to be at the F2F in Munich next week. Looking forward to meeting you there :-) Yes, I am. I look forward to meeting you there too :-) . -----Ursprüngliche Nachricht- Von: Graham Charters [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. Juni 2007 17:10 An: tuscany-dev@ws.apache.org Betreff: Re: Contribute to SCA-OSGi integration Hi Nicole, My turn to chip in :-) I think both approaches are valid and tackle two different goals. If I understand correctly, then the binding approach does not hand the responsibility for the OSGi bundles and services to SCA. So this is more of a peer-to-peer runtime view. I think this approach is appealing if you want to keep OSGi outside the SCA domain for either organizational reasons, or because you don't want to model some existing OSGi application in SCA. The implementation.osgi approach is trying to take an SCA assembly view of the problem where you want to describe and manage the assembly of the OSGi assets with other implementation technologies. Here SCA is responsible for managing the OSGi bundles (installation, activation), and ensuring their external dependencies are resolved. I've inlined some additional comments below. On 19/06/07, Wengatz, Nicole <[EMAIL PROTECTED]> wrote: > Hi Rajini, > > I would prefer a solution where you declare explicitly the bindings, not an implicit registration > of services. > > Please find below a snippet of the OSGi prototype provided by Joel some time ago: > > > > > RetailerComponent > > > > > WarehouseComponent > > > RetailerComponent will not be registered automatically (without a service). The Service tag provides the > information via which binding the RetailerComponent will be accessible, in this case via an OSGi Binding. > The SCA runtime detects the OSGi binding and registers the RetailerComponent as OSGi service in the > OSGi registry. > > The Client uses a reference with OSGi binding to access the RetailerService: > > > RetailerService > > > > > > > > In this case the SCA runtime looks up the Retailer OSGi service in the registry and injects it into > the CustomerComponent which is the client. > > From my point of view we need such an OSGi Binding for the communication of SCA components running in > different implementation types. If we have only an OSGi implementation type I would use instead of an OSGi > binding the OSGI R4 DS (Declarative Services) or Spring OSGi. > Both approaches allow OSGi bundles to talk to SCA components built using different implementation types. For the binding approach it's whatever the service with the OSGi binding is wired to in SCA. For the implementation.osgi approach, it's whatever the component reference is wired to. The runtime needs to make go
Re: Contribute to SCA-OSGi integration
Thank you... Regards, Rajini On 6/19/07, Wengatz, Nicole <[EMAIL PROTECTED]> wrote: > > Hi Graham, > > >OSGi SCA Component -- local wire --> non-OSGi SCA Component (e.g. POJO) > I'm still not sure if I understand your scenario correctly. What do you > mean with > non-OSGi SCA Component, where will it be declared? My understanding is > that the non-OSGi > SCA Component will be deployed in another implementation type, e.g. in > Java or Spring > implementation type. To be able to wire the OSGi SCA Component with the > non-OSGi SCA > component you will need a binding. The other scenario I could imagine is > that you are > talking about a simple POJO or Spring Bean which will be injected via > Dependency Injection, > e.g. in the Spring implementation type or in the OSGi implementation type > with Spring-OSGi > support. Could you please describe what you have in mind, e.g. where you > are planning to > declare the non-OSGi SCA Component? > > Thanks > Nicole > > > -Ursprüngliche Nachricht- > Von: Graham Charters [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 13. Juni 2007 10:07 > An: tuscany-dev@ws.apache.org > Betreff: Re: Contribute to SCA-OSGi integration > > Hi Nicole/Rajini, > > I'm wondering if there is some confusion over terminology and the > scenarios being discussed. I believe Rajini is only referring to OSGi > bundles integrated into SCA through an . So in > these scenarios both components are SCA components. Perhaps for > clarity we should refer to the ones implemented using OSGi bundles as > OSGi SCA components. > > So, for scenario 1, I think we have: > > OSGi SCA Component -- local wire --> non-OSGi SCA Component (e.g. POJO) > > In this scenario the OSGi SCA Component implementation will look up > and expect to find a service in the OSGi Registry. The SCA wiring > states that that service is provided by the non-OSGi SCA Component and > therefore Tuscany must register a proxy service (a proxy to the > non-OSGi SCA Component) in the OSGi Registry. The OSGi SCA Component > implementation will be unaware that it is calling a non-OSGi SCA > Component. > > For scenarios 2, I think we have: > > non-OSGi SCA Component (e.g. POJO) -- local wire --> OSGi SCA Component > > In this scenario, Tuscany knows that the target component is > implemented by an OSGi bundle and it must look-up the target service > in the OSGi Registry. > > Of course, it could easily be me that's confused, but I don't see > where bindings come into these scenarios. I do think it would be good > to expand the scenarios to include bindings thoughts, and perhaps, > Nicole, you could elaborate on the scenarios you describe. For > example, I'm not sure the OSGi components you refer to are SCA. I > think you may be thinking of more a peer-to-peer view of OSGi and SCA. > > Regards, > > Graham. > > On 12/06/07, Wengatz, Nicole <[EMAIL PROTECTED]> wrote: > > Hi Rajini, > > > > good to hear that you're going to contribute to SCA-OSGi :-) > > > > We wrote a paper about the different possibilities of combining OSGi and > > SCA for the SCA drumbeat end of march. You can find it on the OSOA > > homepage: > > http://www.osoa.org/display/Main/SCA+Resources. > > The paper contains a high level description of the OSGi Binding, > > implementation type > > and OSGi host. Would be great to get some comments from you. > > > > >If there are references from the OSGi component to other non-OSGi SCA > > >components, a proxy service is registered by the Tuscany runtime with > > the > > >OSGi registry so that the OSGi bundles can access these SCA services as > > >normal OSGi services. > > Well, this is one option, but not the only one. If for example the > > non-OSGi SCA component > > provides a SOAP service binding, a SOAP proxy will be injected. > > > > >References from non-OSGi components to OSGi components > > >are resolved by looking up the OSGi registry. > > Yes, if the non-OSGi SCA component has declared a reference with OSGi > > binding. > > If the OSGi component has declared a JMS service binding, the non-OSGi > > SCA component > > could use JMS instead of OSGi binding :-) > > > > Best regards > > Nicole > > > > > > > >Hello, > > > > > > >I would like to contribute to the SCA<->OSGi integration activities. > > > > > > >I have been looking at the existing OSGi binding implementation in > > > Tuscany > > > >which exposes SCA services as OSGi services. Even though this bi
Re: Contribute to SCA-OSGi integration
Hi Nicole/Rajini, I'm wondering if there is some confusion over terminology and the scenarios being discussed. I believe Rajini is only referring to OSGi bundles integrated into SCA through an . So in these scenarios both components are SCA components. Perhaps for clarity we should refer to the ones implemented using OSGi bundles as OSGi SCA components. So, for scenario 1, I think we have: OSGi SCA Component -- local wire --> non-OSGi SCA Component (e.g. POJO) In this scenario the OSGi SCA Component implementation will look up and expect to find a service in the OSGi Registry. The SCA wiring states that that service is provided by the non-OSGi SCA Component and therefore Tuscany must register a proxy service (a proxy to the non-OSGi SCA Component) in the OSGi Registry. The OSGi SCA Component implementation will be unaware that it is calling a non-OSGi SCA Component. For scenarios 2, I think we have: non-OSGi SCA Component (e.g. POJO) -- local wire --> OSGi SCA Component In this scenario, Tuscany knows that the target component is implemented by an OSGi bundle and it must look-up the target service in the OSGi Registry. Of course, it could easily be me that's confused, but I don't see where bindings come into these scenarios. I do think it would be good to expand the scenarios to include bindings thoughts, and perhaps, Nicole, you could elaborate on the scenarios you describe. For example, I'm not sure the OSGi components you refer to are SCA. I think you may be thinking of more a peer-to-peer view of OSGi and SCA. Regards, Graham. On 12/06/07, Wengatz, Nicole <[EMAIL PROTECTED]> wrote: Hi Rajini, good to hear that you're going to contribute to SCA-OSGi :-) We wrote a paper about the different possibilities of combining OSGi and SCA for the SCA drumbeat end of march. You can find it on the OSOA homepage: http://www.osoa.org/display/Main/SCA+Resources. The paper contains a high level description of the OSGi Binding, implementation type and OSGi host. Would be great to get some comments from you. >If there are references from the OSGi component to other non-OSGi SCA >components, a proxy service is registered by the Tuscany runtime with the >OSGi registry so that the OSGi bundles can access these SCA services as >normal OSGi services. Well, this is one option, but not the only one. If for example the non-OSGi SCA component provides a SOAP service binding, a SOAP proxy will be injected. >References from non-OSGi components to OSGi components >are resolved by looking up the OSGi registry. Yes, if the non-OSGi SCA component has declared a reference with OSGi binding. If the OSGi component has declared a JMS service binding, the non-OSGi SCA component could use JMS instead of OSGi binding :-) Best regards Nicole > >Hello, > > >I would like to contribute to the SCA<->OSGi integration activities. > > >I have been looking at the existing OSGi binding implementation in > Tuscany > >which exposes SCA services as OSGi services. Even though this binding > is no > >longer working with the latest Tuscany builds, the samples were very > useful > >to understand the scenarios. I was also looking at the notes on the > mailing > >list (they are slightly old - dated Nov 2006) which talk about an > OSGi host > >and also an OSGi implementation type. Is there any ongoing work in > these > >areas? > > >Graham Charters and I have been investigating the use of an OSGi > >implementation type which will enable existing OSGi bundles to be run > as SCA > >components under Tuscany. We are particulary interested in the > scenario > >where Tuscany is in control. If components of OSGi implementation > type are > >specified in the composite, Tuscany starts up an OSGi runtime and > deploys > >the OSGi bundles corresponding to the components into the OSGi > runtime. If > >there are references from the OSGi component to other non-OSGi SCA > >components, a proxy service is registered by the Tuscany runtime with > the > >OSGi registry so that the OSGi bundles can access these SCA services > as > >normal OSGi services. References from non-OSGi components to OSGi > components > >are resolved by looking up the OSGi registry. > > >We would like to obtain feedback on using this approach and also > would like > >to get involved in the ongoing support for SCA<->OSGi integration. > > >Thank you... > > > >Regards, > > >Rajini > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-484) Attribute groups only working if defined in the default namespace
Attribute groups only working if defined in the default namespace - Key: TUSCANY-484 URL: http://issues.apache.org/jira/browse/TUSCANY-484 Project: Tuscany Type: Bug Components: C++ SDO Versions: Cpp-current Environment: Windows Reporter: Graham Charters When loading the following schema I get a parse error "Use of undefined group commonAttributes". http://example.org"; xmlns:ns1="http://example.org"; xmlns="http://www.w3.org/2001/XMLSchema";> It appears that if I change the schema so that the group is defined in the default namespace for the schema, then the parse works. So the following schema does not produce the error. http://example.org"; xmlns="http://example.org"; xmlns:xs="http://www.w3.org/2001/XMLSchema";> -- 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]
