tuscany-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Millies, Sebastian" <Sebastian.Mill...@softwareag.com>
Subject RE: Contributions and Runtime Classpath
Date Thu, 08 Dec 2011 16:31:11 GMT
> -----Original Message-----
> From: Simon Nash [mailto:nash@apache.org]
> Sent: Thursday, December 08, 2011 3:46 PM
> To: user@tuscany.apache.org
> Subject: Re: Contributions and Runtime Classpath
> Millies, Sebastian wrote:
> >> -----Original Message-----
> >> From: Simon Nash [mailto:nash@apache.org]
> >> Sent: Thursday, December 08, 2011 11:32 AM
> >> To: user@tuscany.apache.org
> >> 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.


> > 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/user@tuscany.apache.org/msg02597.html
> [2] http://www.mail-archive.com/user@tuscany.apache.org/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

View raw message