Re: Versioning of Tuscany
On 6/12/08, Simon Nash [EMAIL PROTECTED] wrote: Any non-infinite version number requires making some assumption about the future compatibility of the 3rd party library. Without a crystal ball, this will be hard to get right every time. This is why I am suggesting a more conservative approach. On 6/13/08, Mike Edwards [EMAIL PROTECTED] wrote: If Tuscany itself allows the use of a range of versions of some 3rd party library, then in principle given that we attempt a form of test driven development, we should be testing with ALL of the versions of that 3rd party library. If we don't do that, then we are really winging it in terms of testing - we are implying that the Tuscany code has been verified to work with any and all of the levels within the range, when we have not done that. Experience in general says that it is not wise to assume that because Tuscany works with level 1.x of some library, that it will also work with level 1.x+1. Loosening a tight range is going to be tough. On 6/13/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I'm sure people will find that too simplistic, but I'm going to say it anyway. IMO if we test a release with version X we should just import version X. If somebody wants to run with version Y he gets the source, changes the import to Y, and takes responsiblity for building and testing with Y. If somebody wants version X and Y to co-exist in a VM, well that's possible too. And by the way in an SOA not everybody needs to run everything in a single JVM, so the best option is probably to run incompatible things in different JVMs. Sometimes we're so Java centric that we forget that the JVM runs on an operating system, which can run more than one JVM :) I have cut-and-paste three comments from Simon, Mike and Sebastien in this thread, and they all reflect the same viewpoint : use single tested versions of 3rd party libraries to avoid incompatibilities. Since this view is backed by Tuscany experience, I do fully accept that this is probably the safest starting point (I say starting point because I believe that we will need to broaden version ranges for 3rd party libraries which are shared with Tuscany, use TCCL etc. to support classloading constraints in commonly used scenarios without repackaging Tuscany). But before we go ahead and implement the narrowest possible versioning system, I would like to step back and look at why we are implementing versioning. - What value does versioning add to Tuscany? In other words, why are we doing this? The answer as far as I know is because OSGi users of Tuscany require some level of versioning in order to integrate Tuscany into their OSGi runtimes. At the moment, it is not very clear how much of sharing, isolation, side-by-side execution etc. is typically required. But we should be able to start either with a broad range and fine-tune by narrowing it for specific cases OR we could start with a narrow range and fine-tune by broadening for specific cases. We are never going to be able to get it right for all possible scenarios IMHO. - Do we require side-by-side execution of Tuscany extensions with multiple versions of 3rd party libraries? This has been cited in some notes in the past as a reason why we would like to version Tuscany. But given that Tuscany typically runs outside an OSGi runtime, are we ever going to build Tuscany extensions which mandate OSGi? Personally I dont see this as an immediate requirement - or rather I dont see versioning of Tuscany being adopted in the near future to solve extension versioning problems within Tuscany. - Do we require Tuscany to co-exist applications which use different versions of 3rd party libraries? We do know that there are OSGi users of Tuscany who have this requirement. In fact OSGi users will expect this to work. But do we see versioned third party libraries as first class support in Tuscany? Do we expect non-OSGi users of Tuscany to migrate to OSGi in order to use the versioning support in Tuscany once it is out there? Personally I see versioned libraries only being used by OSGi users of Tuscany and hence it makes sense to adopt OSGi best practice and follow broader version ranges. - When 3rd party libraries become OSGi-enabled by default, do we expect to reuse them, rather than re-bundle them? And another related question is - do we expect to interoperate with 3rd party libraries from other repositories like SpringSource? If we do expect to use 3rd party libraries bundle-ized elsewhere we should be prepared for relatively broad version ranges. Should we have two different versioning strategies - one for Tuscany where we restrict to using single version ranges, and another for 3rd party libraries where we tolerate broader ranges? What would that mean for testing? IMO if we want to interoperate with other 3rd party libraries, we have to start accepting the limitations in our testing, at least for OSGi. At
Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT
Ant, I am not sure how relevant this is, but in the context of versioning Tuscany for OSGi, Tuscany modules are being built as OSGi bundles with real versions (eg. the current build uses 2.0). The version used is not currently derived from the maven version, instead it is specified independently as a property in modules/pom.xml - so it won't actually break if you modified 2.0-incubating-SNAPSHOT to SNAPSHOT. But it will become less obvious to OSGi users what version a Tuscany build really is. We will need a real version for the snapshot builds for building OSGi bundles regardless of whether we use that as the version for maven. The question is whether we need OSGi build versioning to be consistent with maven versions - OSGi users building against Tuscany 1.4-SNAPSHOT probably expect to use the 1.4 release, while non-OSGi users as you say may expect to use the latest SNAPSHOT. Anyway, I just thought I will point this out, I dont actually mind either way. On 6/13/08, ant elder [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 9:41 AM, ant elder [EMAIL PROTECTED] wrote: On Sat, Jun 7, 2008 at 1:11 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: How about 1.5-SNAPSHOT ? This would probably give us some room to have couple releases without the necessity to keep updating the trunk pom version. And this would probably make everybody happy :) On Fri, Jun 6, 2008 at 1:14 AM, ant elder [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende [EMAIL PROTECTED] wrote: I guess part of problem here is because a lot of people assume that the maven artifact version represents what is going to be our next release and then, if it's set as 2.0-SNAPSHOT, it means our next release would be 2.0. I agree, this is exactly the issue. But I'm not sure its that much of an unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT as the trunk version before there has been any decision to start working on a 2.0 in trunk. ...ant I'd prefer the next logical number, 1.3 for example. I still think plain SNAPSHOT would be simplest but as no one else seems to like that I think I agree with this - the next logical number seems better than things like 1.x or 2.0 etc. So, I plan to change trunk to 1.4-SNAPSHOT when the 1.3 branch is taken, do say if you really don't like this but its what we've been doing most of the time in the past so i hope most can live with it. ...ant I've been asked off list to highlight an issue that may not have been clear from whats already been said in this thread. If we use 1.4-SNAPSHOT in trunk then external people who want to stay up to date with the latest code will use that version in their dependencies. They may not pay that close attention to the dev list so when we create the branch for a real 1.4 release and change the trunk to 1.5-SNAPSHOT the users dependencies will still use 1.4-SNAPSHOT but now instead of getting the latest code they're getting the stable branch code. One way this could be avoided is by using a trunk version of simply SNAPSHOT. Is anyone really against SNAPSHOT if we went for that instead of 1.4-SNAPSHOT? ...ant -- Thank you... Regards, Rajini
Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT
On 6/13/08, ant elder [EMAIL PROTECTED] wrote: Are the OSGI real versions required to be numeric, which would also mean 1.x wouldn't work so well as a version for OSGi right? Yes, the versions need to be numeric, 1.x wont work. ...ant On Fri, Jun 13, 2008 at 9:24 AM, Rajini Sivaram [EMAIL PROTECTED] wrote: Ant, I am not sure how relevant this is, but in the context of versioning Tuscany for OSGi, Tuscany modules are being built as OSGi bundles with real versions (eg. the current build uses 2.0). The version used is not currently derived from the maven version, instead it is specified independently as a property in modules/pom.xml - so it won't actually break if you modified 2.0-incubating-SNAPSHOT to SNAPSHOT. But it will become less obvious to OSGi users what version a Tuscany build really is. We will need a real version for the snapshot builds for building OSGi bundles regardless of whether we use that as the version for maven. The question is whether we need OSGi build versioning to be consistent with maven versions - OSGi users building against Tuscany 1.4-SNAPSHOT probably expect to use the 1.4 release, while non-OSGi users as you say may expect to use the latest SNAPSHOT. Anyway, I just thought I will point this out, I dont actually mind either way. On 6/13/08, ant elder [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 9:41 AM, ant elder [EMAIL PROTECTED] wrote: On Sat, Jun 7, 2008 at 1:11 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: How about 1.5-SNAPSHOT ? This would probably give us some room to have couple releases without the necessity to keep updating the trunk pom version. And this would probably make everybody happy :) On Fri, Jun 6, 2008 at 1:14 AM, ant elder [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende [EMAIL PROTECTED] wrote: I guess part of problem here is because a lot of people assume that the maven artifact version represents what is going to be our next release and then, if it's set as 2.0-SNAPSHOT, it means our next release would be 2.0. I agree, this is exactly the issue. But I'm not sure its that much of an unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT as the trunk version before there has been any decision to start working on a 2.0 in trunk. ...ant I'd prefer the next logical number, 1.3 for example. I still think plain SNAPSHOT would be simplest but as no one else seems to like that I think I agree with this - the next logical number seems better than things like 1.x or 2.0 etc. So, I plan to change trunk to 1.4-SNAPSHOT when the 1.3 branch is taken, do say if you really don't like this but its what we've been doing most of the time in the past so i hope most can live with it. ...ant I've been asked off list to highlight an issue that may not have been clear from whats already been said in this thread. If we use 1.4-SNAPSHOT in trunk then external people who want to stay up to date with the latest code will use that version in their dependencies. They may not pay that close attention to the dev list so when we create the branch for a real 1.4 release and change the trunk to 1.5-SNAPSHOT the users dependencies will still use 1.4-SNAPSHOT but now instead of getting the latest code they're getting the stable branch code. One way this could be avoided is by using a trunk version of simply SNAPSHOT. Is anyone really against SNAPSHOT if we went for that instead of 1.4-SNAPSHOT? ...ant -- Thank you... Regards, Rajini -- Thank you... Regards, Rajini
Re: Versioning of Tuscany
/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 -- Thank you... Regards, Rajini
Re: Versioning of Tuscany
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 using Axis2 1.4. This should avoid breakage. Yes, this is true. But how narrow should the range be? SpringSource assumes compatibility at major version. Should we assume minor version? Or should we restrict to revision? Are we saying that we work with 1.3.0, so we would work with 1.3.2, but not 1.4? Or are we saying that we have only tested against 1.3.0, so we will only use 1.3.0? The next step is for Tuscany to determine whether or not Axis2 1.4 is compatible for Tuscany purposes. If it is compatible, Tuscany could release an update for its bundles that changes their Axis2 dependency to (1.3.0, 1.5.0), with no change to the Tuscany code. The dependency graphs for Tuscany (even ignoring applications) is likely to be very complex, because we have 149 3rd party libraries with many 3rd party libraries having dependencies on each other. In the first instance, yes, I agree, we can easily restrict to a single major.minor.revision for each library. We test Tuscany with one combinarion of these 149 libraries. And it works, so we force this combination. But what happens in a year or two, when each of these 149 libraries may have 5 releases (minor releases perhaps, but new versions nevertheless). Do we test all 5 ** 149 combinations of 3rd party libraries to ensure that they can all work together? Even if we had tools which could work through the dependency graphs and provide a minimal set of combinations that could coexist, this would still be an awful lot of testing. Add to this application versioning requirements, third party bundles from other sources, and we will end up with a problem of enormous complexity. This approach
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On 6/10/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports By 1 bundle per module do you mean any sort bundled jar combining multiple of our tuscany/java/sca/module jars is not worth pursuing? ...ant I think that the right design is one bundle per maven module. From an OSGi point of view I would like to ensure that we will continue to have one bundle per 3rd party jar and that these will not be aggregated regardless of how the distribution is zipped up. As for one bundle per maven module, I think there are pros and cons for finely grained and coarsely grained bundles, and it is really just a matter of preference. Since we anyway have nearly 150 3rd party bundles/jars anyway, I personally dont see any problem with one bundle per module. I don't think that aggregating multiple modules into a single bundle makes much sense, or they should be aggregated in a single Maven module in the first place. IMHO modularizing Tuscany is about code quality and maintenance - something internal benefitting Tuscany developers. So we have 100 modules based on the developer's view of Tuscany internals. That does not necessarily mean that end users have to deal with 100 bundles. If 20 core modules are very tightly coupled together and will only operate with each other, as far as an end user is concerned, this could as well be one bundle. Can a Tuscany user combine assembly-xml version 1.3.0 with assembly version 1.3.1? Or even implementation-java with implementation-java-runtime of a different version? The answer is
Versioning of Tuscany
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
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. 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. Regards, Graham. 2008/6/11 ant elder [EMAIL PROTECTED]: On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram [EMAIL PROTECTED] wrote: snip 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
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604217#action_12604217 ] Rajini Sivaram commented on TUSCANY-2343: - Hi all, I have started a discussion on versioning Tuscany on the dev list (http://markmail.org/message/waiieq6cvhtqb332). Since you have already faced problems resulting from inadequate versioning in Tuscany, your input will be very useful. Thank you... - Rajini OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604050#action_12604050 ] Rajini Sivaram commented on TUSCANY-2343: - Daniel, Do you have a date that you would require a bundle-ized Tuscany to be ready by to match with your release dates? It is definitely not going to be ready in time for the 1.3 release - do you require a released version? Sebastian, The DynamicImport-Package statements in the 3rd party jars are temporary (they were used to generate virtual bundles on the fly), and will be replaced with explicit versioned import statements, probably generated using maven-bundle-plugin. There may be a few dynamic imports left in Tuscany, but they will be specific ones that are not wildcarded. - Rajini OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602965#action_12602965 ] Rajini Sivaram commented on TUSCANY-2343: - Daniel, Thank you for doing this. I think we are getting somewhere finally... The current set of 3rd party libraries in Tuscany use DynamicImport-Package rather than generate the real list of imported packages at build time. As a result, the import list changes as classes are loaded. The Equinox behaviour is correct - there should only be one source for a package, so once the package is imported, it should not search locally. You have another version of xerces in your enviroment, with version 2.9.0 (Tuscany provides 2.8.1). It looks like your xerces bundle exports META-INF.services. Since Tuscany's wstx-asl uses Dynamic-ImportPackage: *, it is getting wired to your xerces bundle version 2.9 while reading some resource in META-INF/services. We will be modifying Tuscany's 3rd party bundles to use proper import/exports which will avoid this problem, but we need to sort out our versioning story first, so that may take a while. In the meantime, would it be possible to modify your xerces bundle to stop exporting META-INF.services? I dont think META-INF/services should be an exported package anyway - it should be private to ensure that bundles can have their own list of services. - Rajini OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603038#action_12603038 ] Rajini Sivaram commented on TUSCANY-2343: - Daniel, Now that is good progress, though obviously not quite enough :-(. The exception shows that SDO API bundle is not able to load the class HelperProviderImpl from the SDO implementation bundle. Do you have another copy of SDO bundles (api/impl/lib)? SDO has been packaged as OSGi bundles for a while now, and I think it has been used with Eclipse for sometime. So I didn't want to break it. But the SDO bundles shipped separately use EMF which has a dependency on Eclipse, and I think they require Buddy-Policy for classloading. Tuscany SCA repackages these bundles to avoid the Eclipse dependency (this is probably not an issue for you) and also to enable the bundles to import from each other without requiring Eclipse-specific Buddy-Policy (I think all the SDO bundles need to be buddies). If you do have another set of SDO bundles in your environment, you could either uninstall them and use Tuscany's versions or use Buddy-Policy. If you dont have another version of SDO, it must be a different problem altogether... - Rajini OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602583#action_12602583
]
Rajini Sivaram commented on TUSCANY-2343:
-
Daniel,
It still looks like a problem with TCCL, though I dont know why. I think it is
too early to be related to the JAXB issue.
Can you add a try-catch block in ScaDomainActivator.initDomainByContribution
around the code which creates and starts the SCA domain, and include this
snippet of code twice - just before calling EmbeddedSCADomain.start after you
have set TCCL, and in the catch block.
try {
System.out.println(TCCL : +
Thread.currentThread().getContextClassLoader().getClass());
javax.xml.stream.XMLInputFactory.newInstance();
} catch (Throwable e) {
e.printStackTrace();
}
I would expect to see the print TCCL : class
org.apache.tuscany.sca.osgi.runtime.OSGiBundleActivator$BundleClassLoader and
no exception thrown from the call in both cases if it works.
- Rajini
OSGi bundle design leads to class loading issues
Key: TUSCANY-2343
URL: https://issues.apache.org/jira/browse/TUSCANY-2343
Project: Tuscany
Issue Type: Bug
Reporter: Georg Schmidt
Attachments: Libary Versions.xls, test_bundles.zip
Currently the design of the OSGi bundles leads to class loading exceptions.
There seem to be several reasons for this behavior:
* reexporting of all libraries without version numbers
* imports without version numbers
Please use distinct bundles for 3rd party libraries. That would lead to
easier reusage of your bundles in a larger OSGi project.
The current status leads to undefined system behaviour due to the OSGi class
loading concept.
Please tell if you see a way, how we could support you by achieving this
goal. (If a solution is interesting for you) We are willing to contribute
because its a critical project issue for us.
The problems occur with the current snapshot release. Sorry, I do not know
which version to take.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602606#action_12602606 ] Rajini Sivaram commented on TUSCANY-2343: - Daniel, Could you run the test through the debugger with breakpoints on the line javax.xml.stream.XMLInputFactory.newInstance(); in both the cases? When you get to this line, could you set breakpoints on the methods getResource and findClass in OSGiBundleActivator.BundleClassLoader? I would like to make sure that 1) The same OSGiBundleActivator$BundleClassLoader object is used in both cases 2) The bundles field of this object contains around 200 bundles 3) getResource(META-INF/services/javax.xml.stream.XMLInputFactory) when called returns a valid URL in both cases 4) findClass(com.ctc.wstx.stax.WstxInputFactory) should get called in both cases, and should return a class from the bundle (the first return statement). Sorry, I really dont have a clue what is broken... - Rajini OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602655#action_12602655 ] Rajini Sivaram commented on TUSCANY-2343: - Daniel, I have been staring at OSGiBundleActivator$BundleClassLoader.getResource hoping that something will strike me, but I just can't find any problem with it. I would have been happier if this was a rare timing related issue, but obviously it isn't. bundle.getResource() should only return null if 1) the resource is not present 2) the bundle is not resolved or 3) the caller doesn't have permissions. I can't imagine any of these changing between the two calls in such a consistent way. It obviously looks like some code during Tuscany startup is having an impact, but I have no idea what it could be. If you have Equinox source on your machine, it will be useful to step through the bundle.getResource call in OSGiBundleActivator$BundleClassLoader.getResource for the bundle org.apache.tuscany.sca.wstx-asl-3.2.1.jar in the failing case. Otherwise, maybe compare this setup with your test setup - I am still confused as to why this didn't fail with your test since the same Tuscany code was executed with both - in very similar environments perhaps? - Rajini OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602242#action_12602242 ] Rajini Sivaram commented on TUSCANY-2343: - Daniel, I had installed and started tsucany-sca-installer.jar first, so I had all Tuscany bundles and 3rd party jars installed before starting your bundles. I was expecting that your launch configuration using the installer would also result in the same bundles in Equinox. But yes, I am not using Eclipse, so it could be an Eclipse issue. Could you list the bundles in Equinox when using the installer, and check that all the 3rd party bundles are being installed? Also are all the Tuscany module bundles installed, and in RESOLVED state? The WorkScheduler is in the core module, so do you have a bundle with symbolic name org.apache.tuscany.sca.core installed and resolved? Obviously host-embedded was installed and resolved since the classes from this module are on your stack trace. If all the other bundles are present and resolved, but ServiceDiscovery is not finding the classes, there may some additional logic required in the Tuscany activator when running the bundles under Eclipse. -Rajini OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602292#action_12602292 ] Rajini Sivaram commented on TUSCANY-2343: - Daniel, The latest stack trace looks like a problem with thread context classloading. For XML parsing, the classes from third party bundles should be visible from TCCL. Tuscany's bundle activator sets up a TCCL which includes all 3rd party bundles. If this bundle activator is run from a different thread from the one starting the Tuscany runtime (or if you want to modify TCCL), you have to ensure that TCCL has access to classes from 3rd party libs. The TCCL set by Tuscany can be obtained using o.a.t.s.osgi.runtime.OSGiRuntime.getContextClassLoader(). In your test bundle activator, could you try calling Thread.currentThread().setContextClassLoader(OSGiRuntime.getContextClassLoader()); before starting the Tuscany runtime? This should really be fixed properly in Tuscany (at least for straightforward usecases), but for now, could you try this fix? - Rajini OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602324#action_12602324 ] Rajini Sivaram commented on TUSCANY-2343: - Daniel, I am not sure I missed something, but this stack trace looks exactly the same as the previous one. Does org.eclipse.eilf.connectivity.framework.sca.ScaDomainActivator set TCCL before calling EmbeddedSCADomain.start? If so, is it possible that this bundle is being loaded from the cache (could you try -clean option)? I will try to fix this in Tuscany this weekend, but at the moment it would be safest to set TCCL in all your bundle activators starting SCADomains. - Rajini OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release SDO 1.1.1
Kelvin,
Sorry about the delay in getting back to you - I can see that you have found
a solution. Yes, you are absolutely right, the felix framework should use
scope provided since SdoBundleActivator is only used when SDO is running
inside an OSGi container, and the framework classes are provided by the
container.
On 6/3/08, kelvin goodson [EMAIL PROTECTED] wrote:
Just a thought, would I be right in guessing that if ever our
SdoBundleActivator is touched in the runtime, then the environment would
be
expected to provide the classes to satisfy
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
?
in which case I think declaring a provided scope for the felix dependency
would be the right way to do things
Kelvin.
2008/6/3 kelvin goodson [EMAIL PROTECTED]:
Thanks Ant, that looks like progress, but the felix framework jar is
now
not in the list of distributed jars.
Kelvin.
2008/6/3 ant elder [EMAIL PROTECTED]:
Adding an exclude for felix to the distribution pom can fix that, eg
here's
local changes i have just tried:
Index: src/main/assembly/bin.xml
===
--- src/main/assembly/bin.xml (revision 662488)
+++ src/main/assembly/bin.xml (working copy)
@@ -120,13 +120,13 @@
dependencySets
dependencySet
outputDirectorytuscany-sdo-${sdo.version}/lib/outputDirectory
-includes
-
includeorg.apache.tuscany.sdo:tuscany-sdo-api-r2.1/include
+!-- includes
+
includeorg.apache.tuscany.sdo:tuscany-sdo-api-r2.1/include
includeorg.apache.tuscany.sdo:tuscany-sdo-lib/include
includeorg.apache.tuscany.sdo:tuscany-sdo-impl/include
includeorg.apache.tuscany.sdo:tuscany-sdo-tools/include
includeorg.apache.tuscany.sdo:sample-sdo/include
-/includes
+/includes --
fileMode0644/fileMode
/dependencySet
Index: pom.xml
===
--- pom.xml (revision 662488)
+++ pom.xml (working copy)
@@ -56,6 +56,12 @@
groupIdorg.apache.tuscany.sdo/groupId
artifactIdtuscany-sdo-impl/artifactId
version${pom.version}/version
+exclusions
+exclusion
+groupIdorg.apache.felix/groupId
+artifactIdorg.apache.felix.main/artifactId
+/exclusion
+/exclusions
/dependency
dependency
groupIdorg.apache.tuscany.sdo/groupId
@@ -67,6 +73,7 @@
artifactIdsample-sdo/artifactId
version${pom.version}/version
/dependency
+
/dependencies
build
Which results in a lib directory containing:
backport-util-concurrent-3.0.jar
codegen-2.2.3.jar
codegen-ecore-2.2.3.jar
common-2.2.3.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
sample-sdo-1.1.1-incubating-SNAPSHOT.jar
stax-api-1.0.1.jar
tuscany-sdo-api-r2.1-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-impl-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-lib-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-tools-1.1.1-incubating-SNAPSHOT.jar
wstx-asl-3.2.1.jar
xsd-2.2.3.jar
...ant
On Tue, Jun 3, 2008 at 11:31 AM, kelvin goodson [EMAIL PROTECTED]
wrote:
I had an offline chat with Rajini. It seems we need just the
framework
jar
of felix in the distro, but if the dependency on felix is declared as
test
scope in the pom, then that jar is not available to main phase of the
build. If its not declared as test scope then we get 5 felix jars in
the
binary distro. Rajini's going to take a look when she gets some time.
Kelvin.
2008/6/3 kelvin goodson [EMAIL PROTECTED]:
The felix jars were introduced in the fix for SDO does not work
with
OSGi [1] in commit 620763 [2]. I don't know if this is expected
behaviour, not being an OSGI expert. Comments anyone?
Kelvin.
[1] https://issues.apache.org/jira/browse/TUSCANY-1293
[2] http://svn.apache.org/viewcvs?view=revrev=620763
2008/6/3 kelvin goodson [EMAIL PROTECTED]:
The required libraries are
sample-sdo-%RELEASE%.jar
sdo-api-r2.1-%RELEASE%.jar
tuscany-sdo-lib-%RELEASE%.jar
tuscany-sdo-impl-%RELEASE%.jar
tuscany-sdo-tools-%RELEASE%.jar
codegen-ecore-2.2.3.jar
codegen-2.2.3.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
common-2.2.3.jar
xsd-2.2.3.jar
stax-api-1.0.1.jar
wstx-asl-3.2.0.jar
with
backport-util-concurrent being optional if you want threadsafe
collections with Java 1.4 IIRC
The felix jar inclusions were introduced some time between commit
level
600913 and 627754; I'm working on narrowing this down at the
moment.
Kelvin.
2008/6/2 ant elder [EMAIL PROTECTED]:
It is
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602063#action_12602063 ] Rajini Sivaram commented on TUSCANY-2343: - Daniel, I tried out your test by creating bundles and installing them (I am running Equinox, but not using Eclipse plugins) and the output showed: osgi start 238 creating TestImpl osgi start 239 Starting ... test.composite ready !!! did something It looks like it worked, so I will wait and see your response to Dan's question on security. Dan, Doesn't Tuscany throw SecurityExceptions when security is turned on and the required FilePermissions are not granted? - Rajini OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601495#action_12601495 ] Rajini Sivaram commented on TUSCANY-2343: - I have committed some changes to the installer, which should hopefully enable you to make more progress. There is some more logic to determine the directory to load Tuscany jars from. I am hoping that it will now find the jars relative to the installer.jar in your case. If all else fails, you can set either the environment variable or the system property TUSCANY_HOME to the directory containing the Tuscany jars. Please update to the latest itest/osgi-tuscany (again, sorry). I have added some code in the installer to dump the virtual bundles created by the installer onto the disk. If you run the maven build in itest/osgi-tuscany with the environment variable TUSCANY_OSGI_DEBUG set to true, all the 3rd party libs converted to bundles are written out to the directory containing tuscany-sca-osgi-installer.jar (itest/osgi-tuscany/tuscany-osgi-installer/target). Maybe you can copy these to your Tuscany directory to avoid the pdebuild errors? Tuscany uses these 3rd party bundles if they are found in the TUSCANY_HOME directory. So I am hoping that you will be able to use these to isolate versioning/classloading errors. I had a look at Georg's list of libraries and versioning clashes. Would it be possible for one of you to send me the third party bundles you are using for the clashing libraries (either attach to this JIRA or email to [EMAIL PROTECTED]) ? I would first like to understand the problem with jaxb since the versions are identical. For the others, where you have different versions, do you requireTuscany and your application to share classes from these libraries? What does the warning column indicate - do these correspond to actual classloading errors? Unfortunately, I might not have time during this week to look into this, but if you send me the libraries, depending on how complicated it turns out to be, I will try to respond as soon as I can (I will definitely look at it in the weekend if I can't get to it earlier). Sorry about that. - Rajini OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- 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 ] Rajini Sivaram updated TUSCANY-2330: Attachment: samples-calculator-osgi-runtime-patch.txt Graham, I have attached the patch for the OSGi calculator sample as I have it on my machine. It could help in the discussion on whether this should be a sample or an itest. - Rajini 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, samples-calculator-osgi-runtime-patch.txt 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-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601179#action_12601179 ] Rajini Sivaram commented on TUSCANY-2343: - Georg, Thank you for the list of libraries, I will take a look at those in detail and compare them with Tuscany's. Daniel, I have updated the installer to read jars out of a Tuscany distribution. If you set the enviroment variable TUSCANY_HOME, the installer looks inside TUSCANY_HOME/modules and TUSCANY_HOME/lib for the jars. Is this sufficient for you, or do you require jars to be located relative to the installer jar as well? I haven't used pdebuild with Tuscany, sorry... OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (TUSCANY-2307) Calling OSGi Service with SDO data
On 5/30/08, roshan joseph [EMAIL PROTECTED] wrote: Hi Rajani, The java component I uses has a jms binding and this is invoked by a message send to the queue. So by making this an OSGI bundle, will I be able to get the java component working? Yes, I hope so. If what you are looking is a dummy bundle with the manifest file, I can try that way, will update you soon. The bundle should import the sdo packages (same as your other OSGi bundle). And then I hope they will be able to interoperate. I do need to look at fixing this properly in Tuscany, but the simpler fix for now for you to make progress will be to use a bundle for your java component. Regards Roshan Rajini Sivaram (JIRA) tuscany-dev@ws.apache.org wrote: [ https://issues.apache.org/jira/browse/TUSCANY-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12595937#action_12595937] Rajini Sivaram commented on TUSCANY-2307: - Roshan, Is the Java component (which is invoking the OSGi service) inside an OSGi bundle contribution? If not, will it be possible to make it an OSGi bundle contribution (jar file with OSGi manifest headers)? Calling OSGi Service with SDO data -- Key: TUSCANY-2307 URL: https://issues.apache.org/jira/browse/TUSCANY-2307 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-1.2 Environment: Windows XP, Java Tuscany Sca runtime Reporter: Roshan Joseph Fix For: Java-SDO-Next Hi, I am trying to call an OSGi service from my sca java service running in the Tuscany SCA runtime. I uses the itest\osgi-implementation sample for SDO as my osgi service and calls the getGreetings method with SDO data as the input parameter for this call. I am reusing the HelloWorldService.jar which is in the itest\osgi-implementation folder for my OSGi service component. The composite file of my java service is something like as shown below. xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; xmlns:dbsdo= http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0; xmlns:hw=http://com.siemens.hintegration; name=motionreactorComposite jndiURL=tcp://localhost:61616 bundleSymbolicName=ds.helloworld.sdo.HelloWorldService/ The actual code in my java component where I make the call to OSGi service is as follows: // Call the OSGi service Name name = HelloworldFactory.INSTANCE.createName(); name.setFirst(firstName); name.setLast(lastName); String hello = helloWorldService.getGreetings(name); getLogger().info(OSGi iTest Sample Call: + Hello); getLogger().info(OsgiService called); In the debug mode when the call reaches the OSgi component, I get a illegal argument exception. The error log looks like as shown below. - Exception occured while calling OSGi service java.lang.IllegalArgumentException: argument type mismatch at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeMethod(OSGiTargetInvoker.java:171) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiRemotableInvoker.invokeMethod(OSGiRemotableInvoker.java:75) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget(OSGiTargetInvoker.java:143) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke(OSGiTargetInvoker.java:188) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:103) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:103) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy8.getGreetings(Unknown Source) at com.siemens.hintegration.MotionReactorImpl.getGreetings(MotionReactorImpl.java:178) at com.siemens.hintegration.MotionReactorImpl.onMotionDetected(MotionReactorImpl.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601192#action_12601192 ] Rajini Sivaram commented on TUSCANY-2343: - Sebastian, Thank you for the update. Yes, I do now understand that the pdebuild is broken because we are not converting 3rd party jars into real bundles. They are converted to virtual bundles when the installer runs, but that obviously does not help with the pdebuild. The installer bundle is a temporary solution to enable testing Tuscany under OSGi. We are still discussing the best way to OSGi-enable Tuscany, and this feedback from actual usage has been very helpful. For using the installer bundle at runtime (for now), you can either set TUSCANY_HOME (the installer looks for jars in TUSCANY_HOME/modules and TUSCANY_HOME/lib) - you need to update to the latest level of the code. Alternatively, I can update the code to read the jars relative to the installer.jar. I do completely agree that the current installer jar is not suitable for deployment. I will look through Georg's list to see how much version constraining we will need for the imports - if they are done in Tuscany. - Rajini OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OSGi-enable 3rd party libraries in Tuscany
On 5/29/08, Simon Nash [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: Simon, A couple of comments inline... On 5/28/08, Simon Nash [EMAIL PROTECTED] wrote: Sorry for the long delay in responding. I have been deeply buried in implementing the new WSDL-less support, and I am only just surfacing to follow up on other threads. Comments inline. Simon Rajini Sivaram wrote: On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Simon Nash wrote: ... snip I believe that if we are serious about making OSGi-enablement of Tuscany a first class option, we should consider doing 1). For the longer term to support versioning of 3rd party jars, 1) will provide a standard OSGi mechanism. As more and more 3rd-party libraries are being OSGi-enabled, this can be seen as an intermediate step which enables users of Tuscany to install Tuscany in the same standard OSGi way, into an OSGi runtime. I agree and think we should do (1) everywhere we can. I don't think Tuscany should modify third-party jars that we are redistributing as part of Tuscany. I think we should use some variant of (3) for all third-party jars that aren't already OSGi-enabled. Can you say why? At the moment we are redistributing these libraries as a convenience for people who want to run Tuscany out of the box. If people want to obtain these libraries in some other way (e.g., from a maven repo, by direct download from the third-party project, or as part of some other download), that's fine too. This change would alter that picture considerably. For people using Tuscany within OSGi, it would be necessary to use the modified libraries distributed by Tuscany. I am not sure if OSGi users of Tuscany would expect 3rd party non-bundle jars downloaded from elsewhere to work with Tuscany running under OSGi. If there is a requirement, we can support virtual bundles with naive manifests just for these cases. I am not sure that is reason enough for virtual bundles to be the only (or default) option. On the other hand, I would think that OSGi users of Tuscany may expect 3rd party bundle jars from other projects like ServiceMix to work with Tuscany running under OSGi. We can easily support that with bundle-ized jars. It would be great to have some co-ordination between these projects so that they can share the same bundle-ized 3rd party jars rather than all creating their own copies and giving the user the problem of figuring out whose version of bundle-ized jaxb can be used with Tuscany, ServiceMix, Spring, etc. This might or might not be required outside the OSGi environment, depending on how we set up the distro and the way our extensions locate their third-party dependencies. For users who run Tuscany outside of OSGi, we can (and should) continue to support third party libraries downloaded from anywhere. I dont think bundle-izing 3rd party libraries will require any changes to the way extensions locate their third party dependencies. If the bundle-izing is only intended for use by the native OSGi Tuscany runtime, could we produce a separate distro that contains the native OSGi Tuscany runtime and the bundle-ized 3rd party jars? Our current binary distro is very large and it would not be good to have it contain a complete set of unmodified 3rd party jars and another complete set of the same jars in bundle-ized form. I would also not be keen to change the regular binary distro to only contain bundle-ized jars as I think this will be confusing for non-OSGi users of Tuscany, especially if they don't want to use the exact levels of the 3rd-party jars that Tuscany has decided to bundle-ize. I looked at ServiceMix4 and I see that it is doing something like this with the org.apache.servicemix.bundles.* files. For example, there's one of these that wraps the JAXB implementation in an OSGi bundle. If we do the same in Tuscany, anyone wanting to use Tuscany with ServiceMix4 in an OSGi environment will need the ServiceMix+JAXB bundle and also the Tuscany+JAXB bundle, duplicating all the JAXB implementation classes. Now add SpringSource and a few other projects into the mix and how many copies of the same JAXB code will the user need? Any number greater than one is the wrong answer. If you install ServiceMix4 and Tuscany, at the moment you will have org.apache.servicemix.bundles.jaxb.jar and Tuscany's jaxb.jar on your disk. Using real bundles, we will replace Tuscany's jaxb.jar with org.apache.tuscany.sca.jaxb.jar. We still have two jaxb jars on the system. Using virtual bundles, we will convert Tuscany's jaxb.jar on the fly to org.apache.tuscany.sca.jaxb.jar. The only use case where we reduce disk space is where Tuscany's jaxb.jar is shared with other products running outside OSGi. As I said above, I'm not keen to replace jaxb.jar in the Tuscany binary distro by org.apache.tuscany.sca.jaxb.jar
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600697#action_12600697 ] Rajini Sivaram commented on TUSCANY-2343: - Georg, I realized that some of the bundles installed by Tuscany using the installer did not use export versions for the packages. I have just committed a fix. Could you please update to the latest level before testing your scenario? Sorry about this, I should have checked yesterday - Rajini OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (TUSCANY-2330) Calculator sample running in OSGi
On 5/28/08, Simon Nash [EMAIL PROTECTED] wrote: Graham Charters wrote: I've been wondering whether we should make this an itest rather than a sample. We could keep it as a sample, but it relies on maven-dependency-plugin to work out the dependencies required to run the sample. Is a sample that only works with maven acceptable (I believe the other samples do not) or should I change this to be an itest? We do try hard to make the samples work with ant as well as maven. There have been cases where samples started out with maven support only and the ant support was added later. From your description, it doesn't sound lke this is likely to happen. There are webapp samples in Tuscany which use hardcoded dependency lists for modules and 3rd party libs in their ant build script. We should be able to do something similar for the OSGi sample as well. It involves some more work, but if we agree that sample is the way to go, I think we can get it running under ant. The ant version wont be as flexible as the maven version which works out transitive dependencies, but it should work. I believe the main purpose of this sample is to act as a test for the Tuscany build rather than a sample for a user to copy and adapt. If this is correct, I think it should be changed to an itest. Simon Regards, Graham. 2008/5/23 Graham Charters (JIRA) tuscany-dev@ws.apache.org: [ https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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. -- Thank you... Regards, Rajini
Re: [jira] Commented: (TUSCANY-2330) Calculator sample running in OSGi
On 5/28/08, Simon Laws [EMAIL PROTECTED] wrote: On Wed, May 28, 2008 at 11:16 AM, Simon Nash [EMAIL PROTECTED] wrote: Graham Charters wrote: I've been wondering whether we should make this an itest rather than a sample. We could keep it as a sample, but it relies on maven-dependency-plugin to work out the dependencies required to run the sample. Is a sample that only works with maven acceptable (I believe the other samples do not) or should I change this to be an itest? We do try hard to make the samples work with ant as well as maven. There have been cases where samples started out with maven support only and the ant support was added later. From your description, it doesn't sound lke this is likely to happen. I believe the main purpose of this sample is to act as a test for the Tuscany build rather than a sample for a user to copy and adapt. If this is correct, I think it should be changed to an itest. Simon Regards, Graham. 2008/5/23 Graham Charters (JIRA) tuscany-dev@ws.apache.org: [ https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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. As we have a distribution that doesn't fundamentally depend on, and hence demonstrate, how Tuscany might be deployed in an OSGi environment then I think that a sample that shows how to do this is appropriate. If this means that we have a sample that only runs from maven then it's inconsistent with our other samples but I could live with that. I guess the real answer is do you think a user could base an OSGi installation on what they learn by looking at the sample. I haven't looked at the sample yet myself. Does this bring host-osgi back to life? Is this sample going to be reworked in the short term as the code is moved around? If yes then that would be a justification for keeping it out of samples. In its current form, the sample is too complicated - but it can be simplified quite easily to enable it to be used as both a sample and a test. If this is going to be an itest, I would really like it to reuse code from itest/osgi-tuscany rather than create a new copy of the code, requiring maintenance of two copies. As an itest, this subset should only add maven scripts to create a new set of dependencies. All the code can be used straight out of itest/osgi-tuscany rather than through a copy. Since this code is likely to change a lot as we tackle versioning etc., and since the calculator subset doesn't really add any new code, it would be much easier to maintain a single copy of the code rather than two (even though both are identical at the moment). IMO, it only makes sense to use a separate copy if the code is expected to diverge. Regards Simon -- Thank you... Regards, Rajini
Re: OSGi-enable 3rd party libraries in Tuscany
Simon, A few comments inline... On 5/29/08, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: 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. To clarify what I have been saying, I agree with this and I was expecting that virtual bundles would be constructed in this way. Even though we can technically generate the exact same manifest entry for virtual bundles as we would for real bundles, IMHO decoupling manifest entries which describe very fine grained information about a bundle like the exact versions of packages it imports from the 3rd party jar and storing it in the Tuscany distribution in a non-standard way is just the wrong thing to do. Like we have already shown with itest/osgi-tuscany, virtual bundles provide a quick and easy way for a large project to get up and running inside an OSGi runtime. But IMO, the virtual bundle approach has WORKAROUND written all over it. 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. Think of this from a user's perspective. I am downloading Tuscany and it comes with 149 required dependent bundle-ized 3rd party jars, all at specific levels chosen by Tuscany, and with Tuscany-specific modifications. I would like to understand what you mean by Tuscany-specific modifications. IMO interoperating with 3rd party jars bundle-ized outside of Tuscany is not a nice-to-have, it is a must-have. When we bundle-ize a 3rd party jar, all we add are OSGi manifest entries. If we look at the entries that we add these include 1. Bundle symbolic name : 3rd party jars bundle-ized by Tuscany will use the name org.apache.tuscany.sca.xxx. Typically applications will never refer to this name, but in theory they can (eg. to force a bundle to only use imports from a specific bundle). Use of this name will be a deliberate act by an user, and hence we dont introduce any interoperability issues by using a different name. 2. Bundle version and versions of exported packages : Now this is the most crucial information inside a bundle. It is very crucial that we use the same versioning conventions as everyone else. Basically this means that jaxb-impl-2.1.6.jar will use bundle and package version 2.1.6 regardless of whether it was bundle-ized by Tuscany or anyone else. Regardless of whether we use virtual bundles or real bundles, this is an absolute must-have for sharing of classes between applications and Tuscany. 3. Import-Package, Dynamic-ImportPackage and uses statements in Export-Package: The actual packages imported are going to based on what is imported, and hence should be identical for a bundle regardless of who bundle-ized it. But there could be (and probably will be) differences in the constraints used in Import-Package and uses clauses in exports. These constraints are used to achieve sharing and isolation of classes. For Tuscany, we would probably look at scenarios and tune the constraints for the most common scenarios. But there is always going to be some application somewhere which wishes to use a different set of constraints to achieve a different kind of sharing/isolation. This again comes back to the point that we have to interoperate with bundles generated by other users. And we shouldn't make it too tedious for users to replace Tuscany's copies of 3rd party bundles with their own. IMO, real bundles are much more suited to complex scenarios involving complex versioning/classloading constraints than virtual bundles. I can't easily apply the Tuscany modfications to other levels of the same software that I may need
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600398#action_12600398 ] Rajini Sivaram commented on TUSCANY-2343: - Am I right in assuming that you are using the 5 bundles generated using itest/osgi-tuscany? These bundles have been superceded by a finer-grained set of (roughly) 200 bundles, where each Tuscany module is converted to a separate bundle, and each third party jar is converted on-the-fly to a separate bundle. itest/osgi-tuscany/tuscany-osgi-installer generates a bundle containing the list of Tuscany modules and 3rd party jars and a bundle activator which installs those. To install Tuscany into an OSGi runtime, you should install and start tuscany-sca-osgi-installer.jar. Does this JIRA correspond to the first issue described in http://markmail.org/message/noszcnhr6shqmjt2 ? If so, could you try out the latest version of itest/osgi-tuscany, using the installer bundle? We haven't yet tackled versioning issues with Tuscany, and clearly the coarse grain bundles which were used earlier cannot handle versioning of individual 3rd party jars. The bundles generated by tuscany-sca-osgi-installer.jar for 3rd party jars are versioned (and the version number is the same as the jar version). So it should enable sharing of jars across Tuscany and applications if the application is able to use the same version as Tuscany. If you want to use a different version of 3rd party jar in the application, and force Tuscany to use that version, you can modify the maven dependencies in the installer to exclude the jar (as long as the versions are compatible). Would this be sufficient to handle your scenario? There is still the outstanding issue of version numbers in Tuscany imports. This will be an issue if we want to provide isolation and force either two Tuscany extensions, or a Tuscany extension and an application to use two different versions of a 3rd party library. As we are only beginning to look at versioning in Tuscany, it will be very useful for us to understand the usage scenarios. The level of versioning we add to import statements in Tuscany modules will really depend on whether we are trying to tackle sharing or isolation of classloaders. Could you give some more detail on the scenario that you are using? OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600437#action_12600437 ] Rajini Sivaram commented on TUSCANY-2343: - Georg, Thank you for the details on your scenario. It has been very helpful. For now, I think we have enough information to make progress. When we start introducing more versioning information in the jars, it will be very useful to run these against your scenario first. With tuscany-sca-osgi-installer.jar, 3rd party jars are installed with the actual jar versions. In the example you used of servlet api, the bundle installed will have: Bundle-SymbolicName: org.apache.tuscany.sca.3rdparty.servlet-api-2.5 Bundle-Version: 2.5 Import statements in Tuscany however do not specify a version range. So Tuscany can use a different version of javax.servlet installed by an application and share classes from javax.servlet. As long as the version range used by the application contains the version 2.5, Tuscany and the application will use the same definitions of javax/servlet (either from this bundle or the one installed by the application). If the application uses a version range (eg. version=2.6) which does not match Tuscany's, the application and Tuscany could end up using javax.servlet from different bundles - in this case the application will always use 2.6, but Tuscany may use 2.6 or 2.5 as chosen by the OSGi framework since it does not specify a version range in its import). The issues that we need to address for versioning import statements are: 1) Version ranges specified in import statements should be broad enough to enable sharing. eg. If Tuscany is able to work with versions between 2.4.8-2.6.2 of javax.servlet, the version range should include the entire range of those versions, enabling applications to choose the version. 2) Version ranges should be narrow enough to enable isolation when we want two versions to coexist. eg. If one Tuscany extensionA wants to use version 3.1 of foo.jar and another extensionB (or the application) wants to use 3.3 of the same jar, where classes of the jar are not required to be shared, we should be able to specify narrow ranges of versions in the import of org.foo, so that the extensions use different versions. 3) Versions introduced by tools like the maven-bundle-plugin cannot really provide us 1) and 2). So we will need to carefully analyse the usage of all 3rd party jars to introduce proper version ranges in imports. Hence scenarios like yours can be very useful to ensure that we get it right. Back to tuscany-sca-osgi-installer.jar - this is not built as part of the main build in Tuscany. So you need to run maven from itest/osgi-tuscany. You should then be able to install and start this bundle. You should see around 200 bundles installed when bundle.start() returns. You will need to modify the build script only if you want to disable the installation of a 3rdparty jar. 1) If the JAXB bundle you are using is the same version (eg. 2.6.1) as the one installed by Tuscany, you wont need to change anything. A single bundle will be chosen as exported by the framework. 2) If the JAXB bundle you are using is of a different version (eg. 2.6.2), and the application's import statements use a range which includes both 2.6.1 and 2.6.2, you dont need to change anything. The same export will be used for both application and Tuscany. 3) If the application uses a version range that is different (application requires 2.6.2), you should change the Tuscany installer build script to exclude version 2.6.1, to ensure that Tuscany does not pick that one. Hope this helps. OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OSGi-enable 3rd party libraries in Tuscany
Can we decide on a solution for OSGi-enabling 3rd party libs (either in the distribution or using virtual bundles), so that we can start tackling issues like versioning (https://issues.apache.org/jira/browse/TUSCANY-2343)? On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Simon Nash wrote: ... snip I believe that if we are serious about making OSGi-enablement of Tuscany a first class option, we should consider doing 1). For the longer term to support versioning of 3rd party jars, 1) will provide a standard OSGi mechanism. As more and more 3rd-party libraries are being OSGi-enabled, this can be seen as an intermediate step which enables users of Tuscany to install Tuscany in the same standard OSGi way, into an OSGi runtime. I agree and think we should do (1) everywhere we can. I don't think Tuscany should modify third-party jars that we are redistributing as part of Tuscany. I think we should use some variant of (3) for all third-party jars that aren't already OSGi-enabled. Can you say why? At the moment we are redistributing these libraries as a convenience for people who want to run Tuscany out of the box. If people want to obtain these libraries in some other way (e.g., from a maven repo, by direct download from the third-party project, or as part of some other download), that's fine too. This change would alter that picture considerably. For people using Tuscany within OSGi, it would be necessary to use the modified libraries distributed by Tuscany. This might or might not be required outside the OSGi environment, depending on how we set up the distro and the way our extensions locate their third-party dependencies. I looked at ServiceMix4 and I see that it is doing something like this with the org.apache.servicemix.bundles.* files. For example, there's one of these that wraps the JAXB implementation in an OSGi bundle. If we do the same in Tuscany, anyone wanting to use Tuscany with ServiceMix4 in an OSGi environment will need the ServiceMix+JAXB bundle and also the Tuscany+JAXB bundle, duplicating all the JAXB implementation classes. Now add SpringSource and a few other projects into the mix and how many copies of the same JAXB code will the user need? Any number greater than one is the wrong answer. Another more minor point is that for Graham's minimal OSGi test that's going to be part of the main build, it will be necessary to build these wrapper bundles, increasing the disk space used by the build because of the need to duplicate the contents of all the third-party jars, which are already in my local maven repo. Simon May you could look at what other projects that have spent time working on OSGi are doing. Two examples: - servicemix 4 - springsource app platform There's probably more good examples out there. -- Thank you... Regards, Rajini
Re: [jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
On 5/28/08, Simon Nash [EMAIL PROTECTED] wrote: One comment inline. Simon Rajini Sivaram (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600437#action_12600437] Rajini Sivaram commented on TUSCANY-2343: - Georg, Thank you for the details on your scenario. It has been very helpful. For now, I think we have enough information to make progress. When we start introducing more versioning information in the jars, it will be very useful to run these against your scenario first. With tuscany-sca-osgi-installer.jar, 3rd party jars are installed with the actual jar versions. In the example you used of servlet api, the bundle installed will have: Bundle-SymbolicName: org.apache.tuscany.sca.3rdparty.servlet-api-2.5 Bundle-Version: 2.5 Import statements in Tuscany however do not specify a version range. So Tuscany can use a different version of javax.servlet installed by an application and share classes from javax.servlet. As long as the version range used by the application contains the version 2.5, Tuscany and the application will use the same definitions of javax/servlet (either from this bundle or the one installed by the application). If the application uses a version range (eg. version=2.6) which does not match Tuscany's, the application and Tuscany could end up using javax.servlet from different bundles - in this case the application will always use 2.6, but Tuscany may use 2.6 or 2.5 as chosen by the OSGi framework since it does not specify a version range in its import). The issues that we need to address for versioning import statements are: 1) Version ranges specified in import statements should be broad enough to enable sharing. eg. If Tuscany is able to work with versions between 2.4.8-2.6.2 of javax.servlet, the version range should include the entire range of those versions, enabling applications to choose the version. 2) Version ranges should be narrow enough to enable isolation when we want two versions to coexist. eg. If one Tuscany extensionA wants to use version 3.1 of foo.jar and another extensionB (or the application) wants to use 3.3 of the same jar, where classes of the jar are not required to be shared, we should be able to specify narrow ranges of versions in the import of org.foo, so that the extensions use different versions. It seems like this is coupling two things that are not the same: 1. whether or not the extensions need to share the same loaded classes 2. which version of the dependency the two extensions can tolerate (for their own compatibility needs) Yes, these are two different requirements. And 1) can be handled separately from 2) by using additional attributes in import constraints. But I have assumed that Tuscany will not mandate the use of 3rd party bundles which are distributed with Tuscany, and that Tuscany's 3rd party jars can be substituted with any compatible version of the 3rd party jar which has been bundle-ized separately. That implies that we ultimately rely on import constraints based on version ranges to achieve sharing of classes. So while the easiest solution to 2) may be to make the import version ranges as narrow as possible, 1) requires that version ranges are as broad as possible for sharing classes across Tuscany and applications. At the moment, Tuscany's imports are totally unconstrained, and hence we can achieve 1) fairly easily. But we need to constrain imports to achieve 2). We need to get the right balance between the two so that common usage scenarios of Tuscany do not require specification of complex constraints when using different versions of 3rd party jars in applications. Simon Thank you... Regards, Rajini
Re: OSGi-enable 3rd party libraries in Tuscany
Simon, A couple of comments inline... On 5/28/08, Simon Nash [EMAIL PROTECTED] wrote: Sorry for the long delay in responding. I have been deeply buried in implementing the new WSDL-less support, and I am only just surfacing to follow up on other threads. Comments inline. Simon Rajini Sivaram wrote: On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Simon Nash wrote: ... snip I believe that if we are serious about making OSGi-enablement of Tuscany a first class option, we should consider doing 1). For the longer term to support versioning of 3rd party jars, 1) will provide a standard OSGi mechanism. As more and more 3rd-party libraries are being OSGi-enabled, this can be seen as an intermediate step which enables users of Tuscany to install Tuscany in the same standard OSGi way, into an OSGi runtime. I agree and think we should do (1) everywhere we can. I don't think Tuscany should modify third-party jars that we are redistributing as part of Tuscany. I think we should use some variant of (3) for all third-party jars that aren't already OSGi-enabled. Can you say why? At the moment we are redistributing these libraries as a convenience for people who want to run Tuscany out of the box. If people want to obtain these libraries in some other way (e.g., from a maven repo, by direct download from the third-party project, or as part of some other download), that's fine too. This change would alter that picture considerably. For people using Tuscany within OSGi, it would be necessary to use the modified libraries distributed by Tuscany. I am not sure if OSGi users of Tuscany would expect 3rd party non-bundle jars downloaded from elsewhere to work with Tuscany running under OSGi. If there is a requirement, we can support virtual bundles with naive manifests just for these cases. I am not sure that is reason enough for virtual bundles to be the only (or default) option. On the other hand, I would think that OSGi users of Tuscany may expect 3rd party bundle jars from other projects like ServiceMix to work with Tuscany running under OSGi. We can easily support that with bundle-ized jars. It would be great to have some co-ordination between these projects so that they can share the same bundle-ized 3rd party jars rather than all creating their own copies and giving the user the problem of figuring out whose version of bundle-ized jaxb can be used with Tuscany, ServiceMix, Spring, etc. This might or might not be required outside the OSGi environment, depending on how we set up the distro and the way our extensions locate their third-party dependencies. For users who run Tuscany outside of OSGi, we can (and should) continue to support third party libraries downloaded from anywhere. I dont think bundle-izing 3rd party libraries will require any changes to the way extensions locate their third party dependencies. If the bundle-izing is only intended for use by the native OSGi Tuscany runtime, could we produce a separate distro that contains the native OSGi Tuscany runtime and the bundle-ized 3rd party jars? Our current binary distro is very large and it would not be good to have it contain a complete set of unmodified 3rd party jars and another complete set of the same jars in bundle-ized form. I would also not be keen to change the regular binary distro to only contain bundle-ized jars as I think this will be confusing for non-OSGi users of Tuscany, especially if they don't want to use the exact levels of the 3rd-party jars that Tuscany has decided to bundle-ize. I looked at ServiceMix4 and I see that it is doing something like this with the org.apache.servicemix.bundles.* files. For example, there's one of these that wraps the JAXB implementation in an OSGi bundle. If we do the same in Tuscany, anyone wanting to use Tuscany with ServiceMix4 in an OSGi environment will need the ServiceMix+JAXB bundle and also the Tuscany+JAXB bundle, duplicating all the JAXB implementation classes. Now add SpringSource and a few other projects into the mix and how many copies of the same JAXB code will the user need? Any number greater than one is the wrong answer. If you install ServiceMix4 and Tuscany, at the moment you will have org.apache.servicemix.bundles.jaxb.jar and Tuscany's jaxb.jar on your disk. Using real bundles, we will replace Tuscany's jaxb.jar with org.apache.tuscany.sca.jaxb.jar. We still have two jaxb jars on the system. Using virtual bundles, we will convert Tuscany's jaxb.jar on the fly to org.apache.tuscany.sca.jaxb.jar. The only use case where we reduce disk space is where Tuscany's jaxb.jar is shared with other products running outside OSGi. As I said above, I'm not keen to replace jaxb.jar in the Tuscany binary distro by org.apache.tuscany.sca.jaxb.jar. If this is within the context of a separate OSGi-specific binary distro, I would be OK
Re: Build failure in itest/contribution-classloader (monitor problem)
Simon, Do we actually expect to always find a monitor implementation on the classpath? If so, I think we should throw an exception earlier on if no monitor implementation was found, rather than a NullPointerException masking the original exception when something does go wrong. But shouldn't we actually tolerate the absence of a monitor implementation, and use monitors with checks for null? monitor-logging is not a dependency on host-embedded at the moment. itest/contribution-classloader is the only test that fails because it is the only one which uses the exception code path. On 5/22/08, Simon Laws [EMAIL PROTECTED] wrote: On Wed, May 21, 2008 at 9:33 PM, Simon Nash [EMAIL PROTECTED] wrote: I just did a clean checkout and full build. It failed in itest/contribution-classloader with the following stack trace. The problem is caused by a null value in the monitor variable on line 124 of JavaInterfaceProcessor. This does not seem to happen for other tests. Any ideas? Simon Running org.apache.tuscany.sca.test.contribution.ContributionTestCase Created supplychain.customer.JavaCustomerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Customer.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Retailer.jar Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA contribution classloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contrib ution-test/target/contributions/Warehouse.jar Created supplychain.shipper.JavaShipperComponentImpl using: SCA contribution cla ssloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributio n-test/target/contributions/Shipper.jar Work thread Thread[Thread-2,5,main] - Order, submitted, fulfilled, shipped Created supplychain.customer.JavaCustomerComponentImpl using: java.net.URLClassL [EMAIL PROTECTED] Created supplychain.retailer.JavaRetailerComponentImpl using: java.net.URLClassL [EMAIL PROTECTED] Created supplychain.warehouse.JavaWarehouseComponentImpl using: java.net.URLClas [EMAIL PROTECTED] Created supplychain.shipper.JavaShipperComponentImpl using: java.net.URLClassLoa [EMAIL PROTECTED] Work thread Thread[Thread-4,5,main] - Order, submitted, fulfilled, shipped Created supplychain.illegal.JavaCustomerComponentImpl using: SCA contribution cl assloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributi on-test/target/contributions/IllegalCustomer.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Retailer.jar Created a retailer from Customer supplychain.retailer.JavaRetailerComponentImpl@ 3fac1e22 Created supplychain.customer.JavaCustomerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/CompleteSupplyChain.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/CompleteSupplyChain.jar Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA contribution classloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contrib ution-test/target/contributions/CompleteSupplyChain.jar Created supplychain.shipper.JavaShipperComponentImpl using: SCA contribution cla ssloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributio n-test/target/contributions/CompleteSupplyChain.jar Work thread Thread[Thread-6,5,main] - Order, submitted, fulfilled, shipped Created supplychain.customer.JavaCustomerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/CustomerImpl.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Retailer.jar Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA contribution classloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contrib ution-test/target/contributions/Warehouse.jar Created supplychain.shipper.JavaShipperComponentImpl using: SCA contribution cla ssloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributio n-test/target/contributions/Shipper.jar Work thread Thread[Thread-8,5,main] - Order, submitted, fulfilled, shipped Tests run: 9,
[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-tabpanelfocusedCommentId=12598635#action_12598635
]
Rajini Sivaram commented on TUSCANY-2330:
-
Graham,
I tried out the test (listed below), using your patch, and it seems to work
fine. So if you want, I can check in this code, along with the rest of your
patch tonight, and you can continue from there.
If this is going to be a sample, I think it should use Felix rather than
Equinox to avoid both Felix and Equinox being added to the Tuscany distribution
(depending on the order in which they appear in tuscany-sca-manifest.jar file,
they can result in conflicts when running Tuscany outside OSGi).
The test that I ran looks like:
public class CalculatorTestCase {
private BundleContext bundleContext;
@Before
public void setUp() throws Exception {
String[] equinoxArgs = new String[] {-clean, -console,
-configuration, target/configuration};
bundleContext = EclipseStarter.startup(equinoxArgs, null);
}
@After
public void tearDown() throws Exception {
if (bundleContext != null) {
bundleContext.getBundle().stop();
}
}
@Test
public void runCalculator() throws Exception {
Bundle tuscanyInstallerBundle =
bundleContext.installBundle(file:../tuscany-osgi-installer/target/tuscany-sca-osgi-installer.jar);
tuscanyInstallerBundle.start();
Bundle calculatorBundle =
bundleContext.installBundle(file:../calculator/target/sample-calculator-bundle.jar);
calculatorBundle.start();
}
}
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-tabpanelfocusedCommentId=12598433#action_12598433 ] Rajini Sivaram commented on TUSCANY-2330: - Graham, For some reason, I was expecting this to be an itest, but I notice you intended it to be a sample. That is good, since we currently dont have a sample which runs Tuscany under OSGi. So this module can be a sample as well as a sniff test for OSGi-based Tuscany. However, to enable this to be really used as a sample, it might help if code was simplified. Currently it uses the test harness from itest/osgi-tuscany which builds test bundles on-the-fly from the classes in the samples directories. I feel that is too complicated for use in a sample (yes, that is all my fault). It would be really nice to have a sample which simply does: 1. Create an OSGi runtime 2. Install and start Tuscany OSGi installer bundle 3. Install and start calculator bundle and away it goes and runs the calculator sample on Tuscany inside an OSGi runtime. Step 2 could be replaced later with whatever mechanism we choose to provide for installing Tuscany into OSGi. What do you think? I can help with the code if you like (but it will have to wait till the weekend). PS: Sorry, I should have noticed that you were referring to this as 'sample' all along. - Rajini 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?
Graham, Is there any reason you didn't switch over to one-bundle-per-3rdparty jar? 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. 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. 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. 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 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
Intermittent failures in schema validation
Hello, With the latest codebase, I get intermittent exceptions thrown from the extension samples - the following exception is from samples/binding-echo. It looks like the schemas are not in the order they are expected to be in (sample-binding-echo.xsd and tuscany-sca.xsd). Since the schema list is obtained using classLoader.getResources (through ServiceDiscovery) their ordering cannot really be guaranteed. org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.contribution.service.ContributionException: java.lang.IllegalStateException: org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 'sca:Binding' to a(n) 'type definition' component. at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70) at echo.EchoBindingTestCase.setUp(EchoBindingTestCase.java:35) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.contribution.service.ContributionException: java.lang.IllegalStateException: org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 'sca:Binding' to a(n) 'type definition' component. at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:293) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:171) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242) ... 16 more Caused by: org.apache.tuscany.sca.contribution.service.ContributionException: java.lang.IllegalStateException: org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 'sca:Binding' to a(n) 'type definition' component. at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:362) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:165) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:291) ... 19 more Caused by: java.lang.IllegalStateException: org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 'sca:Binding' to a(n) 'type definition' component. at org.apache.tuscany.sca.contribution.processor.DefaultValidatingXMLInputFactory.initializeSchemas(DefaultValidatingXMLInputFactory.java:147) at org.apache.tuscany.sca.contribution.processor.DefaultValidatingXMLInputFactory.createXMLStreamReader(DefaultValidatingXMLInputFactory.java:200) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.read(CompositeDocumentProcessor.java:106) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.read(CompositeDocumentProcessor.java:55) at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.read(ExtensibleURLArtifactProcessor.java:76) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:465) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:360) ... 21 more Caused by: org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 'sca:Binding' to a(n) 'type definition' component. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDHandler.getGlobalDecl(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseComplexContent(Unknown Source) at
Re: OSGi-enable 3rd party libraries in Tuscany
On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Simon Nash wrote: ... snip I believe that if we are serious about making OSGi-enablement of Tuscany a first class option, we should consider doing 1). For the longer term to support versioning of 3rd party jars, 1) will provide a standard OSGi mechanism. As more and more 3rd-party libraries are being OSGi-enabled, this can be seen as an intermediate step which enables users of Tuscany to install Tuscany in the same standard OSGi way, into an OSGi runtime. I agree and think we should do (1) everywhere we can. I don't think Tuscany should modify third-party jars that we are redistributing as part of Tuscany. I think we should use some variant of (3) for all third-party jars that aren't already OSGi-enabled. Can you say why? At the moment we are redistributing these libraries as a convenience for people who want to run Tuscany out of the box. If people want to obtain these libraries in some other way (e.g., from a maven repo, by direct download from the third-party project, or as part of some other download), that's fine too. This change would alter that picture considerably. For people using Tuscany within OSGi, it would be necessary to use the modified libraries distributed by Tuscany. I am not sure if OSGi users of Tuscany would expect 3rd party non-bundle jars downloaded from elsewhere to work with Tuscany running under OSGi. If there is a requirement, we can support virtual bundles with naive manifests just for these cases. I am not sure that is reason enough for virtual bundles to be the only (or default) option. On the other hand, I would think that OSGi users of Tuscany may expect 3rd party bundle jars from other projects like ServiceMix to work with Tuscany running under OSGi. We can easily support that with bundle-ized jars. This might or might not be required outside the OSGi environment, depending on how we set up the distro and the way our extensions locate their third-party dependencies. For users who run Tuscany outside of OSGi, we can (and should) continue to support third party libraries downloaded from anywhere. I dont think bundle-izing 3rd party libraries will require any changes to the way extensions locate their third party dependencies. I looked at ServiceMix4 and I see that it is doing something like this with the org.apache.servicemix.bundles.* files. For example, there's one of these that wraps the JAXB implementation in an OSGi bundle. If we do the same in Tuscany, anyone wanting to use Tuscany with ServiceMix4 in an OSGi environment will need the ServiceMix+JAXB bundle and also the Tuscany+JAXB bundle, duplicating all the JAXB implementation classes. Now add SpringSource and a few other projects into the mix and how many copies of the same JAXB code will the user need? Any number greater than one is the wrong answer. If you install ServiceMix4 and Tuscany, at the moment you will have org.apache.servicemix.bundles.jaxb.jar and Tuscany's jaxb.jar on your disk. Using real bundles, we will replace Tuscany's jaxb.jar with org.apache.tuscany.sca.jaxb.jar. We still have two jaxb jars on the system. Using virtual bundles, we will convert Tuscany's jaxb.jar on the fly to org.apache.tuscany.sca.jaxb.jar. The only use case where we reduce disk space is where Tuscany's jaxb.jar is shared with other products running outside OSGi. But I imagine disk space for jaxb.jar is not the issue. What we want to minimize is the number of jaxb bundles installed into an OSGi runtime, when ServiceMix, Tuscany etc. etc. are installed into one OSGi runtime. There is nothing stopping Tuscany from using org.apache.servicemix.bundles.jaxb.jar or ServiceMix from using org.apache.tuscany.sca.jaxb.jar, if they can both use the same version. Both of these (and the SpringSource version) have the same versioning conventions and export/imports. Using real bundles, we enable OSGi users to decide which bundles (and how many of them) they want to install into their OSGi runtime. Using virtual bundles, Tuscany will probably end up installing jaxb.jar into OSGi regardless of whether there are other variants that it can use. We are taking control away from the user, and could potentially increase the number of bundles installed unnecessarily, and also potentially generate classloading conflicts. Another more minor point is that for Graham's minimal OSGi test that's going to be part of the main build, it will be necessary to build these wrapper bundles, increasing the disk space used by the build because of the need to duplicate the contents of all the third-party jars, which are already in my local maven repo. As far as I know, Graham's minimal OSGi test is a subset of itest/osgi-tuscany, and hence relies on a manifest.jar file with co-located 3rd party jars (it does not load 3rd party jars directly off the maven repo). The bundle-ized 3rd party jars will replace these
Re: OSGi-enable 3rd party libraries in Tuscany
On 5/15/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: Hello, Following on from the discussion in thread [1], and based on Sebastien's comments [2], we need to make a decision on the best way forward to OSGi-enable third party libraries used by Tuscany. The options we have are: 1. Add OSGi manifest entries to all 3rd party jars in the Tuscany distribution. Existing OSGi tools like maven-bundle-plugin and maven-pax-plugin can be used to generate these bundles. The new manifest entries will not have any impact when Tuscany is run outside OSGi. For signed jars and jars with license restrictions, it may be necessary to generate a bundle with the jar embedded into it, resulting in separate jars for OSGi and non-OSGi. But these should hopefully be small in number. 2. Use non-OSGi mechanism to enable Tuscany bundles running inside OSGi to refer to jars outside OSGi. 3. Create virtual bundles on the fly for 3rd party jars. At the moment, itest/osgi-tuscany does this using auto-generated naive manifests. If we are to use virtual bundles going forward, manifest entries for the virtual bundles should be created at build time, and stored in one of the Tuscany jars. I believe that if we are serious about making OSGi-enablement of Tuscany a first class option, we should consider doing 1). For the longer term to support versioning of 3rd party jars, 1) will provide a standard OSGi mechanism. As more and more 3rd-party libraries are being OSGi-enabled, this can be seen as an intermediate step which enables users of Tuscany to install Tuscany in the same standard OSGi way, into an OSGi runtime. I agree and think we should do (1) everywhere we can. 3) works, and looks easier to roll out, but I would imagine that OSGi users of Tuscany would end up creating their own variants of 1) if we support only 3). And it feels like a wrapper (or rather it is a wrapper), with manifests and their matching 3rd party libs stored separately. How about an interim variation of (3) for the 3rd party JARs that we initially can't cover with (1): +1 For each 3rd party foo.jar, a foo-osgi.jar containing the bundle manifest that'll turn foo.jar into an OSGi virtual bundle, and I mean a proper bundle manifest with actual specific imports / exports instead of the naive *. If we were to use virtual bundles in the long term, I would definitely agree that we need proper bundle manifests. But for an interim solution, I am not sure what it buys us (performance perhaps, but not sure yet). If we use maven-bundle-plugin with all defaults (no explicit import/exports etc) to convert foo.jar into foo-osgi.jar, we will get something like: Export-Package: org.foo, org.foo.impl Import-Package: javax.xml.stream, org.bar The naive bundle manifest generated in itest/osgi-tuscany would generate Export-Package: org.foo, org.foo.impl DynamicImport-Package: * In both cases, we export all packages in foo.jar, In the first case, maven-bundle-plugin calculates the actual packages imported by classes in foo.jar, and imports all of them at build time. In the second case, we dont calculate the imports at build time, instead when Foo tries to use XMLStreamReader, the package javax.xml.stream is dynamically imported. In both cases, the same set of import-export wiring will be done by OSGi, only the timing of the wiring is different. The main difference is what happens when Foo tries to load org.bar.impl.Bar using Class.forName. The first one throws an exception, the second one dynamically imports org.bar.impl. Since this is a third party library where we have no control of what is or isn't imported, we have no choice but to add org.bar.impl to the imports in the first one. So I dont really think the second one is as bad as it looks (for an interim solution). I'm just throwing this up in the air to see any reactions from OSGi-skilled people in the group :) Maybe it's a stupid idea? but that would provide the level of modularity that we're expecting from OSGi, instead of mashing everything up in a central tuscany- manifest.jar which pretty much kills the benefits of using OSGi IMO. Since osgi-tuscany has been changing a lot recently, it may help to summarize what we have at the moment. So here goes: 1. All Tuscany modules are built with OSGi manifest headers using maven-bundle-plugin. So they contain explicit import/exports. Packages are not marked private, so all packages are exported from the modules. Imports are calculated by maven-bundle-plugin, and in some cases, we add additional imports for classes that are dynamically imported using Class.forName. So we now have around 100 bundles corresponding to Tuscany modules (eg. tuscany-contribution-2.0-incubating-SNAPSHOT.jar is an OSGi bundle) 2. Third party jars are installed into OSGi as individual virtual bundles, each with a manifest that exports all packages
Re: OSGi-enable 3rd party libraries in Tuscany
On 5/15/08, Simon Laws [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 3:13 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: Hello, Following on from the discussion in thread [1], and based on Sebastien's comments [2], we need to make a decision on the best way forward to OSGi-enable third party libraries used by Tuscany. The options we have are: 1. Add OSGi manifest entries to all 3rd party jars in the Tuscany distribution. Existing OSGi tools like maven-bundle-plugin and maven-pax-plugin can be used to generate these bundles. The new manifest entries will not have any impact when Tuscany is run outside OSGi. For signed jars and jars with license restrictions, it may be necessary to generate a bundle with the jar embedded into it, resulting in separate jars for OSGi and non-OSGi. But these should hopefully be small in number. 2. Use non-OSGi mechanism to enable Tuscany bundles running inside OSGi to refer to jars outside OSGi. 3. Create virtual bundles on the fly for 3rd party jars. At the moment, itest/osgi-tuscany does this using auto-generated naive manifests. If we are to use virtual bundles going forward, manifest entries for the virtual bundles should be created at build time, and stored in one of the Tuscany jars. I believe that if we are serious about making OSGi-enablement of Tuscany a first class option, we should consider doing 1). For the longer term to support versioning of 3rd party jars, 1) will provide a standard OSGi mechanism. As more and more 3rd-party libraries are being OSGi-enabled, this can be seen as an intermediate step which enables users of Tuscany to install Tuscany in the same standard OSGi way, into an OSGi runtime. I agree and think we should do (1) everywhere we can. 3) works, and looks easier to roll out, but I would imagine that OSGi users of Tuscany would end up creating their own variants of 1) if we support only 3). And it feels like a wrapper (or rather it is a wrapper), with manifests and their matching 3rd party libs stored separately. How about an interim variation of (3) for the 3rd party JARs that we initially can't cover with (1): For each 3rd party foo.jar, a foo-osgi.jar containing the bundle manifest that'll turn foo.jar into an OSGi virtual bundle, and I mean a proper bundle manifest with actual specific imports / exports instead of the naive *. I'm just throwing this up in the air to see any reactions from OSGi-skilled people in the group :) Maybe it's a stupid idea? but that would provide the level of modularity that we're expecting from OSGi, instead of mashing everything up in a central tuscany- manifest.jar which pretty much kills the benefits of using OSGi IMO. Thoughts? [1] http://markmail.org/message/tybuyxoaddjjrpbx [2] http://markmail.org/message/wbuixok3x3hazjqq Thank you... Regards, Rajini -- Jean-Sebastien I agree that, for 3, I don't see why we have to put all the manifests one place. If we have an input lib dir such as 3rdpartylib1.jar 3rdpartylib2.jar 3rdpartylib3.jar Why wouldn't the result of creating manifests for virtual use be... 3rdpartylib1.jar 3rdpartylib1.mf (or 3rdpartylib1-mf.jar if that is better?) 3rdpartylib2.jar 3rdpartylib2.mf 3rdpartylib3.jar 3rdpartylib3.mf And have the naming convention allow the manifests to be picked up and used to create virtual bundles of the jars.. 100 extra manifest files in the distribution directory - hmm... If we do want to generate manifest files for virtual bundles, IMO packaging of this should be discussed along with the bundle provisioning mechanism and the meta-data required to maintain bundle dependencies (OBR repository.xml or whatever we choose to use). More generally, and regardless of whether option 1 or 3 is used, when we install these jars into OSGi are we expecting other applications to be able to use them or are we calculating exports just based on what Tuscany uses? Regardless of 1 or 3, we would use - bundle symbolic name that starts with org.apache.tuscany.sca to distinguish 3rd party jars that Tuscany bundle-ized from 3rd party jars which are already bundles - bundle version that corresponds to the actual jar version (eg. xercesImpl-2.8.1.jar will have Bundle-Version 2.8.1) - export all packages from bundle - export/import calculations for 3rd party jars are completely independent of Tuscany Other applications will be able to use these 3rd party bundles. Simon -- Thank you... Regards, Rajini
OSGi-enable 3rd party libraries in Tuscany
Hello, Following on from the discussion in thread [1], and based on Sebastien's comments [2], we need to make a decision on the best way forward to OSGi-enable third party libraries used by Tuscany. The options we have are: 1. Add OSGi manifest entries to all 3rd party jars in the Tuscany distribution. Existing OSGi tools like maven-bundle-plugin and maven-pax-plugin can be used to generate these bundles. The new manifest entries will not have any impact when Tuscany is run outside OSGi. For signed jars and jars with license restrictions, it may be necessary to generate a bundle with the jar embedded into it, resulting in separate jars for OSGi and non-OSGi. But these should hopefully be small in number. 2. Use non-OSGi mechanism to enable Tuscany bundles running inside OSGi to refer to jars outside OSGi. 3. Create virtual bundles on the fly for 3rd party jars. At the moment, itest/osgi-tuscany does this using auto-generated naive manifests. If we are to use virtual bundles going forward, manifest entries for the virtual bundles should be created at build time, and stored in one of the Tuscany jars. I believe that if we are serious about making OSGi-enablement of Tuscany a first class option, we should consider doing 1). For the longer term to support versioning of 3rd party jars, 1) will provide a standard OSGi mechanism. As more and more 3rd-party libraries are being OSGi-enabled, this can be seen as an intermediate step which enables users of Tuscany to install Tuscany in the same standard OSGi way, into an OSGi runtime. 3) works, and looks easier to roll out, but I would imagine that OSGi users of Tuscany would end up creating their own variants of 1) if we support only 3). And it feels like a wrapper (or rather it is a wrapper), with manifests and their matching 3rd party libs stored separately. Thoughts? [1] http://markmail.org/message/tybuyxoaddjjrpbx [2] http://markmail.org/message/wbuixok3x3hazjqq Thank you... Regards, Rajini
Re: Improving support for running in OSGi
On 5/12/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: At the moment, itest/osgi-tuscany generates a manifest jar file called tuscany-sca-manifest.jar using a copy of the pom in distribution. I was hoping that we could use a single jar for both OSGi and non-OSGi. The list of virtual 3rd party bundles to be installed and the location of their plain jar files is based on the Class-Path entry in this tuscany-sca-manifest.jar. I do understand that this jar doesn't work in Eclipse, but I am not sure what we gain by having an additional jar for OSGi rather than reuse the jar which is already in distribution. Are we planning to get rid of tuscany-sca-manifest.jar in distribution? Here's what really puzzles me: a) We want to use OSGi as it allows us to cut Tuscany in self contained and isolated bundle JARs, enables us to pick the right subsets of JARs for a particular environment, can even enable us to combine different levels of dependency JARs when required by our extensions. b) But now all the info for all the dependency JARs is mashed in a single tuscany-sca-manifest.jar, and frozen in that 'manifest' JAR when we build the Tuscany distribution. Sorry, but I'm having a hard time understanding how to reconcile (a) and (b). We are learning to walk (or in this case crawl), before starting to run. (b) is a temporary step - it is the way it is purely because I work on Tuscany in my (rather non-existent) free time. And it was meant to provide something for Graham to get started on. Can't it just be much simpler than that? - 1 bundle per dependency JAR - containing the OSGi metadata describing that JAR and what it actually imports/exports? Yes, that is the goal. But unfortunately this is not simpler - it requires some more work with the build. The code itself works with individual meta-data or a collective one. The build at the moment is naive and creates a single manifest file. This is the approach that SpringSource for example seems to have chosen for they application platform OSGi repository. IMHO they are on the right path with this. Well, this is not quite the approach SpringSource have taken. SpringSource repositories contain actual OSGi bundles (jars with OSGi manifest entries including export/import statements). From what I have seen and heard so far, Tuscany seems very reluctant to take that step. We still seem to take the view that OSGi is an add-on, something that we would like to use (maybe, but not quite so sure yet). And that is part of the problem. OSGi tools are geared for building OSGi bundles - maven-pax-plugin for instance would be easy to use for converting our third party jars to bundles. It is slightly harder (messier, but not impossible) to just generate the meta-data we need for using virtual bundles. And we still haven't addressed the issue of bundle dependencies - how do we decide which bundles to install? Do we go for something like OBR in Felix, or invent something else? SpringSource have their own implementation of repositories. Having 100 separate 3rd party bundles (virtual or otherwise) doesn't make sense until we also have a mechanism for automagically determining dependencies across bundles and installing the required bundles. We need additional meta-data apart from the manifest entries to enable this. I do agree that all this needs to be done to get the full benefit of OSGi - I just feel that it requires a lot more thought. -- Jean-Sebastien -- Thank you... Regards, Rajini
Re: SDO Databinding and classloaders
Raymond/Mike, Thank you for your responses. I like the idea that it is the responsibility of the binding provider to ensure that data is correctly copied for cross-classloader calls. But will that require the default binding.sca to be aware of classloaders? I will have to look at the code in more detail (my next free weekend) to understand how this will fit in. On 5/12/08, Mike Edwards [EMAIL PROTECTED] wrote: Raymond Feng wrote: snip There is one more player: binding. The remote interaction is controlled by the binding protocol. When the source and target components are running under different context (such as classloader), the binding provider should be responsible to make sure the data are correctly marshalled/unmarshalled. If the binding decides to optimize for the co-located cases (in same VM), it needs to take care of the cross-context data mapping. It is similar that RMI/IIOP copies the data for the co-located services. snip Maybe the binding should handle the cross-classloader data mapping instead of the implementation.osgi. I think you're getting close to the right behaviour here. IF the interface is marked as remotable, then it is expected that the data is copied between client and service provider. Where there is serialization to a real wire protocol, this is obvious. Where the client and the provider live in the same VM, it is possible to *optimise* and avoid formal serialization, but it should really be the binding layer that makes this decision as other factors like security and other policies may come into play. So, data copying between client SDO and provider SDO is one approach. AllowsPassByReference is a feature worth thinking about. The idea is this is a yet further optimisation that allows passing of object(s) between client and provider when they live in the same VM. This clearly requires that the classes on both sides share the same classloader. I'm not sure how the bindings are meant to work this out for the Tuscany runtime. Finally there is the question of local interfaces. These are meant to be by-reference and the same classloader considerations apply as for the last paragraph. Does your brain hurt yet?? Yours, Mike. -- Thank you... Regards, Rajini
Re: Improving support for running in OSGi
On 5/13/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: Can't it just be much simpler than that? - 1 bundle per dependency JAR - containing the OSGi metadata describing that JAR and what it actually imports/exports? Yes, that is the goal. But unfortunately this is not simpler - it requires some more work with the build. The code itself works with individual meta-data or a collective one. The build at the moment is naive and creates a single manifest file. Maybe I can help, can you say what 'more work with the build' this will require? I have modified the code to generate manifest entries for virtual bundles and install 3rd party jars as individual bundles. These bundles export everything in the jar, and import any required package dynamically. itest/osgi-tuscany now installs 200 bundles into OSGi - the performance impact on classloading is quite severe - explicit imports in 3rd party bundles will help improve this, but I am not sure to what extent. The work that still needs to be done is the build-time generation of manifest entries for 3rd party bundles. Based on your comment below, should we start a discussion on whether we can convert 3rd party jars into bundles, rather than generate separate manifests? That would give us a cleaner distribution (and make the build easier). We have been working on the assumption that we cannot modify 3rd party jars, and hence the manifest entries had to be generated and stored separately - hence the virtual bundles. This is the approach that SpringSource for example seems to have chosen for they application platform OSGi repository. IMHO they are on the right path with this. Well, this is not quite the approach SpringSource have taken. SpringSource repositories contain actual OSGi bundles (jars with OSGi manifest entries including export/import statements). It is the approach that SpringSource has taken, or maybe I've not been clear... I meant 1 bundle per dependency JAR, i.e. that bundle is the JAR itself. From what I have seen and heard so far, Tuscany seems very reluctant to take that step. That's too bad, as it's the right approach IMO. -- Jean-Sebastien -- Thank you... Regards, Rajini
Re: SDO Databinding and classloaders
On 5/12/08, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I think there are two different perspectives here: 1) The pass-by-value semantics copies the SDO to make sure it cannot be mutated. My understanding (which is probably wrong) was that @Remotable ensured that the semantics of the call remained the same regardless of whether the caller and the callee were in the same VM or on two different machines. This was part of the reason why I asked the question. If my component A and component B are on the same VM with different classloaders, they dont work, but if I moved component B to another process it works fine. That sounds wrong, but I can understand that it is an unlikely scenario in Tuscany when OSGi is not used. 2) Different classloaders are used for different bundles. We probably shouldn't mix these two. Let's put SCA on the side for now and think in OSGi. Assuming we have two OSGi bundles (B1 B2) and Class C1 from B1 is calling Class C2 from B2 to exchange SDO. How would you handle the classloading issue? Would you make sure B1 and B2 have the same dependency on a 3rd bundle which contains the SDO classes? Or do you package the SDO classes in both B1 and B2 and have the user code take care of the cross-classloader data passing? Once we have clear answers for these questions, we'll figure out which part of the code should be responsible for the cross-classloader data mapping. In pure-OSGi land, there is no concept of remotable services. If B1 invokes a method in B2, the classloaders of the arguments have to match (as in standard Java). So the classes for the arguments should come from the same bundle. If they dont, it is the responsibility of the application code to copy data. implementation.osgi in Tuscany attempts to bring SCA concepts like remotable services to OSGi, and also enables access to non-OSGi services in Tuscany from OSGi. At the moment, we can provide interoperability between OSGi and non-OSGi components using SDOs only if the non-OSGi component is defined in an OSGi contribution (ie, they use the same classloaders). If cross-classloader data mapping is specific to OSGi and unlikely to occur in other scenarios in Tuscany, maybe this should be done in implementation.osgi - what do you think? Thanks, Raymond -- From: Rajini Sivaram [EMAIL PROTECTED] Sent: Sunday, May 11, 2008 1:44 PM To: tuscany-dev@ws.apache.org Subject: SDO Databinding and classloaders Hello, I was looking at a JIRA related to SDO parameters to OSGi services ( https://issues.apache.org/jira/browse/TUSCANY-2307), and was not sure whether the following scenario is valid for standard Java services in Tuscany. Component A and Component B are implemented using implementation.java/ and use default SCA binding. Component A invokes a remotable service from component B. One of the arguments to the service is an SDO object. But Component A and Component B use different classloaders for the SDO object. Will the copying of the SDO object done by databinding-sdo handle copying across multiple classloaders? I couldn't find any code which handles SDO classes loaded by different classloaders, so I was wondering whether we expect only one set of SDO classes to exist in a VM, or if I am just looking in the wrong place. Thank you... Regards, Rajini -- Thank you... Regards, Rajini
[jira] Commented: (TUSCANY-2307) Calling OSGi Service with SDO data
[ https://issues.apache.org/jira/browse/TUSCANY-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12595937#action_12595937 ] Rajini Sivaram commented on TUSCANY-2307: - Roshan, Is the Java component (which is invoking the OSGi service) inside an OSGi bundle contribution? If not, will it be possible to make it an OSGi bundle contribution (jar file with OSGi manifest headers)? Calling OSGi Service with SDO data -- Key: TUSCANY-2307 URL: https://issues.apache.org/jira/browse/TUSCANY-2307 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-1.2 Environment: Windows XP, Java Tuscany Sca runtime Reporter: Roshan Joseph Fix For: Java-SDO-Next Hi, I am trying to call an OSGi service from my sca java service running in the Tuscany SCA runtime. I uses the itest\osgi-implementation sample for SDO as my osgi service and calls the getGreetings method with SDO data as the input parameter for this call. I am reusing the HelloWorldService.jar which is in the itest\osgi-implementation folder for my OSGi service component. The composite file of my java service is something like as shown below. composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://com.siemens.hintegration; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0; xmlns:hw=http://com.siemens.hintegration; name=motionreactorComposite dbsdo:import.sdo factory=com.siemens.hintegration.sdo.MotionReactorFactory / component name=MotionReactorServiceComponent implementation.java class=com.siemens.hintegration.MotionReactorImpl / service name=MotionReactorService interface.java interface=com.siemens.hintegration.MotionReactorService/ !--JMS Binding-- binding.jms initialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory jndiURL=tcp://localhost:61616 destination name=activemq/queue/sendQueue create=always/ /binding.jms /service !-- Reference to the OSGi Service -- reference name=helloWorldService target=OSGiHelloWorldServiceComponent / /component component name=OSGiHelloWorldServiceComponent implementation.osgi xmlns=http://tuscany.apache.org/xmlns/sca/1.0; bundleSymbolicName=ds.helloworld.sdo.HelloWorldService/ /component /composite The actual code in my java component where I make the call to OSGi service is as follows: // Call the OSGi service Name name = HelloworldFactory.INSTANCE.createName(); name.setFirst(firstName); name.setLast(lastName); String hello = helloWorldService.getGreetings(name); getLogger().info(OSGi iTest Sample Call: + Hello); getLogger().info(OsgiService called); In the debug mode when the call reaches the OSgi component, I get a illegal argument exception. The error log looks like as shown below. - Exception occured while calling OSGi service java.lang.IllegalArgumentException: argument type mismatch at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeMethod(OSGiTargetInvoker.java:171) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiRemotableInvoker.invokeMethod(OSGiRemotableInvoker.java:75) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget(OSGiTargetInvoker.java:143) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke(OSGiTargetInvoker.java:188) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:103) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:103) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy8.getGreetings(Unknown Source
SDO Databinding and classloaders
Hello, I was looking at a JIRA related to SDO parameters to OSGi services ( https://issues.apache.org/jira/browse/TUSCANY-2307), and was not sure whether the following scenario is valid for standard Java services in Tuscany. Component A and Component B are implemented using implementation.java/ and use default SCA binding. Component A invokes a remotable service from component B. One of the arguments to the service is an SDO object. But Component A and Component B use different classloaders for the SDO object. Will the copying of the SDO object done by databinding-sdo handle copying across multiple classloaders? I couldn't find any code which handles SDO classes loaded by different classloaders, so I was wondering whether we expect only one set of SDO classes to exist in a VM, or if I am just looking in the wrong place. Thank you... Regards, Rajini
Re: [VOTE] Graduate Apache Tuscany as a Top Level Project (take two)
+1 On 5/10/08, ant elder [EMAIL PROTECTED] wrote: Restarting the graduation vote with the updated proposal words, please vote on the proposal below to graduate Tuscany to a TLP. +1 from me. ...ant X. Establish the Apache Tuscany Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software for distribution at no charge to the public, that simplifies the development, deployment and management of distributed applications built as compositions of service components. These components may be implemented with a range of technologies and connected using a variety of communication protocols. This software will implement relevant open standards including, but not limited to, the Service Component Architecture standard defined by the OASIS OpenCSA member section, and related technologies. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: * Adriano Crestani adrianocrestani at apache dot org * ant elder antelder at apache dot org * Brady Johnson bjohnson at apache dot org * Frank Budinsky frankb at apache dot org * Ignacio Silva-Lepe isilval at apache dot org * Jean-Sebastien Delfino jsdelfino at apache dot org * kelvin goodson kelvingoodson at apache dot org * Luciano Resende lresende at apache dot org * Mark Combellack mcombellack at apache dot org * Matthieu Riou mriou at apache dot org * Mike Edwards edwardsmj at apache dot org * Paul Fremantle pzf at apache dot org * Pete Robbins robbinspg at apache dot org * Raymond Feng rfeng at apache dot org * Simon Laws slaws at apache dot org * Simon Nash nash at apache dot org * Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged. -- Thank you... Regards, Rajini
Re: Improving support for running in OSGi
On 5/10/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: On 5/5/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: At the moment, I am creating a single virtual 3rd party bundle. For the longer term, if there are use-cases where different Tuscany extensions require different versions of 3rd party libs, we may want to split this into multiple virtual bundles. How about having one virtual bundle per 3rd party JAR? Isn't that what we'll need to really leverage the OSGi classloader isolation and versioning capabilities? Isn't that also what these 3rd parties will do once they OSGi-enable their own JARs? Yes, you are absolutely right. I started with the assumption that to leverage versioning of 3rd party libraries, we will need explicit versioned import/export statements in all 3rd party bundles. I preferred to generate these offline during the build process, and the generated manifest file is added to tuscany-sca-manifest.jar (not as a manifest, but as a plain resource). The code which generates virtual bundles at the moment looks for .mf files corresponding to the 3rd party jars. If a file (eg. stax-api-1.0-2.mf) is found in tuscany-sca-manifest.jar, a separate virtual bundle is generated for it (ie, stax-api-1.0-2 becomes a separate bundle). All the remaining jars without specific .mf files and bundled together into a single virtual bundle. OK, the idea of .mf looks good to me, but I can't really use tuscany-sca-manifest.jar as it doesn't work in Eclipse, and out of Eclipse it drags all the Tuscany JARs which I don't always need. Could you put the .mf files in another JAR that I can use in an OSGi environment? At the moment, itest/osgi-tuscany generates a manifest jar file called tuscany-sca-manifest.jar using a copy of the pom in distribution. I was hoping that we could use a single jar for both OSGi and non-OSGi. The list of virtual 3rd party bundles to be installed and the location of their plain jar files is based on the Class-Path entry in this tuscany-sca-manifest.jar. I do understand that this jar doesn't work in Eclipse, but I am not sure what we gain by having an additional jar for OSGi rather than reuse the jar which is already in distribution. Are we planning to get rid of tuscany-sca-manifest.jar in distribution? At the moment, the build generates only a single combined manifest entry, and hence a single virtual bundle is used. I'm confused, can you point me to that single manifest entry and the code or build that generates it? The code is in itest/osgi-tuscany. It is not part of the main build at the moment. It still contains the older 5-bundle version, so the directory structure may be a bit confusing. It is not a particularly efficient build - I have just done enough to get Tuscany running under OSGi with bundle-ized modules and virtual 3rd party libs. The build itself could be tidied up a lot. - tuscany-3rdparty-manifest - The 3rd party manifest entries for OSGi (generates org/apache/tuscany/manifest/MANIFEST.MF) - tuscany-manifest - Generates tuscany-sca-manifest.jar (similar to the manifest jar in distribution, but in addition to its standard manifest, this jar contains a bundle activator that installs 3rd party libs as virtual bundles, and the manifest file above). - test-bundles - Generates two bundle-ized tests (one simple implementation.java sample, and a second webservice sample) for sniff testing Tuscany under OSGi - osgi-tuscany-test - Testcases for OSGi-based Tuscany (runs the two sniff tests from test-bundles, and a bunch of samples directly from the samples build) The following correspond to the old 5-bundle version of Tuscany that are not used anymore. - sca-api - tuscany-spi - tuscany-runtime - tuscany-extensions - tuscany-3rdparty Thanks! -- Jean-Sebastien -- Thank you... Regards, Rajini
[jira] Closed: (TUSCANY-2294) Add OSGi manifest entries to Tuscany modules
[
https://issues.apache.org/jira/browse/TUSCANY-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajini Sivaram closed TUSCANY-2294.
---
Resolution: Fixed
Changes checked in under revision 654236.
Add OSGi manifest entries to Tuscany modules
Key: TUSCANY-2294
URL: https://issues.apache.org/jira/browse/TUSCANY-2294
Project: Tuscany
Issue Type: Bug
Components: Java SCA OSGi Integration
Affects Versions: Java-SCA-1.2
Reporter: Rajini Sivaram
Assignee: Rajini Sivaram
Fix For: Java-SCA-Next
Details on the discussion on adding manifest entries to Tuscany modules are
on this thread:
http://marc.info/?l=tuscany-devm=120936893510825w=2.
Modules will continue to be built as jars, and maven-bundle-plugin will be
used to generate the jar manifest (with OSGi headers). This will not have any
impact on the normal usage of the jars outside OSGi.
Each module pom.xml will contain an entry that looks like:
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
configuration
instructions
Bundle-Version${tuscany.version}/Bundle-Version
Bundle-SymbolicNameorg.apache.tuscany.sca.assembly/Bundle-SymbolicName
Bundle-Description${pom.name}/Bundle-Description
Export-Packageorg.apache.tuscany.sca.assembly*/Export-Package
/instructions
/configuration
/plugin
/plugins
/build
If the module dynamically loads classes from packages which are not visible
to the module (and yes, we do this in some places), there should also
be an additional DynamicImport-Package/ entry which lists the packages
(packages can be wildcarded).
When a new module is added, the section above (which is from
modules/assembly) can be cut-and-paste with the following changes:
1) Bundle-SymbolicName/ should be unique across all modules, and use the
format org.apache.tuscany.sca.module.name
2) Export-Package/ Comma separated list of packages exported by the module.
Package name can be wildcarded. To start with, all modules will use
wildcarded package names to avoid breakage when new subpackages are added.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2292) Remove split-packages across modules in Tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram closed TUSCANY-2292. --- Resolution: Fixed Assignee: Rajini Sivaram Fixed under revision 654236. Remove split-packages across modules in Tuscany --- Key: TUSCANY-2292 URL: https://issues.apache.org/jira/browse/TUSCANY-2292 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Rajini Sivaram Assignee: Rajini Sivaram Priority: Minor Fix For: Java-SCA-Next There are three packages which are split across two modules each in Tuscany: 1) org.apache.tuscany.sca.domain - split across domain and domain-api 2) org.apache.tuscany.sca.node - split across node and node-api 3) org.apache.tuscany.sca.policy.xml - split across policy-xml and policy-xml-ws It will be good to remove these split packages and have cleaner package definitions to enable modules to be built as OSGi bundles. OSGi can cope with split packages with Require-Bundle, but it would be much neater if we didn't have to treat these six modules differently. Can anyone think of any reason why these packages should be split across modules? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2293) Assembly-xsd module defines xsds in the default package
[ https://issues.apache.org/jira/browse/TUSCANY-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram closed TUSCANY-2293. --- Resolution: Fixed Assignee: Rajini Sivaram Temporary fix to use TCCL to load the schema applied under revision 654236. But I agree with Hasan (https://issues.apache.org/jira/browse/TUSCANY-2295) that schema loading should use extension points. Assembly-xsd module defines xsds in the default package --- Key: TUSCANY-2293 URL: https://issues.apache.org/jira/browse/TUSCANY-2293 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-1.2 Reporter: Rajini Sivaram Assignee: Rajini Sivaram Priority: Minor Fix For: Java-SCA-Next All xsds in assembly-xsd are defined in the default package. tuscany-sca.xsd is currently read by ReallySmallRuntimeBuilder using the following code: ReallySmallRuntimeBuilder.class.getClassLoader().getResource(tuscany-sca.xsd); For this code to work under OSGi, ReallySmallRuntimeBuilder has to be in the same bundle as tuscany-sca.xsd. To enable Tuscany modules to be built as separate OSGi bundles, either this classloading needs to be modified (to use Thread context classloader perhaps), or the xsd needs to move into a package (which can then be imported by host-embedded). The use of default package should be avoided wherever possible... -- 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
On 5/5/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: At the moment, I am creating a single virtual 3rd party bundle. For the longer term, if there are use-cases where different Tuscany extensions require different versions of 3rd party libs, we may want to split this into multiple virtual bundles. How about having one virtual bundle per 3rd party JAR? Isn't that what we'll need to really leverage the OSGi classloader isolation and versioning capabilities? Isn't that also what these 3rd parties will do once they OSGi-enable their own JARs? Yes, you are absolutely right. I started with the assumption that to leverage versioning of 3rd party libraries, we will need explicit versioned import/export statements in all 3rd party bundles. I preferred to generate these offline during the build process, and the generated manifest file is added to tuscany-sca-manifest.jar (not as a manifest, but as a plain resource). The code which generates virtual bundles at the moment looks for .mf files corresponding to the 3rd party jars. If a file (eg. stax-api-1.0-2.mf) is found in tuscany-sca-manifest.jar, a separate virtual bundle is generated for it (ie, stax-api-1.0-2 becomes a separate bundle). All the remaining jars without specific .mf files and bundled together into a single virtual bundle. At the moment, the build generates only a single combined manifest entry, and hence a single virtual bundle is used. This is mainly because I couldn't figure out an easy way to generate separate manifest entries using a single pom and maven-bundle-plugin (but then my knowledge of maven is very very limited). In the short term, just sorting out the build to generate individual manifest entries for 3rd party jars will give us something to explore versioning of 3rd party libs, and side-by-side execution of these in Tuscany. For the longer term, we need to look at the best way to generate manifest files for 3rd party libs. Should we for instance do this at runtime, rather than build-time? Could we generate simpler export/dynamic-import statements at runtime without using maven-bundle-plugin, and still support versioning of third party libs? What is the performance impact of individual virtual bundles on classloading? At the moment, we haven't done any analysis of who requires what on TCCL. So all 200 bundles will be on TCCL (making TCCL based classloading rather inefficient). -- Jean-Sebastien -- Thank you... Regards, Rajini
[jira] Created: (TUSCANY-2292) Remove split-packages across modules in Tuscany
Remove split-packages across modules in Tuscany --- Key: TUSCANY-2292 URL: https://issues.apache.org/jira/browse/TUSCANY-2292 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Rajini Sivaram Priority: Minor Fix For: Java-SCA-Next There are three packages which are split across two modules each in Tuscany: 1) org.apache.tuscany.sca.domain - split across domain and domain-api 2) org.apache.tuscany.sca.node - split across node and node-api 3) org.apache.tuscany.sca.policy.xml - split across policy-xml and policy-xml-ws It will be good to remove these split packages and have cleaner package definitions to enable modules to be built as OSGi bundles. OSGi can cope with split packages with Require-Bundle, but it would be much neater if we didn't have to treat these six modules differently. Can anyone think of any reason why these packages should be split across modules? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2293) Assembly-xsd module defines xsds in the default package
Assembly-xsd module defines xsds in the default package --- Key: TUSCANY-2293 URL: https://issues.apache.org/jira/browse/TUSCANY-2293 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-1.2 Reporter: Rajini Sivaram Priority: Minor Fix For: Java-SCA-Next All xsds in assembly-xsd are defined in the default package. tuscany-sca.xsd is currently read by ReallySmallRuntimeBuilder using the following code: ReallySmallRuntimeBuilder.class.getClassLoader().getResource(tuscany-sca.xsd); For this code to work under OSGi, ReallySmallRuntimeBuilder has to be in the same bundle as tuscany-sca.xsd. To enable Tuscany modules to be built as separate OSGi bundles, either this classloading needs to be modified (to use Thread context classloader perhaps), or the xsd needs to move into a package (which can then be imported by host-embedded). The use of default package should be avoided wherever possible... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2294) Add OSGi manifest entries to Tuscany modules
Add OSGi manifest entries to Tuscany modules
Key: TUSCANY-2294
URL: https://issues.apache.org/jira/browse/TUSCANY-2294
Project: Tuscany
Issue Type: Bug
Components: Java SCA OSGi Integration
Affects Versions: Java-SCA-1.2
Reporter: Rajini Sivaram
Assignee: Rajini Sivaram
Fix For: Java-SCA-Next
Details on the discussion on adding manifest entries to Tuscany modules are on
this thread:
http://marc.info/?l=tuscany-devm=120936893510825w=2.
Modules will continue to be built as jars, and maven-bundle-plugin will be used
to generate the jar manifest (with OSGi headers). This will not have any impact
on the normal usage of the jars outside OSGi.
Each module pom.xml will contain an entry that looks like:
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
configuration
instructions
Bundle-Version${tuscany.version}/Bundle-Version
Bundle-SymbolicNameorg.apache.tuscany.sca.assembly/Bundle-SymbolicName
Bundle-Description${pom.name}/Bundle-Description
Export-Packageorg.apache.tuscany.sca.assembly*/Export-Package
/instructions
/configuration
/plugin
/plugins
/build
If the module dynamically loads classes from packages which are not visible to
the module (and yes, we do this in some places), there should also
be an additional DynamicImport-Package/ entry which lists the packages
(packages can be wildcarded).
When a new module is added, the section above (which is from modules/assembly)
can be cut-and-paste with the following changes:
1) Bundle-SymbolicName/ should be unique across all modules, and use the
format org.apache.tuscany.sca.module.name
2) Export-Package/ Comma separated list of packages exported by the module.
Package name can be wildcarded. To start with, all modules will use wildcarded
package names to avoid breakage when new subpackages are added.
--
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
I have a new working itest/osgi-tuscany with the following: 1. modules/ are built with OSGi manifest headers using maven-bundle-plugin 2. For 3rd party jars, a manifest jar is created, similar to tuscany-sca-manifest.jar from the distribution. It contains the standard manifest file (with Jar classpath), a separate OSGi manifest file with import/exports for 3rd party libs created using maven-bundle-plugin, and a bundle activator. The bundle activator creates a virtual bundle for the third party jars using the Jar classpath and installs it into OSGi. 3. itest/osgi-tuscany loads Tuscany modules from the modules build. (it no longer creates the 5 combined bundles). The manifest jar is generated by itest/osgi-tuscany, which also copies all 3rd party libs (so it looks identical to a regular Tuscany distribution). It is not particularly efficient, but it does the job. By adding a bundle activator to tuscany-sca-manifest.jar which can install Tuscany into OSGi, when the manifest bundle is installed into OSGi, we can have a Tuscany distribution which installs itself into OSGi straight out-of-the-box, without doubling the size of the distribution. Users who don't like to have virtual 3rd party bundles can generate a concrete OSGi bundle for the third party jars with a simple jar command using the 3rd party manifest file stored in tuscany-sca-manifest.jar. If Tuscany distribution is split into multiple smaller distributions, I assume we will continue to have a manifest.jar for each part, and the same bundle activator can be inserted into each manifest.jar to cause that part of the distribution to be self-installing for OSGi. At the moment, I am creating a single virtual 3rd party bundle. For the longer term, if there are use-cases where different Tuscany extensions require different versions of 3rd party libs, we may want to split this into multiple virtual bundles. There are a couple of issues that I raised JIRAs for, and once I get responses to those, I can check the code into SVN if there are are no objections. With these changes, you should have enough to look at modularity in Tuscany and decide how to move that forward. On 5/2/08, Graham Charters [EMAIL PROTECTED] wrote: 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
[jira] Commented: (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:comment-tabpanelfocusedCommentId=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
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 13, 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: project ... packagingbundle/packaging ... plugin groupIdorg.apache.felix/groupId artifactIdmaven-bundle-plugin/artifactId extensionstrue/extensions configuration instructions Export-Packageorg.apache.tuscany.sca.foo/Export-Package Import-Packageorg.apache.tuscany.sca.bar/Import-Package Private-Packageorg.apache.tuscany.sca.impl.*/Private-Package /instructions /configuration /plugin ... 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 Export-Package*/Export-Package and Import-Package*/Import-Package, 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 done by the maven-bundle-plugin in this case. The actual generation of the module jar will remain the same as now, the only addition will be a new generated manifest file. We might not use Export-Package*/Export-Package , but instead it would be something more like Export-Packageorg.apache.tuscany.sca.implementation.osgi.*/Export-Package, where the packages are wildcarded, but no assumptions about modularity are made. 2. Use bundle goal with Import/Export as above (generated by maven-bundle-plugin rather than explicitly specified). In this case the jar itself will be generated using maven-bundle-plugin. The output jar should be identical to 1. 3. Use manifest goal with explicitly listed Export-Package/, Import-Package/ as in Sebastien's example. All exported and (maybe) imported packages are explicitly specified in the pom. Everytime a new package is added, the pom should be updated. 4. Use bundle goal with explicitly listed Export-Package/, Import-Package/ and Private-Package/ as in Sebastien's example. This option corresponds to Sebastien's example. In this case both the contents of the jar, as well as the manifest are based on the explicitly listed packages. 1. is the easiest to implement. It makes no assumptions about modularity, and will not have any impact on non-OSGi applications since only the manifest entry is affected. From an OSGi point of view, this gives all we need for osgi-tuscany. 2. does not add any value over 1. 3. This is a half-hearted attempt to enforce modularity. osgi-tuscany will break everytime someone introduces a new package and doesn't update the pom. But Tuscany will continue to operate without OSGi since only the manifest is broken. 3. is not a requirement for OSGi-based Tuscany, but merely the use of OSGi technology to
Re: Improving support for running in OSGi
On 5/2/08, Graham Charters [EMAIL PROTECTED] wrote: 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 thought it would be very unfair of me to suggest that this is not a very big task, when you were the one who had to go and implement it. But now that you agree that it is not too much work, can I change my mind? Seriously though, I could help with getting something up and running quickly, and you could take over from there (I will continue to help if you run into problems). Let me take a look this weekend and see if I can get a quick build with OSGi manifest entries for the modules. There are some modules which require additional options like Require-Bundle for the split packages. Since I have done this once before (even though that was with different plugins) for running Tuscany using OBR, it may be quicker for me to add these (and you can refine them later). I will also try to update osgi-tuscany to use these with some basic support for virtual 3rd party bundles copied over from the existing code and see if they run into any problems. You could then take over and drive it forward, initially fine tuning the OSGi support (finalizing the design for 3rd party libs as well as reducing disk space for tests, getting them to run on Continuum etc) followed by improving modularity. I suspect modularity requires a lot more discussion since it affects everyone. You might want to start a new thread on the mailing list without including OSGi in the subject :-). 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. My problem with option 3. is purely psychological. It seems rather strange to have centralized control of modularity :-). And paranoia - who is going to maintain a continually breaking itest/osgi-tuscany? Probably you, still... I do completely agree that 3. will help us get there faster. But it could reduce the motivation for 4, and throw away the opportunity to involve the entire Tuscany community to drive the improvements in modularity. There was a purpose to writing itest/osgi-tuscany - and that was to ensure that Tuscany could run inside an OSGi runtime. It already has the responsibility to test classloader usage in Tuscany, other issues like URL handling, which used to break under OSGi, and OSGi-specific problems in Tuscany. It might collapse under pressure if also burdened with defining and maintaining Tuscany modularity. But honestly, I think you should choose whichever path makes it easiest for you to drive the modularity work. 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
Re: Improving support for running in OSGi
On 4/30/08, Graham Charters [EMAIL PROTECTED] wrote: 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.). Eventually, I imagine Tuscany bundles containing OSGi manifest entries will be built as a distribution step. So the main purpose of itest/osgi-tuscany should be to ensure that the we can run Tuscany inside an OSGi runtime or a multi-classloader environment with whatever combination we choose for distribution. Having a finer grained bundle structure for itest/osgi-tuscany does not preclude the use of any coarser grain combination in the distribution. I do agree that using finer grained OSGi bundles may divert focus away from exploring higher-level combinations. And we could potentially be fixing issues that would never arise in coarser grained bundles. But adding manifest headers to Tuscany modules could provide some valuable benefits. 1. We can decouple classloading in Tuscany completely from the distribution structure. By proving that each module can run in a separate classloader, we would be ready for any distribution, including addition of individual extension modules as separate bundles. Basically every time someone wants a different distribution structure, we wont need to go and start testing that there are no classloader issues with using that combination. Yes, we may fix some classloading issues that may never arise in real life. But if modules in Tuscany correspond to modules in any sense, we should avoid assuming that different modules are loaded using a single classloader. Most of the classloading issues have already been fixed, and this shouldn't require much effort now. 2. It is very easy to add. maven-bundle-plugin can be used to add the manifest entries, and it is not a big task. At least in the short term, I would expect import/export statements for manifest entries to be generated using maven-bundle-plugin rather than explicitly specified in the pom. So I dont think maintenance will be very unmanageable. 3. It is the easiest way to make OSGi-enablement a first class feature. Until now, all OSGi work in Tuscany has been as segregated as possible from the rest of Tuscany. Using a test module to build and test OSGi-based Tuscany will continue that tradition. Introducing manifest entries in all poms will at least make the OSGi work more mainstream. I would expect that most people copy an existing pom when creating a new module, rather than writing one from scratch, so I would expect that the level of breakage that we will experience will be less than with itest/osgi-tuscany. And this process will help in raising awareness. The extra manifest entries will have no impact on the regular usage (development or execution) of Tuscany without OSGi. 4. The manifest entries generated by maven-bundle-plugin will contain explicit import/export packages in all modules, which I believe are better than maven module dependency listing because they are based on actual use. These could be very useful to Tuscany to improve its modularity story. We are very close to getting this to work - basic tests work with Tuscany modules and 3rd party libs built as 200 separate bundles with minimal changes (at least they did 6 months ago), so it wont be too much wasted effort, regardless of the final distribution structure. 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?). OSGi bundles are already supported as SCA contributions. OSGi import/export is used to resolve references between OSGi contributions (Tuscany does not get involved in this case). SCA import/export is used to resolve references between OSGi contributions and non-OSGi SCA
Re: Improving support for running in OSGi
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 modules to enforce modularity, that can be introduced in step 2. And I would expect that there will be more work in terms of building the distributions suitable for OSGi as well as non-OSGi after 1-4. Thank you... Regards, Rajini
Re: [VOTE] Graduate Apache Tuscany as a Top Level Project
+1 from me On 4/28/08, ant elder [EMAIL PROTECTED] wrote: We've done a lot of work since last October. We now have a diverse community of contributors and have demonstrated the ability to attract new committers to create an even more diverse community, we have shown we can do releases based on Apache guidelines, and we have shown we conduct our discussions in public within full view of the community and can resolve disagreements on the lists. I think we're ready, so please vote on the proposal below to graduate Tuscany to a TLP. +1 from me. ...ant X. Establish the Apache Tuscany Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software that simplifies the development and deployment of service oriented applications and provides a managed service-oriented runtime based on the standards defined by the OASIS OpenCSA group, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: - Adriano Crestani adrianocrestani at apache dot org - ant elder antelder at apache dot org - Brady Johnson bjohnson at apache dot org - Frank Budinsky frankb at apache dot org - Ignacio Silva-Lepe isilval at apache dot org - Jean-Sebastien Delfino jsdelfino at apache dot org - kelvin goodson kelvingoodson at apache dot org - Luciano Resende lresende at apache dot org - Mark Combellack mcombellack at apache dot org - Matthieu Riou mriou at apache dot org - Mike Edwards edwardsmj at apache dot org - Paul Fremantle pzf at apache dot org - Pete Robbins robbinspg at apache dot org - Raymond Feng rfeng at apache dot org - Simon Laws slaws at apache dot org - Simon Nash nash at apache dot org - Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged. -- Thank you... Regards, Rajini
Re: Latest continuum builds are failing due to test failures in itest/osgi-implementation with new test cases helloworld.sdo
Sorry about that. I have committed a fix under revision 648396. Due to a difference in classloading between the IBM JDK that I was using for testing and the Sun(?) JDK on Continuum, an additional class was required to be visible from the test bundle, resulting in the NoClassDefFoundError. I was expecting to see a build failure report if the Continuum build failed after I checked in code. Is that completely turned off now? On 4/15/08, Mark Combellack [EMAIL PROTECTED] wrote: Hi, Over the last few days, the continuum build has been failing for the trunk of Tuscany. The problem is that two tests are failing in itest/osgi-implementation. The relevant error messages are: testJavaToOSGi(helloworld.sdo.SdoTestCase) Time elapsed: 0.424 sec ERROR! java.lang.NoClassDefFoundError at helloworld.sdo.client.HelloWorldClientComponent.getGreetings(HelloWorldClien tComponent.java:33) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvo ker.invoke(JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(P assByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingI nvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(P assByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvoca tionHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvoca tionHandler.java:154) at $Proxy141.getGreetings(Unknown Source) at helloworld.sdo.SdoTestCase.testJavaToOSGi(SdoTestCase.java:81) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:585) at 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(Ab stractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractD irectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireB ooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879 ) testOSGiToJava(helloworld.sdo.SdoTestCase) Time elapsed: 0.278 sec ERROR! java.lang.NoClassDefFoundError at helloworld.sdo.client.HelloWorldClientComponent.getGreetings(HelloWorldClien tComponent.java:33) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invo keMethod(OSGiTargetInvoker.java:171) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiRemotableInvoker.i nvokeMethod(OSGiRemotableInvoker.java:75) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invo keTarget(OSGiTargetInvoker.java:143) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invo ke(OSGiTargetInvoker.java:188) at
[jira] Assigned: (TUSCANY-2209) Question about Conversational OSGi Services and Service References
[ https://issues.apache.org/jira/browse/TUSCANY-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram reassigned TUSCANY-2209: --- Assignee: Rajini Sivaram Question about Conversational OSGi Services and Service References -- Key: TUSCANY-2209 URL: https://issues.apache.org/jira/browse/TUSCANY-2209 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-1.2 Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 1.5.0_10 Reporter: Daniel Stucky Assignee: Rajini Sivaram Attachments: OneWay_Conversation_OSGi_SCA_test.zip For an overview of the problem please check this thread on the mailing-list: http://www.mail-archive.com/[EMAIL PROTECTED]/msg02833.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2209) Question about Conversational OSGi Services and Service References
[ https://issues.apache.org/jira/browse/TUSCANY-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587100#action_12587100 ] Rajini Sivaram commented on TUSCANY-2209: - Daniel, I think you were seeing three instances of Gamma being created because the first instance was created before the annotations were processed, due to a race in OSGiImplementationProvider.startBundle, which is not synchronized. I have committed a fix under revision 646232. Could you try it out? Thank you. Question about Conversational OSGi Services and Service References -- Key: TUSCANY-2209 URL: https://issues.apache.org/jira/browse/TUSCANY-2209 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-1.2 Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 1.5.0_10 Reporter: Daniel Stucky Assignee: Rajini Sivaram Attachments: OneWay_Conversation_OSGi_SCA_test.zip For an overview of the problem please check this thread on the mailing-list: http://www.mail-archive.com/[EMAIL PROTECTED]/msg02833.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2197) Conversations with OSGi services expire immediately
[ https://issues.apache.org/jira/browse/TUSCANY-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586173#action_12586173 ] Rajini Sivaram commented on TUSCANY-2197: - Patch applied under revision 645290. Thank you for the patch, Juergen. Conversations with OSGi services expire immediately --- Key: TUSCANY-2197 URL: https://issues.apache.org/jira/browse/TUSCANY-2197 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-1.2 Environment: Windows XP, Eclipse 3.3.2 Reporter: Jürgen Schumacher Attachments: tuscany-implosgi-osgiannotation.patch This occurred with current revision from sca-java-1.2 branch. I use the Tuscany OSGi bundles created by itests/osgi-tuscany in Eclipse Equinox, the SCA domain is started in a BundleActivator of my test projects. When I use implementation.osgi for a conversational service, the first method call after the init method throws a org.osoa.sca.ConversationEndedException: Conversation 44c36d6c-68af-4ba9-a9ba-354ccc5dd9d0 has expired. I debugged this and it seems that is caused by org.apache.tuscany.sca.implementation.osgi.context.OSGiAnnotations, which uses Long.MAX_VALUE as the default values for maxAge and maxIdleTime which in turn causes an overflow in the initializeConversationAttributes() of org.apache.tuscany.sca.core.conversation.ExtendedConversationImpl. This results in a negative expirationTime which is of course always smaller than the current time. When I change the default values to -1 (as in org.apache.tuscany.sca.implementation.java.impl.JavaImplementationImpl), it works. See attached patch for modules/implementation-osgi. I'm not sure if this is the best or correct solution, but it may be a hint to someone with more knowledge about this code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2105) NoClassDefFoundError: org/osgi/framework/BundleException running osgi-supplychain
[ https://issues.apache.org/jira/browse/TUSCANY-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580717#action_12580717 ] Rajini Sivaram commented on TUSCANY-2105: - Luciano, I modified all the OSGi modules to use Felix 1.0.3 rather than 1.0.1 in the 1.2 branch. Sorry, I wasn't trying to overwrite your changes, but the we had some fixes for classloading and deadlocks in Felix that went into 1.0.3. I hope you don't mind. - Rajini NoClassDefFoundError: org/osgi/framework/BundleException running osgi-supplychain - Key: TUSCANY-2105 URL: https://issues.apache.org/jira/browse/TUSCANY-2105 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Assignee: Luciano Resende Priority: Blocker Fix For: Java-SCA-1.2 run: [java] Exception in thread main java.lang.NoClassDefFoundError: org/osgi/framework/BundleException [java] at org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver.resolveModel(OSGiBundleReferenceModelResolver.java:89) [java] at org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel(ExtensibleModelResolver.java:150) [java] at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:207) [java] at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:74) [java] at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:252) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109) [java] at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation(BaseAssemblyProcessor.java:248) [java] at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:876) [java] at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:80) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109) [java] at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:129) [java] at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:52) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:464) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:348) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:161) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:272) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:155) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:109) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69) [java] at supplychain.SupplyChainClient.main(SupplyChainClient.java:33) [java] Java Result: 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2097) Build errors in itest/osgi-tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580732#action_12580732 ] Rajini Sivaram commented on TUSCANY-2097: - Simon, Thank you for trying out the latest build. cachedir directory is created by the calculator-script sample when it is running under OSGi. I think it is created by one of the script engines, but I couldn't figure out if the directory name is specified somewhere in Tuscany. I also have no idea why the directory is not created when the sample is run outside of OSGi. Does anyone have any clues? Build errors in itest/osgi-tuscany -- Key: TUSCANY-2097 URL: https://issues.apache.org/jira/browse/TUSCANY-2097 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-Next Environment: Windows, Sun JDK 1.5.0_14 Reporter: Simon Nash Fix For: Java-SCA-Next Attachments: jira2097.log Here is a summary of the build errors I am seeing. I will attach my full build log to this JIRA. 1. revision.location error creating archive. This seems to show up on every test, and it does not seem to cause a hard failure in the test. java.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany- test\.felix.test\bundle1\version0.0\revision.location (The system cannot find th e file specified) ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive. (ja va.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-te st\.felix.test\bundle1\version0.0\revision.location (The system cannot find the file specified)) 2. InvocationTargetException in CalculatorRMIReferencetestCase. java.lang.reflect.InvocationTargetException . Caused by: java.rmi.server.ExportException: Port already in use: 8099; nested ex ception is: java.net.BindException: Address already in use: JVM_Bind 3. Various errors in testOSGiTuscany_BindingWS - ERROR: org.apache.felix.framework.cache.BundleArchive: Unable to delete archi ve directory - F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-test\.felix.test \bundle5 java.util.zip.ZipException: The system cannot find the file specified org.osgi.framework.BundleException: Could not create bundle object. . Caused by: java.util.zip.ZipException: The system cannot find the file specified -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2097) Build errors in itest/osgi-tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580800#action_12580800 ] Rajini Sivaram commented on TUSCANY-2097: - Thank you, Ant. I have modified the OSGi testcase which runs calculator-script to set the system property python.cachedir to target/cachedir (revision 639327). So mvn clean should now clear that as well. Build errors in itest/osgi-tuscany -- Key: TUSCANY-2097 URL: https://issues.apache.org/jira/browse/TUSCANY-2097 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-Next Environment: Windows, Sun JDK 1.5.0_14 Reporter: Simon Nash Fix For: Java-SCA-Next Attachments: jira2097.log Here is a summary of the build errors I am seeing. I will attach my full build log to this JIRA. 1. revision.location error creating archive. This seems to show up on every test, and it does not seem to cause a hard failure in the test. java.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany- test\.felix.test\bundle1\version0.0\revision.location (The system cannot find th e file specified) ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive. (ja va.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-te st\.felix.test\bundle1\version0.0\revision.location (The system cannot find the file specified)) 2. InvocationTargetException in CalculatorRMIReferencetestCase. java.lang.reflect.InvocationTargetException . Caused by: java.rmi.server.ExportException: Port already in use: 8099; nested ex ception is: java.net.BindException: Address already in use: JVM_Bind 3. Various errors in testOSGiTuscany_BindingWS - ERROR: org.apache.felix.framework.cache.BundleArchive: Unable to delete archi ve directory - F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-test\.felix.test \bundle5 java.util.zip.ZipException: The system cannot find the file specified org.osgi.framework.BundleException: Could not create bundle object. . Caused by: java.util.zip.ZipException: The system cannot find the file specified -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2105) NoClassDefFoundError: org/osgi/framework/BundleException running osgi-supplychain
[ https://issues.apache.org/jira/browse/TUSCANY-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580285#action_12580285 ] Rajini Sivaram commented on TUSCANY-2105: - The version of Felix in the Tuscany 1.2 distribution is an old released version, while the Felix jars listed in tuscany-sca-manifest.jar are 1.1.0-SNAPSHOT. Shall I modify all OSGi-related modules and tests in Tuscany for the 1.2 branch to use the latest released version of Felix ? The tests which require a fix from the Felix snapshot are turned off in the 1.2 build anyway. NoClassDefFoundError: org/osgi/framework/BundleException running osgi-supplychain - Key: TUSCANY-2105 URL: https://issues.apache.org/jira/browse/TUSCANY-2105 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Fix For: Java-SCA-1.2 run: [java] Exception in thread main java.lang.NoClassDefFoundError: org/osgi/framework/BundleException [java] at org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver.resolveModel(OSGiBundleReferenceModelResolver.java:89) [java] at org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel(ExtensibleModelResolver.java:150) [java] at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:207) [java] at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:74) [java] at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:252) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109) [java] at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation(BaseAssemblyProcessor.java:248) [java] at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:876) [java] at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:80) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109) [java] at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:129) [java] at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:52) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:464) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:348) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:161) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:272) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:155) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:109) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69) [java] at supplychain.SupplyChainClient.main(SupplyChainClient.java:33) [java] Java Result: 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2097) Build errors in itest/osgi-tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580333#action_12580333 ] Rajini Sivaram commented on TUSCANY-2097: - Simon, Could you update to the latest version of itest/osgi-tuscany and modules/osgi-runtime and retry the test? Before running the test, please run mvn clean and also delete the directory itest/osgi-tuscany/.felix.test. Revision 638794 reuses bundles from .felix.test rather than clean it up everytime. That should hopefully avoid the errors you are seeing. The caching of bundles in .felix.test also improves the performance of the tests. It does mean that a clean build is required to test osgi-tuscany when changes are made to the Tuscany runtime. I have moved .felix.test to the target directory so that it is deleted by mvn clean. Thank you Rajini Build errors in itest/osgi-tuscany -- Key: TUSCANY-2097 URL: https://issues.apache.org/jira/browse/TUSCANY-2097 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-Next Environment: Windows, Sun JDK 1.5.0_14 Reporter: Simon Nash Fix For: Java-SCA-Next Attachments: jira2097.log Here is a summary of the build errors I am seeing. I will attach my full build log to this JIRA. 1. revision.location error creating archive. This seems to show up on every test, and it does not seem to cause a hard failure in the test. java.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany- test\.felix.test\bundle1\version0.0\revision.location (The system cannot find th e file specified) ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive. (ja va.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-te st\.felix.test\bundle1\version0.0\revision.location (The system cannot find the file specified)) 2. InvocationTargetException in CalculatorRMIReferencetestCase. java.lang.reflect.InvocationTargetException . Caused by: java.rmi.server.ExportException: Port already in use: 8099; nested ex ception is: java.net.BindException: Address already in use: JVM_Bind 3. Various errors in testOSGiTuscany_BindingWS - ERROR: org.apache.felix.framework.cache.BundleArchive: Unable to delete archi ve directory - F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-test\.felix.test \bundle5 java.util.zip.ZipException: The system cannot find the file specified org.osgi.framework.BundleException: Could not create bundle object. . Caused by: java.util.zip.ZipException: The system cannot find the file specified -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580384#action_12580384 ] Rajini Sivaram commented on TUSCANY-2093: - Revision 638836 removes Felix console from all the OSGi tests. I have now added itest/osgi-implementation to the main build. If any of the problems with implementation.osgi tests recur, I will take it out. Hangs in osgi itests Key: TUSCANY-2093 URL: https://issues.apache.org/jira/browse/TUSCANY-2093 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next I get hangs running various of the osgi itests, the test run part way through then just appear to hang for ever, no IO or CPU activity on the process. Eg, the output on the console for some hangs are: Running org.apache.tuscany.sca.test.osgi.tuscany.OSGiSupplyChainTestCase - Run tests from : ../../../samples/osgi-supplychain Loaded Tuscany, time taken = 31625 ms Running test null(supplychain.SupplyChainClientTestCase) Started OSGi bundle with activator OSGiCustomerImpl Started OSGi bundle with activator OSGiShipperImpl another: [INFO] Building Apache Tuscany OSGi Contribution tests [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 1 source file to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 4 source files to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\surefire-reports --- T E S T S --- Running org.apache.tuscany.sca.contribution.osgi.test.OSGiResolverTestCase - Created supplychain.customer.JavaCustomerComponentImpl using classloader 6.0 Created supplychain.retailer.JavaRetailerComponentImpl using classloader 7.0 Created supplychain.warehouse.JavaWarehouseComponentImpl using classloader 8.0 Created supplychain.shipper.JavaShipperComponentImpl using classloader 9.0 another: Running supplychain.wiring.DSWiring1TestCase - Main thread Thread[main,5,main] Created OSGiCustomerComponentImpl [EMAIL PROTECTED] Activated OSGiCustomerComponentImpl bundle OSGiCustomerComponentImpl.purchaseBooks, retailer1 is [Proxy - [EMAIL PROTECTED] Activated OSGiRetailerComponentImpl bundle Activated OSGiRetailerComponentImpl bundle OSGiRetailerComponentImpl.submitOrder , warehouse is [Proxy - [EMAIL PROTECTED] JavaWarehouseComponentImpl.fulfillOrder : shipper is [Proxy - [EMAIL PROTECTED] Activated OSGiShipperComponentImpl bundle Activated OSGiShipperComponentImpl bundle OSGiShipperComponentImpl.processShipment, customer is [Proxy - [EMAIL PROTECTED] This is easily recreateable so i can help debug, just right now i'm not sure where to look. -- 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: [SCA 1.2] Calculator Sample and OSGI dependencies...
Luciano, At the moment, Tuscany can only have one model resolver for resolution of classes - the ExtensibleModelResolver chooses ClassReferenceModelResolver when a ClassReference is resolved. If a contribution is an OSGi bundle contribution, OSGi bundle resolution should override the classloader based resolution. But I couldn't figure out a neat way to do this without forcing ClassReferenceModelResolver to check if OSGi can be used to resolve the class first. Sebastien's proposed changes on contribution classloading ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28608.html) is expected to fix this. On 3/18/08, Luciano Resende [EMAIL PROTECTED] wrote: Thanks Rajini, it got me further. But I have a question related to your fix, it looks like you are now handling when the OSGI Runtime is not on the classpath. Should we even be triggering some of the OSGI related code when the OSGi runtime is not in use ? I'm wondering how this could affect the simple paths where no OSGI integration is required (e.g default jar contributions and/or file system contributions. Thoughts ? On Mon, Mar 17, 2008 at 2:20 AM, Rajini Sivaram [EMAIL PROTECTED] wrote: Luciano, I have fixed this under revision 637797. On 3/17/08, Luciano Resende [EMAIL PROTECTED] wrote: I'm trying to run the Calculator sample from a SCA Distribution (trunk) and I'm noticing that it now requires OSGI dependencies. Could someone please let me know if this is working as expected ? Below is the exception I'm getting with regular SCA dependencies. (To reproduce, build distribution and run the sample calculator) run: [java] Exception in thread main java.lang.NoClassDefFoundError: org/osgi/framework/BundleException [java] at org.apache.tuscany.sca.contribution.osgi.impl.OSGiClassReferenceModelResolver.initialize (OSGiClassReferenceModelResolver.java:128) [java] at org.apache.tuscany.sca.contribution.osgi.impl.OSGiClassReferenceModelResolver.resolveModel (OSGiClassReferenceModelResolver.java:85) [java] at org.apache.tuscany.sca.contribution.java.impl.ClassReferenceModelResolver.resolveModel (ClassReferenceModelResolver.java:95) [java] at org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel (ExtensibleModelResolver.java:150) [java] at org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve (JavaImplementationProcessor.java:145) [java] at org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve (JavaImplementationProcessor.java:65) [java] at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve (DefaultStAXArtifactProcessorExtensionPoint.java:252) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve (ExtensibleStAXArtifactProcessor.java:109) [java] at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation (BaseAssemblyProcessor.java:248) [java] at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve( CompositeProcessor.java:876) [java] at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve( CompositeProcessor.java:80) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve (ExtensibleStAXArtifactProcessor.java:109) [java] at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve( CompositeDocumentProcessor.java:129) [java] at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve( CompositeDocumentProcessor.java:52) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve (ExtensibleURLArtifactProcessor.java:86) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase (ContributionServiceImpl.java:464) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution (ContributionServiceImpl.java:348) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute (ContributionServiceImpl.java:161) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution (DefaultSCADomain.java:272) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init( DefaultSCADomain.java:155) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init( DefaultSCADomain.java:109) [java
[jira] Commented: (TUSCANY-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579763#action_12579763 ] Rajini Sivaram commented on TUSCANY-2093: - Ant, If you can recreate the hang under maven, could you generate a javacore by pressing Ctrl-Break (on Windows) when the process is hanging? Thank you. Hangs in osgi itests Key: TUSCANY-2093 URL: https://issues.apache.org/jira/browse/TUSCANY-2093 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next I get hangs running various of the osgi itests, the test run part way through then just appear to hang for ever, no IO or CPU activity on the process. Eg, the output on the console for some hangs are: Running org.apache.tuscany.sca.test.osgi.tuscany.OSGiSupplyChainTestCase - Run tests from : ../../../samples/osgi-supplychain Loaded Tuscany, time taken = 31625 ms Running test null(supplychain.SupplyChainClientTestCase) Started OSGi bundle with activator OSGiCustomerImpl Started OSGi bundle with activator OSGiShipperImpl another: [INFO] Building Apache Tuscany OSGi Contribution tests [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 1 source file to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 4 source files to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\surefire-reports --- T E S T S --- Running org.apache.tuscany.sca.contribution.osgi.test.OSGiResolverTestCase - Created supplychain.customer.JavaCustomerComponentImpl using classloader 6.0 Created supplychain.retailer.JavaRetailerComponentImpl using classloader 7.0 Created supplychain.warehouse.JavaWarehouseComponentImpl using classloader 8.0 Created supplychain.shipper.JavaShipperComponentImpl using classloader 9.0 another: Running supplychain.wiring.DSWiring1TestCase - Main thread Thread[main,5,main] Created OSGiCustomerComponentImpl [EMAIL PROTECTED] Activated OSGiCustomerComponentImpl bundle OSGiCustomerComponentImpl.purchaseBooks, retailer1 is [Proxy - [EMAIL PROTECTED] Activated OSGiRetailerComponentImpl bundle Activated OSGiRetailerComponentImpl bundle OSGiRetailerComponentImpl.submitOrder , warehouse is [Proxy - [EMAIL PROTECTED] JavaWarehouseComponentImpl.fulfillOrder : shipper is [Proxy - [EMAIL PROTECTED] Activated OSGiShipperComponentImpl bundle Activated OSGiShipperComponentImpl bundle OSGiShipperComponentImpl.processShipment, customer is [Proxy - [EMAIL PROTECTED] This is easily recreateable so i can help debug, just right now i'm not sure where to look. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579786#action_12579786 ] Rajini Sivaram commented on TUSCANY-2093: - Thank you for the thread dump. I am not sure what happened to the thread which was running OSGi test code. I have tried with the Sun JDK, and still can't recreate the hang (but I am using a slightly later version of the JDK). What version of maven are you using? Hangs in osgi itests Key: TUSCANY-2093 URL: https://issues.apache.org/jira/browse/TUSCANY-2093 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next I get hangs running various of the osgi itests, the test run part way through then just appear to hang for ever, no IO or CPU activity on the process. Eg, the output on the console for some hangs are: Running org.apache.tuscany.sca.test.osgi.tuscany.OSGiSupplyChainTestCase - Run tests from : ../../../samples/osgi-supplychain Loaded Tuscany, time taken = 31625 ms Running test null(supplychain.SupplyChainClientTestCase) Started OSGi bundle with activator OSGiCustomerImpl Started OSGi bundle with activator OSGiShipperImpl another: [INFO] Building Apache Tuscany OSGi Contribution tests [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 1 source file to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 4 source files to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\surefire-reports --- T E S T S --- Running org.apache.tuscany.sca.contribution.osgi.test.OSGiResolverTestCase - Created supplychain.customer.JavaCustomerComponentImpl using classloader 6.0 Created supplychain.retailer.JavaRetailerComponentImpl using classloader 7.0 Created supplychain.warehouse.JavaWarehouseComponentImpl using classloader 8.0 Created supplychain.shipper.JavaShipperComponentImpl using classloader 9.0 another: Running supplychain.wiring.DSWiring1TestCase - Main thread Thread[main,5,main] Created OSGiCustomerComponentImpl [EMAIL PROTECTED] Activated OSGiCustomerComponentImpl bundle OSGiCustomerComponentImpl.purchaseBooks, retailer1 is [Proxy - [EMAIL PROTECTED] Activated OSGiRetailerComponentImpl bundle Activated OSGiRetailerComponentImpl bundle OSGiRetailerComponentImpl.submitOrder , warehouse is [Proxy - [EMAIL PROTECTED] JavaWarehouseComponentImpl.fulfillOrder : shipper is [Proxy - [EMAIL PROTECTED] Activated OSGiShipperComponentImpl bundle Activated OSGiShipperComponentImpl bundle OSGiShipperComponentImpl.processShipment, customer is [Proxy - [EMAIL PROTECTED] This is easily recreateable so i can help debug, just right now i'm not sure where to look. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579839#action_12579839 ] Rajini Sivaram commented on TUSCANY-2093: - Ant, Thank you for the stack trace - this is very useful (even though I still dont know what the problem is). There are two threads there which look suspicious: Felix Shell TUI This thread is doing a System.out.println, which should be piped into the other maven process, and the wait could be because the other process was killed. I am fairly certain this is not the cause since you were able to recreate the hang under Eclipse. But to be absolutely sure, could you remove the line containing org.apache.felix.shell.tui from osgi-implementation\src\test\resources\osgi\felix\felix.config.properties, and see if the hang recurs? main This thread is doing a non-blocking invocation. And looking at the three stack traces you had at the start, they are all doing non-blocking invocations. I wonder what could cause this thread from not completing. It seems to be in RUNNING state, and from the stack trace I can't see anything causing it to block before it completes the call (and the calls results in a print, so it didn't complete in any of your hanging runs). I will dig into the code a bit further. Do you have any ideas? Hangs in osgi itests Key: TUSCANY-2093 URL: https://issues.apache.org/jira/browse/TUSCANY-2093 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next I get hangs running various of the osgi itests, the test run part way through then just appear to hang for ever, no IO or CPU activity on the process. Eg, the output on the console for some hangs are: Running org.apache.tuscany.sca.test.osgi.tuscany.OSGiSupplyChainTestCase - Run tests from : ../../../samples/osgi-supplychain Loaded Tuscany, time taken = 31625 ms Running test null(supplychain.SupplyChainClientTestCase) Started OSGi bundle with activator OSGiCustomerImpl Started OSGi bundle with activator OSGiShipperImpl another: [INFO] Building Apache Tuscany OSGi Contribution tests [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 1 source file to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 4 source files to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\surefire-reports --- T E S T S --- Running org.apache.tuscany.sca.contribution.osgi.test.OSGiResolverTestCase - Created supplychain.customer.JavaCustomerComponentImpl using classloader 6.0 Created supplychain.retailer.JavaRetailerComponentImpl using classloader 7.0 Created supplychain.warehouse.JavaWarehouseComponentImpl using classloader 8.0 Created supplychain.shipper.JavaShipperComponentImpl using classloader 9.0 another: Running supplychain.wiring.DSWiring1TestCase - Main thread Thread[main,5,main] Created OSGiCustomerComponentImpl [EMAIL PROTECTED] Activated OSGiCustomerComponentImpl bundle OSGiCustomerComponentImpl.purchaseBooks, retailer1 is [Proxy - [EMAIL PROTECTED] Activated OSGiRetailerComponentImpl bundle Activated OSGiRetailerComponentImpl bundle OSGiRetailerComponentImpl.submitOrder , warehouse is [Proxy - [EMAIL PROTECTED] JavaWarehouseComponentImpl.fulfillOrder : shipper is [Proxy - [EMAIL PROTECTED] Activated OSGiShipperComponentImpl bundle Activated OSGiShipperComponentImpl bundle OSGiShipperComponentImpl.processShipment, customer is [Proxy - [EMAIL PROTECTED] This is easily recreateable so i can help debug, just right now i'm not sure where to look. -- 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: Hang in new UID() in ThreadPoolWorkManager
And http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4939977 On 3/18/08, Raymond Feng [EMAIL PROTECTED] wrote: Not sure if this is related: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851715. Your thread hangs at: at java.net.Inet4AddressImpl.getLocalHostName(Native Method) at java.net.InetAddress.getLocalHost(InetAddress.java:1297) Can you try a simple java test case to call java.net.InetAddress.getLocalHost()? Thanks, Raymond -- From: ant elder [EMAIL PROTECTED] Sent: Tuesday, March 18, 2008 4:12 AM To: tuscany-dev tuscany-dev@ws.apache.org Subject: Hang in new UID() in ThreadPoolWorkManager Debugging TUSCANY-2093 it looks like I get a hang in the new UID() statement on line 92. Googling around i can't find much about what could be causing that, i've tried different JVMs, stopping firewalls, all the various network apps running etc, nothing makes any difference. Any one have any ideas? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thank you... Regards, Rajini
Re: Hang in new UID() in ThreadPoolWorkManager
Ant, Did you try running without the Felix console - remove the line containing org.apache.felix.shell.tui from osgi-implementation\src\test\resources\osgi\felix\felix.config.properties? On 3/18/08, ant elder [EMAIL PROTECTED] wrote: Yes that simple test works ok, also changing the maven-surefire-plugin config to have forkModenever/forkMode also fixes the problem as does running in debug mode in eclipse (even with no breakpoints set). ...ant On Tue, Mar 18, 2008 at 3:45 PM, Raymond Feng [EMAIL PROTECTED] wrote: Not sure if this is related: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851715. Your thread hangs at: at java.net.Inet4AddressImpl.getLocalHostName(Native Method) at java.net.InetAddress.getLocalHost(InetAddress.java:1297) Can you try a simple java test case to call java.net.InetAddress.getLocalHost()? Thanks, Raymond -- From: ant elder [EMAIL PROTECTED] Sent: Tuesday, March 18, 2008 4:12 AM To: tuscany-dev tuscany-dev@ws.apache.org Subject: Hang in new UID() in ThreadPoolWorkManager Debugging TUSCANY-2093 it looks like I get a hang in the new UID() statement on line 92. Googling around i can't find much about what could be causing that, i've tried different JVMs, stopping firewalls, all the various network apps running etc, nothing makes any difference. Any one have any ideas? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thank you... Regards, Rajini
[jira] Commented: (TUSCANY-2097) Build errors in itest/osgi-tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579925#action_12579925 ] Rajini Sivaram commented on TUSCANY-2097: - Simon, Could you delete the directory itest\osgi-tuscany\osgi-tuscany-test\.felix.test and rerun the test? Thank you... Build errors in itest/osgi-tuscany -- Key: TUSCANY-2097 URL: https://issues.apache.org/jira/browse/TUSCANY-2097 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-Next Environment: Windows, Sun JDK 1.5.0_14 Reporter: Simon Nash Fix For: Java-SCA-Next Attachments: jira2097.log Here is a summary of the build errors I am seeing. I will attach my full build log to this JIRA. 1. revision.location error creating archive. This seems to show up on every test, and it does not seem to cause a hard failure in the test. java.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany- test\.felix.test\bundle1\version0.0\revision.location (The system cannot find th e file specified) ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive. (ja va.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-te st\.felix.test\bundle1\version0.0\revision.location (The system cannot find the file specified)) 2. InvocationTargetException in CalculatorRMIReferencetestCase. java.lang.reflect.InvocationTargetException . Caused by: java.rmi.server.ExportException: Port already in use: 8099; nested ex ception is: java.net.BindException: Address already in use: JVM_Bind 3. Various errors in testOSGiTuscany_BindingWS - ERROR: org.apache.felix.framework.cache.BundleArchive: Unable to delete archi ve directory - F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-test\.felix.test \bundle5 java.util.zip.ZipException: The system cannot find the file specified org.osgi.framework.BundleException: Could not create bundle object. . Caused by: java.util.zip.ZipException: The system cannot find the file specified -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-2086) implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace
[ https://issues.apache.org/jira/browse/TUSCANY-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram closed TUSCANY-2086. --- Resolution: Fixed implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace - Key: TUSCANY-2086 URL: https://issues.apache.org/jira/browse/TUSCANY-2086 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Environment: Windows XP, Eclipse 3.3.2 (org.eclipse.osgi 3.3.2) Reporter: Jürgen Schumacher Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 Attachments: tuscany-equinox-runtime.patch, tuscany.osgi.sample.launch.zip, tuscany.osgi.sample.zip This issue refers to activities described in http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200803.mbox/[EMAIL PROTECTED] When trying to test implementation.osgi I ended with this error message: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:276) ... caused by Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:227) ... While Tuscany is right in that I did not provide a componentType file, it seems to be wrong in how it has created the filename. I debugged a bit and found the following: org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver has a method getBundleFilename(...) that tries to extract the bundles filename from its location by looking for the last / in the location and using the rest afterwards. But when the bundle is located in my Eclipse workspace as a Plugin project under development and not packed as a JAR and I run my examples in a Equinox runtime, the reported location is e.g. [EMAIL PROTECTED]:file:../workspace/EILF/tuscany.osgi.sample/ where tuscany.osgi.sample is the actual bundle name. Therefore getBundleFilename returns just an empty string. And this empty string is used later in org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(...) to build the filename for the component type file, which results in .componentType as the complete filename in this case. I suppose the current code is meant to look for the componentType file next to a bundle JAR with the same basename as the bundle JAR. I'm not sure where it should look for it in my case, probably inside the workspace bundle directory, as the workspace directory itself is usually not visible in Eclipse and so it would be inconvenient to edit the file in the IDE. Sorry that I cannot provide a test case currently because had to create own Tuscany bundles to get this far (see mail thread linked above for details), which would be a bit large to attach, I suppose (-; Also I cannot provide a patch yet, because I'm quite new to OSGi and Tuscany myself and therefore cannot estimate what would be a valid solution currently. Of course if you have any ideas how to solve this, I can test it in my setup and give more feedback. Thanks in advance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2096) When itest/osgi-tuscany bundles run in Equinox, OSGiRuntime does not find EquinoxRuntime, but uses FelixRuntime
[ https://issues.apache.org/jira/browse/TUSCANY-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579934#action_12579934 ] Rajini Sivaram commented on TUSCANY-2096: - Jurgen, Thank you for the patch. It has been applied under revision 638445. I am not sure if the .mar file is used anywhere, so I didn't want to remove it without being sure. Is there a problem with having these files in the bundle or is it because they have been added to the Bundle-ClassPath? When itest/osgi-tuscany bundles run in Equinox, OSGiRuntime does not find EquinoxRuntime, but uses FelixRuntime --- Key: TUSCANY-2096 URL: https://issues.apache.org/jira/browse/TUSCANY-2096 Project: Tuscany Issue Type: Improvement Components: Java SCA OSGi Integration Affects Versions: Java-SCA-Next Environment: Windows XP, Sun JDK 1.5.0_11, Eclipse 3.3.2 (Equinox 3.3.2) Reporter: Jürgen Schumacher Priority: Minor Attachments: itest-osgituscany-runtime-pom.patch I used the OSGi bundles generated by itest/osgi-tuscany in Equinox. The BundleActivator of the tuscany-runtime bundle calls OSGiRuntime.findRuntime(), which creates a org.apache.tuscany.sca.osgi.runtime.FelixRuntime. This seems not to disturb operation very much, because the main difference to EquinoxRuntime is in starting and stopping a Felix or Equinox runtime. But it can be easily fixed by adding the package of EclipseStarter, org.eclipse.core.runtime.adaptor, to the DynamicImport-Package statement of the manifest of the tuscany-runtime bundle. See attached patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2089) java.lang.NoClassDefFoundError: running sample Calculator using ant script
[ https://issues.apache.org/jira/browse/TUSCANY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579359#action_12579359 ] Rajini Sivaram commented on TUSCANY-2089: - The dependency on OSGi API for non-OSGi samples has been fixed under revision 637797. The dependency on Felix snapshots for OSGi modules in Tuscany is still outstanding. java.lang.NoClassDefFoundError: running sample Calculator using ant script -- Key: TUSCANY-2089 URL: https://issues.apache.org/jira/browse/TUSCANY-2089 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-1.2 run: [java] Exception in thread main java.lang.NoClassDefFoundError: org/apache/tuscany/sca/host/embedded/SCADomain [java] at calculator.CalculatorClient.main(CalculatorClient.java:31) [java] Java Result: 1 -- 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: Tests for Tuscany running under OSGi
Ant, Thank you for testing that. I have added the new project dependency (node2-launcher) to osgi-tuscany under revision 637945. On 3/17/08, ant elder [EMAIL PROTECTED] wrote: On Mon, Mar 17, 2008 at 12:20 PM, Simon Nash [EMAIL PROTECTED] wrote: snip I tried to build itest/osgi-tuscany to see what its time and space overheads are, but I ran into multiple errors (incorrect pom and some tests failing). Is anyone else able to get this to build cleanly? If you're seeing failures like: Unresolved package in bundle 9: package; ((package= org.apache.tuscany.sca.node.launcher then yes i also see that now. I guess its yet another break due to trunk changes and osgi-tuscany needing to be updated as its not in the build. ...ant -- Thank you... Regards, Rajini
Re: Tests for Tuscany running under OSGi
Simon, At the moment, bundles are generated using maven-bundle-plugin, using maven dependencies. Because the test splits Tuscany into five bundles, it may be tricky to automatically find the jars for each bundle (I dont know enough about maven to do this). The build would be simpler if we had a single Tuscany bundle instead, but most of the classloading problems identified by the tests are because of a multi-classloader environment, and hence I am not keen on merging the bundles. If you can suggest some way of automating the generation of bundles without maven dependencies, I will be happy to change the build. On 3/17/08, Simon Laws [EMAIL PROTECTED] wrote: On Mon, Mar 17, 2008 at 2:49 PM, ant elder [EMAIL PROTECTED] wrote: On Mon, Mar 17, 2008 at 12:20 PM, Simon Nash [EMAIL PROTECTED] wrote: snip I tried to build itest/osgi-tuscany to see what its time and space overheads are, but I ran into multiple errors (incorrect pom and some tests failing). Is anyone else able to get this to build cleanly? If you're seeing failures like: Unresolved package in bundle 9: package; ((package= org.apache.tuscany.sca.node.launcher then yes i also see that now. I guess its yet another break due to trunk changes and osgi-tuscany needing to be updated as its not in the build. ...ant Can we automate the updating of the OSGi artifacts to match the truck status? Simon -- Thank you... Regards, Rajini
Re: Tests for Tuscany running under OSGi
Simon, Sorry about that. I hadn't done a clean build, so I didn't notice that binding-feed-atom didn't exist anymore. Thank you... Regards, Rajini On 3/17/08, Simon Nash [EMAIL PROTECTED] wrote: ant elder wrote: On Mon, Mar 17, 2008 at 12:20 PM, Simon Nash [EMAIL PROTECTED] wrote: snip I tried to build itest/osgi-tuscany to see what its time and space overheads are, but I ran into multiple errors (incorrect pom and some tests failing). Is anyone else able to get this to build cleanly? If you're seeing failures like: Unresolved package in bundle 9: package; ((package= org.apache.tuscany.sca.node.launcher then yes i also see that now. I guess its yet another break due to trunk changes and osgi-tuscany needing to be updated as its not in the build. ...ant That was one of the problems. The other was a reference in the tuscany-extensions pom to tuscany-binding-feed-atom, which does not seem to exist. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2086) implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace
[ https://issues.apache.org/jira/browse/TUSCANY-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579509#action_12579509 ] Rajini Sivaram commented on TUSCANY-2086: - Thank you for the patch. It has been applied under revision 637970. I will take a look at your tests. implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace - Key: TUSCANY-2086 URL: https://issues.apache.org/jira/browse/TUSCANY-2086 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Environment: Windows XP, Eclipse 3.3.2 (org.eclipse.osgi 3.3.2) Reporter: Jürgen Schumacher Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 Attachments: tuscany-equinox-runtime.patch, tuscany.osgi.sample.launch.zip, tuscany.osgi.sample.zip This issue refers to activities described in http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200803.mbox/[EMAIL PROTECTED] When trying to test implementation.osgi I ended with this error message: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:276) ... caused by Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:227) ... While Tuscany is right in that I did not provide a componentType file, it seems to be wrong in how it has created the filename. I debugged a bit and found the following: org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver has a method getBundleFilename(...) that tries to extract the bundles filename from its location by looking for the last / in the location and using the rest afterwards. But when the bundle is located in my Eclipse workspace as a Plugin project under development and not packed as a JAR and I run my examples in a Equinox runtime, the reported location is e.g. [EMAIL PROTECTED]:file:../workspace/EILF/tuscany.osgi.sample/ where tuscany.osgi.sample is the actual bundle name. Therefore getBundleFilename returns just an empty string. And this empty string is used later in org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(...) to build the filename for the component type file, which results in .componentType as the complete filename in this case. I suppose the current code is meant to look for the componentType file next to a bundle JAR with the same basename as the bundle JAR. I'm not sure where it should look for it in my case, probably inside the workspace bundle directory, as the workspace directory itself is usually not visible in Eclipse and so it would be inconvenient to edit the file in the IDE. Sorry that I cannot provide a test case currently because had to create own Tuscany bundles to get this far (see mail thread linked above for details), which would be a bit large to attach, I suppose (-; Also I cannot provide a patch yet, because I'm quite new to OSGi and Tuscany myself and therefore cannot estimate what would be a valid solution currently. Of course if you have any ideas how to solve this, I can test it in my setup and give more feedback. Thanks in advance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579514#action_12579514 ] Rajini Sivaram commented on TUSCANY-2093: - Ant, Can you recreate the hang in itest/osgi-contribution or itest/osgi-implementation under Eclipse in debug mode? If you can, could you generate a stack trace of all the threads when it is hanging? Otherwise, would it be possible to generate a javacore when the test is hanging? What platform are you running the test on? Could you also check the version of Felix (the date on the snapshot) that is in your maven repository, so that I can try using the same one? Thank you. Hangs in osgi itests Key: TUSCANY-2093 URL: https://issues.apache.org/jira/browse/TUSCANY-2093 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next I get hangs running various of the osgi itests, the test run part way through then just appear to hang for ever, no IO or CPU activity on the process. Eg, the output on the console for some hangs are: Running org.apache.tuscany.sca.test.osgi.tuscany.OSGiSupplyChainTestCase - Run tests from : ../../../samples/osgi-supplychain Loaded Tuscany, time taken = 31625 ms Running test null(supplychain.SupplyChainClientTestCase) Started OSGi bundle with activator OSGiCustomerImpl Started OSGi bundle with activator OSGiShipperImpl another: [INFO] Building Apache Tuscany OSGi Contribution tests [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 1 source file to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 4 source files to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\surefire-reports --- T E S T S --- Running org.apache.tuscany.sca.contribution.osgi.test.OSGiResolverTestCase - Created supplychain.customer.JavaCustomerComponentImpl using classloader 6.0 Created supplychain.retailer.JavaRetailerComponentImpl using classloader 7.0 Created supplychain.warehouse.JavaWarehouseComponentImpl using classloader 8.0 Created supplychain.shipper.JavaShipperComponentImpl using classloader 9.0 another: Running supplychain.wiring.DSWiring1TestCase - Main thread Thread[main,5,main] Created OSGiCustomerComponentImpl [EMAIL PROTECTED] Activated OSGiCustomerComponentImpl bundle OSGiCustomerComponentImpl.purchaseBooks, retailer1 is [Proxy - [EMAIL PROTECTED] Activated OSGiRetailerComponentImpl bundle Activated OSGiRetailerComponentImpl bundle OSGiRetailerComponentImpl.submitOrder , warehouse is [Proxy - [EMAIL PROTECTED] JavaWarehouseComponentImpl.fulfillOrder : shipper is [Proxy - [EMAIL PROTECTED] Activated OSGiShipperComponentImpl bundle Activated OSGiShipperComponentImpl bundle OSGiShipperComponentImpl.processShipment, customer is [Proxy - [EMAIL PROTECTED] This is easily recreateable so i can help debug, just right now i'm not sure where to look. -- 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: Tests for Tuscany running under OSGi
On 3/17/08, Simon Nash [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: Simon, Sorry about that. I hadn't done a clean build, so I didn't notice that binding-feed-atom didn't exist anymore. I did an svn up to pick up the latest itest/osgi-tuscany changes and I got further this time. The modules all built but I got test failures. Here's the stack trace from the tests. Sorry that it is long but there seem be multiple failures of different severity. Any ideas? Simon, I haven't seen the exception you are seeing (the first one in your log). Is it possible that you may be running out of disk space? I just realized that Felix caches bundles, and hence requires quite a lot of disk space to run Tuscany. So the total disk space required to build and run osgi-tuscany is close to 180M - it is at this point that I should take back the request to add osgi-tuscany to the build. Am I right in assuming that you are using the Sun JDK? Jurgen had also run into the OutOfMemory problem with perm gen space (the error right at the end of your log), which I haven't run into with the IBM JDK. It almost looks like Sun's JDK doesn't manage to garbage collect fully after an OSGi run (maybe classes are not GC'ed even after the classloader is unreachable, I am not sure). I have modified the test pom to fork a new VM for each test to avoid that error. That does slow down the tests, but at least they will run (hopefully). Thank you... Regards, Rajini
[jira] Commented: (TUSCANY-2086) implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace
[ https://issues.apache.org/jira/browse/TUSCANY-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579629#action_12579629 ] Rajini Sivaram commented on TUSCANY-2086: - For your bundle named /./tuscany.osgi.sample/, the componentType file that implementation.osgi looks for is tuscany/osgi/sample.componentType. At least it should be - the code used to assume that all bundles were .jar files. I have put it another fix, so hopefully it will now look for tuscany/osgi/sample.componentType. Tuscany processes componentType files only from SCA contributions. In your test, contribution.jar is the SCA contribution. The componentType file should be in that jar file for Tuscany to process it. The bundle that is in your OSGi runtime can be referred to from an implementation.osgi component in an SCA composite, but that bundle is not used to resolve SCA artifacts. Hope this helps. implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace - Key: TUSCANY-2086 URL: https://issues.apache.org/jira/browse/TUSCANY-2086 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Environment: Windows XP, Eclipse 3.3.2 (org.eclipse.osgi 3.3.2) Reporter: Jürgen Schumacher Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 Attachments: tuscany-equinox-runtime.patch, tuscany.osgi.sample.launch.zip, tuscany.osgi.sample.zip This issue refers to activities described in http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200803.mbox/[EMAIL PROTECTED] When trying to test implementation.osgi I ended with this error message: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:276) ... caused by Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:227) ... While Tuscany is right in that I did not provide a componentType file, it seems to be wrong in how it has created the filename. I debugged a bit and found the following: org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver has a method getBundleFilename(...) that tries to extract the bundles filename from its location by looking for the last / in the location and using the rest afterwards. But when the bundle is located in my Eclipse workspace as a Plugin project under development and not packed as a JAR and I run my examples in a Equinox runtime, the reported location is e.g. [EMAIL PROTECTED]:file:../workspace/EILF/tuscany.osgi.sample/ where tuscany.osgi.sample is the actual bundle name. Therefore getBundleFilename returns just an empty string. And this empty string is used later in org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(...) to build the filename for the component type file, which results in .componentType as the complete filename in this case. I suppose the current code is meant to look for the componentType file next to a bundle JAR with the same basename as the bundle JAR. I'm not sure where it should look for it in my case, probably inside the workspace bundle directory, as the workspace directory itself is usually not visible in Eclipse and so it would be inconvenient to edit the file in the IDE. Sorry that I cannot provide a test case currently because had to create own Tuscany bundles to get this far (see mail thread linked above for details), which would be a bit large to attach, I suppose (-; Also I cannot provide a patch yet, because I'm quite new to OSGi and Tuscany myself and therefore cannot estimate what would be a valid solution currently. Of course if you have any ideas how to solve this, I can test it in my setup and give more feedback. Thanks in advance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-2083) GroovyClassLoader throws NoClassDefFoundError when Tuscany is run inside OSGi
[ https://issues.apache.org/jira/browse/TUSCANY-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram closed TUSCANY-2083. --- Resolution: Fixed GroovyClassLoader is now created using the Tuscany classloader as parent since it is used to find Groovy classes, and not contribution classes. This change will not have any effect during normal Tuscany run outside of OSGi since Tuscany classloader will be the TCCL. GroovyClassLoader throws NoClassDefFoundError when Tuscany is run inside OSGi - Key: TUSCANY-2083 URL: https://issues.apache.org/jira/browse/TUSCANY-2083 Project: Tuscany Issue Type: Bug Components: Java SCA Groovy Implementation Extension Affects Versions: Java-SCA-1.1 Reporter: Rajini Sivaram Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 When Tuscany is run under OSGi, calculator-script sample throws the following exception: java.lang.NoClassDefFoundError: groovy.lang.Script at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:264) at java.security.SecureClassLoader.defineClass(Unknown Source) at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:57) at groovy.lang.GroovyClassLoader$ClassCollector.createClass(GroovyClassLoader.java:445) at groovy.lang.GroovyClassLoader$ClassCollector.onClassNode(GroovyClassLoader.java:463) at groovy.lang.GroovyClassLoader$ClassCollector.call(GroovyClassLoader.java:467) at org.codehaus.groovy.control.CompilationUnit$10.call(CompilationUnit.java:701) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:885) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:436) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:277) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:248) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:243) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:225) at org.apache.tuscany.sca.contribution.groovy.GroovyModelResolver.addModel(GroovyModelResolver.java:55) at org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.addModel(ExtensibleModelResolver.java:132) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:454) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:386) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:203) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:272) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:158) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:109) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:231) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69) at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:35) GroovyModelResolver creates a GroovyClassLoader with the thread context classloader as its parent. The class is already loaded from the 3rd party OSGi bundle and this bundle classloader is part of TCCL. -- 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: [SCA 1.2] What's new in JMS and OSGI for Java SCA 1.2 release ?
Done for OSGi (some of the code is not committed yet, but I will get it done in time for 1.2). On 3/13/08, Luciano Resende [EMAIL PROTECTED] wrote: After looking into the commit logs and other information sources, I still don't have a good feeling of how to describe the updates around JMS and OSGI. Could people working on these area please update the Java SCA 1.2 release wiki with what's new in this release ? - Thanks On Wed, Mar 12, 2008 at 11:31 AM, Luciano Resende [EMAIL PROTECTED] wrote: I have created a wiki page to help us centralize and track contents for the Java SCA 1.2 release. I'm going to start looking into the commit logs to check the new features, but owners feel free to update the wiki as desired. I'm also going to create a local distribution and verify the sample status, and create any jira for the issues I find. Any help is appreciated. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Release+-+Java+SCA+1.2 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- 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] -- Thank you... Regards, Rajini
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12578830#action_12578830 ] Rajini Sivaram commented on TUSCANY-2068: - Ant, Thank you for applying the patch. Could you raise a JIRA for the hang? I haven't been able to recreate a hang, and I think Graham had the tests running to completion as well. Are you using the latest version of itest/osgi-implementation? 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: ant elder 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]
Re: [jira] Created: (TUSCANY-2083) GroovyClassLoader throws NoClassDefFoundError when Tuscany is run inside OSGi
Ant, To recreate this, uncomment calculator-script from the list of tests in org.apache.tuscany.sca.test.osgi.tuscany.TuscanySamplesUsingOldDomainTestCase.java. You may want to comment out the others while testing. samples/calculator-script will be run against Tuscany running in an OSGi container, and the test throws the exception. I am not sure of a fix yet (or even what the exact problem is), I need to look into it a bit more... On 3/14/08, ant elder [EMAIL PROTECTED] wrote: Could you say a little about how to recreate this and maybe some pointers on what could be done to fix it? I'm interested in trying to fix it so i get a better understanding of all the OSGi and class loader stuff. ...ant On Thu, Mar 13, 2008 at 8:12 PM, Rajini Sivaram (JIRA) tuscany-dev@ws.apache.org wrote: GroovyClassLoader throws NoClassDefFoundError when Tuscany is run inside OSGi - Key: TUSCANY-2083 URL: https://issues.apache.org/jira/browse/TUSCANY-2083 Project: Tuscany Issue Type: Bug Components: Java SCA Groovy Implementation Extension Affects Versions: Java-SCA-1.1 Reporter: Rajini Sivaram Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 When Tuscany is run under OSGi, calculator-script sample throws the following exception: java.lang.NoClassDefFoundError: groovy.lang.Script at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:264) at java.security.SecureClassLoader.defineClass(Unknown Source) at groovy.lang.GroovyClassLoader.access$300( GroovyClassLoader.java:57) at groovy.lang.GroovyClassLoader$ClassCollector.createClass( GroovyClassLoader.java:445) at groovy.lang.GroovyClassLoader$ClassCollector.onClassNode( GroovyClassLoader.java:463) at groovy.lang.GroovyClassLoader$ClassCollector.call( GroovyClassLoader.java:467) at org.codehaus.groovy.control.CompilationUnit$10.call( CompilationUnit.java:701) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes( CompilationUnit.java:885) at org.codehaus.groovy.control.CompilationUnit.compile( CompilationUnit.java:436) at groovy.lang.GroovyClassLoader.parseClass( GroovyClassLoader.java:277) at groovy.lang.GroovyClassLoader.parseClass( GroovyClassLoader.java:248) at groovy.lang.GroovyClassLoader.parseClass( GroovyClassLoader.java:243) at groovy.lang.GroovyClassLoader.parseClass( GroovyClassLoader.java:225) at org.apache.tuscany.sca.contribution.groovy.GroovyModelResolver.addModel( GroovyModelResolver.java:55) at org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.addModel (ExtensibleModelResolver.java:132) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase (ContributionServiceImpl.java:454) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution (ContributionServiceImpl.java:386) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute (ContributionServiceImpl.java:203) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution (DefaultSCADomain.java:272) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init( DefaultSCADomain.java:158) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain .init(DefaultSCADomain.java:109) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance( SCADomain.java:231) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance( SCADomain.java:69) at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java :35) GroovyModelResolver creates a GroovyClassLoader with the thread context classloader as its parent. The class is already loaded from the 3rd party OSGi bundle and this bundle classloader is part of TCCL. -- 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] -- Thank you... Regards, Rajini
[jira] Closed: (TUSCANY-2067) URL Handling in Tuscany breaks when Tuscany is run under OSGi
[ https://issues.apache.org/jira/browse/TUSCANY-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram closed TUSCANY-2067. --- Resolution: Fixed Revision 637139 adds support for bundle URLs as contributions and contribution artifacts in Tuscany. Both bundle:// and bundleresource:// URLs are supported, but the code has only been tested under Apache Felix, so I am not sure if any extra work is required for Equinox. URL Handling in Tuscany breaks when Tuscany is run under OSGi - Key: TUSCANY-2067 URL: https://issues.apache.org/jira/browse/TUSCANY-2067 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Reporter: Rajini Sivaram Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 Code in the old DefaultSCADomain and the new domain/node APIs manipulate URLs returned by classloader.getResource() to open a directory or jar file corresponding to a contribution. This breaks when Tuscany is run under OSGi since OSGi returns bundle:// or bundleresource:// URLs instead of the file:// and jar:// URLs supported under Tuscany. A full description of the problem and possible solutions are described in the thread http://www.mail-archive.com/[EMAIL PROTECTED]/msg02213.html. -- 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] Assigned: (TUSCANY-2086) implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace
[ https://issues.apache.org/jira/browse/TUSCANY-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram reassigned TUSCANY-2086: --- Assignee: Rajini Sivaram implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace - Key: TUSCANY-2086 URL: https://issues.apache.org/jira/browse/TUSCANY-2086 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Environment: Windows XP, Eclipse 3.3.2 (org.eclipse.osgi 3.3.2) Reporter: Jürgen Schumacher Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 This issue refers to activities described in http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200803.mbox/[EMAIL PROTECTED] When trying to test implementation.osgi I ended with this error message: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:276) ... caused by Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:227) ... While Tuscany is right in that I did not provide a componentType file, it seems to be wrong in how it has created the filename. I debugged a bit and found the following: org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver has a method getBundleFilename(...) that tries to extract the bundles filename from its location by looking for the last / in the location and using the rest afterwards. But when the bundle is located in my Eclipse workspace as a Plugin project under development and not packed as a JAR and I run my examples in a Equinox runtime, the reported location is e.g. [EMAIL PROTECTED]:file:../workspace/EILF/tuscany.osgi.sample/ where tuscany.osgi.sample is the actual bundle name. Therefore getBundleFilename returns just an empty string. And this empty string is used later in org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(...) to build the filename for the component type file, which results in .componentType as the complete filename in this case. I suppose the current code is meant to look for the componentType file next to a bundle JAR with the same basename as the bundle JAR. I'm not sure where it should look for it in my case, probably inside the workspace bundle directory, as the workspace directory itself is usually not visible in Eclipse and so it would be inconvenient to edit the file in the IDE. Sorry that I cannot provide a test case currently because had to create own Tuscany bundles to get this far (see mail thread linked above for details), which would be a bit large to attach, I suppose (-; Also I cannot provide a patch yet, because I'm quite new to OSGi and Tuscany myself and therefore cannot estimate what would be a valid solution currently. Of course if you have any ideas how to solve this, I can test it in my setup and give more feedback. Thanks in advance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2086) implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace
[ https://issues.apache.org/jira/browse/TUSCANY-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578873#action_12578873 ] Rajini Sivaram commented on TUSCANY-2086: - I have modified OSGiBundleReferenceModelResolver.getBundleFilename to return the last segment of the name when the path corresponds to a directory. I am not sure if you will run into other problems though. implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace - Key: TUSCANY-2086 URL: https://issues.apache.org/jira/browse/TUSCANY-2086 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Environment: Windows XP, Eclipse 3.3.2 (org.eclipse.osgi 3.3.2) Reporter: Jürgen Schumacher Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 This issue refers to activities described in http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200803.mbox/[EMAIL PROTECTED] When trying to test implementation.osgi I ended with this error message: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:276) ... caused by Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:227) ... While Tuscany is right in that I did not provide a componentType file, it seems to be wrong in how it has created the filename. I debugged a bit and found the following: org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver has a method getBundleFilename(...) that tries to extract the bundles filename from its location by looking for the last / in the location and using the rest afterwards. But when the bundle is located in my Eclipse workspace as a Plugin project under development and not packed as a JAR and I run my examples in a Equinox runtime, the reported location is e.g. [EMAIL PROTECTED]:file:../workspace/EILF/tuscany.osgi.sample/ where tuscany.osgi.sample is the actual bundle name. Therefore getBundleFilename returns just an empty string. And this empty string is used later in org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(...) to build the filename for the component type file, which results in .componentType as the complete filename in this case. I suppose the current code is meant to look for the componentType file next to a bundle JAR with the same basename as the bundle JAR. I'm not sure where it should look for it in my case, probably inside the workspace bundle directory, as the workspace directory itself is usually not visible in Eclipse and so it would be inconvenient to edit the file in the IDE. Sorry that I cannot provide a test case currently because had to create own Tuscany bundles to get this far (see mail thread linked above for details), which would be a bit large to attach, I suppose (-; Also I cannot provide a patch yet, because I'm quite new to OSGi and Tuscany myself and therefore cannot estimate what would be a valid solution currently. Of course if you have any ideas how to solve this, I can test it in my setup and give more feedback. Thanks in advance. -- 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]
