[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-3386:
------------------------------------
[~andriese] Any update on this?
> Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3386
> URL: https://issues.jboss.org/browse/WFLY-3386
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Environment: CentOS, Mac (Mountain Lion).
> Reporter: Andries Ehlers
> Assignee: Martin Kouba
>
> Background:
> The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI.
> Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise.
> Error:
> We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below).
> -----------------------------
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na]
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months
[JBoss JIRA] (DROOLS-538) Unable to resolve class error , drools 5.5 in concurrent execution. JSR94Support and Spring
by Maruthi Shanmugam (JIRA)
Maruthi Shanmugam created DROOLS-538:
----------------------------------------
Summary: Unable to resolve class error , drools 5.5 in concurrent execution. JSR94Support and Spring
Key: DROOLS-538
URL: https://issues.jboss.org/browse/DROOLS-538
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5.0.Final
Environment: Linux Red Hat , Enterprise, JDK 1.6, Drools 5.5.Final
Reporter: Maruthi Shanmugam
Assignee: Mark Proctor
Priority: Blocker
We use Drools 5.5 and drool implementation is done through Spring JSR94Support API>
The Rule engine is called in concurrent mode,
i.e , JSR94Support.executeStateless(name,list) is executed through multiple threads.
And when the rules are executed we randomly get the following exception
org.drools.RuntimeDroolsException: Unable to resolve class 'someclass(this is sample)here actual class is printed>'
at org.drools.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:126)
at org.drools.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:48)
at org.drools.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:83)
at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:159)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
at org.drools.reteoo.ReteooStatelessSession.executeWithResults(ReteooStatelessSession.java:273)
The rules are registered every 15 minutes through RuleAdministrator.registerRuleExecutionset ,
so whenever we refresh the rules and the subsequent thread even after the registration is completed, fails with the above message. This happens only when the rules are invoked concurrently.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months
[JBoss JIRA] (WFLY-3531) JPA persistence unit services should start completly before sub-deployments reach the next deployment phase
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-3531?page=com.atlassian.jira.plugin.... ]
Scott Marlow closed WFLY-3531.
------------------------------
> JPA persistence unit services should start completly before sub-deployments reach the next deployment phase
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3531
> URL: https://issues.jboss.org/browse/WFLY-3531
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 9.0.0.Alpha1
>
>
> This is about EAR deployments that contain multiple sub-deployments. Currently, EJB jar sub-deployments may still be starting their JPA persistence units while other sub-deployments move ahead (in parallel) to other deployment phases (which can cause the entity classes to be loaded before the persistence provider has been registered with the class file transformer for the persistence unit).
> Each deployment/sub-deployment should set the NEXT_PHASE_DEP on the persistence unit service (see current phaseContext.addToAttachmentList(Attachments.NEXT_PHASE_DEPS, puServiceName) in PersistenceUnitServiceHandler). For this to work, each deployment/subdeployment should set NEXT_PHASE_DEPS during the FIRST_MODULE_USE phase for each pre-determine persistence unit service name).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months
[JBoss JIRA] (AS7-6245) ClassNotFoundException if CMP2 entity-command is used
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6245?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6245:
----------------------------------------------
Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 901279|https://bugzilla.redhat.com/show_bug.cgi?id=901279] from ASSIGNED to CLOSED
> ClassNotFoundException if CMP2 entity-command is used
> -----------------------------------------------------
>
> Key: AS7-6245
> URL: https://issues.jboss.org/browse/AS7-6245
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Labels: cmp, ejb2
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP)
>
>
> If a EJB2 - CMP2 EntityBean uses an entity-command 'mysql-get-generated-keys' to generate the primary key, the server deploy with an error message:
> Caused by: java.lang.RuntimeException: JBAS018572: Could not load driver class: com.mysql.jdbc.PreparedStatement
> This may happen for different entity-commands if other databases are used!
> If the datasource module is added to the org/jboss/as/cmp modules dependencies, the startup shows:
> MSC000001: Failed to start service ... : JBAS010785: Failed start store manager
> Caused by: java.lang.RuntimeException: JBAS010732: Couldn't create entity command
> Caused by: java.lang.RuntimeException: JBAS018574: Could not load org.jboss.resource.adapter.jdbc.StatementAccess
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months
[JBoss JIRA] (WFLY-1415) Move away from expensive enum switch
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-1415?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-1415:
-----------------------------------
The most important thing to look at are the XML parsers. They use enums for element and attribute names; instead we can just switch and match on the literal string.
As for JIRA formatting, click on the circled ? symbol for information on the tags and formatting. It's not HTML.
> Move away from expensive enum switch
> ------------------------------------
>
> Key: WFLY-1415
> URL: https://issues.jboss.org/browse/WFLY-1415
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: David Lloyd
> Priority: Minor
> Labels: janitor
> Fix For: 9.0.0.CR1
>
>
> We use enums and enum switch extensively. These constructs generate many, many additional classes and bloat the code base unnecessarily.
> All cases where we are using enum-based switches for our XML parsers should be converted to use Java 7 String switch instead. The enum values shall be replaced with String constant fields, all enum switches converted to String switches, and all enum types removed from these classes. The net result should be a reduction by dozens if not hundreds of .class files, and possibly a measurable performance boost as well.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months
[JBoss JIRA] (WFLY-3574) management API blocking write requests during initialization
by Michael Mutschler (JIRA)
[ https://issues.jboss.org/browse/WFLY-3574?page=com.atlassian.jira.plugin.... ]
Michael Mutschler updated WFLY-3574:
------------------------------------
Steps to Reproduce:
In this simple example I try to remove the default ExampleDS (it should fail, but the bug is, that I get no result)
Here is the Listener I use:
{code:title=ConfigListener.java|borderStyle=dashed}
@WebListener
public class ConfigListener implements ServletContextListener {
@Override
public void contextInitialized(ServletContextEvent servletContextEvent) {
RemoveExampleDS.run();
}
@Override
public void contextDestroyed(ServletContextEvent servletContextEvent) {}
}
{code}
RemoveExampleDS has the actual code to remove the Datasource:
{code:title=RemoveExampleDS.java|borderStyle=dashed}
public class RemoveExampleDS {
public static void run() {
try {
deleteDataSource("ExampleDS");
} catch (IOException e) { log(e); }
}
private static void deleteDataSource(String dsName) throws IOException {
log("removing datasource " + dsName);
final ModelNode request = new ModelNode();
request.get(ClientConstants.OP).set(ClientConstants.REMOVE_OPERATION);
request.get(ClientConstants.OP_ADDR).add("subsystem", "datasources");
request.get(ClientConstants.OP_ADDR).add("data-source", dsName);
execute(request);
log("datasource " + dsName + " removed");
}
private static void execute(ModelNode request) throws IOException {
log("connecting to management");
ModelControllerClient client = ModelControllerClient.Factory.create("localhost", 9990);
log("executing: " + request);
ModelNode response = client.execute(request);
log("response: " + response);
client.close();
log(response.get(ClientConstants.RESULT));
}
private static void log(Object o) { System.out.println(o); }
}
{code}
I packed this into a war, and it is the only war I am running in a default wildfly installation.
The log looks like this. Note: there is no response for the remove!
{noformat}
2014-07-02 14:26:54,280 INFO [stdout] (MSC service thread 1-12) removing datasource ExampleDS
2014-07-02 14:26:54,292 INFO [stdout] (MSC service thread 1-12) connecting to management
2014-07-02 14:26:54,317 INFO [stdout] (MSC service thread 1-12) executing: {
2014-07-02 14:26:54,318 INFO [stdout] (MSC service thread 1-12) "operation" => "remove",
2014-07-02 14:26:54,319 INFO [stdout] (MSC service thread 1-12) "address" => [
2014-07-02 14:26:54,319 INFO [stdout] (MSC service thread 1-12) ("subsystem" => "datasources"),
2014-07-02 14:26:54,319 INFO [stdout] (MSC service thread 1-12) ("data-source" => "ExampleDS")
2014-07-02 14:26:54,320 INFO [stdout] (MSC service thread 1-12) ]
2014-07-02 14:26:54,320 INFO [stdout] (MSC service thread 1-12) }
2014-07-02 14:26:54,344 INFO [org.xnio] (MSC service thread 1-12) XNIO version 3.2.2.Final
2014-07-02 14:26:54,359 INFO [org.xnio.nio] (MSC service thread 1-12) XNIO NIO Implementation Version 3.2.2.Final
{noformat}
was:
In this simple example I try to remove the default ExampleDS (it should fail, but the bug is, that I get no result)
Here is the Listener I use:
{code:title=ConfigListener.java|borderStyle=dashed}
@WebListener
public class ConfigListener implements ServletContextListener {
@Override
public void contextInitialized(ServletContextEvent servletContextEvent) {
RemoveExampleDS.run();
}
@Override
public void contextDestroyed(ServletContextEvent servletContextEvent) {}
}
{code}
RemoveExampleDS has the actual code to remove the Datasource:
{code:title=RemoveExampleDS.java|borderStyle=dashed}
public class RemoveExampleDS {
public static void run() {
try {
deleteDataSource("ExampleDS");
} catch (IOException e) { log(e); }
}
private static void deleteDataSource(String dsName) throws IOException {
log("removing datasource " + dsName);
final ModelNode request = new ModelNode();
request.get(ClientConstants.OP).set(ClientConstants.REMOVE_OPERATION);
request.get(ClientConstants.OP_ADDR).add("subsystem", "datasources");
request.get(ClientConstants.OP_ADDR).add("data-source", dsName);
execute(request);
log("datasource " + dsName + " removed");
}
private static void execute(ModelNode request) throws IOException {
log("connecting to management");
ModelControllerClient client = ModelControllerClient.Factory.create("localhost", 9990);
log("executing: " + request);
ModelNode response = client.execute(request);
log("response: " + response);
client.close();
log(response.get(ClientConstants.RESULT));
}
private static void log(Object o) { System.out.println(o); }
}
{code}
I packed this into a war, and it is the only war I am running in a default wildfly installation.
The log looks like this. Note: there is no response for the remove!
{{
2014-07-02 14:26:54,280 INFO [stdout] (MSC service thread 1-12) removing datasource ExampleDS
2014-07-02 14:26:54,292 INFO [stdout] (MSC service thread 1-12) connecting to management
2014-07-02 14:26:54,317 INFO [stdout] (MSC service thread 1-12) executing: {
2014-07-02 14:26:54,318 INFO [stdout] (MSC service thread 1-12) "operation" => "remove",
2014-07-02 14:26:54,319 INFO [stdout] (MSC service thread 1-12) "address" => [
2014-07-02 14:26:54,319 INFO [stdout] (MSC service thread 1-12) ("subsystem" => "datasources"),
2014-07-02 14:26:54,319 INFO [stdout] (MSC service thread 1-12) ("data-source" => "ExampleDS")
2014-07-02 14:26:54,320 INFO [stdout] (MSC service thread 1-12) ]
2014-07-02 14:26:54,320 INFO [stdout] (MSC service thread 1-12) }
2014-07-02 14:26:54,344 INFO [org.xnio] (MSC service thread 1-12) XNIO version 3.2.2.Final
2014-07-02 14:26:54,359 INFO [org.xnio.nio] (MSC service thread 1-12) XNIO NIO Implementation Version 3.2.2.Final
}}
> management API blocking write requests during initialization
> ------------------------------------------------------------
>
> Key: WFLY-3574
> URL: https://issues.jboss.org/browse/WFLY-3574
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.1.0.Final
> Environment: default configuration
> Reporter: Michael Mutschler
> Assignee: Alexey Loubyansky
> Priority: Critical
>
> I want to apply some configuration before the real application is starting. Mainly I want to update a datasource. Therefore I wrote a WebListener, and during the initialization I want to modify the wildfly configuration via management API.
> I can read the configuration, but when I want to execute a delete or add request, nothing happens; the command does not return! There seems to be a deadlock.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months
[JBoss JIRA] (WFLY-3574) management API blocking write requests during initialization
by Michael Mutschler (JIRA)
Michael Mutschler created WFLY-3574:
---------------------------------------
Summary: management API blocking write requests during initialization
Key: WFLY-3574
URL: https://issues.jboss.org/browse/WFLY-3574
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CLI
Affects Versions: 8.1.0.Final
Environment: default configuration
Reporter: Michael Mutschler
Assignee: Alexey Loubyansky
Priority: Critical
I want to apply some configuration before the real application is starting. Mainly I want to update a datasource. Therefore I wrote a WebListener, and during the initialization I want to modify the wildfly configuration via management API.
I can read the configuration, but when I want to execute a delete or add request, nothing happens; the command does not return! There seems to be a deadlock.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months
[JBoss JIRA] (WFLY-2929) Create maven modules to build all the new distributions
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2929?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-2929.
----------------------------------
Resolution: Done
> Create maven modules to build all the new distributions
> -------------------------------------------------------
>
> Key: WFLY-2929
> URL: https://issues.jboss.org/browse/WFLY-2929
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Fix For: 9.0.0.CR1
>
>
> This involves creating the following new maven modules:
> core-build
> web-build
> ee-build
> clustering-build
> These will create distributions that correspond to the output of the split up repositories. The final build step will be changed to merge all these distributions together.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months