commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rony G. Flatscher" <Rony.Flatsc...@wu-wien.ac.at>
Subject Re: [logging] Any takers ? (Placing "commons-logging-1.1.jar"into"${JAVA_HOME}/jre/lib/endorsed" o.k.?
Date Tue, 07 Nov 2006 16:38:11 GMT
Hi there,

thank you (Alfredo and Simon) very much for your feedback, which assures
me to go the "endorsed" directory!

Basically, I agree that one should not use the "ext" or "endorsed"
directory for individual applications, but either pack them into one
app-lib or adjust the classpath accordingly.

The case in question is about deploying Jakarta's BSF (including the
ooRexx language engine) allowing any Java app or non-Java-app having
Java-APIs ("in or out") to take advantage of the BSF scripting engines
there are. So this is meant as a true extension to the installed JRE.
The BSF4Rexx package is meant for people who usually do not have any
Java background, but want to use Java as if it was ooRexx (much simpler
syntax) in order to take advantage of all the functionality Java allows
for (actually there are use cases where Java gets used, but the ooRexx
programmers won't really notice that).

This use case does not stop at pure Java apps however. The real reason
for me to decide to use the "ext" directory came with the wish to allow
one to use the BSF engines in the context of OpenOffice (OOo) to allow
scripting OOo with scripting languages the OOo programmers have never
thought about (to support)...

OOo is basically written in C++, but because Sun bought StarOffice (of
which OOo is the opensource version), all C++ UNO components can be
interacted with with Java). Since a year, OOo also has a scripting
framework which is written in Java itself (allowing Javascript/Rhino,
BeanShell), so it supplies a perfect infrastructural environment to
deploy Jakarta BSF to add any of the BSF scripting engines as internal
macro languages to OOo!

When analysing the OOo use case it turned out, that OOo itself manages
which Java it uses. There is a GUI element to configure the JRE in case
of multiple installs, but no documented API to do that programmatically
at all!

To make a long story short, the easiest and most stable solution seemed
to have been to install BSF into the "ext" directory, which allows it to
be used from the command line and drive OOo (here the CLASSPATH is set
to point to the OOo interface jars) *and* to allow OOo to use it without
any need to configure OOo's Java settings (which only would have been
possible by hand, an error prone procedure, plus in an environment where
there are dozens, if not hundreds of installations necessary, manual
installation is just not practical).

This scenario has been working quite well for more than a year, but
since the official release of BSF needs commons-logging, other apps
using common-logging got into problems because of the BSF-version being
placed in the "ext" directory. Hence the moving to "endorsed", which
seems to solve this clash situation reliably. But I was not sure whether
other side-effects could pop-up that I was not thinking about.

Again, thank you very much for your feedback which has helped me a lot
to reassure that venue!

Regards,

---rony




Alfredo Ledezma Melendez wrote:
> Hi,
>
> I agree with Simon, isolation is the word to consider. From my point of
> view, the best approach is to have a common repository to all the libs you
> need, and just set the CLASSPATH according to your particular needs.
>
> AFAIK no problems might happen with your approach, though.
>
> Regards,
> Alfredo
>
>   
>> -----Original Message-----
>> From: Simon Kitching [mailto:skitching@apache.org]
>> Sent: Martes, 07 de Noviembre de 2006 03:23 a.m.
>> To: Jakarta Commons Users List
>> Subject: Re: [logging] Any takers ? (Placing "commons-logging-
>> 1.1.jar"into"${JAVA_HOME}/jre/lib/endorsed" o.k.?
>>
>> Hi,
>>
>> I don't know of any issues that might occur.
>>
>> I think putting libs into the java install is a pretty ugly thing to do
>> though. Applications should stand alone. I'm also against putting webapp
>> libs into appserver shared directories, etc. though the whole world
>> appears to disagree with me on that one.
>>
>> Regards,
>>
>> Simon
>>
>> On Mon, 2006-11-06 at 19:40 +0100, Rony G. Flatscher wrote:
>>     
>>> Hi there,
>>>
>>> so far no answer has arrived via the common-user list. I would
>>> appreciate *any* comments anyone would have to the idea to put the
>>> commons-logging jar into the "${JAVA_HOME}/jre/lib/endorsed" directory
>>> to solve incompatibility issues, if other packages have their own
>>> commons-logging.jar, but stumble over one that may have been installed
>>> into the Java extension directory  "${JAVA_HOME}/jre/lib/ext".
>>>
>>> Preliminary tests show the problem to be solved by installing the
>>> commons-logging.jar into the "endorsed" directory, but before changing
>>> the installation routine to do that for a special BSF package, I would
>>> like to learn about potential pitfalls from the experts...
>>>
>>> Regards,
>>>
>>> ---rony
>>>
>>> P.S.: The original message of last week was (path issue corrected):
>>>
>>>       
>>>>> Hi there,
>>>>>
>>>>> creating an installer for Jakarta's BSF to be placed into
>>>>> "${JAVA_HOME}/jre/lib/ext" to make it available to all Java apps,
>>>>>           
>> also
>>     
>>>>> had me put "commons-logging-1.1.jar" to the
>>>>>           
>> "${JAVA_HOME}/jre/lib/ext" directory.
>>     
>>>>> But because of reports of users of Eclipse's help system and Geronimo
>>>>> (both apps won't run afterwards) I moved the "commons-logging-
>>>>>           
>> 1.1.jar"
>>     
>>>>> to the "endorsed" directory which remedied the situation.
>>>>>
>>>>> Would there be situations where this could cause problems elsewhere?
>>>>>
>>>>> Thanks for any hints/insights in advance!
>>>>>
>>>>> ---rony
>>>>>
>>>>>           


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message