Posts filed under ‘Jboss AS 7’

EJB Lookup w/ JNDI on Jboss AS 7

Hello everyone!

I was kinda busy last months, so I did not have time to publish more posts here :/

Anyway, some weeks ago i have noticed a little (big) issue on JBoss AS 7 – I couldn’t make EJB lookup using JNDI!

I had to Google a lot to find a concrete answer.

So I’d like to share a way to do it.

First of all, you must have AS 7.1.x, even if it is not at the final version yet. You can download it here.

Then, create a file named jboss-ejb-client.properties into your src folder, and add this content

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false

remote.connections=default

remote.connection.default.host=localhost
remote.connection.default.port = 4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

remote.connection.two.host=localhost
remote.connection.two.port = 4447
remote.connection.two.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

Now the disgusting part. You’ll need to make a big workaround here.
Your class is going to have lots of information. And one BIG important thing – this first example only works for Stateful EJBs. I’ll show an example for Stateless EJBs later. So remember – STATEFUL EJBs:

public class ClientMyStatefulBean {

static {
Security.addProvider(new JBossSaslProvider());
}

//STATIC BLOCK - YOU MUST HAVE THIS

public static void main(String[] args) throws NamingException {

final Hashtable jndiProperties = new Hashtable();
jndiProperties.put(Context.URL_PKG_PREFIXES,
"org.jboss.ejb.client.naming");
final Context context = new InitialContext(jndiProperties);

final String appName = "";

final String moduleName = "myBeans";
// THIS IS THE NAME OF THE JAR WITH YOUR EJBs. Write its name here, without the .jar.

final String distinctName = "";
//    AS7 allows deployments to have an distinct name. If you don't use this feature, let this field empty.

final String beanName = MyBean.class.getSimpleName();
//EJB CLASS WITH THE IMPLEMENTATION (simple name)

final String viewClassName = Bean.class.getName();
// FULLY QUALIFIED NAME OF THE REMOTE CLASS (interface).

Bean bean = (Bean) context.lookup("ejb:" + appName + "/"
+ moduleName + "/" + distinctName + "/" + beanName + "!"
+ viewClassName + "?stateful");

}

}

Now for STATELESS BEANS, do this:

public class ClientMyStatelessBean {

static {
Security.addProvider(new JBossSaslProvider());
}

//STATIC BLOCK - YOU MUST HAVE THIS

public static void main(String[] args) throws NamingException {

final Hashtable jndiProperties = new Hashtable();
jndiProperties.put(Context.URL_PKG_PREFIXES,
"org.jboss.ejb.client.naming");
final Context context = new InitialContext(jndiProperties);

final String appName = "";

final String moduleName = "myBeans";
// THIS IS THE NAME OF THE JAR WITH YOUR EJBs. Write its name here, without the .jar.

final String distinctName = "";
//    AS7 allows deployments to have an distinct name. If you don't use this feature, let this field empty.

final String beanName = MyBean.class.getSimpleName();
//EJB CLASS WITH THE IMPLEMENTATION (simple name)

final String viewClassName = Bean.class.getName();
// FULLY QUALIFIED NAME OF THE REMOTE CLASS (interface).

Bean bean = (Bean) context.lookup("ejb:" + appName + "/" + moduleName + "/" + distinctName + "/" + beanName + "!" + viewClassName)

//NOTICE THAT DOING LOOKUP FOR STATELESS EJBs IS DIFFERENT FROM  STATEFUL EJBs!!!

}

}

It is not over yet!
Now you must add some jars to your classpath!
You’ll need these jars:

  • jboss-transaction-api_1.1_spec-1.0.0.Final.jar
  • jboss-ejb-api_3.1_spec-1.0.1.Final.jar
  • jboss-ejb-client-1.0.0.Beta10.jar
  • jboss-marshalling-1.3.0.GA.jar
  • xnio-api-3.0.0.CR5.jar
  • jboss-remoting-3.2.0.CR6.jar
  • jboss-logging-3.1.0.Beta3.jar
  • xnio-nio-3.0.0.CR5.jar
  • jboss-sasl-1.0.0.Beta9.jar
  • jboss-marshalling-river-1.3.0.GA.jar

You can find all these jars into your Jboss AS 7 folder inside “modules” folder.
Or, to make things more simple, I’ve created this project at github ->https://github.com/hannelita/jboss-as-libs-ejb-lookup

All necessary libs are there, just include them into your classpath and things should work :)

Need more references? You can find the here:

Docs -> https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI

Issue discussion -> https://issues.jboss.org/browse/AS7-1338

Project example -> https://github.com/jaikiran/quickstart/tree/master/ejb-remote

I’d like to thank a guy called Jaikiran Pai for publishing this information into JBoss Docs! :)

Well, just to finish the topic – I think its still an ugly way to do ejb lookup. For xample, that static block and all those strings are disgusting. Hope to have a better solution for further versions! :)

