> This sounds great, thanks for all of the advice.
>
> However, if I were to deploy the web project
> separately from the ear, and use remote interfaces,
> how would I configure virtual domains in Glassfish?
> Don't virtual sites require a .war be deployed to
> the app server?
Not necessarily, there's no requirement that a virtual server have a WAR associated with it. Each virtual server has a docroot parameter that would use to serve up static files, assuming that a WAR didn't intercept the request first.
But if you simply deploy the EAR against one virtual server, there's nothing stopping you from creating other virtual servers, deploying WARs to them, and having them reference your EARs EJBs.
> Also, here's another approach I'm considering -
> letting designers use ant to build and deploy the
> project to staging.
>
> I would setup the app in Netbeans and import it into
> our SVN repo. The designers would then use
> TortoiseSVN to download the project. They could make
> whatever changes necessary to the presentation layer
> of the app, which is all stored in the .war project.
> When completed, they could run and against the
> build.xml that Netbeans generated and compile a .ear
> file, which could be deployed to the staging server
> via the Glassfish admin console.
>
> Does this sound feasible? Is it a poor approach? If
> so, what are my drawbacks and limitations? I'm not
> very familiar w/ ant and have never done it this
> way...but it seems logical that it would work just
> fine.
Ant will do anything you want. It's very generic.
You could readily give all of the designers an EJB project that represents your core functionality. Then the designers could write their front end in a WAR project against that EJB project, bundled as an EAR. They can test and play and whatever.
When it's all said and done, you can then take their WAR, and all of the other designers WARs, and bundle them all together with your EJB code in to a single consolidated EAR that you deploy to staging or production.
So, Designer A would have a.war and ejb.jar bundled in to a.ear.
Designer B would have b.war and ejb.jar bundled in to b.ear.
Designer C would have c.war and ejb.jar bundled in to c.ear.
They all test locally.
Finally, through Ant tasks or whatever you like, you end up with an EAR for your staging and production server that contains a.war, b.war, c.war and ejb.jar.
So, that can work too. The only real distinction in the end is that with this technique you have 1 deployable artifact to the production app server, vs if you were using the remote interfaces, you'd have 4 (3 encompassing each independent war, and 1 for EJB piece). The only benefit to the latter is that you can redeploy a single war on the server without affecting the other wars or the EJB piece. If that's not important to you, then the single EAR containing everything will work fine.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=244595