Hi, (if this is getting too OT tell me to sling my hook) I just printed and read the jdk 1.3 optional packages versioning document (again) then found this .. http://java.sun.com/j2se/1.4/docs/guide/plugin/developer_guide/extensions.ht ml the section on "Java Extensions Installation" made interesting reading.
What is anyones opinion of the issues raised by installing Jakarta components in this way (into lib/ext), rather than as bundled jars in the application classpath? I understand that it raises security questions, but am on shaky ground about the impact of these, what other concerns are there? (what is the Jakarta policy on signing jars, is there a jakarta certificate or certification authority, if not should there be?) I also wonder how this method would work in practice where applications have their own classloader, for instance I put my JDBC drivers into tomcats "common" directory for use by all my servlet applications. If I installed them (complete with acceptable manifest) as extensions would my servlet application find them correctly, and find the correct versions? If so why don't I know about this already..(don't answer that!) Furthermore.. if I have a singleton which is placed in tomcats common directory only one instance will be created across all webapps, if it is in the WEB-INF/lib a new one will be created for each app. What is the implication of generalising the scope by installing it in the /lib/ext/ of my JVM? I assume there will still be one instantiated for each running instance of the JVM, but am I wrong in this assumption? It seems to me that we have here a mechanism with plenty of potential to reduce the duplication of jars, and what needs to be done is to create an installation manager which can check dependancies and install jars as required. Particularly as both the implementation and specification version manifest attributes can be used to precisely define dependancies, and compatibility. Perhaps there should be a jakarta "environment" project (tied in some way to GUMP?) oh no we've been here already haven't we.. ah well, at least I caught up eventually. :-) Ho hum, time I stopped doing this and spent some quality time with my family.. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
