> One limitation of classpath-prefix is that you have to include a specific jar
> name, or a specific directory that contains class files, which are different
> for every patch. Not sure if the wildcard (*) in classpath-prefix is
> supported or not in glassfish when running with JDK 6.
Yes v1/v2 does not allow wildcards to be placed in classpath-prefix and since
this is not VM classpath, wild-cards would not work with JDK6. Kedar/Byron,
could this be an RFE to be handled by the launcher?
Thanks
--Siva.
glassfish_at_javadesktop.org wrote:
> domain.xml classpath-prefix attribute is defined in glassfish\lib\dtds\sun-domain_1_3.dtd
>
> classpath-prefix
> A java classpath string that is prefixed to server-classpath
> classpath-suffix
> A java classpath string that is appended to server-classpath
> ... ...
>
> I like the idea of having a special service-pack directory. It will benefit both product use and development time as well. What I'm currently doing, when I get a patch jar to test, is to do the following steps:
>
> make a temp dir
> unjar the patch jar
> find the appserver jar that contains the patched classes (usually appserv-rt.jar)
> back the original jar to <jar-name>.orig
> jar uvf $GLASSFISH_HOME/lib/appserv-rt.jar /tmp/patch/com/sun
>
> See these are very manual steps. I don't want to edit my domain.xml to add a classpath-prefix to point to a jar or directory.
>
> One limitation of classpath-prefix is that you have to include a specific jar name, or a specific directory that contains class files, which are different for every patch. Not sure if the wildcard (*) in classpath-prefix is supported or not in glassfish when running with JDK 6.
>
> -cheng
> [Message sent by forum member 'cf126330' (cf126330)]
>
> http://forums.java.net/jive/thread.jspa?messageID=242591
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>