|
Replies:
4
-
Last Post:
Nov 8, 2007 10:27 AM
by: whartung
|
|
|
|
|
|
|
Moving ALL sites and apps to Glassfish V2!  Need some simple advice
Posted:
Nov 7, 2007 9:20 AM
|
|
|
After 2 years of trying to "sell" Java here at work, I've finally cracked 'em and we'll be migrating all of our web sites away from ASP, VB, ASP.NET, etc. over to Java EE on Glassfish. Finally, after getting SSL to work properly on Glassfish v2 and getting our ecommerce app(s) to run properly, everyone was more willing to concede.
Now, on to the questions I have as to how to approach this.
1) We don't use *any* other server-side technology...once our sites and apps are converted one-by-one...if it needs to access a database, it is going to use JPA. That being said; is there any necessity for using a "front-end" to Glassfish, such as Apache? Our ecommerce app is served directly from GF on port 80, which is how I'd prefer it.
2) If the answer to #1 is, "no, all you need is Glassfish" - then what would be the best approach for our "brochure" sites, which are maintained by the design staff. They'd be accessing pages and resources for updates regularly and a compressed archive (i.e. .ear file) isn't acceptable, since they would use something like Dreamweaver to edit pages and not Netbeans or another Java IDE. Simply put, can I drag/drop files to Glassfish to publish them as I would with Apache or IIS-based, static web sites?
3) If the answer to #3 is "yes" - can I deploy full-on Java EE apps as uncompressed files? If I'm using Netbeans, what am I copying into Glassfish and where do I copy it to?
Thank you VERY much in advance!
-Vinnie
|
|
|
|
|
|
|
Re: Moving ALL sites and apps to Glassfish V2! Need some simple
advice
Posted:
Nov 7, 2007 9:57 AM
in response to: zambizzi
|
|
|
|
|
Thanks for choosing GlassFish!! Please contact me offline (John.Clingan@Sun.COM
) to chat some more on this topic.
More below.
On Nov 7, 2007, at 9:20 AM, glassfish@javadesktop.org wrote:
> After 2 years of trying to "sell" Java here at work, I've finally
> cracked 'em and we'll be migrating all of our web sites away from
> ASP, VB, ASP.NET, etc. over to Java EE on Glassfish. Finally, after
> getting SSL to work properly on Glassfish v2 and getting our
> ecommerce app(s) to run properly, everyone was more willing to
> concede.
>
> Now, on to the questions I have as to how to approach this.
>
> 1) We don't use *any* other server-side technology...once our sites
> and apps are converted one-by-one...if it needs to access a
> database, it is going to use JPA. That being said; is there any
> necessity for using a "front-end" to Glassfish, such as Apache? Our
> ecommerce app is served directly from GF on port 80, which is how
> I'd prefer it.
>
If you want clustering then you can have your hardware load balancer
balance across the cluster. You can also load balance across
standalone instances of course.
We also have support for load balancing via a plugin which works with
with IIS, apache and the Sun Web Server. Here's some resources that
will help get you going if the software load balancer is of interest:
https://glassfish.dev.java.net/javaee5/build/GlassFish_LB_Cluster.html
https://glassfish.dev.java.net/javaee5/lb-admin/
> 2) If the answer to #1 is, "no, all you need is Glassfish" - then
> what would be the best approach for our "brochure" sites, which are
> maintained by the design staff. They'd be accessing pages and
> resources for updates regularly and a compressed archive (i.e. .ear
> file) isn't acceptable, since they would use something like
> Dreamweaver to edit pages and not Netbeans or another Java IDE.
> Simply put, can I drag/drop files to Glassfish to publish them as I
> would with Apache or IIS-based, static web sites?
>
The answer is always "it depends" as to whether or not you want to use
a web server, but GlassFish can deliver up static content just fine.
> 3) If the answer to #3 is "yes" - can I deploy full-on Java EE apps
> as uncompressed files? If I'm using Netbeans, what am I copying
> into Glassfish and where do I copy it to?
>
This may help:
http://weblogs.java.net/blog/jfarcand/archive/2006/01/fast_web_applic_1.html
> Thank you VERY much in advance!
>
> -Vinnie
> [Message sent by forum member 'zambizzi' (zambizzi)]
>
> http://forums.java.net/jive/thread.jspa?messageID=244328
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
[att1.html]
|
|
|
|
|
|
|
|
|
Re: Moving ALL sites and apps to Glassfish V2! Need some simple advice
Posted:
Nov 7, 2007 10:04 AM
in response to: zambizzi
|
|
|
You can do everything you want.
You don't need Apache to front GlassFish, it'll serve up your static content just fine.
If they are all hosted under a single domain (www.example.com), then here is what I would do.
I would take your "heavy" database based application(s), create WAR files for them and bundle them with the EAR with your back end EJBs.
This lets them rely on the local interface for performance and such.
For your "brochure" sites, I would simply make then independent WAR files, but NOT bundled within the EAR. If they need any DB access, it's most likely lightweight access. They can get their services from the same EJBs that are in your EAR, but you'll use the remote interface to support them rather than the local.
The reason I would pull them out, is that you can trivially create a skeleton web app directory structure, put the files and folders in the structure, and then deploy the directory (rather than a WAR file) in place in to the app server. The users can then simply upload static content or JSPs all day long without having to do a redeploy. It also keeps their content out of your EAR, giving you more flexibility on how it's deployed and what not.
You can also just dump everything in to one large directory stucture, all within the same EAR, and simply deploy the structure. But I like the separation and modularity of the "micro sites" being in their own deployment structure. Marketing folks move faster than back office folks, so if they want to add some servlet or make some tweak, it's not big deal to redeploy their little piece of the server. In GF you can't redeploy a WAR individually within a EAR, you need to deploy the entire app. With seperate WARs, you can bring them up and down independently. Again, if it's mostly just static content, there's no reason to redeploy, but it's an option if they start wanting some local dynamic logic that needs a new jar or something.
The overall key is to keep your EJB tier as stable and robust as practical so it doesn't change as much.
DO be careful talking to remote beans. Local interfaces can make you lazy and passing that "large list of stuff" is no big deal with a local interface, but with a remote interface it'll beat you up. But certainly don't be afraid of remote interfaces, used judiciously they give you a lot of flexibility (like when you want to, say, move the brochure sites to their own server, they can still access the EJBs from the main server -- amazing!).
Also, you can play with the virtual hosts if you like, and make simple static sites with those. Then you can have, say, "brochure.example.com". Set up a bunch of those and you can run them in the same server or on different servers. Do a static site, or a simple WAR based site. Whatever you want. It's all straightforward.
All of this works like a champ.
|
|
|
|
|
|
|
|
|
Re: Moving ALL sites and apps to Glassfish V2! Need some simple advice
Posted:
Nov 8, 2007 9:17 AM
in response to: whartung
|
|
|
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?
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.
|
|
|
|
|
|
|
|
|
Re: Moving ALL sites and apps to Glassfish V2! Need some simple advice
Posted:
Nov 8, 2007 10:27 AM
in response to: zambizzi
|
|
|
> 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.
|
|
|
|
|
java.net RSS
