Showing posts with label javaee. Show all posts
Showing posts with label javaee. Show all posts
Tuesday, February 20, 2018
WildFly 12.0.0.Beta1 tagged and available
WildFly 12.0.0.Beta1 has been tagged and has been (I think) officially released. The announcement happened a few days back in the dev mailing list and unlike the previous releases, this time the release binaries seem to be only available in Maven repository and can be obtained from here - WildFly 12.0.0.Beta1 distribution (the .tar.gz and .zip are the relevant ones). The list of changes for this release can be found in the JIRA release notes.
As you'll notice in the release notes, there's some initial support for EE 8 specs, including Servlet 4.0 among others. Plus there's also numerous bug fixes in this release from the previous 11.0.0.Final version which was released some months back. As usual, please give this version a try and if there are any issues or feedback that you would like to report, please start a discussion in the WildFly user forum
If you haven't been following the WildFly dev mailing list, there's also a discussion which outlines the release plans for WildFly going forward. You can find that discussion here
Finally, there's been major changes to Java EE processes and committee and even the name, over the past year. If you haven't been following those changes, then you can read through Mark Little's recent blogs including the most recent ones which talk about the new brand name for Java EE and setting up of the working group.
As you'll notice in the release notes, there's some initial support for EE 8 specs, including Servlet 4.0 among others. Plus there's also numerous bug fixes in this release from the previous 11.0.0.Final version which was released some months back. As usual, please give this version a try and if there are any issues or feedback that you would like to report, please start a discussion in the WildFly user forum
If you haven't been following the WildFly dev mailing list, there's also a discussion which outlines the release plans for WildFly going forward. You can find that discussion here
Finally, there's been major changes to Java EE processes and committee and even the name, over the past year. If you haven't been following those changes, then you can read through Mark Little's recent blogs including the most recent ones which talk about the new brand name for Java EE and setting up of the working group.
Sunday, December 07, 2014
WildFly 8.2.0.Final release - Quick overview of the changes
It's been a while since I last wrote on this blog. Although I have had some topics that I wanted to blog about, I just haven't found enough time to do it. I finally decided to write this up today after I saw a mail from one of the JBoss community members, checking up on why there haven't been any updates here lately (thanks for checking, Bhaskar! :)).
Before I move on to some technical things, a quick personal update - It's now been more than a year now since I changed jobs. I no longer work at Red Hat, JBoss. My (almost) 5 years at JBoss have been very fruitful and I enjoyed being part of the (JBoss AS/WildFly) application server development team. Last year, I decided to move on to something different and the right opportunity came along and I decided to take it up. Some of you know that I've been involved with the JBoss community for longer than the 5 years that I had been employed at Red Hat. I have been a JBoss community member since around 2004/2005, so even though I have moved on from Red Hat, I am still active in the JBoss forums.
Now that you all know what I've been upto, let's move on to some technical things.
The WildFly team just released the 8.2.0.Final version of WildFly some days back. As usual, it's available for download on the project's download page http://wildfly.org/downloads/. This is mainly a bug fix (plus some features) release in the 8.x series. I for one, was pleased to see this release happen because it allows the community to receive bug fixes on top of 8.1.0.Final release, which has been tested/used in the community for quite some time now. The WildFly team has indicated that this will be the last release in the 8.x series which sounds reasonable, given that the development team has already moved on to work on the 9.x series. It's never easy to work/maintain more than one major version of the code, especially in the context of bug fixes and backward compatibility.
The complete overview of changes in available in this announcement on Jason's blog http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/. CDI spec upgrade and improved WebSocket support are the main items in terms of feature set. There's also this note in the release notes:
There was a recent forum thread, where one of the users asked what that really means. Here's some background to that change https://issues.jboss.org/browse/WFLY-3102. As noted in that JIRA, this was feature request that was raised in the context of EJBs packaged in .war deployments. Most of you, I guess, will be aware that Java EE spec allows EJBs to be deployed as part of the .war deployment. What this means is that you can place your EJB classes within the .war/WEB-INF/classes or within a jar in .war/WEB-INF/lib. Although, this sounds straightforward for the end users, there are some technical implications to this (given the way Java EE "components" and "modules" are defined and configured within the server ecosystem). One such detail, is the way one configures the EJBs that are part of the .war deployment. Remember that if this EJB was part of a separate EJB module (within a .jar packaging outside of the .war) then one would use the ejb-jar.xml (and the WildFly specific jboss-ejb3.xml) as the deployment descriptors to configure it. This applies to EJBs deployed in a .war deployment too. i.e. one can use those same files for configuring EJBs. Now since these EJBs are part of a .war, the .war itself can/will have a deployment descriptor if its own (the web.xml and jboss-web.xml).
With that context, consider a case where the you have EJBs within the .war deployment and your .war deployment descriptor (the jboss-web.xml) configures a specific security domain for that deployment. Now remember that the EJBs too can configure a security domain (in jboss-ejb3.xml) and if none is configured and security is enabled on some EJBs, then the default "other" security domain gets used. So let's say your .war deployment, in which the EJBs reside, states that it wants to use "foo-bar" security domain and the EJBs, within that deployment, don't specify any specific security domain. So what should one expect in such scenario? Should the EJBs use the security domain configured at the .war level or should they default to the "other" security domain (since the EJB deployment descriptors don't specify any specific security domain configuration). The previous versions of WildFly had decided to use the default "other" security domain for the EJBs in such a case. Of course, the EJBs could use a jboss-ejb3.xml to set a different security domain, one which matches the jboss-web.xml. So that JIRA which I linked to earlier requested for a better, smarter and a more logical default in such cases. So starting this 8.2.0.Final version of WildFly, if you have a .war containing the EJBs and the EJBs don't define a security domain, then the security domain for any secured EJBs in that deployment *defaults* to the one that's defined at the .war deployment level. If the .war deployment doesn't set any specific security domain, then it ultimately, defaults to the "other" security domain. A good and logical change IMO. This will reduce some of the "surprises" that users have reported with previous version of WildFly, when it came to the security domain usage of EJBs in .war deployments.
For more about this, you can read the discussion here https://developer.jboss.org/thread/250375 and ask any questions you have around this, in that thread.
Although, not specific to 8.2.0.Final, the WildFly release contain a "patch" distribution which you can use if you already are using WildFly 8.1.0.Final and just want to "upgrade" to this new release. WildFly 8 has patch management built in and one can apply this patch on top of an existing 8.1.0.Final version.
As noted earlier, the WildFly development team has moved on to the next version of the project. Work is now continuing on 9.x version which already has a Alpha version released. So going forward, from what I have read, the releases will happen in the 9.x series.
Before I move on to some technical things, a quick personal update - It's now been more than a year now since I changed jobs. I no longer work at Red Hat, JBoss. My (almost) 5 years at JBoss have been very fruitful and I enjoyed being part of the (JBoss AS/WildFly) application server development team. Last year, I decided to move on to something different and the right opportunity came along and I decided to take it up. Some of you know that I've been involved with the JBoss community for longer than the 5 years that I had been employed at Red Hat. I have been a JBoss community member since around 2004/2005, so even though I have moved on from Red Hat, I am still active in the JBoss forums.
Now that you all know what I've been upto, let's move on to some technical things.
WildFly 8.2.0.Final released!
The WildFly team just released the 8.2.0.Final version of WildFly some days back. As usual, it's available for download on the project's download page http://wildfly.org/downloads/. This is mainly a bug fix (plus some features) release in the 8.x series. I for one, was pleased to see this release happen because it allows the community to receive bug fixes on top of 8.1.0.Final release, which has been tested/used in the community for quite some time now. The WildFly team has indicated that this will be the last release in the 8.x series which sounds reasonable, given that the development team has already moved on to work on the 9.x series. It's never easy to work/maintain more than one major version of the code, especially in the context of bug fixes and backward compatibility.
What does WildFly 8.2.0.Final contain?
The complete overview of changes in available in this announcement on Jason's blog http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/. CDI spec upgrade and improved WebSocket support are the main items in terms of feature set. There's also this note in the release notes:
- EJBs in WARs now inherit the WAR security domain
There was a recent forum thread, where one of the users asked what that really means. Here's some background to that change https://issues.jboss.org/browse/WFLY-3102. As noted in that JIRA, this was feature request that was raised in the context of EJBs packaged in .war deployments. Most of you, I guess, will be aware that Java EE spec allows EJBs to be deployed as part of the .war deployment. What this means is that you can place your EJB classes within the .war/WEB-INF/classes or within a jar in .war/WEB-INF/lib. Although, this sounds straightforward for the end users, there are some technical implications to this (given the way Java EE "components" and "modules" are defined and configured within the server ecosystem). One such detail, is the way one configures the EJBs that are part of the .war deployment. Remember that if this EJB was part of a separate EJB module (within a .jar packaging outside of the .war) then one would use the ejb-jar.xml (and the WildFly specific jboss-ejb3.xml) as the deployment descriptors to configure it. This applies to EJBs deployed in a .war deployment too. i.e. one can use those same files for configuring EJBs. Now since these EJBs are part of a .war, the .war itself can/will have a deployment descriptor if its own (the web.xml and jboss-web.xml).
With that context, consider a case where the you have EJBs within the .war deployment and your .war deployment descriptor (the jboss-web.xml) configures a specific security domain for that deployment. Now remember that the EJBs too can configure a security domain (in jboss-ejb3.xml) and if none is configured and security is enabled on some EJBs, then the default "other" security domain gets used. So let's say your .war deployment, in which the EJBs reside, states that it wants to use "foo-bar" security domain and the EJBs, within that deployment, don't specify any specific security domain. So what should one expect in such scenario? Should the EJBs use the security domain configured at the .war level or should they default to the "other" security domain (since the EJB deployment descriptors don't specify any specific security domain configuration). The previous versions of WildFly had decided to use the default "other" security domain for the EJBs in such a case. Of course, the EJBs could use a jboss-ejb3.xml to set a different security domain, one which matches the jboss-web.xml. So that JIRA which I linked to earlier requested for a better, smarter and a more logical default in such cases. So starting this 8.2.0.Final version of WildFly, if you have a .war containing the EJBs and the EJBs don't define a security domain, then the security domain for any secured EJBs in that deployment *defaults* to the one that's defined at the .war deployment level. If the .war deployment doesn't set any specific security domain, then it ultimately, defaults to the "other" security domain. A good and logical change IMO. This will reduce some of the "surprises" that users have reported with previous version of WildFly, when it came to the security domain usage of EJBs in .war deployments.
For more about this, you can read the discussion here https://developer.jboss.org/thread/250375 and ask any questions you have around this, in that thread.
What are the other notable things in WildFly 8.2.0.Final?
Although, not specific to 8.2.0.Final, the WildFly release contain a "patch" distribution which you can use if you already are using WildFly 8.1.0.Final and just want to "upgrade" to this new release. WildFly 8 has patch management built in and one can apply this patch on top of an existing 8.1.0.Final version.
What's next for WildFly?
As noted earlier, the WildFly development team has moved on to the next version of the project. Work is now continuing on 9.x version which already has a Alpha version released. So going forward, from what I have read, the releases will happen in the 9.x series.
Wednesday, January 22, 2014
WildFly 8.0 CR1 release and WildFly 8 book
I guess by now everyone is aware that the community JBoss AS server has been renamed to WildFly. The WildFly team has been busy pushing out releases of the 8.0 series during the past few months. It's been a month now since the 8.0 CR1 version of WildFly was released. This is a significant release since the 8.0 CR1 version passes the Java EE7 TCK 100%. The Final version of 8.0 is expected any time soon http://lists.jboss.org/pipermail/wildfly-dev/2014-January/001458.html.
Along with this good news about the WildFly 8.0 series nearing the final version, the other good news is that there's now a WildFly 8 administration guide available for purchase. The author of the book is Francesco Marchioni, who in the past has authored books on the JBoss AS series.
Along with this good news about the WildFly 8.0 series nearing the final version, the other good news is that there's now a WildFly 8 administration guide available for purchase. The author of the book is Francesco Marchioni, who in the past has authored books on the JBoss AS series.
Brief review of the WildFly 8 book
The WildFly 8 book by Francesco is aimed at admins and does a good job of covering various administrative configurations for each of the major subsystems that form a part of the WildFly server. The author starts by covering the basics, from installation of the server and goes on to give an overview of the standalone and domain modes of the server. He then goes on to extensively explain each of the major subsystem administration configurations, like the new web subsystem which is backed by Undertow. There's also chapters on EJB and clustering configurations.
Francesco does a good job of covering the major subsystems and also keep the content concise. I found the book to be a good read from an administrator point of view. There are certain tidbits for developers too, but the book is mostly aimed at admins. If you are looking for some book to give you a quick and extensive overview of the subsystems in WildFly, then this is worth it.
Thursday, July 25, 2013
WildFly 8.0.0.Alpha3 released with support for EJB invocations over HTTP
A week back we released WildFly 8.0.0.Alpha3 version. As usual the download is available on WildFly downloads page. This release comes within a month of the 8.0.0.Alpha2 release. Keeping up with the goals of WildFly 8, this new release contains additional EE7 support, certain bug fixes and also some WildFly specific features. The entire release notes are available here.
In this article, I'll provide some details about one of the WildFly features which has made into this release.
Traditionally, WildFly and previously named JBoss AS have opened different ports for different protocols and communication. For example, in the JBoss AS7 and now WildFly 8 series, by default the server opens the http port (which is by default 8080), remoting port (which is backed by JBoss Remoting and by default is 4447) and other such ports for usage by the applications deployed on the server. One of the goals of WildFly 8 (Final) is to have one single port open for all types of communication. This is meant to allow admins a better control of the server (firewall rules for example).
As some of you might know by now, the WildFly 8 series now uses Undertow as its web container. Undertow supports a standard feature called HTTP Upgrade. As can be read in that RFC, this feature allows the HTTP protocol to switch to a different protcol based on the presence of a header in the protocol data. This HTTP Upgrade feature acts as the backbone of the proposed "single port for communication" feature in WildFly.
Now that we have some background on HTTP Upgrade, let get to the details about the new feature that WildFly 8.0.0.Alpha3 introduces. Up until WildFly 8.0.0.Alpha2 (and previously in JBoss AS7 series) a project called JBoss Remoting has been the underlying protocol for remote communication with the server. The communication by default used to happen on the port 4447. Many of you will be familiar with this port, since this is what you used while looking up EJBs from a remote client.
Starting WildFly 8.0.0.Alpha3 (i.e. this new release), this port is no longer opened by WildFly by default. So how does one invoke EJBs or even use remote-naming (which too used this port) starting this version? The answer is simple, these remote clients will now have to use the HTTP port which by default is port 8080. The rest of the code will remain the same. This HTTP port is managed by the Undertow server which like I said earlier, has support for HTTP Upgrade. Internally, the EJB client API project (which is JBoss specific project dealing with remote EJB invocations) does the necessary plumbing to request Undertow to switch to JBoss "remoting" protocol while communicating on that HTTP port. Undertow then switches the protocol to "remoting" and the rest of the communication transparently happens as if it was the usual invocation on the remoting port.
So let's see some code to understand what exactly changes from previous version to the new version, from a remote client point of view. Let's take the example of the jboss-ejb-client.properties that's used to invoke EJBs. Earlier, you probably had:
Starting this release, the only thing that changes is the port number in that properties, rest of it remains the same. So:
So that's it from a typical client point of view.
For other new features and bug fixes, please take a look at the release notes.
In this article, I'll provide some details about one of the WildFly features which has made into this release.
WildFly ports
Traditionally, WildFly and previously named JBoss AS have opened different ports for different protocols and communication. For example, in the JBoss AS7 and now WildFly 8 series, by default the server opens the http port (which is by default 8080), remoting port (which is backed by JBoss Remoting and by default is 4447) and other such ports for usage by the applications deployed on the server. One of the goals of WildFly 8 (Final) is to have one single port open for all types of communication. This is meant to allow admins a better control of the server (firewall rules for example).
HTTP Upgrade support in Undertow
As some of you might know by now, the WildFly 8 series now uses Undertow as its web container. Undertow supports a standard feature called HTTP Upgrade. As can be read in that RFC, this feature allows the HTTP protocol to switch to a different protcol based on the presence of a header in the protocol data. This HTTP Upgrade feature acts as the backbone of the proposed "single port for communication" feature in WildFly.
EJB invocation over HTTP
Now that we have some background on HTTP Upgrade, let get to the details about the new feature that WildFly 8.0.0.Alpha3 introduces. Up until WildFly 8.0.0.Alpha2 (and previously in JBoss AS7 series) a project called JBoss Remoting has been the underlying protocol for remote communication with the server. The communication by default used to happen on the port 4447. Many of you will be familiar with this port, since this is what you used while looking up EJBs from a remote client.
Starting WildFly 8.0.0.Alpha3 (i.e. this new release), this port is no longer opened by WildFly by default. So how does one invoke EJBs or even use remote-naming (which too used this port) starting this version? The answer is simple, these remote clients will now have to use the HTTP port which by default is port 8080. The rest of the code will remain the same. This HTTP port is managed by the Undertow server which like I said earlier, has support for HTTP Upgrade. Internally, the EJB client API project (which is JBoss specific project dealing with remote EJB invocations) does the necessary plumbing to request Undertow to switch to JBoss "remoting" protocol while communicating on that HTTP port. Undertow then switches the protocol to "remoting" and the rest of the communication transparently happens as if it was the usual invocation on the remoting port.
So let's see some code to understand what exactly changes from previous version to the new version, from a remote client point of view. Let's take the example of the jboss-ejb-client.properties that's used to invoke EJBs. Earlier, you probably had:
remote.connections=default
# the server hostname/IP
remote.connection.default.host=10.19.20.12
# the port for communication
remote.connection.default.port=4447
Starting this release, the only thing that changes is the port number in that properties, rest of it remains the same. So:
remote.connections=default
# the server hostname/IP
remote.connection.default.host=10.19.20.12
# the port for communication (the HTTP port)
remote.connection.default.port=8080
So that's it from a typical client point of view.
For other new features and bug fixes, please take a look at the release notes.
Monday, June 03, 2013
WildFly 8.0.0.Alpha1 release and a bit of history
It's been around 2 weeks now since we released WildFly 8.0.0.Alpha1 version. The download is available on the WildFly downloads page. I'm sure many of you might be wondering what WildFly is and some of you who are aware of what it is, might not be aware that there has been a release. I'll try and answer some of these questions and also add some details about what this release contains.
JBoss Application Server (both the name and the project) has been a very popular project over the years. Initially when it started off, it was known simply as JBoss. Anytime anyone referred to the name JBoss, people knew that they were talking about the JBoss Application Server community edition. Over the years though, the reference started to get hazy. The community edition JBoss Application Server also has a paid and fully supported version known as JBoss Enterprise Application Platform (JBoss EAP). Notice the "JBoss" name in there? So there's JBoss Application Server community edition and then there's JBoss EAP paid version. It did not stop there! Over the years, various community projects hosted at jboss.org started naming their projects with the name "JBoss" in it. So there was "JBoss ESB", "JBoss Transactions", "JBoss Messaging" and many such projects with the name "JBoss" in it. It's certainly no fault of those projects that they used "JBoss" as part of the name. It did make sense to use that name, since those projects were developed by JBoss community members. By the way, did you just notice the name "JBoss" even means a reference to the JBoss community as a whole?
So I guess at this point you might have realized where I'm headed with all this historical evidence. Clearly, the name "JBoss" had started to mean much more than just the JBoss Application Server community project. Although it was good thing from a brand point of view, it clearly wasn't too good from various other aspects. We had started seeing too much confusion about what each project/product stood for not just from a name point of view but also a release roadmap point of view. Take for example JBoss Application Server and JBoss EAP - users, typically those who are more busy with their application (rightly so) than trying to understand what each variant of project/product with the name "JBoss" in it meant, were just not sure which one to pick and which release of those had what features in it. Of course, it would take some explanation to help them understand this, but doing this on a regular basis was a clear sign that this isn't the right way forward.
So slowly during the past few years, there has been a conscious decision not to name new projects with "JBoss" in its name and also to rename some of the existing projects wherever possible. So for example, when "JBoss Messaging" project decided to release a completely new and better version, the project decided to name it "HornetQ". Similarly, JBoss Transactions is now known as Narayana. There are various examples of such renames and new names. Obviously, doing the same for JBoss Application Server would need some time and extra efforts since it was a really huge change for various reasons. But it had to be done ultimately and that's why it's now WildFly.
The rename is only for the JBoss Application Server community edition. The paid version is still named JBoss Enterprise Application Platform (JBoss EAP). Since one of the original intentions of the rename was to clear the confusion between JBoss Application Server community edition and similar named JBoss EAP, the name change only applies to the community edition. So ultimately, over time, when someone refers to WildFly, we clearly know they are talking about the community project and very specifically the application server project.
WildFly 8.0.0.Alpha1 is the continuation of the release cycle of the application server community edition, which was previously known as JBoss AS7. The last release of JBoss AS7 was 7.1.1.Final (way back in March 2012) and WildFly 8.0.0.Alpha1 is now the next release of the same project with the new name.
I know I already answered a variant of this question earlier, but I wanted to include the answer to this differently worded question too since I wanted it to be very clear that WildFly is just a rename of JBoss Application Server. It is not a new project. So WildFly 8.0.0.Alpha1 release is the continuation of the release cycle of the previously named JBoss Application Server project.
Now that we have addressed what WildFly is and a history around the name change, let's focus on the release itself. Some time back, Jason, the project lead of WildFly, listed down the goals of WildFly 8 release in the 2 dev mailing list threads here:
Like Jason noted in the WildFly 8 release schedule thread, we plan to push out a release almost every other month with the goal of having a 8.0.0.Final version at the end of this year. So, like with all the help that the community provided during AS7 releases:
Community help for JBoss AS 7.0 release - https://community.jboss.org/thread/169491
Community help for JBoss AS 7.1 release - https://community.jboss.org/thread/195430
please continue to do the same for WildFly releases.
In the coming weeks/months, we plan to blog more about the WildFly releases and the technologies that the WildFly runtime supports. In fact, Jason has asked in this dev mailing list thread http://lists.jboss.org/pipermail/wildfly-dev/2013-May/000144.html whether the community members will be willing to blog too. That's another way of contributing too. So if you have any blogs that you have written or plan to write on WildFly, do let us know about it in that thread.
Thanks for noticing! That's the logo for WildFly which the jboss.org team of artists (yeah, we do have team for that) helped us come up with :) Like it?
So what's WildFly?
WildFly is the new name for the community project which was previously known as JBoss Application Server. Late in 2012, we decided that we had to rename the community project, JBoss Application Server, to something else. As part of that (long drawn out) process, community members were asked to suggest new names and a few selected names were voted to select the new name. Ultimately, WildFly turned out to be the winner.
Why did we change the name?
JBoss Application Server (both the name and the project) has been a very popular project over the years. Initially when it started off, it was known simply as JBoss. Anytime anyone referred to the name JBoss, people knew that they were talking about the JBoss Application Server community edition. Over the years though, the reference started to get hazy. The community edition JBoss Application Server also has a paid and fully supported version known as JBoss Enterprise Application Platform (JBoss EAP). Notice the "JBoss" name in there? So there's JBoss Application Server community edition and then there's JBoss EAP paid version. It did not stop there! Over the years, various community projects hosted at jboss.org started naming their projects with the name "JBoss" in it. So there was "JBoss ESB", "JBoss Transactions", "JBoss Messaging" and many such projects with the name "JBoss" in it. It's certainly no fault of those projects that they used "JBoss" as part of the name. It did make sense to use that name, since those projects were developed by JBoss community members. By the way, did you just notice the name "JBoss" even means a reference to the JBoss community as a whole?
So I guess at this point you might have realized where I'm headed with all this historical evidence. Clearly, the name "JBoss" had started to mean much more than just the JBoss Application Server community project. Although it was good thing from a brand point of view, it clearly wasn't too good from various other aspects. We had started seeing too much confusion about what each project/product stood for not just from a name point of view but also a release roadmap point of view. Take for example JBoss Application Server and JBoss EAP - users, typically those who are more busy with their application (rightly so) than trying to understand what each variant of project/product with the name "JBoss" in it meant, were just not sure which one to pick and which release of those had what features in it. Of course, it would take some explanation to help them understand this, but doing this on a regular basis was a clear sign that this isn't the right way forward.
So slowly during the past few years, there has been a conscious decision not to name new projects with "JBoss" in its name and also to rename some of the existing projects wherever possible. So for example, when "JBoss Messaging" project decided to release a completely new and better version, the project decided to name it "HornetQ". Similarly, JBoss Transactions is now known as Narayana. There are various examples of such renames and new names. Obviously, doing the same for JBoss Application Server would need some time and extra efforts since it was a really huge change for various reasons. But it had to be done ultimately and that's why it's now WildFly.
So what happens to the "JBoss" name in JBoss EAP?
The rename is only for the JBoss Application Server community edition. The paid version is still named JBoss Enterprise Application Platform (JBoss EAP). Since one of the original intentions of the rename was to clear the confusion between JBoss Application Server community edition and similar named JBoss EAP, the name change only applies to the community edition. So ultimately, over time, when someone refers to WildFly, we clearly know they are talking about the community project and very specifically the application server project.
How does WildFly 8.0.0.Alpha1 release relate to the previous JBoss AS7 releases?
WildFly 8.0.0.Alpha1 is the continuation of the release cycle of the application server community edition, which was previously known as JBoss AS7. The last release of JBoss AS7 was 7.1.1.Final (way back in March 2012) and WildFly 8.0.0.Alpha1 is now the next release of the same project with the new name.
Is WildFly 8.0.0.Alpha1 a release of a new project?
I know I already answered a variant of this question earlier, but I wanted to include the answer to this differently worded question too since I wanted it to be very clear that WildFly is just a rename of JBoss Application Server. It is not a new project. So WildFly 8.0.0.Alpha1 release is the continuation of the release cycle of the previously named JBoss Application Server project.
What's new in 8.0.0.Alpha1 release?
Now that we have addressed what WildFly is and a history around the name change, let's focus on the release itself. Some time back, Jason, the project lead of WildFly, listed down the goals of WildFly 8 release in the 2 dev mailing list threads here:
WildFly 8 roadmap (proposal) - http://lists.jboss.org/pipermail/jboss-as7-dev/2013-March/007884.html
WildFly 8 Schedule - http://lists.jboss.org/pipermail/wildfly-dev/2013-May/000062.html
So those are the goals and the schedule for WildFly 8.
WildFly 8.0.0.Alpha1 is the first milestone towards that. The release contains some of the new Java EE7 features, a new web server implementation named Undertow (as a replacement to JBossWeb web server) and some other new features. Of course, it also contains numerous bug fixes and since the previous release was more than a year back, the number of bug fixes are huge. Jason has summarized the WildFly 8.0.0.Alpha1 release in the dev mailing thread here http://lists.jboss.org/pipermail/wildfly-dev/2013-May/000139.html.
Please download this new version and give it a try. Like always, any feedback, questions or asking for help is always welcome in our WildFly user forums.
So those are the goals and the schedule for WildFly 8.
WildFly 8.0.0.Alpha1 is the first milestone towards that. The release contains some of the new Java EE7 features, a new web server implementation named Undertow (as a replacement to JBossWeb web server) and some other new features. Of course, it also contains numerous bug fixes and since the previous release was more than a year back, the number of bug fixes are huge. Jason has summarized the WildFly 8.0.0.Alpha1 release in the dev mailing thread here http://lists.jboss.org/pipermail/wildfly-dev/2013-May/000139.html.
Please download this new version and give it a try. Like always, any feedback, questions or asking for help is always welcome in our WildFly user forums.
What's next for WildFly?
Like Jason noted in the WildFly 8 release schedule thread, we plan to push out a release almost every other month with the goal of having a 8.0.0.Final version at the end of this year. So, like with all the help that the community provided during AS7 releases:
Community help for JBoss AS 7.0 release - https://community.jboss.org/thread/169491
Community help for JBoss AS 7.1 release - https://community.jboss.org/thread/195430
please continue to do the same for WildFly releases.
In the coming weeks/months, we plan to blog more about the WildFly releases and the technologies that the WildFly runtime supports. In fact, Jason has asked in this dev mailing list thread http://lists.jboss.org/pipermail/wildfly-dev/2013-May/000144.html whether the community members will be willing to blog too. That's another way of contributing too. So if you have any blogs that you have written or plan to write on WildFly, do let us know about it in that thread.
Those of you who want to try out the nightly builds of WildFly, can get it from our continuous integration job mentioned here https://community.jboss.org/thread/224262.
By the way, what's that image at the beginning of this article?
Thanks for noticing! That's the logo for WildFly which the jboss.org team of artists (yeah, we do have team for that) helped us come up with :) Like it?
Friday, December 23, 2011
JBoss AS 7.1.0.CR1 "Flux Capacitor" released
It's been just one month since we released JBoss AS 7.1.0.Beta1. Within that one month we have been able to fix numerous issues in JBoss AS7, add more features and resolve various other JIRAs. As a result, we now have 7.1.0.CR1 "Flux Capacitor" available for downloads.
This new release contains around 378 resolved JIRAs. The highlights of this release include:
- EE6 Full Profile support is now feature complete. What this means is - all the features required for EE6 full profile support are now available in AS7.
- Various improvements in AS7 management
- Clustering improvement:
- Stateful session bean replication support
- Clustered SSO
Friday, September 23, 2011
JBoss AS 7.0.2 "Arc" released!
More good news on the JBoss AS7 front. JBoss AS 7.0.2.Final "Arc" has been released today! It's been one month since AS 7.0.1 was released. Within this short period of time there have been numerous bugs fixed and more features and improvements implemented. All these bug fixes and features have been included in this 7.0.2 release.
This new release mainly consists of the following features/improvements:
- JSF 2.1 Async
- EJB support
- Resurrected -b option for command line binding
- SSO support
- JNDI memory footprint improvement
- Limited support for Hibernate 3.3
Download the server binary from here and extract it to a folder of your choice. Start the standalone server using the standalone.sh (standalone.bat for Windows OS) script available in JBOSS_HOME/bin folder:
jpai@jpai-laptop:bin$ ./standalone.sh
...
18:45:36,893 INFO [org.jboss.as.remoting] (MSC service thread 1-3) Listening on /127.0.0.1:9999
18:45:37,030 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-4) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080
In the logs you'll notice that the server is being bound to 127.0.0.1 IP (by default). What this means is that all your services including the web access won't be accessible remotely from a different machine via the IP address or hostname of your machine.
As a quick check, access the following pages:
http://localhost:8080
http://localhost:9990
The first one is the default home page of your server and the second URL is the admin console. Now try accessing them using your machine's IP or hostname instead of localhost and you'll notice that they aren't accessible. Now let's see how we can enable access via your machine's IP or hostname.
Stop your running server and start it with the following command:
jpai@jpai-laptop:bin$ ./standalone.sh -b 10.67.2.193
...
18:47:24,588 INFO [org.jboss.as.remoting] (MSC service thread 1-1) Listening on /127.0.0.1:9999
18:47:24,818 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-2) Starting Coyote HTTP/1.1 on http--10.67.2.193-8080
Now you'll notice that the http interface (for your web applications) is now bound to 10.67.2.193 (the IP you passed). However, the management interface (on which the admin console is exposed) still binds to localhost. So now, you'll be able to access the AS home page (and your applications) at http://10.67.2.193:8080 and the admin console at http://localhost:9990
If you want to change the binding address for your management interface too, then you'll have to additionally use the -bmanagement option as follows:
jpai@jpai-laptop:bin$ ./standalone.sh -b 10.67.2.193 -bmanagement 10.67.2.193
...
18:48:56,295 INFO [org.jboss.as.remoting] (MSC service thread 1-2) Listening on /10.67.2.193:9999
18:48:56,654 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-1) Starting Coyote HTTP/1.1 on http--10.67.2.193-8080
As you can see the http interface and the management interface are now both bound to the IP address that you passed as a option to the startup script. So you'll now be able to access the home page at http://10.67.2.193:8080 and the admin console at http://10.67.2.193:9990. That's it!
So go get a fresh copy of 7.0.2 and start using it. If you run into any issues are have any suggestions, feel free to report them in our user forum.
Saturday, August 20, 2011
Deploy a Java EE application on OpenShift Express (with AS7 support)
During the past few years, I've been hearing about "cloud" services more and more. Initially I wasn't really curious to try them out. But a few months (a year?) back, I decided to see what it was all about. I have been involved with Java EE development for more than 7 years now, so I decided to see what it takes to deploy my Java EE application to the cloud. I set out looking for documentation and other usual blog articles and such. At that point, whichever cloud services I thought of trying out, would require me to provide my credit card details even to try out a trial application. I wasn't too keen to provide my credit card details just to try out a few applications of mine. So I kind of gave up on trying out my applications on cloud, although I kept reading about what other developers were doing to deploy their applications on cloud.
At about the same time, I came across this elaborate writeup on how one of the developers had setup his application involving Weld and JSF, on Google App Engine - Part1, Part2. The blog was well written and explained what was required to get your Java EE application up and running on a cloud service. But the important piece of information in those articles was that, users who had an application which was implemented as per Java EE standards (to be portable) had to change many of the application parts just to get them running on cloud. This was because many of the Java EE technologies weren't supported by the cloud service provider. This didn't look appealing to me. After all, what would I gain by doing that. So at that point, I as a Java EE developer, wasn't too interested in experimenting with deploying my application on cloud.
So here's what I did to be able to deploy my Java EE application which uses the technologies available in Java EE6 webprofile and which deploys fine on my local AS7 instance, to OpenShift Express. You might have already guessed that I'm no expert about OpenShift (or cloud services in general), so in this article doesn't have any advanced technical details, but contains more of a how-to on deploying Java EE applications to OpenShift Express.
So let's start then.
The "rhc-create-domain" is part of the client tool that you installed earlier. If you haven't yet installed those tools, then you won't be able to use these commands, so don't miss that step! The "rhc-create-domain" accepts a few more optional parameters. To see the list of accepted parameters, you can run the following command:
Note that the term "application" can be a bit confusing (atleast I found it a bit confusing) because all you are doing at this point is setting up JBoss AS7 server.
The command to create an application is rhc-create-app. The rhc-create-app accepts multiple options. For a complete list of options run:
The -a option lets you specify the name for your application. This name will be part of the URL that you use to access your application. If your application name is "foo" and (the previously created) domain name is "bar", then the URL to access your application will be http://foo-bar.rhcloud.com/.
The -t option in that command, specifies the application type. In our case, we are interested in jbossas-7.0
The other option of importance is the -r option which you'll use to point to a folder on your local filesystem where OpenShift will store all the data related to your application. Part of that data will be a local copy of the git repo (version control system). We'll see this in more detail later on in this blog.
So at this point, we have created a domain and then an application and have made sure that it's accessible to the world. In short, your cloud server is up and running and you can now deploy your Java EE applications to that server.
I chose the "kitchensink" application from those quick starts. The kitchensink application uses Java Persistence API (JPA) for persistence and by default uses the java:jboss/datasources/ExampleDS which is shipped by default by JBoss AS7. The ExampleDS uses H2 as its database.This is how the persistence.xml looks like:
After building the application, the deployable war is named jboss-as-kitchensink.war and is available on my local file system. My next step would be to deploy it my JBoss AS7 server which we have setup on the OpenShift Express cloud. Let's see how that's done.
In our case, we'll focus on how to deploy an already built Java EE application to your OpenShift Express cloud server. In the previous step, we built the jboss-as-kitchensink.war. Now, copy that war file to the "deployments" subfolder of your local git repository. In this case, it's /home/jpai/OpenShift/myapps/demo/deployments:
So with this "push" we have now deployed our application to the remote OpenShift Express JBoss AS7 server. The jboss-as-kitchensink.war will be deployed at the "jboss-as-kitchensink" web application context. So the URL to access the application will be http://jaikiran-jbossas.rhcloud.com/jboss-as-kitchensink. Go ahead and access that URL. The application does nothing fancy - it allows you to add a user name, email and phone number which will then be stored in the database.
Like I mentioned earlier, the kitchensink application uses ExampleDS datasource which is backed by H2 database. So all the data will be stored remotely in the H2 database.
Once this file is updated, save the changes and commit it to your local git repo:
So at this point we have now changed our kitchensink application to use MySQL database and have deployed it to our OpenShift Express AS7 server. So let's access the application URL again http://jaikiran-jbossas.rhcloud.com/jboss-as-kitchensink. As you see, that page now prominently displays our message about MySQL DB being used. Go ahead and try out that app by adding some dummy user information.
That's it! We have successfully deployed our application to OpenShift Express server and the application is available for use.
OpenShift Express User guide
OpenShift forums
OpenShift IRC #openshift on irc.freenode.net. The folks here are very helpful!
Scott Stark's blog. Scott's blogs contain a lot of useful information about AS7 on OpenShift and OpenShift in general. Scott's blog is definitely a must read!
At about the same time, I came across this elaborate writeup on how one of the developers had setup his application involving Weld and JSF, on Google App Engine - Part1, Part2. The blog was well written and explained what was required to get your Java EE application up and running on a cloud service. But the important piece of information in those articles was that, users who had an application which was implemented as per Java EE standards (to be portable) had to change many of the application parts just to get them running on cloud. This was because many of the Java EE technologies weren't supported by the cloud service provider. This didn't look appealing to me. After all, what would I gain by doing that. So at that point, I as a Java EE developer, wasn't too interested in experimenting with deploying my application on cloud.
Enter OpenShift!
But this month, the OpenShift announcement about being able to deploy your JBoss AS7 Java EE applications to cloud, caught my eye. By the way, I do work for RedHat and am part of the JBoss AS7 team, but I wasn't keeping a watch on what the OpenShift team was upto, so this announcement came as a pleasant surprise! So I decided to give it a try. After reading some of the documentation on the project site, I found out that OpenShift offers two different services. One was "OpenShift Express" and the other "OpenShift Flex". OpenShift Express is free to use (that was one more good news for me) while OpenShift Flex requires your Amazon EC2 credentials and you'll be charged for the EC2 usage (there's however a free trial going on currently). I decided to give OpenShift Express a try since it was free and suits my current needs of just trying out a quick and simple Java EE application deployment and access to that application.So here's what I did to be able to deploy my Java EE application which uses the technologies available in Java EE6 webprofile and which deploys fine on my local AS7 instance, to OpenShift Express. You might have already guessed that I'm no expert about OpenShift (or cloud services in general), so in this article doesn't have any advanced technical details, but contains more of a how-to on deploying Java EE applications to OpenShift Express.
So let's start then.
Sign up
The first step is to sign up here to create an account for yourself. The sign up just requires a valid email address to which your account details will be dispatched. On signing up, you'll receive a mail which contains a link to activate your account and will take you to the login screen. Login using the email id and password that you used to register.Get Access to OpenShift Express
So let's got the OpenShift Express page. On that page you will notice a "Get Access to Express" button on left hand side. Click on it to get access to "Express". You'll be notified (immediately) through a mail to the email id which you registered. Check the mail which will contain a link to a quick start guide, to help you get started with OpenShift Express.Install client tools
The quick start contains the instructions to get you started with the installation procedure. The first step includes installing a few client tools on your system to help you interact with OpenShift. Follow those instructions to install the client tools (I won't repeat them here, since it's well explained in that guide).Create a domain
Now once we have the client tools, we are now ready to setup our "domain" on the OpenShift cloud. Setting up a domain will create a unique domain name that you can use for your applications. The domain name will be part of the URL which you will use to access the application and which you'll publish to your users for access. The command to create the domain is easy: rhc-create-domain -l <email-id-you-registered-with> -n <domain-name-of-your-choice>
The "rhc-create-domain" is part of the client tool that you installed earlier. If you haven't yet installed those tools, then you won't be able to use these commands, so don't miss that step! The "rhc-create-domain" accepts a few more optional parameters. To see the list of accepted parameters, you can run the following command:
rhc-create-domain --help
Create a jbossas-7.0 application
Once you have successfully create a domain, your next step is to create an "application". Currently OpenShift Express supports different "types" of applications, each of them backed by Git (which is a version control system). At the point of writing this post, the supported application types are jbossas-7.0, perl-5.10, rack-1.1, wsgi-3.2 and php-5.3. I'm interested in deploying a Java EE application, so I'll be creating a "jbossas-7.0" application. This type of application provides you a JBoss AS 7.0.0 instance in the OpenShift cloud to which you can deploy your applications. So let's now create an application of type jbossas-7.0.Note that the term "application" can be a bit confusing (atleast I found it a bit confusing) because all you are doing at this point is setting up JBoss AS7 server.
The command to create an application is rhc-create-app. The rhc-create-app accepts multiple options. For a complete list of options run:
rhc-create-app --help
rhc-create-app -a <application-name> -l <email-id-you-used-to-register> -t jbossas-7.0 -r <path-on-local-filesystem-for-the-repository>
The -a option lets you specify the name for your application. This name will be part of the URL that you use to access your application. If your application name is "foo" and (the previously created) domain name is "bar", then the URL to access your application will be http://foo-bar.rhcloud.com/.
The -t option in that command, specifies the application type. In our case, we are interested in jbossas-7.0
The other option of importance is the -r option which you'll use to point to a folder on your local filesystem where OpenShift will store all the data related to your application. Part of that data will be a local copy of the git repo (version control system). We'll see this in more detail later on in this blog.
Access your server URL
So once you run the command and it successfully completes, it will print out the URL where the application is available. You can (immediately) use that URL to access the application. On accessing that URL you'll notice a welcome page, which is an indication that the application has been installed successfully and available for access. For me, the URL to the newly created application was http://jaikiran-jbossas.rhcloud.com/.So at this point, we have created a domain and then an application and have made sure that it's accessible to the world. In short, your cloud server is up and running and you can now deploy your Java EE applications to that server.
Create and deploy a Java EE application
So let's now move to the step of creating and deploying a Java EE application. I didn't have any specific application in mind, but wanted to deploy an application which would involve accessing a database. Instead of creating a brand new application, I decide to use one of the quick start applications that come with JBoss AS7. The quick start applications for JBoss AS7 are available for download here. Once you have downloaded the quick start archive, unzip it to a location of your choice. Building the quick start examples will require Maven build tool be installed on your system. The details about the quick start applications and how to build them can be found here. Those interested in trying it out themselves, might want to look at that guide.I chose the "kitchensink" application from those quick starts. The kitchensink application uses Java Persistence API (JPA) for persistence and by default uses the java:jboss/datasources/ExampleDS which is shipped by default by JBoss AS7. The ExampleDS uses H2 as its database.This is how the persistence.xml looks like:
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="primary">
<!-- If you are running in a production environment, add a managed
data source, the example data source is just for proofs of concept! -->
<jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
<properties>
<!-- Properties for Hibernate -->
<property name="hibernate.hbm2ddl.auto" value="create-drop" />
<property name="hibernate.show_sql" value="false" />
</properties>
</persistence-unit>
</persistence>
After building the application, the deployable war is named jboss-as-kitchensink.war and is available on my local file system. My next step would be to deploy it my JBoss AS7 server which we have setup on the OpenShift Express cloud. Let's see how that's done.
Deploy the application to OpenShift Express
Remember, while creating the "application" using the rhc-create-app command, we used the -r option to point to a folder on our local file system to create a local copy of the application repository. That's the place which will be used now for deploying our applications. In my case, I used /home/jpai/OpenShift/myapps/demo as the repo location. This is how that folder looks like: demo
|
|--- deployments
|
|--- pom.xml
|
|--- README
|
|--- src
In our case, we'll focus on how to deploy an already built Java EE application to your OpenShift Express cloud server. In the previous step, we built the jboss-as-kitchensink.war. Now, copy that war file to the "deployments" subfolder of your local git repository. In this case, it's /home/jpai/OpenShift/myapps/demo/deployments:
cp /home/jpai/jboss-as-quickstarts-7.0.0.Final/kitchensink/target/jboss-as-kitchensink.war /home/jpai/OpenShift/myapps/demo/deployments
jpai@jpai-laptop:demo$ git add deployments/jboss-as-kitchensink.war
jpai@jpai-laptop:demo$ git commit -m "Deploy kitchensink application" deployments/jboss-as-kitchensink.war
[master 1637c21] Deploy kitchensink application
1 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 deployments/jboss-as-kitchensink.war
jpai@jpai-laptop:openshift$ git push origin master
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 393.71 KiB, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: Stopping application...
remote: done
remote: Found .openshift/config/standalone.xml... copying to ...
....
....
....
remote: Starting application...done
To ssh://6a7ff43a6c2246999de28219a5aaa4ae@jaikiran-jbossas.rhcloud.com/~/git/jaikiran.git/
6e57976..1637c21 master -> master
So with this "push" we have now deployed our application to the remote OpenShift Express JBoss AS7 server. The jboss-as-kitchensink.war will be deployed at the "jboss-as-kitchensink" web application context. So the URL to access the application will be http://jaikiran-jbossas.rhcloud.com/jboss-as-kitchensink. Go ahead and access that URL. The application does nothing fancy - it allows you to add a user name, email and phone number which will then be stored in the database.
Like I mentioned earlier, the kitchensink application uses ExampleDS datasource which is backed by H2 database. So all the data will be stored remotely in the H2 database.
Using the MySQL database available in OpenShift Express
OpenShift Express sets up a MySQL datasource template for you when you create a jbossas-7.0 application type. The details of the database can be found in the <path-to-local-repo>/.openshift/config/standalone.xml: <subsystem xmlns="urn:jboss:domain:datasources:1.0">
<datasources>
<datasource jndi-name="java:jboss/datasources/ExampleDS" enabled="true" use-java-context="true" pool-name="H2DS">
<connection-url>jdbc:h2:${jboss.server.data.dir}/test;DB_CLOSE_DELAY=-1</connection-url>
<driver>h2</driver>
<pool></pool>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
<validation></validation>
<timeout></timeout>
<statement></statement>
</datasource>
<datasource jndi-name="java:jboss/datasources/MysqlDS" enabled="false" use-java-context="true" pool-name="MysqlDS">
<connection-url>jdbc:mysql://127.1.1.1:3306/mysql</connection-url>
<driver>mysql</driver>
<security>
<user-name>admin</user-name>
<password>changeme</password>
</security>
</datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
<driver name="mysql" module="com.mysql.jdbc">
<xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
</driver>
</drivers>
</datasources>
</subsystem>
jpai@jpai-laptop:openshift$ rhc-ctl-app -a <application-name> -l <email-id-we-used-to-register> -e add-mysql-5.1
RESULT:
Mysql 5.1 database added. Please make note of these credentials:
Root User: admin
Root Password: as43n34023n
Connection URL: mysql://127.1.1.1:3306/
<datasource jndi-name="java:jboss/datasources/MysqlDS" enabled="true" use-java-context="true" pool-name="MysqlDS">
<connection-url>jdbc:mysql://127.1.1.1:3306/mysql</connection-url>
<driver>mysql</driver>
<security>
<user-name>admin</user-name>
<password>as43n34023n</password>
</security>
</datasource>
Once this file is updated, save the changes and commit it to your local git repo:
jpai@jpai-laptop:demo$ git commit -m "Enable the MysqlDS and fix the password" ./
[master dd7b58a] Fix the datasource password
1 files changed, 1 insertions(+), 1 deletions(-)
Push these changes to remote repo:
jpai@jpai-laptop:openshift$ git push origin master
Counting objects: 9, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 494 bytes, done.
Total 5 (delta 2), reused 0 (delta 0)
remote: Stopping application...
remote: done
....
.....
remote: Starting application...done
To ssh://6a7ff43a6c2246999de28219a5aaa4ae@jaikiran-jbossas.rhcloud.com/~/git/jaikiran.git/
2d38fa8..dd7b58a master -> master
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="primary">
<!-- Changed to use MysqlDS -->
<jta-data-source>java:jboss/datasources/MysqlDS</jta-data-source>
<properties>
<!-- Properties for Hibernate -->
<property name="hibernate.hbm2ddl.auto" value="create-drop" />
<property name="hibernate.show_sql" value="false" />
</properties>
</persistence-unit>
</persistence>
<h3>
<span style="color: red;">
This application uses MySQL database as its persistence store
</span>
</h3>
jpai@jpai-laptop:kitchensink$ cp target/jboss-as-kitchensink.war /home/jpai/OpenShift/myapps/demo/deployments
jpai@jpai-laptop:demo$ git commit -m "Use MySQL database for kitchensink application" ./
[master ded2445] Use MySQL database for kitchensink application
1 files changed, 0 insertions(+), 0 deletions(-)
jpai@jpai-laptop:openshift$ git push origin master
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 1.35 KiB, done.
Total 4 (delta 2), reused 0 (delta 0)
remote: Stopping application...
remote: done
remote: Found .openshift/config/standalone.xml... copying to...
...
...
...
remote: Starting application...done
To ssh://6a7ff43a6c2246999de28219a5aaa4ae@jaikiran-jbossas.rhcloud.com/~/git/jaikiran.git/
1637c21..ded2445 master -> master
jpai@jpai-laptop:demo$
So at this point we have now changed our kitchensink application to use MySQL database and have deployed it to our OpenShift Express AS7 server. So let's access the application URL again http://jaikiran-jbossas.rhcloud.com/jboss-as-kitchensink. As you see, that page now prominently displays our message about MySQL DB being used. Go ahead and try out that app by adding some dummy user information.
That's it! We have successfully deployed our application to OpenShift Express server and the application is available for use.
Summary
It's been a pleasant experience so far with OpenShift. I plan to try out a few more things with OpenShift, in the coming days and blog about any interesting details.Useful resources
While working on deploying this application, I had to use some documents and help from the OpenShift community to understand how this is all setup,. Here's a list of useful resources related to OpenShift in general:OpenShift Express User guide
OpenShift forums
OpenShift IRC #openshift on irc.freenode.net. The folks here are very helpful!
Scott Stark's blog. Scott's blogs contain a lot of useful information about AS7 on OpenShift and OpenShift in general. Scott's blog is definitely a must read!
Where to look for help
OpenShift questions in general are answered in the OpenShift forums. For questions around AS7 on OpenShift, the best place to ask questions is the JBoss Cloud Group.
Labels:
as7,
as7_openshift,
javaee,
javaee6,
JBoss,
jboss_application_server7,
jbossas,
jbossas7,
openshift,
openshift_express
Friday, August 19, 2011
JBoss AS 7.0.1 - Configuring EJB3 Pools
Now that AS 7.0.1 has been released, let's take a look at what new EJB3 features are available. Like I mentioned in my previous post AS 7.0.1 now allows you to configure pools for your stateless session beans and MDBs. Currently we allow configuring the pools at the subsystem level, which means that the pool will be applicable for all the beans deployed on the server. In some upcoming release, we'll allow configuring the pools at individual deployment and individual bean level. Let's, for now, see how the configuration looks like at the subsystem level.
In my previous post I mentioned that AS 7.0.1 has 2 distributions. One which is purely webprofile and the other (named "everything") has additional EE features like support for MDBs. In this post, I'll be using the "Everything" distribution and the JBOSS_HOME/standalone/configurations/standalone-preview.xml for explaining the configurations.
Before we begin with the configurations, for those of you who are new to AS7, let's just see how to start the server using a specific configuration file. First, download the server and the unzip the binary in a folder of your choice. Then from the command prompt, move to the "bin" folder of the installation. Within this folder, you will see a standalone.bat/standalone.sh and domain.bat/domain.sh. We'll be concentrating on the standalone server in this post, but the same applies to the EJB3 subsystem in the domain configurations.
A strict max pool allows you to configure a maximum upper limit for the pool. At runtime, when all the bean instances from the pool are in use and a new bean invocation request comes in, the pool blocks the request till the next bean instance is available or till a timeout (set in instance-acquisition-timeout) is reached. Each pool has a unique name. The configurations above show 2 strict max pools named "slsb-strict-max-pool" and "mdb-strict-max-pool". You can add a new strict max pool in there and set a unique name of your choice to it. You can either edit the xml by hand (when the server is down) to add a new strict max pool or you can use the Command Line Client (CLI) that comes with AS7. We'll see how to use the CLI, later in this post.
Once you are connected to the server from the CLI, you can now run operations from the CLI to manage your running server. Let's now see how we can manage the bean instance pool configurations for EJB3 subsystem.
An important thing to note is that you don't have to type all of that on the CLI. The CLI provides a very (very) useful tab completion feature! So typing in /subsystem= and pressing the tab will show you the available options.
Now the "add" operation will have to be executed on a particular "resource". i.e. the server has to know what to add and where. This is known as addressing. In order to run an operation, an address needs to be provided (don't confuse this with the hostname/port "address" of the server, that's completely different). In AS7 management terms, the server is made up of manageable "resources" and each resource has a address of its own. For example, each of the subsystems that make up the server configuration can be addressed. To refer to the ejb3 subsystem from the command line client, you use /subsystem=ejb3 (you can use the tab completion).
Let's say our new pool that we are creating is going to be named "new-pool". So ultimately the address at which the "add" operation needs to be carried out would look like:
After running that operation, you can now open the standalone-preview.xml in a text editor and notice that a new strict max bean instance pool, named "new-pool" has been added to the "bean-instance-pools":
So that's how you create a new bean instance pool from the CLI.
Let's first see how it's done for MDBs:
So, if you know disabling the pooling benefits you, then that's how you can disable it.
I plan to write some more blog posts in the upcoming days, to explain some other features of AS7 and/or EJB3 in AS7. If you have any questions or run into issues, please visit us in our user forums.
In my previous post I mentioned that AS 7.0.1 has 2 distributions. One which is purely webprofile and the other (named "everything") has additional EE features like support for MDBs. In this post, I'll be using the "Everything" distribution and the JBOSS_HOME/standalone/configurations/standalone-preview.xml for explaining the configurations.
Before we begin with the configurations, for those of you who are new to AS7, let's just see how to start the server using a specific configuration file. First, download the server and the unzip the binary in a folder of your choice. Then from the command prompt, move to the "bin" folder of the installation. Within this folder, you will see a standalone.bat/standalone.sh and domain.bat/domain.sh. We'll be concentrating on the standalone server in this post, but the same applies to the EJB3 subsystem in the domain configurations.
Starting the standalone server
So let's start the server. I'm on a Linux system, so I'll use the standalone.sh file. Those of you on Windows, will have to use standalone.bat. jpai@jpai-laptop:bin$ ./standalone.sh
jpai@jpai-laptop:bin$ ./standalone.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /NotBackedUp/jpai/jboss-as-7.0.1.Final
JAVA: /opt/Java/SunJava-6/jdk1.6.0_21//bin/java
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman
=========================================================================
09:30:31,537 INFO [org.jboss.modules] JBoss Modules version 1.0.1.GA
09:30:31,765 INFO [org.jboss.msc] JBoss MSC version 1.0.0.GA
09:30:31,818 INFO [org.jboss.as] JBoss AS 7.0.1.Final "Zap" starting
09:30:32,618 WARN [org.jboss.as] No security realm defined for native management service, all access will be unrestricted.
09:30:32,693 INFO [org.jboss.as] creating http management service using network interface (management) port (9990)
09:30:32,694 WARN [org.jboss.as] No security realm defined for http management service, all access will be unrestricted.
09:30:32,703 INFO [org.jboss.as.logging] Removing bootstrap log handlers
09:30:32,720 INFO [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
09:30:32,739 INFO [org.jboss.as.clustering.infinispan.subsystem] (Controller Boot Thread) Activating Infinispan subsystem.
09:30:32,905 INFO [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
09:30:32,915 INFO [org.jboss.as.naming] (MSC service thread 1-1) Starting Naming Service
09:30:32,918 INFO [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
09:30:32,940 INFO [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
09:30:32,957 INFO [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.2.0.Beta2
09:30:32,968 INFO [org.xnio] (MSC service thread 1-4) XNIO Version 3.0.0.Beta3
09:30:32,982 INFO [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.0.0.Beta3
09:30:33,182 INFO [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-4) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /opt/Java/SunJava-6/jdk1.6.0_21/jre/lib/i386/server:/opt/Java/SunJava-6/jdk1.6.0_21/jre/lib/i386:/opt/Java/SunJava-6/jdk1.6.0_21/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib
09:30:33,203 INFO [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-2) Starting remote JMX connector
09:30:33,209 INFO [org.jboss.as.remoting] (MSC service thread 1-1) Listening on /127.0.0.1:9999
09:30:33,232 INFO [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
09:30:33,390 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-4) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080
09:30:33,512 INFO [org.jboss.as.connector] (MSC service thread 1-1) Starting JCA Subsystem (JBoss IronJacamar 1.0.3.Final)
09:30:33,554 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) Bound data source [java:jboss/datasources/ExampleDS]
09:30:33,919 INFO [org.jboss.as.deployment] (MSC service thread 1-4) Started FileSystemDeploymentService for directory /NotBackedUp/jpai/jboss-as-7.0.1.Final/standalone/deployments
09:30:33,931 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.1.Final "Zap" started in 2636ms - Started 93 of 148 services (55 services are passive or on-demand)
Using a different server configuration file
The standalone.sh command by default uses a configuration file named "standalone.xml" which is present in JBOSS_HOME/standalone/configuration folder. The command also allows you to specify a different configuration file, to start the server. Like I mentioned, earlier, I'll be using the standalone-preview.xml in this post. So let's start the server using the standalone-preview.xml. jpai@jpai-laptop:bin$ ./standalone.sh -server-config=standalone-preview.xml
09:35:59,694 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.1.Final "Zap" started in 3586ms - Started 125 of 184 services (59 services are passive or on-demand)
EJB3 subsystem configurations
Now that we have seen how to startup the server, let's move on to see the configurations. In the standalone-preview.xml, look for the EJB3 subsystem which looks like this: <subsystem xmlns="urn:jboss:domain:ejb3:1.1" >
<timer-service>
<thread-pool core-threads="1" max-threads="4" />
<data-store path="timer-service-data" relative-to="jboss.server.data.dir" />
</timer-service>
<!-- EJB3 pools -->
<pools>
<bean-instance-pools>
<strict-max-pool name="slsb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5"
instance-acquisition-timeout-unit="MINUTES"/>
<strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5"
instance-acquisition-timeout-unit="MINUTES"/>
</bean-instance-pools>
</pools>
<!-- Default MDB configurations -->
<mdb>
<resource-adapter-ref resource-adapter-name="hornetq-ra"/>
<bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
</mdb>
<!-- Session bean configurations -->
<session-bean>
<stateless>
<bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
</stateless>
</session-bean>
</subsystem>
EJB3 Pools
The next piece of configuration is the "pools": <!-- EJB3 pools -->
<pools>
<bean-instance-pools>
<strict-max-pool name="slsb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5"
instance-acquisition-timeout-unit="MINUTES"/>
<strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5"
instance-acquisition-timeout-unit="MINUTES"/>
</bean-instance-pools>
</pools>
A strict max pool allows you to configure a maximum upper limit for the pool. At runtime, when all the bean instances from the pool are in use and a new bean invocation request comes in, the pool blocks the request till the next bean instance is available or till a timeout (set in instance-acquisition-timeout) is reached. Each pool has a unique name. The configurations above show 2 strict max pools named "slsb-strict-max-pool" and "mdb-strict-max-pool". You can add a new strict max pool in there and set a unique name of your choice to it. You can either edit the xml by hand (when the server is down) to add a new strict max pool or you can use the Command Line Client (CLI) that comes with AS7. We'll see how to use the CLI, later in this post.
Message driven bean configurations
Let's now move to the next configurations in that EJB3 subsystem: <!-- Default MDB configurations -->
<mdb>
<resource-adapter-ref resource-adapter-name="hornetq-ra"/>
<bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
</mdb>
Default resource adapter for MDBs
The "resource-adapter-ref" element specifies the default resource-adapter which will be used by the MDBs. In this example, it shows that we use hornetq-ra as the default RA.Default bean instance pool for MDBs
The bean-instance-pool-ref acts as a reference to a bean-instance-pool, which will be used as the default pool configuration for all MDBs. In this example, we see that it points to "mdb-strict-max-pool" which we saw in the earlier section was configured as a strict max pool with 20 as the upper limit for the pool. If you want to change the default bean instance pool for MDBs, then just change the pool-name attribute of the bean-instance-pool-ref element to some other bean instance pool that's available. You can either do it by editing the xml directly (when the server is down) or use the CLI to do this (we'll see how that's done, later).Stateless session bean configurations
Moving on to the next section in the EJB3 configurations, you'll see: <!-- Session bean configurations -->
<session-bean>
<stateless>
<bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
</stateless>
</session-bean>
Using the Command Line Client (CLI)
AS7 comes with a powerful command line client. Check the AS7 documentation on CLI for a quick reference. The command line client tool is started using the jboss-admin.sh/jboss-admin.bat scripts that are available in the JBOSS_HOME/bin folder: jpai@jpai-laptop:bin$ ./jboss-admin.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /]
[disconnected /] connect
Connected to standalone controller at localhost:9999
[standalone@localhost:9999 /]
Once you are connected to the server from the CLI, you can now run operations from the CLI to manage your running server. Let's now see how we can manage the bean instance pool configurations for EJB3 subsystem.
Create a new strict max bean instance pool from the CLI
After you have connected to the server from the CLI, you can create a new strict max bean instance pool as follows: [standalone@localhost:9999 /] /subsystem=ejb3/strict-max-bean-instance-pool=new-pool:add
An important thing to note is that you don't have to type all of that on the CLI. The CLI provides a very (very) useful tab completion feature! So typing in /subsystem= and pressing the tab will show you the available options.
Understanding the bean instance pool creation command
From the CLI documentation:An operation request basically consists of three parts: The address, an operation name and an optional set of parameters.In this example, our goal is to create a new strict max bean instance pool. This can be done by issuing a "add" operation. In the command that I posted above, notice the use of ":add" at the end. An operation always starts with a ":" followed by the operation name. So in the example above, we are issuing the ":add" operation.
The formal specification for an operation request is:
[/node-type=node-name (/node-type=node-name)*] : operation-name [( [parameter-name=parameter-value (,parameter-name=parameter-value)*] )]
Now the "add" operation will have to be executed on a particular "resource". i.e. the server has to know what to add and where. This is known as addressing. In order to run an operation, an address needs to be provided (don't confuse this with the hostname/port "address" of the server, that's completely different). In AS7 management terms, the server is made up of manageable "resources" and each resource has a address of its own. For example, each of the subsystems that make up the server configuration can be addressed. To refer to the ejb3 subsystem from the command line client, you use /subsystem=ejb3 (you can use the tab completion).
Let's say our new pool that we are creating is going to be named "new-pool". So ultimately the address at which the "add" operation needs to be carried out would look like:
/subsystem=ejb3/strict-max-bean-instance-pool=new-pool
[standalone@localhost:9999 /] /subsystem=ejb3/strict-max-bean-instance-pool=new-pool:add
[standalone@localhost:9999 /] /subsystem=ejb3/strict-max-bean-instance-pool=new-pool:add
{"outcome" => "success"}
After running that operation, you can now open the standalone-preview.xml in a text editor and notice that a new strict max bean instance pool, named "new-pool" has been added to the "bean-instance-pools":
<pools>
<bean-instance-pools>
<strict-max-pool name="slsb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
<strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
<strict-max-pool name="new-pool"/>
</bean-instance-pools>
</pools>
[standalone@localhost:9999 /] /subsystem=ejb3/strict-max-bean-instance-pool=take2:add(max-pool-size=15,timeout=2)
[standalone@localhost:9999 /] /subsystem=ejb3/strict-max-bean-instance-pool=take2:add(max-pool-size=15,timeout=2)
{"outcome" => "success"}
<pools>
<bean-instance-pools>
<strict-max-pool name="slsb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
<strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
<strict-max-pool name="new-pool"/>
<strict-max-pool name="take2" max-pool-size="15" instance-acquisition-timeout="2"/>
</bean-instance-pools>
</pools>
So that's how you create a new bean instance pool from the CLI.
Setting/changing the default bean instance pool used by the MDBs and the SLSBs
In the previous section we saw how to create a new bean instance pool. Now if we want this new pool to be our default pool configuration for MDBs and/or SLSBs, then we can use the CLI to do that.Let's first see how it's done for MDBs:
[standalone@localhost:9999 /] /subsystem=ejb3:write-attribute(name=default-mdb-instance-pool, value=take2)
[standalone@localhost:9999 /] /subsystem=ejb3:write-attribute(name=default-mdb-instance-pool, value=take2)
{"outcome" => "success"}
<mdb>
<resource-adapter-ref resource-adapter-name="hornetq-ra"/>
<bean-instance-pool-ref pool-name="take2"/>
</mdb>
[standalone@localhost:9999 /] /subsystem=ejb3:write-attribute(name=default-slsb-instance-pool, value=new-pool)
{"outcome" => "success"}
<session-bean>
<stateless>
<bean-instance-pool-ref pool-name="new-pool"/>
</stateless>
</session-bean>
Disabling pooling for MDBs and Stateless Session Beans
We also allow pooling to be disabled for MDBs and SLSBs. However, it's not always recommended since it can have performance impacts. If as a developer, you know that your beans aren't too heavy during construction (i.e. nothing in constructor and nothing in @PostConstruct), then it sometimes help to disable pooling for the beans. Currently the only way to do this, is by removing the <bean-instance-pool-ref> element from the <mdb> and/or <stateless> elements in the EJB3 subsystem configuration. We don't currently have a way to do this via the CLI nor do we have a way to specify this at per deployment or per bean level.So, if you know disabling the pooling benefits you, then that's how you can disable it.
Summary
I hadn't thought that this blog would get this lengthy. But since most of this is new in AS7, it was worth writing this up. So, in this blog we saw how and where the EJB3 bean instance pools are configured, how to create new bean instance pools, how to change the default bean instance pools for MDBs and Stateless session beans. We also saw how all of this can be done using the CLI in AS7.I plan to write some more blog posts in the upcoming days, to explain some other features of AS7 and/or EJB3 in AS7. If you have any questions or run into issues, please visit us in our user forums.
Subscribe to:
Posts (Atom)
