tuscany-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Nash <n...@apache.org>
Subject Re: Contributions and Runtime Classpath
Date Thu, 08 Dec 2011 18:22:57 GMT
Millies, Sebastian wrote:
>> -----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.
>
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/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.
> 
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
> 


Mime
View raw message