Hi Alexis;
Alexis Moussine-Pouchkine schrieb:
> is "asadmin deploy --libraries" an option here?
Thought about this as well, but in most cases I want libraries to be around
before starting the domain and deploying webapps requiring them. So to ask:
- What does "asadmin deploy --libraries" do if I am to deploy, say, a newer
version of a jar already deployed for another application? Will it replace
the "old" one or rather keep both versions?
- Will "asadmin deploy --libraries" deploy libraries depending upon the
application to be deployed, or can I also use this to deploy --libraries
shared among many (all) applications in the domain?
> placing stuff in lib/ should work but in this brave new world of
> modularity it might also break GF.
Indeed. I also wonder what would happen given one of the packages dumped to
<domain>/lib/ accidentially might happen to be an OSGi bundle? ;)
While in this discussion I am tempted to file an issue against v3 related to
this, as I think there should be a place (<domain>/lib/) where an
application developer / deployer could place custom libraries without being
capable to, by this and just by throwing in a poorly chosen jar, mess up the
whole app server installation... ;)
> Also, are you using the Hibernate IPS package available on the update
> center? This one places JAR files in GLASSFISH_HOME/lib and has been
> tested to work correctly.
So where's the difference between $GLASSFISH_HOME/lib/ and <domain>/lib/,
from this point of view? Or, other way 'round, is there a place where to
dump jars without eventually affecting the whole app server? This really
would be beneficial... :)
Cheers,
Kristian
--
Dipl.-Ing.(BA) Kristian Rink * Software- und Systemingenieur
planConnect GmbH * Könneritzstr. 33 * 01067 Dresden
fon: 0351 215 203 71 * cell: 0176 2447 2771 * mail: rink_at_planconnect.de
Amtsgericht Dresden HRB: 20 015 * St.-Nr. FA DD I 201 / 116 / 05360
Geschäftsführer: Stefan Voß, Karl Stierstorfer