Millies, Sebastian wrote:
-----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.
No problem. We found it quite surprising how much has to be left out
or touched on just briefly in order to condense all of SCA and Tuscany
into a 400 page book. Because of this, the book is intended as an
introduction and not a complete reference.
Also, this is a tricky area because things mostly work if you don't
follow the rule/guideline, and there's no warning to say that you are
skating on thin ice.
[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).
>
Thanks for this. We are all learning, and it's great for the Tuscany
developers to have feedback from users like yourself so that we know
where the tricky areas are and can (hopefully) improve them in the future.
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.
I think I should clarify something about the points in [1]. Points 4, 5
and 6 are needed if you want to use different versions of jars in your
application from those used by the Tuscany runtime--for example, a
different level of Axis2. I don't think that's your situation, so you
should be able to ignore those points.
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.
You should be able to copy the service interface .class files into different
jars for use by the JUnit tests and put these test jars on the classpath.
The test jars would need to load contributions in the correct fashion
(i.e., the test jars should not have direct references to any of the
contents of the contribution jars). I presume the interface copying could
be automated as part of your build process.
What about utility classes that are used by many contributions and by
clients - can I put those on the class path? I guess not.
It's fine to put these classes on the classpath, as long as they are not
part of any contribution. As I said in my earlier post, contribution code
can see classes loaded by the application classloader. So you can put
non-contribution classes (used as dependencies of contribution code)
on the classpath without causing any problems for contribution code.
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.
I don't think you need to go to such extreme lengths. Isn't there some
way to set up Eclipse so that the global utility project appears on the
classpath but your contribution jars don't appear on the classpath?
Simon
-- 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