December 30, 2011 at 8:40 pm 3 comments

jbpm + Seam 3 + JBoss AS 7 => Yes, Solved!

Hi, all!!

Some of you emailed me saying that it was impossible to have jbpm + Seam 3 + JBoss AS 7 up and running. And yes, I have been trying to deploy an application with this death combo and have been experienced some problems.
First of all, I entered #seam-dev IRC chat, and found out that I should use version 3.0.1-SNAPSHOT for Seam modules (in case, I had to adopt this version for persistence, config and faces module). 3.0.1-SNAPSHOT really solved lots of problems, BUT I still got some weird persistence problems when I deployed the application. Obviously I thought they were related to persistence module, but no, it was Security module that is unstable until the release of this post. So, I prefer to remove Security module for while, I did not have time to see how could I hack it. Well, everything should work by now, but… No. I started having weird problems with faces-config.xml – JBoss log accused some exceptions telling me something like that:
18:06:56,635 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-5) Unsanitized stacktrace from failed start…: java.lang.UnsupportedOperationException
     at javax.faces.application.Application.getResourceHandler(Application.java:287) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
     at javax.faces.application.ApplicationWrapper.getResourceHandler(ApplicationWrapper.java:506) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
     at org.jboss.seam.faces.environment.SeamApplicationWrapper$Proxy$_$$_WeldClientProxy.getResourceHandler(SeamApplicationWrapper$Proxy$_$$_WeldClientProxy.java) [seam-faces-3.1.0-20110720.041339-24.jar:]
     at com.sun.faces.config.processor.ApplicationConfigProcessor.setResourceHandler(ApplicationConfigProcessor.java:752) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:310) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:116) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:216) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:339) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:226) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
     at org.apache.catalina.core.StandardContext.start(StandardContext.java:3821) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
     at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
     at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
     at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
18:06:56,637 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-5) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
     at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:358) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:226) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
     at org.apache.catalina.core.StandardContext.start(StandardContext.java:3821) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
     at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
     at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
     at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
Caused by: java.lang.UnsupportedOperationException
     at javax.faces.application.Application.getResourceHandler(Application.java:287) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
     at javax.faces.application.ApplicationWrapper.getResourceHandler(ApplicationWrapper.java:506) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
     at org.jboss.seam.faces.environment.SeamApplicationWrapper$Proxy$_$$_WeldClientProxy.getResourceHandler(SeamApplicationWrapper$Proxy$_$$_WeldClientProxy.java) [seam-faces-3.1.0-20110720.041339-24.jar:]
     at com.sun.faces.config.processor.ApplicationConfigProcessor.setResourceHandler(ApplicationConfigProcessor.java:752) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:310) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:116) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:216) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:339) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     … 9 more
18:06:56,639 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/ui]] (MSC service thread 1-5) Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
     at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:294) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
     at org.apache.catalina.core.StandardContext.start(StandardContext.java:3821) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
     at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
     at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
     at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
Caused by: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
     at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:358) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:226) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     … 8 more
Caused by: java.lang.UnsupportedOperationException
     at javax.faces.application.Application.getResourceHandler(Application.java:287) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
     at javax.faces.application.ApplicationWrapper.getResourceHandler(ApplicationWrapper.java:506) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
     at org.jboss.seam.faces.environment.SeamApplicationWrapper$Proxy$_$$_WeldClientProxy.getResourceHandler(SeamApplicationWrapper$Proxy$_$$_WeldClientProxy.java) [seam-faces-3.1.0-20110720.041339-24.jar:]
     at com.sun.faces.config.processor.ApplicationConfigProcessor.setResourceHandler(ApplicationConfigProcessor.java:752) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:310) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:116) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:216) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:339) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     … 9 more
18:06:56,641 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Error listenerStart
18:06:56,641 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Context [/ui] startup failed due to previous errors
18:06:56,642 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-5) Unexpected exception when attempting to tear down the Mojarra runtime: java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.application.ApplicationFactory
     at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:804) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
     at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:306) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
     at com.sun.faces.config.InitFacesContext.getApplication(InitFacesContext.java:108) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:327) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
     at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3465) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
     at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3970) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
     at org.apache.catalina.core.StandardContext.start(StandardContext.java:3888) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
     at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
     at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
     at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
18:06:56,646 INFO  [org.jboss.web] (MSC service thread 1-5) registering web context: /ui
18:06:56,647 INFO  [org.jboss.as] (MSC service thread 1-5) JBoss AS 7.0.0.Final “Lightning” started in 22974ms – Started 485 of 544 services (59 services are passive or on-demand)
Wow, really weird. Removing Seam Faces module seems to solve the problem. LOL, obviously I couldn’t remove it. So, there should be some dependency screwing up my project. After 3 days looking for that, I found out what was it. As the title of the post says, this project uses jbpm, and one of jbpm modules is the human-tasks modules, which… Has a seam 2 lib as one of its dependencies. Yep, thats true, so Seam 2 crashes with Seam 3 causing lots of weird exceptions…
So i just removed the Seam 2 dependency adding a <exclusion> block at my pom.xml:

