> -----Original Message----- > From: Simon Nash [mailto:[email protected]] > Sent: Thursday, December 08, 2011 3:46 PM > To: [email protected] > Subject: Re: Contributions and Runtime Classpath > > Millies, Sebastian wrote: > >> -----Original Message----- > >> From: Simon Nash [mailto:[email protected]] > >> Sent: Thursday, December 08, 2011 11:32 AM > >> To: [email protected] > >> Subject: Re: Contributions and Runtime Classpath > >> > > [snip] > >> My guess is that you have broken the "golden rule" to keep all your > >> contribution classes off the Java classpath. > > > > yes, indeed. I was not even aware of the rule. I have read the > > Tuscany in Action book, but that does not mention it, nor does > > the SCA assembly model spec. > > > Hi Sebastian, > I did put "golden rule" in quotes. It's perhaps more of a best- > practice > guideline rather than a hard and fast rule, as things will usually > (but not always) work if you don't follow the guideline. > > This has been discussed on the Tuscany user list (see [1] and [2]). > Post [2] is on a thread that you started. This guideline/rule could > have been included explicitly in the book rather than just being part > of the book sample code, but there's a limit to how much detail we > were able to put in the book without going over the agreed page count > and/or and burying the casual reader in over-complexity. It's not > part of the SCA Assembly Model spec because it's a Tuscany thing, > though this spec does explain that contributions are able to use the > normal Java mechanisms to load and reference code.
I'm sorry of I was over-critical of the book, I didn't mean to be, it's very valuable. And I also not fully understand the implications of thread[2] back then - all I did was introduce import/export statements in my sca-contribution xml files, and as everything then seemed to worked flawlessly, I did not anticipate getting into classloader hell later on. My mistake. [snip] > > Is there more deployment information of such importance documented > > somewhere that I should be aware of? > > > > I can't give a Yes or No answer to such a wide-ranging question. > Unlike commercial products that deliver code accompanied by hundreds > or thousands of pages of detailed documentation, Tuscany aims to > help users who have questions or problems by providing timely and > high-quality support via these mailing lists. I'm sorry if this > experience has made you disappointed. I really am very happy with the support you (and others) give on this list. In my opinion, this kind of thing can be much more helpful than a big book - I would not have had time to read thousands of manual pages beforehand. And even if I had, for lack of experience with Tuscany I'd have been likely to miss the relevant point anyway (cf. comment above). > > Simon > > [1] http://www.mail-archive.com/[email protected]/msg02597.html > [2] http://www.mail-archive.com/[email protected]/msg02897.html Thanks for the pointer to [1]. That's just the thing I was looking for. Point 3. in that post (using copies of service interfaces in client code) sounds like a maintenance nightmare for JUnit tests. All my tests involve RMI clients exercising some service interface, which I'd have to double. What about utility classes that are used by many contributions and by clients - can I put those on the class path? I guess not. In Eclipse, at the moment I have a dependency to a global utility project that everything else depends on. I suppose that will have to go, and I just cannot use the standard Eclipse build and launch support, with project dependencies and all. Instead, I'll have to always build with maven (or ant) and put the jars somewhere where the contributions can locate them. Like the scatours.launcher.LauncherUtil. -- Sebastian IDS Scheer Consulting GmbH Geschäftsführer/Managing Directors: Kamyar Niroumand, Ivo Totev Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken, Germany - Registergericht/Commercial register: Saarbrücken HRB 19681 http://www.softwareag.com
