Salient Soft

A useful article on this, and on keeping Eclipse clean is here. Some general points on this are as follows :-

1. In my experience it does not pay to let workspaces become too large, as metadata corruption can sometimes cause the whole workspace to fail to load and cross project pollution of metadata can happen. It also helps with performance not to have a huge workspace. I keep all related projects for a given application in the same workspace, but not others.
2. The article describes the use of the -clean command line argument to remove cached OSGi framework and Eclipse run time metadata. I haven’t used it myself, but it is said to be able to fix really obscure bugs/issues caused by metadata corruption.
3. When creating a new workspace, use File/Export/Preferences to save a preferences file which can be imported into the new workspace. This will allow e.g. your plug in libraries and other preferences to be quickly defined in the new workspace. If you do not do this, you need to either download the libraries again via eclipse’s user library management, or load them one at a time. An xml file is used to define the userlibraries and I did not look into how to store a library repository locally with its own xml definition.
4. Note that when sharing the libraries across multiple workspaces, you will want to change the default download locatation when downloading them initially – the default is <workspace>\libraries, which would mean that subsequent workspaces would be sharing libraries from inside another one.  This post here details my typical folder structure which places the shared libraries at a level above the workspaces. You will need to modify the download path each time you download a library (in my case this involves just taking out the Workspaces\<workspace>\ levels from the path).

No Comments »

An interesting article on this is here. It is very thorough and lists all the common gotchas and workarounds to do the job properly.

No Comments »

This Glassfish article  is a must read reference on the naming and JNDI minefield when looking up local and remote EJBs.
There is also a very  informative Refcardz card on this topic. Refcardz can be downloaded as PDFs if  you register.
In my experience, there is a lot of misinformation around the internet on this which can be time consuming to weed out.

I’ve posted some examples of local and remote EJB access via both injection and JNDI here.

Here are some key points I worked through and learned :-

1. Despite a number of blog posts to the contrary, EJBs can be injected via @EJB into JSF managed beans, POJOs called from managed beans, and servlets provided the JSF/servlets are running in the EJB container, e.g. if Glassfish is used both as servlet and EJB container.
2. When injecting local EJBs, using the defaults on @EJB and matching defaults e.g. on @Stateless will work and the bean will inject.
3. When injecting remote EJBs via @EJB, use the mappedName argument to specify the JNDI name of the remote bean. It is also essential to specify the class of the remote EJB interface in the beanInterface argument to @EJB. Failure to do this will result in NamingExceptions, which can give the misleading impression that it is the JNDI name that is wrong.
4. If @EJB is not used, then <ejb-local-ref> may be used in web.xml to define a reference to the bean. If @EJB is used then this is handled automatically. The above Glassfish article details how the various fields in @EJB and <ejb-local-ref> are related.
5. In addition to @EJB and direct JNDI lookups, EJBs can be injected via JSF using a custom EL resolver which performs the JNDI lookups and injections performed in faces-config.xml.  An interesting example of a custom EL resolver to do this is here. However, for injecting EJBs,  @EJB requires no extra code. It is also possible to inject EJBs via Spring, into beans managed by a Spring container. However these have not been pursued as @EJB is the easiest way. It would be overkill to use a Spring container purely for EJB injection/service location.

No Comments »

Interesting post by Nick Johnson about how to optimise lazy fetches and avoid loading the whole tree.
http://spatula.net/blog/2007/03/optimizing-message-tree-with-jpa.html

No Comments »