In this post you can find often used Java EE 6 configuration files (along with their schema declarations to aid your IDE’s code assistant):
Java EE 6 brings a lot new features. Among the others there is the concept of profiles. Java EE starts with the definition of two: Full and Web Profile.
The idea is to create separate and more specialized set of services that better suits your job. E.g. if you only want to use Servlets, JSP and add some EJB’s – do you really need full-blown application server with JMS, JMX, CORBA, JAX-WS and a lot of other abbreviations?
If not, then perhaps the Web Profile is enough for you. If you need those additional services like remote EJB, JAX-RS (this one is a bit awkward and it’s possible it’ll be moved to the Web Profile in EE 7), Timers, etc. – then you probably should go with the Full Profile.
The point is – you have the choice. Moreover, the application server vendors can create their software to support only the particular profile – it’s supposed to lower the barrier for introducing new application severs to the market.
So, if we have Full and Web Profile, we should now be able to deploy our applications using not only
EAR (Enterprise ARchive) as in pre Java EE 6 days but we should also be able to use
WAR (Web ARchive). And in fact it is possible – you can deploy your Java EE 6 application using WAR.
Now, you might think that because the
WAR is for Web Archives, it’s mainly for the Web Profile. At the same time
EAR is for Enterprise Application Archive, so for Full Profile.
And there is nothing wrong with this thinking – it’s intuitive and it’s right.
However, it’s worth realizing that the
WAR are just a matter of packaging. It’s not the definition of what profile am I using. In other words, e.g. I can use all Full Java EE Profile services with the
WAR packaging format. You can deploy your application that uses Timers, Remote EJBs and others, wrap it in the WAR and deploy it – and that’s perfectly fine.
The bottom line is: the Web and Full Profile are for definition of what services need to be provided; the packaging of your application doesn’t declare what services you’ll be using.
Few days ago I’ve created a simple interceptors spike-solution at Github. Its purpose was to show my colleagues that in the EJB’s interceptors you can implement a code that exists in the same transaction and the same security context as the called EJB business method. Moreover, you can benefit from all the dependency injection you need.
This project uses the following resources injected by the Application Server:
TransactionSynchronizationRegistry– used for getting current transaction key and checking if we’re in the same transaction (I’ve written about it e.g. here),
SessionContext– for reading user’s principal – user’s security context is also available in the interceptor,
EntityManager– to persist some data before invoking the business method; it exists in the same transaction as the called method, so either both: the interceptor persistence and business method ends with success or both of them will be rolled-back.
This example also shows how easily you can add RESTful Web Service to your application (take a look at com.piotrnowicki.interceptors.web package).
It also shows that you can define interceptors in the deployment descriptor – without recompilation of your code. Such interceptors will be invoked for every business method in the given module (assuming no exclusion through annotation or DD occurs). An alternative is to define what beans or methods should be intercepted.
In Midnight Commander when you press ctrl + \ you can access directory hotlist and you can quickly choose connection you want to establish.
The problem is – you cannot by default save passwords, so every time you select this connection you need to input it. Sure, it’s safe to do so, but if using them in your desktop and you’re the only user of it – you can expect a bit more pragmatic approach.
You can define your site’s password explicitly in the MC configuration file which, by default, resides in
Just edit this file and you’ll see entry similar to below:
Maven has some really great features. One of them is filtered resources.
Basically, if you use Maven for some time, I’m sure you know what by default everything you put in
src/main/resources will be added to the classpath in the resulting artifact (e.g. in the
WEB-INF/classes for a *.war archive.) Putting resources in this location is a common way of adding Java properties file to your project.
Now what is interesting: you can use Maven variables in those resource files and they can be swapped into final value during the
process-resource phase. You just need to tell Maven that it is not a “regular” resource and that it should be filtered.
More than 18 months ago I’ve posted my mock exam for Oracle Certified Expert Web Component Developer certification. Until now it’s quite popular and useful (deducting from the comments) for many of you. What I dislike about this exam is that it’s published as a plain WordPress post and it’s rather awful to edit it and it’s not so easy to read as well. So, that’s the aim of my small side project: to create a basic platform for presenting exam questions and their answers.
The whole application is available at the:
It’s rather micro-sized but I decided to publish the first version without all the whistles-and-blows just to start moving users to get used to it. Therefore, the first version gives you the very basic functionality of questions viewing and on-demand answer showing.
There are also two other reasons I decided to do so.
Firstly, the more features I plan to include in the software the longer the design and implementation phases last and in time it’s harder and harder to finally release the app in the state you accept.
Secondly, I really wanted to get familiar with the JSF 2.x and never really had possibility to do so. I found that this project is a good motivation to learn it. Nevertheless, the JSF / web part of the application is the weakest and a bit dirty/ugly. It is the first candidate to change in the next iterations.
In time, more functionality will be added and the user experience is supposed to rise. If you’re curious
Technically, the application is created using the Java EE 6 (JSF, EL, EJB, CDI, JPA) and deployed on OpenShift’s JBoss AS 7.1 cartridge.
As a side note – the old version of the Mock Exam will still be available but only in form of a PDF located here. This is to encourage users to the new (or rather more precisely – first) version of the exam simulator.
I hope you’ll enjoy it and it’ll help you in your preparations.
FETCH JOIN is useful in cases when you want to eagerly load some lazy loaded collection of your entity. By default all
@ManyToMany relationships are lazy loaded. There are some valid cases when (despite the settings in your mapped entity), you want to eagerly load the related entity.
One of the way of doing it is to use
JOIN FETCH JPQL clause.
It’s worth remembering that
JOIN FETCH is used mainly because of its side-effect of populating the pointed relationship – it’s still a JOIN and must be treated like it when it comes to the duplicated result set problem.
You can easily create a fully functional, basic Maven repository on your web hosting provider’s account. It will give others the possibility to access your released artifacts using clean URLs (like
maven.yoursite.com) or use it as a repository straight from the Maven.
To achieve it, you’ll need to:
- create Maven FTP user,
- create a subdomain (optional),
- add Maven server configuration,
- add distribution management to your pom.xml,
- add Maven FTP wagon provider,
- use your repository in client projects.
By default few of the security features are turned off in OpenShift JBoss 7.1 cartridge.
If you want to use the Java EE security features first you need to define your security roles and constraints in your deployment descriptor, e.g.
Yesterday I took the SpringSource Certified Spring 3.0 Professional exam and passed it sucessfully with 94%. Below you can find some information about my preparation process, the exam form and the type of questions. So, here we go.