[api-dev] OOo Java ClassLoader strategies ? (Re: [dev] Saxon9 and OpenOffice 2.4

[Rony G. Flatscher]

Hi there,

starting with OOo 2.4 the OOo Java ClassLoader strategies got changed.

What are the current rules for OOo 2.4 and OOo 3.x ClassLoaders?
(Maybe together with a simple explanation of the problems that have been 
intended to be solved by those changes. But also, why would the 
CLASSPATH setting not be honored by OOo, whereas the PATH setting - 
thankfully! - is honored?)


Knowing them would really alleviate a lot of developing problems, where 
one loses really tons of time/resources to a) figure out that a class 
loader problem may be in effect and b) trying to find possible solutions.


If this is the wrong list then please advise which list would be the 
appropriate one, where Java class loader issues get discussed.


---rony

P.S.: Please note the Reply-to: .

P.P.S.: It can be really quite frustrating to realize that OOo programs 
work nicely via Java, but deployed from within of OOo all of a sudden 
exhibit all kind of weird and hard to debug errors.





Ariel Constenla-Haile wrote:

Agnisys escribió:

Hi,
  Can someone help me run an XSLT transformation using Saxon in an 
Openoffice 2.4 extension?
  I get a  "net.sf.saxon.TransformerFactoryImpl not found" error. 
Thanks,

Anupam.


Hi Anupam,

this sound like the typical classpath problem with OOo extensions 
(since changes in 2.3): search for "classpath" in 
[EMAIL PROTECTED] and dev@api.openoffice.org, for example


"Classpath problem in OOo 2.3" 
http://extensions.openoffice.org/servlets/BrowseList?list=dev&by=thread&from=1865383 



"Classpath in OO Extensions" 
http://api.openoffice.org/servlets/BrowseList?list=dev&by=thread&from=1938832 



"ClassNotFoundException while loading class from external jar" 
http://extensions.openoffice.org/servlets/BrowseList?list=dev&by=thread&from=2096555 



As this seems to be a very frequent question, I thinks it's time that 
someone writes a Wiki page explaining why things changed from 2.2 to 
2.3, and how to solve it, providing a simple example.


Regards
Ariel. 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [api-dev] OOo Java ClassLoader strategies ? (Re: [dev] Saxon9 and OpenOffice 2.4

[Tobias Krais]

Hi Rony,

> Knowing them would really alleviate a lot of developing problems, where
> one loses really tons of time/resources to a) figure out that a class
> loader problem may be in effect and b) trying to find possible solutions.

May be this Issue helps you:
http://www.openoffice.org/issues/show_bug.cgi?id=80100

Greetings, Tobias

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [api-dev] OOo Java ClassLoader strategies ? (Re: [dev] Saxon9 and OpenOffice 2.4

[Stephan Bergmann]

On 08/12/08 01:35, Rony G. Flatscher wrote:

Hi there,

starting with OOo 2.4 the OOo Java ClassLoader strategies got changed.

What are the current rules for OOo 2.4 and OOo 3.x ClassLoaders?
(Maybe together with a simple explanation of the problems that have been 
intended to be solved by those changes. But also, why would the 
CLASSPATH setting not be honored by OOo, whereas the PATH setting - 
thankfully! - is honored?)


Knowing them would really alleviate a lot of developing problems, where 
one loses really tons of time/resources to a) figure out that a class 
loader problem may be in effect and b) trying to find possible solutions.


The rules are really simple (also see 
):


- The root application class loader of the VM knows virtually no jars.

- The Java UNO environment uses one underlying class loader (child of 
the root application class loader, loading the Java UNO runtime classes 
and the classes that represent UNO types---also see the discussion of 
the UNO-Type-Path manifest entry in the Developer Guide), and a 
dedicated class loader (child of the one underlying class loader) per 
Java UNO component (i.e., jar).


- Native code that starts Java code needs to create appropriate class 
loaders manually.


- A jar that depends on additional classes needs to make sure they are 
found (e.g., with a Class-Path manifest entry).


- Java code that instantiates classes from names needs to make sure it 
does so relative to an appropriate class loader (e.g., by setting a 
context class loader).


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [api-dev] OOo Java ClassLoader strategies ? (Re: [dev] Saxon9 and OpenOffice 2.4

[Rony G. Flatscher]

Hi Tobias,

Tobias Krais wrote:

Hi Rony,

  

Knowing them would really alleviate a lot of developing problems, where
one loses really tons of time/resources to a) figure out that a class
loader problem may be in effect and b) trying to find possible solutions.



May be this Issue helps you:
http://www.openoffice.org/issues/show_bug.cgi?id=80100
  
thank you *very* much for this interesting link, which allowed me to 
learn about the change and induce the motivation behind it!


Regards,

---rony

Re: [api-dev] OOo Java ClassLoader strategies ? (Re: [dev] Saxon9 and OpenOffice 2.4

[Rony G. Flatscher]

Hi Stephan,

Stephan Bergmann wrote:

On 08/12/08 01:35, Rony G. Flatscher wrote:

Hi there,

starting with OOo 2.4 the OOo Java ClassLoader strategies got changed.

What are the current rules for OOo 2.4 and OOo 3.x ClassLoaders?
(Maybe together with a simple explanation of the problems that have 
been intended to be solved by those changes. But also, why would the 
CLASSPATH setting not be honored by OOo, whereas the PATH setting - 
thankfully! - is honored?)


Knowing them would really alleviate a lot of developing problems, 
where one loses really tons of time/resources to a) figure out that a 
class loader problem may be in effect and b) trying to find possible 
solutions.


The rules are really simple (also see 
):


- The root application class loader of the VM knows virtually no jars.

- The Java UNO environment uses one underlying class loader (child of 
the root application class loader, loading the Java UNO runtime 
classes and the classes that represent UNO types---also see the 
discussion of the UNO-Type-Path manifest entry in the Developer 
Guide), and a dedicated class loader (child of the one underlying 
class loader) per Java UNO component (i.e., jar).


- Native code that starts Java code needs to create appropriate class 
loaders manually.


- A jar that depends on additional classes needs to make sure they are 
found (e.g., with a Class-Path manifest entry).


- Java code that instantiates classes from names needs to make sure it 
does so relative to an appropriate class loader (e.g., by setting a 
context class loader).



Thank you *very* much indeed!

This helps a *lot* to judge and analyze/trace problems, that may be 
linked to Java ClassLoaders (and also to more precisely coin/discuss 
RFEs in this area :) ...).
[Together with Tobias' link it has become possible to grasp a bit the 
motivation for the change that took place for 2.3 (and also to see how 
long in advance it was prepared).]


Regards,

---rony







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]