May 5, 2012 - EJB is null inside RESTful web service

Comments

While developing my enterprise application and learning Java EE at the same time, I came to a situation where injecting an EJB inside a RESTful web service class would be the same as nothing. The EJB variable was always null.

So, what did I change to fix this?
This was my source code before:
@Path("/mypath")
public class MyREST {

@EJB
private MyFacadeLocal myFacade;

public MyREST() {
}

@GET
@Produces("text/plain")
public String respond() {
return "DONE";
}
}
I forgot to tell the scope of the service. I managed to make it work by turning it request scoped (although from what I read it should be, by default, request scoped):
@RequestScoped
@Path("/mypath")
public class MyREST {

@EJB
private MyFacadeLocal myFacade;

public MyREST() {
}

@GET
@Produces("text/plain")
public String respond() {
return "DONE";
}
}

If I make it session scoped, I end up with the issue: Error creating managed object for class.

If I make it @Stateless, it also works properly and seems to be the recommended way:
@Stateless
@Path("/mypath")
public class MyREST {

@EJB
private MyFacadeLocal myFacade;

public MyREST() {
}

@GET
@Produces("text/plain")
public String respond() {
return "DONE";
}
}

Notice that MyFacadeLocal is actually an interface for the session bean (which doesn't have the @LocalBean annotation itself). If I want to directly inject the session bean (called MyFacade) I need to have the @LocalBean annotation in it. If not, the EJB inside the RESTful web service may not be properly deployed and the following error may appear:

java.lang.IllegalStateException: Exception attempting to inject Remote ejb-ref name=rest.MyREST/myFacade,Remote 3.x interface =ejb.MyFacade,ejb-link=null,lookup=,mappedName=,jndi-name=ejb.MyFacade,refType=Session into class rest.MyREST: Lookup failed for 'java:comp/env/rest.MyREST/myFacade' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

Here's MyFacade without requiring an interface (assuming you'll be using it locally anyway):
@LocalBean
@Stateless
public class MyFacade extends AbstractFacade {
@PersistenceContext(unitName = "myjpaunit")
private EntityManager em;

@Override
protected EntityManager getEntityManager() {
return em;
}

public MyFacade() {
super(My.class);
}

@Override
public int count() {
return super.count();
}

@Override
public void create(My entity) {
super.create(entity);
}

@Override
public void edit(My entity) {
super.edit(entity);
}

@Override
public My find(Object id) {
return super.find(id);
}

@Override
public List findAll() {
return super.findAll();
}

@Override
public List findRange(int[] range) {
return super.findRange(range);
}

@Override
public void remove(My entity) {
super.remove(entity);
}
}

Another cause for having a null EJB is if, for any reason, an exception is thrown inside of it. Java EE will not inject it if running the EJB methods that are supposed to be called through the dependent object leads to exceptions. So, if you comment every call in your dependent object and then just check if the EJB is null, you'll see it isn't. But if you make use of a malfunctioning method, the EJB will just become null.
Useful links:
Glassfish embedded with JUnit for EJB testing

May 5, 2012 - Error creating managed object for class

Comments

Well, while developing my enterprise application in NetBeans 7.1.2 with GlassFish 3.1.2 as the application server, the following most notable error appeared and made the project unable to deploy:

Error creating managed object for class: class org.jboss.weld.servlet.WeldListener

and a bunch of other errors and exceptions.


I tried to revert my changes since the last revision from the revision control and found myself in the same situation.

Manual clean followed by build also did nothing.

Solution:
My gut told me I just needed to clean the NetBeans trash and so I did:

  • I deleted all of my project locally;
  • Restarted NetBeans;
  • Checked out my project from the revision control again;
  • Run it, and it worked!
I don't know the cause of this, but if you can't find another way then just try to clean your NetBeans generated junk.

I was having this in the context of a RESTful web service (Jersey) plus EJBs which was working properly. A little investigation told me that it might be a bug in Jersey, check the links below for more information.

