I am against this:
1. Office does not have control about what jars are used.
2. One can use the class path configuration in the options dialog.

The java framework supports also a direct mode which is  used in our build
environment, where the CLASSPATH can also be used. However, there is a clear
distinction between this mode and the "application mode" which uses OOo. In the
latter, the settings are read and written to the javasettings_xxx.xml.

However I do not see it necessary to change this for the moment.

ad 1. Office does not have control about what jars are used.

So what ? 

- Office doesn't have any control of Office Java extension jars anyway. 
- Office does not have any control over the jars in the Java extension
directories (except of course, of not supplying the ext.dirs infos). 
- Office does not have any control over Java apps that get started via JNI by
any extension. 

What is your concrete security concern? 

What use-cases do you think about, that would pose a security threat to an
Office extension written in Java (and that would not exist in C++ written
extensions) that would make it unacceptable to supply the CLASSPATH to the Java
extension?

[Office is not a web-browser or web-start like application, where you would
really have to be wary about security concerns as uncontrollable jars from the
net would be downloaded and executed on your local machine at all times and in
an uncontrollable manner. Hence the sandbox-model notion there.] 

---

Following your stance would mandate that Office stops supplying the currently
set PATH environment variable to its extensions and scripts! Office does not
have control over the applications, DLLs neither. [There your security concerns
would be even more valid.] 

----------------------------------------------------------------------

ad 2. One can use the class path configuration in the options dialog.

The class path configuration options dialog does unfortunately *not* solve the
problem at all. The reason: you cannot set that information for a Java extension
at installation time as there are no UNO APIs available to define those values! 

This means that you would need to have the Office *user* enter correctly
sensible Java configuration values *by hand* into the dialog. Such a user would
need to know the correct local Java setup (and probably the set CLASSPATH
values). Now imagine that that user is not a programmer like you and me, but a
secretary or a manager and you see the problem there. Of course you could have
the admin do all that setup (by hand??), should you have an admin in the first
place! But in larger shops the admin would be over-excercised walking from
machine to machine to drive the class path dialog manually!

---

If the CLASSPATH environment variable got set for Java apps, then there is
usually a compelling (configuration) reason for that. It allows for admins and
Java extension developers to create a very flexible and easy maintainable
environment on any client machine.

---rony


P.S.: BTW, does Office dispatch Java code with a security manager set, because
of security concerns? 

@ronyf:

The class path configuration options dialog does unfortunately *not* solve the
problem at all. The reason: you cannot set that information for a Java extension
at installation time as there are no UNO APIs available to define those values! 

Why would you set it at installation time, and not in the Jar manifest? You can
simply bundle all necessary jars in your extension and use two attributes in the
manifest file: class-path and uno-type-path. If your extension depends on the
software you cannot bundle, you should simply use disk search or something like
this, and then load the jars by reflection or whatever the method, which would
make classes load automatically. Using CLASSPATH variable is also possible in
this scenario, simply get it value with Java API, and then load classes you
need. Come on, these are very easy programming tasks! :) Plus, relying on the
CLASSPATH doesn't seem to be very user-friendly either. A secretary doesn't know
what environment variables are :P

@milek_pl:

If the only use-case/scenario is to create a self-contained and insulated (maybe
even sealed jar) then you are right. 

To add flexibility you suggest that one would have to start to write programs,
that scan disks on their own to search and find jars that should be used by
loading the classes one-self. 

You also think that this is an easy programmatic job? If so, please sketch the
necessary steps that need to be programmed in order to arrive at the flexibility
that merely honoring CLASSPATH would allow for? (And please take into account
that those programs need to become aware of the operating system they run on as
well, adding another bit of complexity.)

Ad "secretary": you are 100% right, fiddling with the CLASSPATH or *any
configuration setup* is nothing a secretary could or should do! 

In organizations you have technicians or hire technicians to do that for you.

---

Now think about honoring CLASSPATH (or allowing to programmatically change the
OOo Java configuration) to add jars which should be searched by the UNO/OOo
class loader. No programming would be needed at all!

In the case that plumbing is needed, the easiest way is to do that by changing
the CLASSPATH (and doing so would not be done by secretaries in this scenario,
but rolled out by skilled technicians, e.g. batch updates to the system
configuration in a form that honors different operating system environments).

Now, if CLASSPATH should not be honored by default (e.g. for security reasons),
then one should be able to supply a header entry in the manifest file to
explicitly request the honoring of CLASSPATH. 

[Alternatively, being able to programmatically interact with the OOo Java
configuration would allow maintenance people to do the same in essence: create
patch scripts to update/replace/extend the jars that the class loaders should
look up by default.]

@ronyf:

What I meant is that it's trivial to use Java to *explicitly* get the value of
the environmental variable "CLASSPATH". Then you simply use the value to get the
classes or jars (searching the disk is not so easy and clean, you're right). I'd
even recommend it because the implicit support for classpath values changes with
every release of OOo :( This way, you will be safe with your extension.

@milek_pl

In my experience, your suggestion:

"Why would you set it at installation time, and not in the Jar manifest? You can
simply bundle all necessary jars in your extension and use two attributes in the
manifest file: class-path and uno-type-path."

simply doesn't work on OOo 3.x.  The library jar files are simply not found no
matter what you put in the manifest.  If this worked, it would be a satisfactory
solution to this issue in my mind.  This way, your extension is self-contained
and the dependencies are under the control of the extension developer (i.e. the
user doesn't have to keep some system-wide dependency up to date whenever you
change the extension.)

@kastork:  What exactly does not work?  (The best thing would be to provide a
pointer to a failing extension.)

Well,  it looks like I need to do more research.

I just created an example to show you what I want to do and, to my surprise, it 
works.  But I also have other examples that do not work.

In all these cases the oxt has in it a 'lib' directory containing additional 
jar files, and the appropriate entries in manifests etc.  Sometimes this just 
works, but sometimes I have to explicitly add thes jar files to the classpath 
in the OOo java options (OOo crashes if I don't).  It is only certain library 
jars that cause this behavior.

At this point I'm guessing the 'broken' examples make assumptions about the 
class loader in use, and somehow the OOo custom class loader isn't being used 
(or isn't being found for some reason) -- so that would imply it is a bug in 
our libraries, not the OOo system.

I'll re-file when I can identify the unique attributes of jar libraries that 
cause this.

Reset the assignee to the default "issues@openoffice.apache.org".