Dockerfile to build a JBoss EAP 5.2 image for Docker containers - jmmorenogavira/docker-jboss-eap. JBoss EAP 6.4.0 – Configure web application security from zero. JBOSS 6 – Configure web application security. In this example we’ll show how to manage web application security using the ManagementRealm of Jboss 6.x and filtering roles directly on a rest service by using javax annotations.
Active6 years, 9 months ago
Question about the source code for JBoss EAP versions 4 5 or 6.
Let's say we decided to purchase JBoss EAP 6 from RedHat. Can we still run maven to build JBoss EAP version? Are there closed source resources involved?
Basically we are worried that going with the EAP version will limit our ability to utilize JBoss as an Open Source tool.
I would imagine there is closed source involved. Otherwise, for example, people would be able to take the patches from JBoss EAP 4.3 and then apply them to JBoss 4.2.3.GA community version. Or am I mistaken?
Please see this reference: JBoss Enterprise Application Platform Component Details https://access.redhat.com/knowledge/articles/112673 - Describes each open source JBoss component utilized from JBoss AS EAP version. But what it does not describe is patches etc that are applied.
Nicholas DiPiazza
Nicholas DiPiazzaNicholas DiPiazza
1 Answer
There is no closed source nature to EAP or any Red Hat products. When you purchase a subscription from Red Hat you get access to the product and its source code in its entirety. From the link you have provided, you will notice that it lists all of the platform components bundled with EAP & the community version which was taken.
The software development cycle at Red Hat means that they take these community projects and enhance the various components to ensure they meet a standard of robustness, security, stability which is suitable for Enterprise implementation. All enhancements made to the product are then given back to the community & their various projects so that they can incorporate these into later versions. A majority of Open Source projects/products are licensed under the GPL License, meaning that any changes or additions made to the software must be given back to the community.
As for building EAP through maven, could you elaborate on this? EAP comes pre-packaged, ready to go out of the box, you simply have to unzip, configure & deploy to a location of your choice, then deploy your application and away you go. EAP or any Red Hat product does not require any Maven Build process in order to use it.
If you have any concerns, please contact Red Hat's Sales teams who will be more than happy to got into more detail about the Open Source nature of Red Hat & its products.
Not the answer you're looking for? Browse other questions tagged jbosseap or ask your own question.
Join the DZone community and get the full member experience.
Join For Free
Introduction
Some time ago we decided to upgrade our application from JBoss 5 to 7 (technically 7.2). In this article I going to describe several things which we found problematic. At the end I also provided a short list of benefits we gained in retrospect.
First some general information about our application. It was built using EJB 3.0 technology. We have 2 interfaces for communicating with other components – JMS and JAX-WS. We use JBoss AS 5 as our messaging broker which is started as a separate JVM process. This part of the system we were not allowed to change. Finally – we use JPA to store processing results to Oracle DB.
Step #1 – Convince your Product Owner
Although our application was rather small and built on JEE5 standard it took us 4 weeks to migrate it to JEE6 and JBoss 7. So you can't do it as a maintenance ticket – it's simply too big. There is always problem with providing Business Value of such migration for Product Owners as well as for key Stakeholders. There are several aspects which might help you convincing them. One of the biggest benefits is processing time. JBoss 7 is simply faster and has better caching (Infinispan over Ehcache). Another one is startup time (our server is ready to go in 5-6 seconds opposed to 1 minute in JBoss 5). Finally – development is much faster (EJB 3.1 is much better then 3.0). The last one might be translated to “time to market”. Having above arguments I'm pretty sure you'll convince them.
Step #2 – Do some reading
Here is a list on interesting links which are worth reading before the migration:
JBoss 5 isn't packaged very well, so I suppose you many dependencies included in your classpath (either directly or by transitive dependencies). This is the first big change in JBoss 7. Now I strongly advice you to use this artifact in your dependency management section:
We also decided to stick only to JEE6 spec and configure all additional JBoss 7 options with proper XML files. If it sounds good for your project too, just add this dependency and you're done with this step:
After cleaning up dependencies your code probably won't compile for a couple of days or even weeks. It takes time to clean this up.
Step #4 – EJB 3.0 to 3.1 migration
Dependency Injection is a heart of the application, so it is worth to start with it. Almost all of your code should work, but you'll have some problems with beans annotated with @Service (these are singletons with JBoss 5 EJB Extended API). You just need to replace them with @Singleton annotations and put @PostConstruct annotation on your init method. One last thing – remember to use proper concurrency strategy. We decided to use @ConcurrencyManagement(BEAN) and leave the implementation as is.
Step #5 – Upgrade to JPA 2.0
If you used JPA 1.0 with Hibernate, I'm pretty sure you have a lot of non standard annotations defining caching or cascading. All of them might be successfully replaced with JPA 2.0 annotations and finally you might get rid of Hibernate from compile classpath and depend only on JPA 2.0. Here are several standard things to do:
Get rid of Hibernate's Session.evict and switch to EntityManager.detach
Get rid of Hibernate's @Cache annotation and replace it with @Cachable
Fix Cascades (now delete orphan is a part of @XXXToYYY annotations)
Remove Hibernate dependency and stick with JEE6 spec
Step #6 – Fix Hibernate's sequencer
Migrating Hibernate 3 to 4 is a bit tricky because of the way it uses sequences (fields annotated with @Id). Hibernate by default uses a pool of ids instead of incrementing sequence. An example will be more descriptive:
Jboss Eap 5 2 0 Zip Code Download
Some_DB_Sequence.nextval -> 1
Hibernate 3: 1*50 = 50; IDs to be used = 50, 51, 52.…, 99
Some_DB_Sequence.nextval -> 2
Hibernate 3: 2*50 = 100; IDs to be used = 100, 101, 102.…, 149
In Hibernate 4.x there is a new sequence generator that uses new IDs that are 1:1 related to DB sequence. Typically it's disabled by default... but not in JBoss 7.1. So after migration, Hibernate tries to insert entities using IDs read from sequence (using new sequence generator) that were already used which causes constraint violation. The fastest solution is to switch Hibernate to the old method of sequence generation (described in example above), that requires following change in persistence.xml:
Step #7 – Caching
Infinispan is shipped with JBoss 7 and does not require much configuration. There is only one setting in persistence.xml which needs to be set and the others might be removed:
Infinispan itself might require some extra configuration – just use standalone-full-ha.xml as guide.
Step #8 – RMI with JBoss 5
If you're using a lot of RMI communicating with other JBoss 5 servers – I have bad information for you – JBoss 5 and 7 are totally different and this kind of comminication will not work. I strongly recommend to switch to some other technology like JAX-WS. In the retrospect we are very glad we decided to do it.
Step #9 – JMS migration
We thought it would be really hard to connect with JMS server based on JBoss 5. It turned out that you have 2 options and both work fine:
Start HornetQ server on your own instance and create a bridge to JBoss 5 instance
Use Generic JMS adapter: https://github.com/jms-ra/generic-jms-ra
Jboss Eap 5 2 0 Zip Code Map
Step #10 – Fix EAR layout
In JBoss 5 it does not matter where all jars are being placed. All EJBs are being started. It does not work with JBoss 7 anymore. All EJB which should start must be added as modules.
Step #11 – JMX console
Calculator
Bad information – it's not present in JBoss 7. We liked it very much, but we had to switch to jvisualvm to invoke our JMX operations. There is a ticket in WildFly Jira opened for that: https://issues.jboss.org/browse/WFLY-1197. Unfortunately at moment of writing this article it is not resolved.
Some thoughts in retrospect
It is really time consuming task to migrate from JBoss 5 to 7. Although in my opinion it is worth it. Now we have better caching for cluster solutions (Infinispan), better DI (EJB 3.1) and better Web Services (CXF instead of JBoss WS). Processing time decreased by 25% without any code change. Development speed increased in my opinion (it is really hard to measure it) by 50% and we are much more productive (faster server restarts). Memory footprint lowered from 1GB to 512MB. Finally automatic application redeployment finally works! However there is always a price to pay – the migration took us 4 weeks (2 sprints). We didn't write any code for our business in that period. So make sure you prepare well for such migration and my last advice – invest some time to write good automatic functional tests (we use Arquillian for that). Once they're green again – you're almost crossing finishing line.
Like This Article? Read More From DZone
5'2 In Meters
Opinions expressed by DZone contributors are their own.