I also invite you to comment on a better solution for this and I'll update this post with it.

Update: I can now reproduce this issue, if I set my RESTful web service to be session scoped (@SessionScoped) it breaks but sometimes I can make it work by changing to request scoped (@RequestScoped) again. My source code is simply the following:

@SessionScoped
@Path("/mypath")
public class MyREST {

@EJB
private MyFacadeLocal myFacade;

public MyREST() {
}

@GET
@Produces("text/plain")
public String respond() {
return "DONE";
}
}

Useful links:

Apr 17, 2012 - Generated Facelets templates not applying / can't find CSS stylesheets

Comments

Using NetBeans, I have created a Facelets template and a Facelets template client through the wizards provided. No changes were made to the source code.

However, when navigating in the generated template client with my browser, I noticed that the sections "inserted" (e.g, header, footer, content) were not being stylized in any way.

After a great deal of head banging onto the wall, I finally found a solution for this.
I checked the generated HTML source code in my browser (from /faces/index.xhtml, my template client)  to see where the CSS files were being pointed at:
http://localhost:8080/MyContextRoot/faces/resources/css/default.css
http://localhost:8080/MyContextRoot/faces/resources/css/cssLayout.css

These files were not publicly available, so the browser couldn't load them to process the styles. This was all generated by NetBeans. My /faces/index.xhtml was generated dynamically with sucess, so it wasn't a problem with the mapping of the Faces servlet.

After comparing my project files, specifically the WEB-INF/web.xml, with an empty project I came to the conclusion that the cause of the problem was a conflict in servlet URL patterns. This is how my web.xml looked like:
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
<servlet>
<servlet-name>ServletAdaptor</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>ServletAdaptor</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>10</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>faces/index.xhtml</welcome-file>
</welcome-file-list>
</web-app>

