I have moved my blog to blog.dechateau.nl.
A few interesting posts are available from that address now as well; the rest will be kept here for the time being.
Thursday, March 9, 2017
Sunday, February 19, 2017
Will Java EE 8 meet its schedule?
What's currently the scope of Java EE 8?
Last September, Oracle revealed the changed plans for Java EE 8 during the JavaOne conference: to be more relevant with the currently ongoing 'Cloud' trend, and with an ambitious time schedule that includes a final release in the second half of 2017 (yes, that's this year!). It was communicated as a proposal, and the final decision would not be taken before a new Community Survey was kept. When the results came in late December (details here), the resemblance with the proposed changes was striking...In short, this is what it boiled down to:
- Servlet 4.0, JAX-RS 2.1, JSON-B 1.0 en JSON-P 1.1 received enough votes to remain in the planning unchanged
- JSF 2.3, CDI 2.0 and the late-to-the-party Bean Validation 2.0 were not part of the technologies that were surveyed, but it was decided that enough progress was made to keep them in
- In the results, support for OAuth and OpenID Connect was relatively high in demand, but these will not be included in Java EE 8 in order not to jeopardize the planning; Security API 1.0 is in, however, but with a different scope
- Management 2.0 and JMS 2.1 were deemed irrelevant, so these updates were withdrawn, and the existing versions are kept
- MVC 1.0 scored rather low as well, and will be transferred to the community as a 'stand-alone component'
- Even though they were introduced/proposed at JavaOne, Configuration en Health Checking will be postponed to another version as well, to keep the schedule feasible
Is the development of the various JSRs on track?
During the half year since JavaOne, there could clearly be more activity detected than in the period before that, when work seemed all but abandoned for most JSRs. But is this sufficient to meet the deadline? Not a single 'final draft' is published, so none of the standards will be finished early.JSON-B seems to be in the best shape, the ballot for the 'public review' was passed successfully in August. JSON-P, JSF and CDI have just entered the 'public review' period, and the remaining five are at some point of the 'early drafts' stage.
I tried to plot the various JSRs and their 'position' regarding the JCP process:
It seems that there is plenty of work to be done to make sure that all of the nine JSRs that make up Java EE 8 will be ready for a 'final release' before the end of the year.
So, if you're interested in helping out, go to your local JUG and join their Adopt-a-JSR program! If such a program is not in place yet, help them get one started!
Oh, and if you happen to be living in the Netherlands: contact us at jcp@nljug.org, and we'll assist you in getting your contributions where they count!
Sunday, June 8, 2014
Use Apache 2.4.x as a secure reverse proxy for JBoss Wildfly
Quite some time ago, I wrote a post about using Apache as a secure reverse proxy for JBoss AS5. The development of both web servers and application servers has not come to a stand-still, so I felt it was time for a follow-up - not in the least because I have to configure such a set-up again myself.
This time around, Apache httpd has advanced to version 2.4 (the Ubuntu distro I'm using, 14.04 LTS, comes with version 2.4.7; the latest version available is 2.4.9); the JBoss application server has been going through versions AS6, AS7 and finally - reflecting a new naming scheme - Wildfly8 (I'm using version 8.1.0.Final).
For me, Apache is installed in
Note: The JBoss documentation expresses a preference for mod_cluster when putting the app server behind an Apache. However, this component is - as far as I can tell - only available for httpd 2.2.x (x >= 8), and trying to included the precompiled modules in an httpd 2.4 led to errors.
I decided to keep the default Apache installation and use mod_proxy_ajp instead; that was possible since I didn't need the advantages mod_cluster advertises to have over its alternatives.
This time around, Apache httpd has advanced to version 2.4 (the Ubuntu distro I'm using, 14.04 LTS, comes with version 2.4.7; the latest version available is 2.4.9); the JBoss application server has been going through versions AS6, AS7 and finally - reflecting a new naming scheme - Wildfly8 (I'm using version 8.1.0.Final).
For me, Apache is installed in
/etc/apache2/
, and you may install Wildfly anywhere (I'll use {$wildfly-home-dir}
to denote the path).Note: The JBoss documentation expresses a preference for mod_cluster when putting the app server behind an Apache. However, this component is - as far as I can tell - only available for httpd 2.2.x (x >= 8), and trying to included the precompiled modules in an httpd 2.4 led to errors.
I decided to keep the default Apache installation and use mod_proxy_ajp instead; that was possible since I didn't need the advantages mod_cluster advertises to have over its alternatives.
Securing the connection
To enable SSL security on the connection, enable the following parts in the
/etc/apache2
directory by creating a symbolic link in the *-enabled
subdirectories that point to the *-available
subdirectories:/etc/apache2/mods-enabled$ sudo ln -s ../mods-available/ssl.conf
/etc/apache2/mods-enabled$ sudo ln -s ../mods-available/ssl.load
/etc/apache2/mods-enabled$ sudo ln -s ../mods-available/socache_shmcb.load
/etc/apache2/mods-enabled$ sudo ln -s ../mods-available/rewrite.load
/etc/apache2/sites-enabled$ sudo ln -s ../sites-available/default-ssl.conf
To make sure that all calls are made secure, redirect calls to the normal HTTP endpoints by adding an appropriate entry in the default virtual host configuration:
- In
/etc/apache2/sites-enabled/000-default.conf
:
RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Note 1: The preferred
RedirectPermanent
directive didn't seem to work properly for me. Maybe I just mis-configured something for that.
Note 2: An official SSL certificate needs to be purchased and installed to remove the warning browsers issue when landing on a page on the server. I'm not delving deeper into this issue here, see the mod_ssl description for details.
Enable the AJP protocol in Wildfly
To be accessible for the calls through the reverse proxy, Wildfly must expose a port on which it listens for traffic following the AJP protocol.
- Add an entry to the
{$wildfly-home-dir}/standalone/configuration/standalone.xml
file, in theundertow
subsystem within thedefault-server
section:
<name="ajpListener" scheme="http" socket-binding="ajp"/>
That's all, because the corresponding socket binding is enabled by default (see bottom of that file), on port 8009.
Setting up Apache as a secure reverse proxy for Wildfly
Enable the following modules in order to be able to use
mod_proxy_ajp
:/etc/apache2/mods-enabled$ sudo ln -s ../mods-available/proxy.conf
/etc/apache2/mods-enabled$ sudo ln -s ../mods-available/proxy.load
/etc/apache2/mods-enabled$ sudo ln -s ../mods-available/proxy_ajp.load
Activate the secure reverse proxy to the application server:
- Add a proxying entry to the
/etc/apache2/mods-enabled/proxy.conf
file:
ProxyPass / ajp://localhost:8009/
- Enable secure proxying in the
/etc/apache2/sites-enabled/default-ssl.conf
file:
SSLProxyEngine on
Taking it for a test run
Now fire up the application server:{$wildfly-home-dir}/bin/standalone.sh
and (re)start the webserver:
sudo service apache2 restart
and go to the root of your installation (which may be
http://localhost/
if you're trying this out locally). What you should see now is a warning from your browser, telling you the certificate that's used by the site you're trying to access is not trusted. If you choose to ignore this warning - you can, i.e. if you trust your own server - then you should be redirected to the landing page of the Wildfly installation (or anything you have deployed in the root context instead), served over a secure SSL connection.Saturday, June 16, 2012
Install Oracle JDK 7 on Ubuntu
Update: while the method below is still a possibility (and people running Linux are usually not afraid to go the extra mile to have their system running exactly as they want), there is of course a much, much simpler way to accomplish the same: using the PPA from the "WebUpd8" team, your Oracle JDK is installed and kept up-to-date in a breeze.
Just follow the instructions on https://launchpad.net/~webupd8team/+archive/ubuntu/java!
Since I've been installing Java for development purposes a few times now on different machines running Ubuntu and had to look up how to do that each time (my attention span obviously is too short to remember properly), I've decided to make a blog entry out of it.
So the following steps will guide you through the process:
1) Download the JDK from Oracle
Go to the JDK download page and choose the version you need or want. You have to accept the agreement and you will want to choose the package for Linux in the compressed tarball format (Make sure you get the correct version corresponding to your Ubuntu installation; I got the 64-bits version, so that's jdk-[version]-linux-x64.tar.gz; for 32-bits you'd need the one with -i586 in the name).
At the time of this writing, the newest version was JDK7u5, but these guidelines should work on any 'modern' JDK.
Note: if you're interested in developing JavaFX, unlike the Windows and Mac OS packages, the Linux JDK doesn't contain the JavaFX SDK. You'll need to get a 'developer preview' here, and to be able to download it I had to log in with my (free) Oracle account.
2) Extract the package
You can use the file manager, right-click on the package and choose 'Extract here'.
Alternatively, if you insist on using the command line, use (assuming you're in the directory the package was downloaded to):
3) Move the extracted package to the right directory
The JDK should be moved to the place where all the libraries reside, so first you create a logical path and then you move the package:
4) Enable the JDK
Now the system needs to be able to find the JDK, more specifically the binaries that can be run: the main Java laucher, the compiler and the Web Start launcher.
5) Make the new JDK the default choice - if necessary
If the JDK you just installed is the only one on your system, then this step is not required. If you're not working on a freshly installed machine, this will most likely not be the case, and you'll need to configure the settings so the new JDK is picked instead of the other ones.
Rinse and repeat for the compiler and Web Start launcher:
Note: if you're getting a “No such file or directory” message instead of the Java version and you've made sure the symbolic links are correct and the files are there, chances are that you've installed a 32-bits JDK on a 64-bits OS. Remove the directory under /usr/lib/jvm/jdk1.7.0/ and start again from step 1, choosing the right package this time.
Just follow the instructions on https://launchpad.net/~webupd8team/+archive/ubuntu/java!
Since I've been installing Java for development purposes a few times now on different machines running Ubuntu and had to look up how to do that each time (my attention span obviously is too short to remember properly), I've decided to make a blog entry out of it.
So the following steps will guide you through the process:
1) Download the JDK from Oracle
Go to the JDK download page and choose the version you need or want. You have to accept the agreement and you will want to choose the package for Linux in the compressed tarball format (Make sure you get the correct version corresponding to your Ubuntu installation; I got the 64-bits version, so that's jdk-[version]-linux-x64.tar.gz; for 32-bits you'd need the one with -i586 in the name).
At the time of this writing, the newest version was JDK7u5, but these guidelines should work on any 'modern' JDK.
Note: if you're interested in developing JavaFX, unlike the Windows and Mac OS packages, the Linux JDK doesn't contain the JavaFX SDK. You'll need to get a 'developer preview' here, and to be able to download it I had to log in with my (free) Oracle account.
2) Extract the package
You can use the file manager, right-click on the package and choose 'Extract here'.
Alternatively, if you insist on using the command line, use (assuming you're in the directory the package was downloaded to):
tar -xvf jdk-[version]-linux-x64.tar.gz
3) Move the extracted package to the right directory
The JDK should be moved to the place where all the libraries reside, so first you create a logical path and then you move the package:
sudo mkdir -p /usr/lib/jvm/jdk1.7.0 sudo mv jdk1.7.0_05/* /usr/lib/jvm/jdk1.7.0/(You'll be prompted for your password to be able to perform the sudo commands.)
4) Enable the JDK
Now the system needs to be able to find the JDK, more specifically the binaries that can be run: the main Java laucher, the compiler and the Web Start launcher.
sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.7.0/bin/java" 1 sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/jdk1.7.0/bin/javac" 1 sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/usr/lib/jvm/jdk1.7.0/bin/javaws" 1
5) Make the new JDK the default choice - if necessary
If the JDK you just installed is the only one on your system, then this step is not required. If you're not working on a freshly installed machine, this will most likely not be the case, and you'll need to configure the settings so the new JDK is picked instead of the other ones.
sudo update-alternatives --config javaThis will bring up an overview of the available alternatives, indicating the current default. Just enter the number that is printed in front of the launcher from the fresh install.
Rinse and repeat for the compiler and Web Start launcher:
sudo update-alternatives --config javac sudo update-alternatives --config javawsYou can check whether all went well by retrieving the version of the Java installation:
java -versionand you should see something like:
java version "1.7.0_05" Java(TM) SE Runtime Environment (build 1.7.0_05-b05) Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)And you're done!
Note: if you're getting a “No such file or directory” message instead of the Java version and you've made sure the symbolic links are correct and the files are there, chances are that you've installed a 32-bits JDK on a 64-bits OS. Remove the directory under /usr/lib/jvm/jdk1.7.0/ and start again from step 1, choosing the right package this time.
Labels:
Java
Wednesday, April 25, 2012
Customizing the JNDI name(s) of the JBoss 5.1 ConnectionFactory
Customizing the JNDI name(s) of the JBoss 5.1 ConnectionFactory takes the following steps:
- Change or add the binding name(s) in the [server]/deploy/messaging/connection-factories-service.xml file:
jboss.messaging:service=ServerPeer jboss.messaging:service=Connector,transport=bisocket jboss.messaging:service=PostOffice /ConnectionFactory /XAConnectionFactory java:/ConnectionFactory java:/XAConnectionFactory /YOUR_JNDI_NAME_HERE
Same goes for the clustered connection factory (defined in the same file just under the other one).
- Only if necessary (i.e. changed in the above) adjust the corresponding reference in the JMS datasource file ([server]/deploy/messaging/jms-ds.xml, this is the original file referencing the standard java:/XAConnectionFactory reference):
DefaultJMSProvider org.jboss.jms.jndi.JNDIProviderAdapter java:/XAConnectionFactory java:/XAConnectionFactory java:/XAConnectionFactory
Now you can use whatever name you want to bind the connection factory to from within your application!
Labels:
JBoss
Tuesday, August 16, 2011
Update on the Quartz caveat
My previous post explained how to use Quartz on JBoss 5.1, and gave you a heads-up about the way JBoss properties are mangled on Windows platforms.
Kudos to the guys at Terracotta, who picked up quickly on the corresponding issue I filed and included a fix in the very next release (which is 2.1, released September 16th)!
Kudos to the guys at Terracotta, who picked up quickly on the corresponding issue I filed and included a fix in the very next release (which is 2.1, released September 16th)!
Monday, July 18, 2011
'External' Quartz on JBoss 5.1
On our current project, we have the requirement to be able to run our application on more than JBoss AS alone. When confronted with the need to schedule certain tasks, we considered a few options:
1) Clean up your installation.
So, the first job at hand is to remove the Quartz artifacts from our JBoss installation. I guess it makes sense to prevent different versions from showing up in your classpath. The files to be removed are:
2) Add the required Quartz libraries to you server.
The following file should be in place after this step:
Note that this file is not downloaded if you include the dependencies through Maven as indicated above, you have to download the full distribution to get it.
3) Add an MBean to the JBoss configuration.
The following is a simple example of a Quartz MBean configuration:
Put the XML above in a x-service.xml file in your server's deploy dir, like e.g.:
Obviously it now is possible to use Quartz from code inside deployed applications. Just retrieve the scheduler from JNDI like so:
a) Enable the Quartz plugin that reads jobs and triggers from an indicated XML file. This is done by adding the following properties to the configuration shown in step 3):
b) Create a class that implements the org.quartz.Job interface for each such a task. This interface exposes exactly one method, void execute(JobExecutionContext ctx), which is called when the job is triggered.
c) Provide the quartz-jobs.xml file that is indicated in the extra configuration in step a) (the file name and path can be adjusted to your liking) with the appropriate timing to start your jobs. For our tasks we use Cron-like jobs, with the Quartz CronTrigger (see http://www.quartz-scheduler.org/api/2.0.0/org/quartz/CronTrigger.html). An example configuration is:
One last CAVEAT: On Windows, the ${jboss.server.home.dir} expression resolves to a String that contains backward slashes ('\') instead of forward slashes as path delimiter. The way the Quartz extension for JBoss reads in the properties is not able to cope with that, so you may need to provide a full path explicitly for any file names.
- Use EJB timers: Due to the nature of the tasks (e.g. interdependencies) this mechanism is not suitable - it's simply just not sophisticated enough.
- Use the Quartz functionality provided along with the JBoss distribution: While this may do exactly what we need, it wouldn't be portable to app servers from other vendors.
- "Another way to use Quartz in JBoss"
- "JBoss Quartz tutorial"
- "Scheduling a job using Jboss-5.1.0.GA and Quartz"
We use provided scope here since we won't be including Quartz in our project's deliverables; instead we put such dependencies on our server explicitly. Either approach would work, though.org.quartz-scheduler quartz-jboss 2.0.2 provided
1) Clean up your installation.
So, the first job at hand is to remove the Quartz artifacts from our JBoss installation. I guess it makes sense to prevent different versions from showing up in your classpath. The files to be removed are:
- ${jboss.home.dir}/common/lib/quartz.jar
- ${jboss.home.dir}/server/[SERVER_NAME]/deploy/quartz-ra.rar (in EAP this is an exploded RAR, so remove the directory)
2) Add the required Quartz libraries to you server.
The following file should be in place after this step:
- ${jboss.home.dir}/server/[SERVER_NAME]/lib/quartz-all-2.0.2.jar
Note that this file is not downloaded if you include the dependencies through Maven as indicated above, you have to download the full distribution to get it.
3) Add an MBean to the JBoss configuration.
The following is a simple example of a Quartz MBean configuration:
If you use this, no extra DataSource needs to be configured and Quartz keeps its jobs in memory. For more specifics on the configuration possibilities (there are a lot!), see http://www.quartz-scheduler.org/docs/configuration/.Quartz org.quartz.scheduler.instanceName = DefaultQuartzScheduler org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool org.quartz.threadPool.threadCount = 5 org.quartz.threadPool.threadPriority = 4 org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore
Put the XML above in a x-service.xml file in your server's deploy dir, like e.g.:
- ${jboss.home.dir}/server/[SERVER_NAME]/deploy/quartz-service.xml
Obviously it now is possible to use Quartz from code inside deployed applications. Just retrieve the scheduler from JNDI like so:
InitialContext ctx = new InitialContext(); Scheduler scheduler = (Scheduler) ctx.lookup("Quartz");But for our purpose this just isn't good enough, we want to be able to schedule tasks from configuration files. To accomplish that, we need to perform a number of steps:
a) Enable the Quartz plugin that reads jobs and triggers from an indicated XML file. This is done by adding the following properties to the configuration shown in step 3):
org.quartz.plugin.jobInitializer.class = org.quartz.plugins.xml.XMLSchedulingDataProcessorPlugin org.quartz.plugin.jobInitializer.fileNames = ${jboss.server.home.dir}/conf/quartz-jobs.xml org.quartz.plugin.jobInitializer.scanInterval = 120For details on this plugin see http://www.quartz-scheduler.org/api/2.0.0/org/quartz/plugins/xml/XMLSchedulingDataProcessorPlugin.html.
b) Create a class that implements the org.quartz.Job interface for each such a task. This interface exposes exactly one method, void execute(JobExecutionContext ctx), which is called when the job is triggered.
c) Provide the quartz-jobs.xml file that is indicated in the extra configuration in step a) (the file name and path can be adjusted to your liking) with the appropriate timing to start your jobs. For our tasks we use Cron-like jobs, with the Quartz CronTrigger (see http://www.quartz-scheduler.org/api/2.0.0/org/quartz/CronTrigger.html). An example configuration is:
In this example the task executed by the com.acme.quartz.TestJob class is triggered at 3:00 AM on weekdays.* * true false TestJob com.acme.quartz.TestJob TestCronTrigger TestJob 0 0 3 ? * MON-FRI
One last CAVEAT: On Windows, the ${jboss.server.home.dir} expression resolves to a String that contains backward slashes ('\') instead of forward slashes as path delimiter. The way the Quartz extension for JBoss reads in the properties is not able to cope with that, so you may need to provide a full path explicitly for any file names.
Labels:
JBoss
Subscribe to:
Posts (Atom)