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 EAR and 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 ~/.config/mc/hotlist.

Just edit this file and you’ll see entry similar to below:

Continue reading

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.

Continue reading

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:

exam.piotrnowicki.com

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

what is planned in the next release, you would like to suggest some enhancements by yourself or like to contribute — take a look at the project’s Github site and the issues tab.

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.

JPA’s FETCH JOIN is useful in cases when you want to eagerly load some lazy loaded collection of your entity. By default all @OneToMany and @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.

Continue reading

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 yoursite.com/maven or maven.yoursite.com) or use it as a repository straight from the Maven.

To achieve it, you’ll need to:

  1. create Maven FTP user,
  2. create a subdomain (optional),
  3. add Maven server configuration,
  4. add distribution management to your pom.xml,
  5. add Maven FTP wagon provider,
  6. use your repository in client projects.

Continue reading