1 Reply Latest reply on Jul 24, 2007 5:30 PM by Brian Stansberry

    Re: Fix to EJBTHREE-424 forces use of @Clustered annotation

    Liz Newbie

      Cross posting from the EJB3 forum since I'm not getting a lot of response there. This was posted back in April. It seems that StringPropertyReplacer is not checking for null before calling methods on the string (which in this case is missing because I don't want to use the @Clustered annotation.)

      "lizmstanley" wrote:
      I'm running JBoss 4.2.0 CR1. This is a result of the fix to JIRA issue EJBTHREE-424. In BaseSessionProxyFactory.substituteSystemProperty, the StringPropertyReplacer is used to allow the substitution of a partition name for the @Clustered annotation. However, if there is no such annotation in the bean, StringPropertyReplacer throws a NullPointerException as there is no value to replace. As a result, the bean is not deployed and the following messages are output:

      10:10:53,005 WARN [BaseSessionProxyFactory] Unable to replace @Clustered partition attribute null. Caused by class java.lang.NullPointerException null
      10:10:53,005 WARN [ServiceController] Problem starting service jboss.j2ee:ear=MyEar.ear,jar=beans.jar,name=MyBean,service=EJB3
      javax.naming.NameNotFoundException: null not bound

      My goal here is not to include any vendor-specific annotations like @Clustered in the code. Instead we prefer to specify that type of information in deployment descriptors that can be included at runtime so we could deploy to different platforms if desired, without having to change the code itself.

      In the earlier version of JBoss we were running (4.0.4), we were forced to use DefaultPartition as the name of the cluster, but were able to specify the clustering attributes in the deployment descriptor, such whether the bean is to be clustered, and the load balancing scheme. Now we are able to specify a different partition name, but are no longer able to use the deployment descriptor as the sole source of clustering information. This is undesirable as it defeats any possibility of platform-independent code.