<exclusion>

<groupId>org.jboss.seam</groupId>

<artifactId>jboss-seam</artifactId>

</exclusion>
 (add this into the jar that depends on jbpm human-task module)
Then, just put Seam faces module back. Everything sould work fine :)

July 27, 2011 at 6:36 pm 2 comments

jbpm5 and Jboss AS 7 – little issue

Hi, all!

Recently I tried to deploy a web application in JBoss AS 7 that contains some jbpm 5 dependencies on its pom.xml.
Unfortunately I got stucked into a weird error – “Deployment of “ui.war” was rolled back with failure message {“Services with missing/unavailable dependencies” => [“jboss.persistenceunit.\”ui.war#org.jbpm.task\” missing [ jboss.data-source.java:/ ]“]” [see the image below]:

So, as I was a jbpm newbie, I decided to take a look at docs to try to answers some questions about this, after taking some time asking my self “Y U NO WORK?”
The problem is that the dependency

<groupId>org.jbpm</groupId></pre>
<artifactId>jbpm-human-task</artifactId>

contains a persistence.xml file with this content:

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<persistence version="1.0"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence

http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd

                                 http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"
             xmlns:orm="http://java.sun.com/xml/ns/persistence/orm"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns="http://java.sun.com/xml/ns/persistence">
  <persistence-unit name="org.jbpm.task">
    <provider>org.hibernate.ejb.HibernatePersistence</provider>
    <class>org.jbpm.task.Attachment</class>
    <class>org.jbpm.task.Content</class>
    <class>org.jbpm.task.BooleanExpression</class>
    <class>org.jbpm.task.Comment</class>
    <class>org.jbpm.task.Deadline</class>
    <class>org.jbpm.task.Comment</class>
    <class>org.jbpm.task.Deadline</class>
    <class>org.jbpm.task.Delegation</class>
    <class>org.jbpm.task.Escalation</class>
    <class>org.jbpm.task.Group</class>
    <class>org.jbpm.task.I18NText</class>
    <class>org.jbpm.task.Notification</class>
    <class>org.jbpm.task.EmailNotification</class>
    <class>org.jbpm.task.EmailNotificationHeader</class>
    <class>org.jbpm.task.PeopleAssignments</class>
    <class>org.jbpm.task.Reassignment</class>
    <class>org.jbpm.task.Status</class>
    <class>org.jbpm.task.Task</class>
    <class>org.jbpm.task.TaskData</class>
    <class>org.jbpm.task.SubTasksStrategy</class>
    <class>org.jbpm.task.OnParentAbortAllSubTasksEndStrategy</class>
    <class>org.jbpm.task.OnAllSubTasksEndParentEndStrategy</class>
    <class>org.jbpm.task.User</class>
    <properties>
      <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>
      <property name="hibernate.connection.driver_class" value="org.h2.Driver"/>
      <property name="hibernate.connection.url" value="jdbc:h2:mem:mydb" />
      <property name="hibernate.connection.username" value="sa"/>
      <property name="hibernate.connection.password" value="sasa"/>
      <property name="hibernate.connection.autocommit" value="false" />
      <property name="hibernate.max_fetch_depth" value="3"/>
      <property name="hibernate.hbm2ddl.auto" value="create" />
      <property name="hibernate.show_sql" value="false" />
    </properties>
  </persistence-unit>
</persistence> 
AS 7 gets crazy about it because it reads this file from jbpm-human-task jar and cannot find the <jta-data-source> tag! Even if you create a new persistence.xml file containing this persistence unit and try to point a jta-data-source, it will not work, because JBoss AS still reads this persistence inside this jar!
After I realized that, I found some bug reports (here and here) talking about similar issues.
For while I dont think there’s a fix for that. If you want to test you application without jbpm-human-task features, I suggest you to add this lines of exclusion into your pom.xml:
<exclusions><exclusion>

<groupId>org.jbpm</groupId>

<artifactId>jbpm-human-task</artifactId>

</exclusion>

</exclusions>

Edited: Sures, removing the module is the worst solution in the world. I just blogged to show you where the problem was. I suggest you clone jbpm project at github (you will have to clone Drools project also). After that, remover the persistence file into human-task module and rebuild it (tip – manually remove jbpm into your local maven repository. This will avoid lots of problems. Then, create a persistence.xml with this content, and just add the tag <jta-data-source>. Finally, run mvn -o clean install into the project that depends on jbpm. )

July 14, 2011 at 3:01 pm 5 comments


Calendar

July 2014
M T W T F S S
« Mar    
 123456
78910111213
14151617181920
21222324252627
28293031  

Posts by Month

Posts by Category


Follow

Get every new post delivered to your Inbox.