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
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: 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: 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
Re: Versioning of Tuscany
, although I'm no legal expert [2]. > > Regards, Graham. > > [1] http://commons.apache.org/releases/versioning.html > [2] > http://www.springsource.com/repository/app/faq;jsessionid=3F9467729AC282FE4E08199FDCE40863#q6 > > > > 2008/6/11 Rajini Sivaram <[EMAIL PROTECTED]>: > > Following on from the discussion on OSGi-enabling third party libraries ( > > http://markmail.org/message/snltdk2yovr6maq5), this thread addresses the > > options for versioning Tuscany bundles and 3rd party libraries > distributed > > with Tuscany and the implications of choosing these options. I have put > > together some notes on the wiki ( > > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Versioning) > > > > There were two outstanding questions from Simon Nash in the previous > > discussion which I will summarize here to ensure that they are not lost > in > > this discussion. > > > > 1. Why can't we generate import constraints which will suit all > > applications? > > 2. *I'm concerned by the assumption here that Tuscany's versions of 3rd > > party bundles will be used both by Tuscany and by applications. An > > application may be using other software as well as Tuscany, and this > other > > software may include its own versions of bundles for javax.servlet or > jaxb. > > If Tuscany requires its versions of these bundles to be used, and the > other > > software requires its versions to be used, this requires the > application > > developer to understand how to resolve any conflicts.* > > > > The answer to 1) relates to how broad (or narrow) version ranges in > imports > > are. Broad ranges prevent isolation and reduce scope for side-by-side > > execution, narrow ranges prevent class sharing and upgrading to newer > > versions. There is more detail with examples on the wiki. > > > > Question 2) is addressed first on the wiki (Figure 1 and Figure 2 show > these > > scenarios). I would personally like to follow OSGi best practice and > enable > > maximum sharing. There are some cases where we have no choice but to > share > > (eg. SDO). I don't believe we can eliminate conflicts altogether - but > > following standard practice will make it less complicated for OSGi > > developers to resolve conflicts. > > > > Thoughts? > > > > > > Thank you... > > > > Regards, > > > > Rajini > > > -- 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-tabpanel&focusedCommentId=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.
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: > > > > > > > > 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
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/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
[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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.
[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=12602211#action_12602211 ] Rajini Sivaram commented on TUSCANY-2343: - Dan, I dont know whether Daniel runs with security on, so I will wait for his response. It could be an OSGi classloading issue rather than a security issue. Daniel, Is there a possibility that the bundles from the previous run are still in the cache? Could you run with "-clean" option to Equinox? And to answer the question in your last note - yes, the code creating SCADomain should work in OSGi. - 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-tabpanel&focusedCommentId=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.
Re: OSGi-enable 3rd party libraries in Tuscany
Simon, Thank you, I will start a new thread on versioning third party bundles in Tuscany. I will copy over the questions from your note to make sure that they are addressed. I will try and put together some examples to illustrate the points from this thread to get started off. Your input and the input of others who understand how Tuscany is really used will be extremely valuable in getting this right (it may just be that I am making it more complicated that it needs to be). I will try to get an initial note out on the mailing list by the end of the week. Thank you... Regards, Rajini On 6/3/08, Simon Nash <[EMAIL PROTECTED]> wrote: > > See comments inline. > > Simon > > Rajini Sivaram wrote: > >> 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 understand this point and I agree that there is value in adopting > an approach that provides the best experience for OSGi users, as long > as this does not create issues in a non-OSGi environment. > > >> >> 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
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 @@
> >>
> >>
> >>
> >> tuscany-sdo-${sdo.version}/lib
> >> -
> >> -
> >> org.apache.tuscany.sdo:tuscany-sdo-api-r2.1
> >> +
> >> 0644
> >>
> >>
> >> Index: pom.xml
> >> ===
> >> --- pom.xml (revision 662488)
> >> +++ pom.xml (working copy)
> >> @@ -56,6 +56,12 @@
> >> org.apache.tuscany.sdo
> >> tuscany-sdo-impl
> >> ${pom.version}
> >> +
> >> +
> >> +org.apache.felix
> >> +org.apache.felix.main
> >> +
> >> +
> >>
> >>
> >> org.apache.tuscany.sdo
> >> @@ -67,6 +73,7 @@
> >> sample-sdo
> >> ${pom.version}
> >>
> >> +
> >>
> >>
> >>
> >>
> >> 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=rev&rev=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 strange.
> >>
> >> Removing the at the bottom of the assembly bin.xml
> changes
> >> it
> >> so
> >> that the dependencies do get included again,
[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-tabpanel&focusedCommentId=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.
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
[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-tabpanel&focusedCommentId=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: [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)" wrote:
>
> [
> https://issues.apache.org/jira/browse/TUSCANY-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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(JDKInvocationHan
[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-tabpanel&focusedCommentId=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.
[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.
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 diff
Re: [jira] Commented: (TUSCANY-2330) Calculator sample running in OSGi
On 5/29/08, Simon Laws <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 8:48 AM, Rajini Sivaram < > [EMAIL PROTECTED]> wrote: > > > 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) : > > > >> > > > >>> [ > > > >>> > > > > > > https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599389#action_12599389 > > > ] > > > >>> > > > >>> Graham Charters commented on TUSCANY-2330: > > > >>> -- > > > >>> > > > >>> Hi Rajini, sorry for taking so long to respond. Please go ahead > and > > > >>> check the code in with your update. Changing it to use Felix is > fine > > > by me. > > > >>> I tested it with both and there was little discernible difference > in > > > >>> performance. > > > >>> > > > >>> Thanks, Graham. > > > >>> > > > >>> Calculator sample running in OSGi > > > >>>> - > > > >>>> > > > >>>>Key: TUSCANY-2330 > > > >>>>URL: > > > https://issues.apache.org/jira/browse/TUSCANY-2330 > > > >>>>Project: Tuscany > > > >>>> Issue Type: Wish > > > >>>> Components: Java SCA Samples > > > >>>> Affects Versions: Java-SCA-Next > > > >>>>Environment: All > > > >>>> Reporter: Graham Charters > > > >>>>Fix For: Java-SCA-Next > > > >>>> > > > >>>>Attachments: calculator-osgi-sample.patch > > > >>>> > > > >>>> Original Estimate: 2h > > > >>>> Remaining Estimate: 2h > > > >>>> > > > >>>> It would help with preserving OSGi support if an OSGi sample were > > run > > > as > > > >>>> a matter of course, rather than only by a small number of > > > developers. This > > > >>>> wish is to add the smallest sample possible based on existing > > Tuscany > > > module > > > >>>> dependencies. > > > >>>> > > > >>> -- > > > >>> This message is automatically generated by JIRA. > > > >>> - > > > >>> You can reply to this email to add a comment to the issue online. > > > >>> > > > >>> > > > >>> > > > >> > > > > > > > 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 i
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) : > >> > >>> [ > >>> > https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599389#action_12599389 > ] > >>> > >>> Graham Charters commented on TUSCANY-2330: > >>> -- > >>> > >>> Hi Rajini, sorry for taking so long to respond. Please go ahead and > >>> check the code in with your update. Changing it to use Felix is fine > by me. > >>> I tested it with both and there was little discernible difference in > >>> performance. > >>> > >>> Thanks, Graham. > >>> > >>> Calculator sample running in OSGi > - > > Key: TUSCANY-2330 > URL: > https://issues.apache.org/jira/browse/TUSCANY-2330 > Project: Tuscany > Issue Type: Wish > Components: Java SCA Samples > Affects Versions: Java-SCA-Next > Environment: All > Reporter: Graham Charters > Fix For: Java-SCA-Next > > Attachments: calculator-osgi-sample.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > It would help with preserving OSGi support if an OSGi sample were run > as > a matter of course, rather than only by a small number of > developers. This > wish is to add the smallest sample possible based on existing Tuscany > module > dependencies. > > >>> -- > >>> This message is automatically generated by JIRA. > >>> - > >>> You can reply to this email to add a comment to the issue online. > >>> > >>> > >>> > >> > > > 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: [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) : >> >>> [ >>> https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599389#action_12599389] >>> >>> Graham Charters commented on TUSCANY-2330: >>> -- >>> >>> Hi Rajini, sorry for taking so long to respond. Please go ahead and >>> check the code in with your update. Changing it to use Felix is fine by me. >>> I tested it with both and there was little discernible difference in >>> performance. >>> >>> Thanks, Graham. >>> >>> Calculator sample running in OSGi - Key: TUSCANY-2330 URL: https://issues.apache.org/jira/browse/TUSCANY-2330 Project: Tuscany Issue Type: Wish Components: Java SCA Samples Affects Versions: Java-SCA-Next Environment: All Reporter: Graham Charters Fix For: Java-SCA-Next Attachments: calculator-osgi-sample.patch Original Estimate: 2h Remaining Estimate: 2h It would help with preserving OSGi support if an OSGi sample were run as a matter of course, rather than only by a small number of developers. This wish is to add the smallest sample possible based on existing Tuscany module dependencies. >>> -- >>> This message is automatically generated by JIRA. >>> - >>> You can reply to this email to add a comment to the issue online. >>> >>> >>> >> > -- 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-tabpanel&focusedCommentId=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: 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 wr
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-tabpanel&focusedCommentId=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
[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-tabpanel&focusedCommentId=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
[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-tabpanel&focusedCommentId=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.
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 : > > fi
[jira] Commented: (TUSCANY-2330) Calculator sample running in OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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.
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.(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 org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.
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.
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 (i
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
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
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/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
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: > > > > > > 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. > > > > > > > > > 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/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
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: > 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 > > 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
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
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 >* ant elder >* Brady Johnson >* Frank Budinsky >* Ignacio Silva-Lepe >* Jean-Sebastien Delfino >* kelvin goodson >* Luciano Resende >* Mark Combellack >* Matthieu Riou >* Mike Edwards >* Paul Fremantle >* Pete Robbins >* Raymond Feng >* Simon Laws >* Simon Nash >* Venkata Krishnan > > 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
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 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
[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-tabpanel&focusedCommentId=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.
> 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">
>factory="com.siemens.hintegration.sdo.MotionReactorFactory" />
>
>class="com.siemens.hintegration.MotionReactorImpl" />
>
>interface="com.siemens.hintegration.MotionReactorService"/>
>
>
>initialContextFactory="org.apache.activemq.jndi.ActiveMQInitialContextFactory"
> jndiURL="tcp://localhost:61616">
>
>create="always"/>
>
>
>
>
> target="OSGiHelloWorldServiceComponent" />
>
>
>
> http://tuscany.apache.org/xmlns/sca/1.0";
> 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.in
[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.
[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-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-dev&m=120936893510825&w=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:
>
>
>
> org.apache.felix
> maven-bundle-plugin
>
>
>
> ${tuscany.version}
>
> org.apache.tuscany.sca.assembly
>
> ${pom.name}
>
> org.apache.tuscany.sca.assembly*
>
>
>
>
>
> 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 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) should be unique across all modules, and use the
> format org.apache.tuscany.sca.
> 2) 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
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
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 > > > > Conti
[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-dev&m=120936893510825&w=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:
org.apache.felix
maven-bundle-plugin
${tuscany.version}
org.apache.tuscany.sca.assembly
${pom.name}
org.apache.tuscany.sca.assembly*
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 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) should be unique across all modules, and use the
format org.apache.tuscany.sca.
2) 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] 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-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.
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
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 1&3, we need to make sure these are regularly tested > > under osgi. > > > > > Sounds good to me, with the following comments: > > When you have (1) + (3) you can already run a continuum OSGi build, before > attacking (2). I'd actually suggest to start building on continuum as soon > as we have (1). > > - I'm not clear on what you meant by 'use the Maven bundle plugin'. Will > we write something like this for example: > > ... > bundle > ... > >org.apache.felix >maven-bundle-plugin >true > > >org.apache.tuscany.sca.foo >org.apache.tuscany.sca.bar >org.apache.tuscany.sca.impl.* > > > > ... I think we have four options on how we start bundle-izing Tuscany modules, using maven-bundle-plugin. 1. Use the manifest goal to generate the manifest entry in all module jars, with * and *, which export all the packages from the module and import everything used by the module. The Export-Package and Import-Package statements in the generated manifest will use explicit package import/exports like: Import-Package: javax.xml.namespace,javax.xml.parsers,org.apache.tuscany.sca.contribution.resolver,... Export-Package: org.apache.tuscany.sca.implementation.osgi;version="2.0";uses:="o.a.t.s.assembly",/... The analysis of Import/Export will be 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 * , but instead it would be something more like org.apache.tuscany.sca.implementation.osgi.*, 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 , 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 , and 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 improve modularity. osgi-tuscany will take on the role on policing modularity(apart from testing that Tuscany can be run in an OSGi runtime). 4. This is OSGi best practice. If a new package is introduced and the pom is not updated, the jar itself will be unusable. Basically this requires all developers to be OSGi-aware. The
[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-tabpanel&focusedCommentId=12593731#action_12593731 ] Rajini Sivaram commented on TUSCANY-2285: - Raymond, Was the issue with maven-bundle-plugin and SDO related to building on JDK 1.4 (which is not supported with Tuscany-SCA)? If not, could you describe the problem and/or how to recreate it? We can use the manifest goal for sca-api, but we may want to use bundle/bundleall goals to generate the high-level combinations for distribution. I am sure the Felix team will help to fix the problem if we can identify what the issue was. Thank you... > Make sca-api automatically build as an OSGi bundle > -- > > Key: TUSCANY-2285 > URL: https://issues.apache.org/jira/browse/TUSCANY-2285 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core Runtime, Java SCA OSGi Integration >Affects Versions: Java-SCA-Next > Environment: All >Reporter: Graham Charters >Priority: Minor > Fix For: Java-SCA-Next > > Attachments: sca-api-bundle.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Itest/osgi-tuscany creates an OSGi bundle for the sca-api module. As a step > towards providing better support for OSGi, it has been suggested on the > dev-list that we simply make sca-api automatically build as an OSGi bundle. > This does not preclude it being used as a normal jar. > I have a patch which I will attached shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Improving support for running in OSGi
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: 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 referenc
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 > - ant elder > - Brady Johnson > - Frank Budinsky > - Ignacio Silva-Lepe > - Jean-Sebastien Delfino > - kelvin goodson > - Luciano Resende > - Mark Combellack > - Matthieu Riou > - Mike Edwards > - Paul Fremantle > - Pete Robbins > - Raymond Feng > - Simon Laws > - Simon Nash > - Venkata Krishnan > > 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 >
[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-tabpanel&focusedCommentId=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] 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-2197) Conversations with OSGi services expire immediately
[ https://issues.apache.org/jira/browse/TUSCANY-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2097) Build errors in itest/osgi-tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2097) Build errors in itest/osgi-tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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.(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-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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]
[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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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.(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-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-tabpanel&focusedCommentId=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] 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 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-2097) Build errors in itest/osgi-tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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]
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 never 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" > > 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
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" > 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-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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]
[jira] Commented: (TUSCANY-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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]
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 > >
[jira] Commented: (TUSCANY-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579631#action_12579631 ] Rajini Sivaram commented on TUSCANY-2093: - Ant, The jars are the same version as I have. What Java SDK are you using? 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-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-tabpanel&focusedCommentId=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 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]
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-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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]
[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-tabpanel&focusedCommentId=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 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]
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: > > > > > > > > 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] > >
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: > > > > > > > > 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
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: > > > > 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
[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-tabpanel&focusedCommentId=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: [SCA 1.2] Calculator Sample and OSGI dependencies...
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.( > 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 calculator.CalculatorClient.main(CalculatorClient.java > :31) > [java] Java Result: 1 > > > -- > 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] Closed: (TUSCANY-2087) Tuscany Jaas authentication uses Tuscany classloader to load callback class from contribution
[ https://issues.apache.org/jira/browse/TUSCANY-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram closed TUSCANY-2087. --- Resolution: Fixed Jaas Callback class is now resolved during the resolve phase using the standard model resolvers (revision 637634). > Tuscany Jaas authentication uses Tuscany classloader to load callback class > from contribution > - > > Key: TUSCANY-2087 > URL: https://issues.apache.org/jira/browse/TUSCANY-2087 > 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 > > > org.apache.tuscany.sca.policy.security.jaas.JaasAuthenticationPolicyHandler.beforeInvoke > uses Class.forName without specifying a classloader to load a callback class > from a contribution. This will only work if the contribution and the Tuscany > extension tuscany-policy-security are loaded using the same classloader. The > code should use the contribution's model resolver/classloader to obtain the > callback class, though I am not sure where it is expected to get it from. > samples/calculator-implementation-policies fails when Tuscany is run under > OSGi because the classloaders used for Tuscany and the contributions are > different. -- 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.(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]
