There is a very nice overview of exactly what Glassfish (and indeed what an application server in general) is here: https://glassfish.dev.java.net/faq/v2/GlassFishOverview.pdf
If you are new to Glassfish, or just wondering what it can do, this is a good place to start.
Sunday, June 24, 2007
Sunday, June 10, 2007
Glassfish...Summing it Up
I've been using Glassfish for about a year now and its cousin the Sun Java System Application Server for several years prior to that and have noticed a steady improvement in the product. Some of the nice things about Glassfish include:
1) Support for leading edge technology like EJB 3
2) Nice GUI for administration
3) Price :)
4) Good user community (see link to the right for home page)
5) Support for clustered environments
6) Relative ease of use (due in part to the GUI)
7) Very nice logger...it even has some graphic capability in Log Statistics :)
8) Stability of the actual application server (not necessariliy the admin console...read on) is very good with the later versions like the one tested. In fact, I cannot remember having any problems with and vesion of Glassfish after build 33 with respect to up time during my load tests.
All things considered, Glassfish proves to be a very capable Java application server. There are some things that can be done to make it even better though. First, as with all software of this magnitude, there are a few bugs to be ironed out here and there. The Glassfish community does a good job with this, but a couple items I noticed for this latest build include:
1) Problem with Help Search. Typing in JDBC then clicking Search for example yielded no results.
2) As mentioned in a prior blog post, there are some instances where drop down boxes were not populated...having them deactivated may make more sense.
3) Missing System Properties icon (no biggy obviously)
4) Clicking on Admin Service under Configuration logged me out. This only happened once (the first time) but I am certain it was not due to a time out as I had just clicked on Connector Service before that and received a response. This also happened the first time I clicked on Security->Realms and Connectors.
There are also some things that I would like to see added/changed to Glassfish. Those include:
1) Snap points in logs. What I mean by this is to give the admin the ability to click a button and have the log insert some sort of marker. This is useful when changing setting or running tests. You might give them the ability to add text to the marker. For example: <<<<<<< MARKER: Test new connection Pool >>>>>>>
2) Snap point in configuration with comparison utility. This would allow administrators the ability to roll back changes much more easily and to see what was changed and when it was done. It would also be nice to be able to see performance characteristics tied to these changes. In other words, have the configuration changes add markers that can be seen in the monitors.
3) When running on Windows, there are some Unix specific items that should be greyed out or not displayed. Example: Logging->Write to System Log to use Unix syslog service.
4) The ability to configure email alerting based on application and log level.
5) The ability to tune the application server based on anticipated usage. For example, I noticed in my performance testing that this version of Glassfish produced better results for smaller sized data packets than build 36, but that build produced better results for larger sized packets. That made me wonder if it might be possible to allow tuning at least at the install level. If it could be done at the application level, all the better!
6) Although the help system (aside from the bug I mentioned) is very good, a printed manual that gave detailed information and good real world examples would go a long way in helping the adoption of Glassfish IMHO.
Aside from these wants and minor bugs, when it comes down to the ability of Glassfish to do what it needs to do easily, efficiently, and reliably, I think Duke says it best:
1) Support for leading edge technology like EJB 3
2) Nice GUI for administration
3) Price :)
4) Good user community (see link to the right for home page)
5) Support for clustered environments
6) Relative ease of use (due in part to the GUI)
7) Very nice logger...it even has some graphic capability in Log Statistics :)
8) Stability of the actual application server (not necessariliy the admin console...read on) is very good with the later versions like the one tested. In fact, I cannot remember having any problems with and vesion of Glassfish after build 33 with respect to up time during my load tests.
All things considered, Glassfish proves to be a very capable Java application server. There are some things that can be done to make it even better though. First, as with all software of this magnitude, there are a few bugs to be ironed out here and there. The Glassfish community does a good job with this, but a couple items I noticed for this latest build include:
1) Problem with Help Search. Typing in JDBC then clicking Search for example yielded no results.
2) As mentioned in a prior blog post, there are some instances where drop down boxes were not populated...having them deactivated may make more sense.
3) Missing System Properties icon (no biggy obviously)
4) Clicking on Admin Service under Configuration logged me out. This only happened once (the first time) but I am certain it was not due to a time out as I had just clicked on Connector Service before that and received a response. This also happened the first time I clicked on Security->Realms and Connectors.
There are also some things that I would like to see added/changed to Glassfish. Those include:
1) Snap points in logs. What I mean by this is to give the admin the ability to click a button and have the log insert some sort of marker. This is useful when changing setting or running tests. You might give them the ability to add text to the marker. For example: <<<<<<< MARKER: Test new connection Pool >>>>>>>
2) Snap point in configuration with comparison utility. This would allow administrators the ability to roll back changes much more easily and to see what was changed and when it was done. It would also be nice to be able to see performance characteristics tied to these changes. In other words, have the configuration changes add markers that can be seen in the monitors.
3) When running on Windows, there are some Unix specific items that should be greyed out or not displayed. Example: Logging->Write to System Log to use Unix syslog service.
4) The ability to configure email alerting based on application and log level.
5) The ability to tune the application server based on anticipated usage. For example, I noticed in my performance testing that this version of Glassfish produced better results for smaller sized data packets than build 36, but that build produced better results for larger sized packets. That made me wonder if it might be possible to allow tuning at least at the install level. If it could be done at the application level, all the better!
6) Although the help system (aside from the bug I mentioned) is very good, a printed manual that gave detailed information and good real world examples would go a long way in helping the adoption of Glassfish IMHO.
Aside from these wants and minor bugs, when it comes down to the ability of Glassfish to do what it needs to do easily, efficiently, and reliably, I think Duke says it best:
Saturday, June 09, 2007
Glassfish Performance
A while back I wrote a test application that pits CORBA (using Java's ORB), EJB 3.0 (using Glassfish), and sockets against one another. For the EJB 3.0 test, this involves accessing stateless session beans on the server.
The client is a fairly simple application that spawns a given number of threads where each one requests data of varying size from the server. The client threads each do this as many times as they can in a given interval and then the results are tallied. The interval is broken down into two parts. A warm up period and a actual period. EJB in particular seems to show better results after a nice warmup period. I've run this test several times since early this year and have noted some steady improvement in the performance of Glassfish (the CORBA and the sockets test remained flat as their server side implementations did not change).
Here are the results for a relatively short test. Only the EJB results are provided as those are the ones we are interested in here. The sizes of data packets are dived into five categories:
TINY = 1000 bytes
SMALL = 5000 bytes
MEDIUM = 10000 bytes
LARGE = 20000 bytes
XLARGE = 50000 bytes
As a side note, Glassfish builds prior to 36 had a timeout problem (Exceeded 1,800,000 milliseconds) so you cannot run extended period tests on older versions.
On Glassfish 36
Thread_1 found 22159 warmup and 35631 actual Tiny datapoints
On Glassfish Build 41
Thread_2 found 23514 warmup and 38000 actual Tiny datapoints
Although many test runs need to be conducted to weed out anomalies, from this set of data we can see that the newer build clearly had an improvement in performance in Tiny, Small, and Medium packets. By the time we got to the large packets the old version was about as fast and even showed an edge in the XLarge performance criteria. Here it is graphically:
Hmmm...have the Glassfish folks done some tuning as of late? Might it be possible to someday set an option that allows you to tune your installation? For example, some applications deal primarily with returning small data packets of text based data while others deal in larger binary files (big images for example). If you knew the size of the data your app server dealt with, then perhaps there might be a way to tune this on an install by install basis.
When some more app servers suport EJB 3 (note that Oracle's does now as well), I'll run these tests again and pit Glassfish against them. From what I've seen with it so far though, my thought is that Glassfish will do more than hold its own...in fact, Glassfish may just have a little piranha in it and eat their lunch! We'll see.
Next time I'll go over some of the things I'd like to see added/changed to/about Glassfish.
The client is a fairly simple application that spawns a given number of threads where each one requests data of varying size from the server. The client threads each do this as many times as they can in a given interval and then the results are tallied. The interval is broken down into two parts. A warm up period and a actual period. EJB in particular seems to show better results after a nice warmup period. I've run this test several times since early this year and have noted some steady improvement in the performance of Glassfish (the CORBA and the sockets test remained flat as their server side implementations did not change).
Here are the results for a relatively short test. Only the EJB results are provided as those are the ones we are interested in here. The sizes of data packets are dived into five categories:
TINY = 1000 bytes
SMALL = 5000 bytes
MEDIUM = 10000 bytes
LARGE = 20000 bytes
XLARGE = 50000 bytes
As a side note, Glassfish builds prior to 36 had a timeout problem (Exceeded 1,800,000 milliseconds) so you cannot run extended period tests on older versions.
On Glassfish 36
Thread_1 found 22159 warmup and 35631 actual Tiny datapoints
Thread_4 found 19889 warmup and 31647 actual Tiny datapoints
Thread_0 found 20032 warmup and 31655 actual Tiny datapoints
Thread_3 found 22300 warmup and 35617 actual Tiny datapoints
Thread_2 found 20031 warmup and 31575 actual Tiny datapoints
Thread_0 found 11822 warmup and 18273 actual Small datapoints
Thread_1 found 12950 warmup and 19549 actual Small datapoints
Thread_4 found 11787 warmup and 18100 actual Small datapoints
Thread_3 found 13011 warmup and 19518 actual Small datapoints
Thread_2 found 11815 warmup and 18168 actual Small datapoints
Thread_3 found 6069 warmup and 9687 actual Medium datapoints
Thread_2 found 5692 warmup and 9080 actual Medium datapoints
Thread_4 found 5693 warmup and 9039 actual Medium datapoints
Thread_0 found 5699 warmup and 9084 actual Medium datapoints
Thread_1 found 6081 warmup and 9609 actual Medium datapoints
Thread_4 found 3268 warmup and 5399 actual Large datapoints
Thread_3 found 3300 warmup and 5507 actual Large datapoints
Thread_0 found 3222 warmup and 5392 actual Large datapoints
Thread_1 found 3329 warmup and 5460 actual Large datapoints
Thread_2 found 3263 warmup and 5361 actual Large datapoints
Thread_4 found 1377 warmup and 2233 actual XLarge datapoints
Thread_0 found 1370 warmup and 2227 actual XLarge datapoints
Thread_1 found 1373 warmup and 2225 actual XLarge datapoints
Thread_3 found 1382 warmup and 2219 actual XLarge datapoints
Thread_2 found 1358 warmup and 2226 actual XLarge datapoints
On Glassfish Build 41
Thread_2 found 23514 warmup and 38000 actual Tiny datapoints
Thread_4 found 23581 warmup and 37653 actual Tiny datapoints
Thread_1 found 24727 warmup and 39992 actual Tiny datapoints
Thread_3 found 24543 warmup and 40005 actual Tiny datapoints
Thread_0 found 23553 warmup and 38002 actual Tiny datapoints
Thread_1 found 12854 warmup and 19917 actual Small datapoints
Thread_2 found 12385 warmup and 19169 actual Small datapoints
Thread_3 found 12968 warmup and 19798 actual Small datapoints
Thread_0 found 12497 warmup and 19201 actual Small datapoints
Thread_4 found 12498 warmup and 19215 actual Small datapoints
Thread_2 found 6024 warmup and 9630 actual Medium datapoints
Thread_1 found 6256 warmup and 10028 actual Medium datapoints
Thread_3 found 6229 warmup and 10038 actual Medium datapoints
Thread_0 found 6101 warmup and 9615 actual Medium datapoints
Thread_4 found 6045 warmup and 9636 actual Medium datapoints
Thread_2 found 3238 warmup and 5392 actual Large datapoints
Thread_3 found 3369 warmup and 5678 actual Large datapoints
Thread_0 found 3224 warmup and 5395 actual Large datapoints
Thread_4 found 3237 warmup and 5372 actual Large datapoints
Thread_1 found 3353 warmup and 5622 actual Large datapoints
Thread_2 found 1288 warmup and 2114 actual XLarge datapoints
Thread_3 found 1333 warmup and 2154 actual XLarge datapoints
Thread_0 found 1293 warmup and 2123 actual XLarge datapoints
Thread_4 found 1289 warmup and 2128 actual XLarge datapoints
Thread_1 found 1324 warmup and 2170 actual XLarge datapoints
Although many test runs need to be conducted to weed out anomalies, from this set of data we can see that the newer build clearly had an improvement in performance in Tiny, Small, and Medium packets. By the time we got to the large packets the old version was about as fast and even showed an edge in the XLarge performance criteria. Here it is graphically:
Hmmm...have the Glassfish folks done some tuning as of late? Might it be possible to someday set an option that allows you to tune your installation? For example, some applications deal primarily with returning small data packets of text based data while others deal in larger binary files (big images for example). If you knew the size of the data your app server dealt with, then perhaps there might be a way to tune this on an install by install basis.
When some more app servers suport EJB 3 (note that Oracle's does now as well), I'll run these tests again and pit Glassfish against them. From what I've seen with it so far though, my thought is that Glassfish will do more than hold its own...in fact, Glassfish may just have a little piranha in it and eat their lunch! We'll see.
Next time I'll go over some of the things I'd like to see added/changed to/about Glassfish.
Sunday, June 03, 2007
Another helping of Glassfish...mmmm good stuff!
Today I'd like to work with some old things and some new...let's start out by configuring a database for use with Glassfish. In specific, I'll be adding a connection pool for SQL Server using a third party (jTDS) driver.
Here is the procedure
1) Unzip the driver.
2) Copy the jTDS.jar file to the Glassfish's lib directory.
3) If you haven't done so, add a database using in Enterprise Manager...for this test I called
it glassfishdb
4) Add logins as needed to have access to us the glassfishdb
5) Start Application Server as described in a prior blog entry. Note that if Glassfish is
already running then you will want to restart it so it will find the JDBC driver.
6) Open up the Sun Admin Console and log in.
7) Add a connection pool by clicking on Create New JDBC Connection Pool under Other Tasks then
follow this list:
a) Name = sqlserverproxy (or some name of your choice)
b) Resource Type = XADataSource (depends of course...)
c) Database Vendor = Microsoft SQL Server
Click Next (upper right)
d) Datasource Classname = net.sourceforge.jtds.jdbcx.JtdsDataSource
e) Description = Enter some description (SQL Server for Glassfish Test for example)
f) Check connection validation required
g) Servername = localHost
h) port = 1433 (SQL SErver default unless you have changed it)
i) Databasename = glassfishdb
j) User = the user you set up
k) Password = the password you gave the user
After that, click Save then click Ping to verify all is OK.
Note that if you have a question about any of the parameters mentioned here or those I did not specify (pool size for example), simply click Help (upper right hand corner) and Glassfish you tell you all you need to know about this page.
Once that part is complete, you'll want to add a JDBC resource. On the left hand pane, expand Resources, then expand JDBC Resources. On the right hand pane, click New. Give it some name (glassfishResoucePool for example) and select the connection pool name you set up in the prior step, add a description of your choice, then make sure the enabled box is checked.
That's all there is to it! The GUI steps you throught the process and provides assistance should you need it, and even allows you to verify connectivity (via the ping).
So good for the tried and true (this functionality is has been in Glassfish more or less unchanged for as long as I can remember), let's try something a bit newer next. I recall back in an earlier build of Glasssifh (circa b27-30) there was a problem getting web services generated through Netbeans to work due to a problem with Glassfish...let's see if this is still the case.
Following instructions at http://www.netbeans.org/kb/55/websvc-jax-ws.html I built and deployed a test web service (CalculatorWS). I then went into the Classfish Admin Console to see if it was successfully deployed and, hopefully as this did not work the last time I checked, test it out.
To do that, click on Web Services in the left hand pane and verify that ClaculateWS is there.
Click on the name to bring up more options. Here you will see a button labeled Test. This is the part that was missing/broken when I last tried but now it works great.
Click on Test and you will see that Glassfish brings up a little tester web page for you.
It even shows you the soap request and response (click add). Very nice!
Next week I'll try to test some of the performance improvements over prior versions. In build 33 I saw a substantial improvement for simple stateless session EJBs transporting data in packet sizes from 2 to 20K over build 27. Will the improvments continue?
Until next time then...
Here is the procedure
1) Unzip the driver.
2) Copy the jTDS.jar file to the Glassfish's lib directory.
3) If you haven't done so, add a database using in Enterprise Manager...for this test I called
it glassfishdb
4) Add logins as needed to have access to us the glassfishdb
5) Start Application Server as described in a prior blog entry. Note that if Glassfish is
already running then you will want to restart it so it will find the JDBC driver.
6) Open up the Sun Admin Console and log in.
7) Add a connection pool by clicking on Create New JDBC Connection Pool under Other Tasks then
follow this list:
a) Name = sqlserverproxy (or some name of your choice)
b) Resource Type = XADataSource (depends of course...)
c) Database Vendor = Microsoft SQL Server
Click Next (upper right)
d) Datasource Classname = net.sourceforge.jtds.jdbcx.JtdsDataSource
e) Description = Enter some description (SQL Server for Glassfish Test for example)
f) Check connection validation required
g) Servername = localHost
h) port = 1433 (SQL SErver default unless you have changed it)
i) Databasename = glassfishdb
j) User = the user you set up
k) Password = the password you gave the user
After that, click Save then click Ping to verify all is OK.
Note that if you have a question about any of the parameters mentioned here or those I did not specify (pool size for example), simply click Help (upper right hand corner) and Glassfish you tell you all you need to know about this page.
Once that part is complete, you'll want to add a JDBC resource. On the left hand pane, expand Resources, then expand JDBC Resources. On the right hand pane, click New. Give it some name (glassfishResoucePool for example) and select the connection pool name you set up in the prior step, add a description of your choice, then make sure the enabled box is checked.
That's all there is to it! The GUI steps you throught the process and provides assistance should you need it, and even allows you to verify connectivity (via the ping).
So good for the tried and true (this functionality is has been in Glassfish more or less unchanged for as long as I can remember), let's try something a bit newer next. I recall back in an earlier build of Glasssifh (circa b27-30) there was a problem getting web services generated through Netbeans to work due to a problem with Glassfish...let's see if this is still the case.
Following instructions at http://www.netbeans.org/kb/55/websvc-jax-ws.html I built and deployed a test web service (CalculatorWS). I then went into the Classfish Admin Console to see if it was successfully deployed and, hopefully as this did not work the last time I checked, test it out.
To do that, click on Web Services in the left hand pane and verify that ClaculateWS is there.
Click on the name to bring up more options. Here you will see a button labeled Test. This is the part that was missing/broken when I last tried but now it works great.
Click on Test and you will see that Glassfish brings up a little tester web page for you.
It even shows you the soap request and response (click add). Very nice!
Next week I'll try to test some of the performance improvements over prior versions. In build 33 I saw a substantial improvement for simple stateless session EJBs transporting data in packet sizes from 2 to 20K over build 27. Will the improvments continue?
Until next time then...
Sunday, May 27, 2007
A little more Glassfish please...
Today I'm going to talk about my experience with the latest (build 41 at the time of this writing) version of Glassfish, and open source Java application server.
Getting the Software
Glassfish can be obtained from several sources. You can get it directly from https://glassfish.dev.java.net/downloads/v2-b41d.html and also packaged with Netbeans 6.0 which can be obtained at http://dlc.sun.com/netbeans/download/6.0/milestones/latest/
Note that Glassfish may be referred to as Sun Java System Application Server 9.1 Beta 2 b41d on the Netbeans site...same product with an alternate name. For this review I used both methods.
Installation
If you decide to download it stand alone outside of NetBeans, then just follow the instructions at https://glassfish.dev.java.net/downloads/v2-b41d.html and choose either clustered or non-clustered version. Also, don't forget to set java_home as mentioned in the instructions. For this review, I chose to install a clustered version using this procedure and installed a non-clustered version with the Netbeans 6.- package. For many, the that approach might be best, and it gives you one heck of a nice IDE to use that integrates with Glassfish (and other Java app servers) very well.
I did run into a small snag when installing though. On my machine, the port that Glassfish defaults to (8080) was in use, so I changed the setup-cluster.xml file to use port 8081 instead. I set up the non-clustered version to point here as well...this will be no problem since I will only be running one at a time. After changing the port, the install succeeded.
Starting Up Glassfish.
As mentioned earlier, one of the nice things about NetBeans is how well it integrates with various application servers. The non-clustered version of Glassfish was already set up for me, and it was very simple to add the clustered version to the list of application servers my NetBeans installation knew about. To me, using an IDE like NetBeans to interact (start/stop/access the console/etc.) makes a lot of sense, but you can always use the command line if you wish. Information on how that is done can be found here: https://glassfish.dev.java.net/downloads/quickstart/index.html.
For this review, I'll be doing things the easy way...though NetBeans. With that in mind, the way you start up Glassfish, or any application server using NetBeans, is to select the Runtime tab, expand the Servers entry, right click on the application server of your choice, and then click Start. This is what I did to start the non-clustered version.
I then stopped that, and started the clustered version to make sure it too was installed correctly...it was.
Side note: Another nice thing about NetBeans is that it gives you a new tab in the output window for each app server you bring up. This window shows you what is going on with the server....taking a look at this output, all is well.
Viewing the Admin Console
Through NetBeans, I selected the Admin Console by right clicking on clustered version of Glassfish (same location we used to start it). This brings up a web page to log into. Just give it the username and password you used when installing Glassfish (default is admin, with password adminadmin).
Upon doing this you will be presented with a very nice looking home page. All I can say is WOW...this looks much nicer look than the old SJAS8.1 I'm used to (let along...well...nothing for another open source application server I've used. :).
When I get a new toy....err....piece of software, I'm not one for reading every line of documentation before I try it out, and Glassfish is no exception. So, played around with it a little...”kicked the tires” so to speak. Here are a few observations:
I tried to create a stand alone instance: From Common Tasks (first page) under Enterprise Tasks, select Create New Stand-Alone Instance. Doing that though I noticed that the Node Agent drop down was not populated.. I'll have to check into that later...must be some additional setup needed first...for now I just created a new cluster by selecting the option above the one I just mentioned...that worked just fine
Creating clustered instance worked fine.
I left the clustered version's Admin Console and then stopped the server, then started up the non-clustered version instead. Since I have no plans of running in a clustered environment at this installation, I'll be focusing on the non-clustered version from here on out.
...
Same procedure starting the Admin Console as before....
Looking at this version you can see that the options related to clustering are gone but other than that, the same nice looking interface is still there. The more I see the more impressed I am
with the level of maturity this version has. Seems very well laid out and easy to navigate.
I viewed the log...surprised at the number of warnings, but looking at them they
make sense. Yes, I said the messages actually make sense! For example, one message was “This operation failed, because it could not be handled by this domain. An example of such an operation is creating application server instances or clusters when they are not supported by the given domain. The actual error is: MBean instance not found”.
Note that they give you the ability to filter messages too. I could really have used that in times past.
The help system is very nice. The only thing I would like to see is the ability to get pdf versions of the content.
I did note one minor glitch...noticed the icon wasn't displayed for System Properties under Configuration in the Common Tasks area. Other than that, everything seems to be exactly as it should.
Well, that's all I have time for today. Next I'll set up a database and maybe run some tests...perhaps even compare performance between this version and an older one.
Getting the Software
Glassfish can be obtained from several sources. You can get it directly from https://glassfish.dev.java.net/downloads/v2-b41d.html and also packaged with Netbeans 6.0 which can be obtained at http://dlc.sun.com/netbeans/download/6.0/milestones/latest/
Note that Glassfish may be referred to as Sun Java System Application Server 9.1 Beta 2 b41d on the Netbeans site...same product with an alternate name. For this review I used both methods.
Installation
If you decide to download it stand alone outside of NetBeans, then just follow the instructions at https://glassfish.dev.java.net/downloads/v2-b41d.html and choose either clustered or non-clustered version. Also, don't forget to set java_home as mentioned in the instructions. For this review, I chose to install a clustered version using this procedure and installed a non-clustered version with the Netbeans 6.- package. For many, the that approach might be best, and it gives you one heck of a nice IDE to use that integrates with Glassfish (and other Java app servers) very well.
I did run into a small snag when installing though. On my machine, the port that Glassfish defaults to (8080) was in use, so I changed the setup-cluster.xml file to use port 8081 instead. I set up the non-clustered version to point here as well...this will be no problem since I will only be running one at a time. After changing the port, the install succeeded.
Starting Up Glassfish.
As mentioned earlier, one of the nice things about NetBeans is how well it integrates with various application servers. The non-clustered version of Glassfish was already set up for me, and it was very simple to add the clustered version to the list of application servers my NetBeans installation knew about. To me, using an IDE like NetBeans to interact (start/stop/access the console/etc.) makes a lot of sense, but you can always use the command line if you wish. Information on how that is done can be found here: https://glassfish.dev.java.net/downloads/quickstart/index.html.
For this review, I'll be doing things the easy way...though NetBeans. With that in mind, the way you start up Glassfish, or any application server using NetBeans, is to select the Runtime tab, expand the Servers entry, right click on the application server of your choice, and then click Start. This is what I did to start the non-clustered version.
I then stopped that, and started the clustered version to make sure it too was installed correctly...it was.
Side note: Another nice thing about NetBeans is that it gives you a new tab in the output window for each app server you bring up. This window shows you what is going on with the server....taking a look at this output, all is well.
Viewing the Admin Console
Through NetBeans, I selected the Admin Console by right clicking on clustered version of Glassfish (same location we used to start it). This brings up a web page to log into. Just give it the username and password you used when installing Glassfish (default is admin, with password adminadmin).
Upon doing this you will be presented with a very nice looking home page. All I can say is WOW...this looks much nicer look than the old SJAS8.1 I'm used to (let along...well...nothing for another open source application server I've used. :).
When I get a new toy....err....piece of software, I'm not one for reading every line of documentation before I try it out, and Glassfish is no exception. So, played around with it a little...”kicked the tires” so to speak. Here are a few observations:
I tried to create a stand alone instance: From Common Tasks (first page) under Enterprise Tasks, select Create New Stand-Alone Instance. Doing that though I noticed that the Node Agent drop down was not populated.. I'll have to check into that later...must be some additional setup needed first...for now I just created a new cluster by selecting the option above the one I just mentioned...that worked just fine
Creating clustered instance worked fine.
I left the clustered version's Admin Console and then stopped the server, then started up the non-clustered version instead. Since I have no plans of running in a clustered environment at this installation, I'll be focusing on the non-clustered version from here on out.
...
Same procedure starting the Admin Console as before....
Looking at this version you can see that the options related to clustering are gone but other than that, the same nice looking interface is still there. The more I see the more impressed I am
with the level of maturity this version has. Seems very well laid out and easy to navigate.
I viewed the log...surprised at the number of warnings, but looking at them they
make sense. Yes, I said the messages actually make sense! For example, one message was “This operation failed, because it could not be handled by this domain. An example of such an operation is creating application server instances or clusters when they are not supported by the given domain. The actual error is: MBean instance not found”.
Note that they give you the ability to filter messages too. I could really have used that in times past.
The help system is very nice. The only thing I would like to see is the ability to get pdf versions of the content.
I did note one minor glitch...noticed the icon wasn't displayed for System Properties under Configuration in the Common Tasks area. Other than that, everything seems to be exactly as it should.
Well, that's all I have time for today. Next I'll set up a database and maybe run some tests...perhaps even compare performance between this version and an older one.
Saturday, May 26, 2007
Glassfish.
Well, after a LONG vacation from blogging here, I found something worth writing about...the new version of Glassfish, the open source Java application server.
Over the next few weeks I'll review this tool...should be interesting!
Wednesday, October 05, 2005
Spring in fall.
For those of you who use J2EE you are probably aware of a framework called Spring. Well it looks like the Spring folks are going to have a get together. Details can be found here: http://thespringexperience.com/show_view.jsp?showId=44
I have some Spring experience and by far and large, like it. It allows you to apply concepts like Inversion of Control (or what I prefer to call dependancy injection) and Aspect Oriented Programming without writing a lot of code yourself.
At first I found Spring too daunting, and thought that the Struts framework was much easier to deal with and understand. What I needed to do was get away from the architect's point of view and try it on the development level (get my hands dirty). Once that was done, the fog began to lift.
Here is a quick start tutorial I wrote on Spring for those who happen to use Java Studio Creator (a tool I really like...the version soon to be released that is): http://swforum.sun.com/jive/thread.jspa?threadID=52657&tstart=20
I have some Spring experience and by far and large, like it. It allows you to apply concepts like Inversion of Control (or what I prefer to call dependancy injection) and Aspect Oriented Programming without writing a lot of code yourself.
At first I found Spring too daunting, and thought that the Struts framework was much easier to deal with and understand. What I needed to do was get away from the architect's point of view and try it on the development level (get my hands dirty). Once that was done, the fog began to lift.
Here is a quick start tutorial I wrote on Spring for those who happen to use Java Studio Creator (a tool I really like...the version soon to be released that is): http://swforum.sun.com/jive/thread.jspa?threadID=52657&tstart=20
Subscribe to:
Posts (Atom)
