This is where being in a large organisation can have advantages specifically where development is separate from operations
If the dev guys create an EAR that passses all testcases and works standalone then they might consider that theire code is ready to be promoted
When operational guys find a problem when deploying to a clustered environment they toss it back to the dev guys and say your code doesnt work (when another node is used)
If the dev guys put in a hardcoded resource (hardcoded filename) that Node1 has access to and Node2 does not have access to well then the devs need to place that resource on
a Virtual File or some universally accessible location
if the devs are providing any code that is specific to an environment then they need to make those environment attributes a configurable option in either
*.properties
*.xml
Notice that domain.xml under element name you have the ability to supply multiple properties with name and value attributes e.g.
<property name= value=
if your dev guys are building a OSGI compliant build you may want to populate dynamic attributes to be rebuilt by felix
domain.xml would contain
<jvm-options>-Dfelix.fileinstall.dir=${com.sun.aas.installRoot}/modules/autostart/</jvm-options>
autostart folder would contain
org.apache.felix.fileinstall-autodeploy-bundles.cfg
which would contain
# Directory being watched by fileinstall.
felix.fileinstall.dir=${com.sun.aas.instanceRoot}/autodeploy/bundles/
# Time period fileinstaller thread in ms.
felix.fileinstall.poll=5000
# log level
felix.fileinstall.log.level=3
# should new bundles be started or installed only? true => start, false => only install
felix.fileinstall.bundles.new.start=true
# should bundles be started transiently?
felix.fileinstall.bundles.startTransient=true
any new properties files conaining new attributes that should be bundled by felix are located at
${com.sun.aas.instanceRoot}/autodeploy/bundles/
BTW: the rebuild process should also generate fresh jars wars and ears so any problems with corrupt jar/war/ear will not be go away
An interesing deployment challenge,
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> To: users_at_glassfish.java.net
> Subject: GlassFish 2.1.1 - Application client jar is generated corruptly in clustered environment / Java Web Start
> From: forums_at_java.net
> Date: Wed, 22 Aug 2012 06:09:30 -0500
>
> We have an EAR about 25 MB in size. This EAR contains an application client,
> two EJB projects and two Web projects. When the EAR is deployed in a
> non-clustered environment (standalone) everything is fine: the application
> client jar is generated correctly (size about 20MB). You can launch the
> client via Java Web Start. However, when we deploy the EAR in a clustered
> environment (consists of two nodes with one instance on each node) the
> generated application client jar - which can be found under
> GF_PATH/nodeagents/nodeagent1/instance1/generated/xml/j2ee-apps/EAR-folder..
> - shows that the generated "EAR-name"Client.jar is always in a corrupted
> state. You cannot even open the file with a zip tool etc. This file
> corruption happens on both instances and is always reproducible. *If you
> delete the corrupted file on both instances and restart the cluster, the
> application client jar gets generated again and this time, the file is always
> generated correctly.* I started to test this further by shutting down one
> instance in the cluster to see if has something to do with the sync process
> for each instance during deployment. But the problem remains, it does not
> matter if on instance is down or not - the generated file is corrupt. Does
> anyone else have this problem in a clustered environment? As I mentioned
> above in a standalone app server we do not have this problem. Any help
> appreciated. Thank you. squibber
>
> --
>
> [Message sent by forum member 'squibber']
>
> View Post: http://forums.java.net/node/889421
>
>