The /* URL pattern from the Jersey servlet will basically hide the stylesheets location, so they will not be accessible through the generated template code.


Fixing it


1. The best fix is the right one. Go to your WEB-INF/web.xml and fix any superposition of URL patterns. In my case I changed the Jersey URL pattern from:
    <servlet-mapping>
<servlet-name>ServletAdaptor</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
to:
    <servlet-mapping>
<servlet-name>ServletAdaptor</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>

2. If you don't want to do the above method, open your template file (in my case it was template.xhtml) and replace the following lines:

<link href="./resources/css/default.css" rel="stylesheet" type="text/css" />
<link href="./resources/css/cssLayout.css" rel="stylesheet" type="text/css" />
with:
<h:outputStylesheet name="css/default.css"/>
<h:outputStylesheet name="css/cssLayout.css"/>

The difference is that now the actual HTML CSS include code will be generated in the server with the correct link for the CSS files. I checked the code that was generated in my case, which was:
<link type="text/css" rel="stylesheet" href="/MyProject/faces/javax.faces.resource/css/default.css" />
<link type="text/css" rel="stylesheet" href="/MyProject/faces/javax.faces.resource/css/cssLayout.css" />

And it also works. You can use it but it is less portable and depends on the configuration and future releases.

I hope that in the future Oracle adds a way to auto-detect these conflicts in NetBeans to ease development for beginner Java EE developers.

Useful links:
JSF template not applied
Styles not getting applied for the Facelets template client
Applying a Facelets Template

Update (2015-Oct-11) with a recommended introduction to JSF:
JSF Tutorial: An Introduction to JSF

Apr 4, 2012 - Fixing remote GlassFish server errors on NetBeans

Comments

If you are having errors when adding a remote GlassFish server to your NetBeans installation and you are sure there's connectivity between you and the remote server and all the required ports are open, a possible cause might be not having the remote secure administration enabled (which is required if you want to deploy remotely).


__locations failed on Glassfish VM


Remote host closed connection during handshake

Just get access to your server's system console and use asadmin to enable the secure administration:

Any OS:
asadmin enable-secure-admin


Make sure you have the GlassFish bin folder in your path, which contains the asadmin script.

Apr 2, 2012 - No Program Associated with Emptying the Recycle Bin Error

Comments

When trying to empty the recycle bin in Microsoft Windows Vista/7/2008/2008 R2 (and probably XP, though it was not tested) via the "Empty the Recycle Bin" option, the following error appears:


I've had this problem in my Windows computer for a few months already but only now I decided to check what it was all about.

For some reason, an important registry key disappeared from my operating system (which isn't statistically weird given that my Windows installation is already 28 months old).

First, I made some research about this problem but it ended up non-conclusive and without solutions nor interesting workarounds.

As such, I will show you how I managed to fix this issue:


1.
I started searching for relevant entries about the recycle bin with the Registry Editor (regedit).

[You can run the Registry Editor by writing "regedit" in the start menu, then right-click the first result that appears and selecting "Run as administrator".]

I stumbled upon the following suspicious key:

HKEY_CLASSES_ROOT\CLSID\{645FF040-5081-101B-9F08-00AA002F954E}\shell\empty\command

2.
I went to another computer I had working alright and searched for the same key to find out that the contents were different.

HKEY_CLASSES_ROOT\CLSID\{645FF040-5081-101B-9F08-00AA002F954E}\shell\empty\command

3.
I just tried to copy the DelegateExecute String key to my bad Windows installation registry.

However, I had no permissions to write in the original key because it's not supposed to be touched.

When trying to add the missing key, permission was denied 

4.
I used the amazing RegDACL program from Frank Heyne to unlock the key:

In a Windows Command Prompt (or PowerShell) execute the following command (having RegDACL in either the path or the current directory):

[You can run the Command Prompt by writing "cmd" in the start menu, then right-click the first result that appears and selecting "Run as administrator".]

RegDACL.exe HKCR\CLSID\{645FF040-5081-101B-9F08-00AA002F954E}\shell\empty\command /GGA:W(NI)

Now it should be possible to change the registry key (if you do it as Administrator):

C:\>RegDACL.exe HKCR\CLSID\{645FF040-5081-101B-9F08-00AA002F954E}\shell\empty\command /GGA:F(CI)



RegDACL 6.2 - Permissions Manager for Registry keys for Windows

Copyright (c) 1999-2007 Frank Heyne Software (http://www.heysoft.de)

This program is Freeware, use it on your own risk!





Granting "W(NI)" access for predefined group "Administrators"

 - adding new entry

Don't forget to restore the original permissions afterwards.

5.
Finally I just added a String key named: DelegateExecute with the content: {48527bb3-e8de-450b-8910-8c4099cb8624}, or use the .reg inside the previous key (HKEY_CLASSES_ROOT\CLSID\{645FF040-5081-101B-9F08-00AA002F954E}\shell\empty\command) file I provide at the end of this post.

It should look like this after adding the missing key


The problem should now be fixed, if you go to the "Empty the Recycle Bin" option you'll see the familiar dialog:



One more thing. I had a backup key in my computer made by the trial TuneUp Utilities 2012, so it may have been the cause of this issue.

Update of 2012-04-19:

Download the .reg file that fixes the key automatically: DelegateExecute.reg
(you still need to apply the permissions explained earlier)

Useful links:
RegDACL

Mar 22, 2012 - Adding comments in GNS3 IOS baseconfig files

Comments

If you want to write some comments in your GNS3 baseconfig files for the Cisco IOS, you can use the exclamation mark. It is mainly used for separating commands for easier reading. Everything that is written after the exclamation mark is ignored.

Here's an example:

enable ! a comment
configure terminal
interface FastEthernet0/0 ! now I will configure the FastEthernet0/0 interface
ip address 192.168.1.1 255.255.255.0
no shut
!
end


Some links:

Cisco IOS Command Line Interface Tutorial