[JBoss JIRA] (DROOLS-2397) PMML modules have classloader issues in OSGi
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2397?page=com.atlassian.jira.plugi... ]
Tibor Zimányi updated DROOLS-2397:
----------------------------------
Sprint: 2018 Week 33-35 (was: 2018 Week 33-35, 2018 Week 36-38)
> PMML modules have classloader issues in OSGi
> --------------------------------------------
>
> Key: DROOLS-2397
> URL: https://issues.jboss.org/browse/DROOLS-2397
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.6.0.Final
> Environment: Equinox OSGi container, Java 8
> Reporter: Jens Reimann
> Assignee: Lance Leverich
> Labels: drools-core
>
> The drools PMML modules (drools-pmml and kie-pmml) both suffer from a few class loader issues when running inside an OSGi container.
> The KieBase built for transforming the PMML model to Drools model selects the wrong class loader (based on the context class loader). The JAXB instance creator fails with the same problem.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-2397) PMML modules have classloader issues in OSGi
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2397?page=com.atlassian.jira.plugi... ]
Tibor Zimányi updated DROOLS-2397:
----------------------------------
Story Points: 8
> PMML modules have classloader issues in OSGi
> --------------------------------------------
>
> Key: DROOLS-2397
> URL: https://issues.jboss.org/browse/DROOLS-2397
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.6.0.Final
> Environment: Equinox OSGi container, Java 8
> Reporter: Jens Reimann
> Assignee: Lance Leverich
> Labels: drools-core
>
> The drools PMML modules (drools-pmml and kie-pmml) both suffer from a few class loader issues when running inside an OSGi container.
> The KieBase built for transforming the PMML model to Drools model selects the wrong class loader (based on the context class loader). The JAXB instance creator fails with the same problem.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-2989) Avoid refire of rules with synthetic Fact Handles
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2989?page=com.atlassian.jira.plugi... ]
Tibor Zimányi updated DROOLS-2989:
----------------------------------
Story Points: 5
> Avoid refire of rules with synthetic Fact Handles
> -------------------------------------------------
>
> Key: DROOLS-2989
> URL: https://issues.jboss.org/browse/DROOLS-2989
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Reporter: Luca Molteni
> Assignee: Luca Molteni
>
> Currently the FromNode and the AccumulateNode create "synthetic" fact handles, that means they're not serialized and they're recreated in memory each time we need the access.
> There's already a way to avoid the refiring of the rules but involves serializing and deserializing these synthetic Fact Handles without the objects.
> We now want a better way to do it by serializing the objects without their FactHandles and at the same time keep the same behaviour as before (same number of rules should fire)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-2877) Update the top level data type, considering changes in an external/nested sub data type
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2877?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2877:
--------------------------------
Description:
User is able to achieve inconsistent state in *Manage custom data type dialog* See the attached picture. There is changed top level itemDefinition *Address* to *Adress111* however the itemDefinition *Person* stil shows it address field as *Adress*, it should be *Adress111* too.
h2. Steps to reproduce
- Open the attached model
- Invoke manage custom data type dialog
- Change the Address item definition as shown in picture
-- Person item definition should update its fields
- Reopen the manage dialog
- Person will still have field of *Adress* type
- Click edito to this field
-- Nothing selected will be shown
-- It should select *Adress111*
h2. Acceptance test
- Steps to reproduce fixed (/)
- Change item definition that should affect multiple item definitions (/)
- Changing multiple item definititons in parallel is prohibited (x)
was:
User is able to achieve inconsistent state in *Manage custom data type dialog* See the attached picture. There is changed top level itemDefinition *Address* to *Adress111* however the itemDefinition *Person* stil shows it address field as *Adress*, it should be *Adress111* too.
h2. Steps to reproduce
- Open the attached model
- Invoke manage custom data type dialog
- Change the Address item definition as shown in picture
-- Person item definition should update its fields
- Reopen the manage dialog
- Person will still have field of *Adress* type
- Click edito to this field
-- Nothing selected will be shown
-- It should select *Adress111*
h2. Acceptance test
- Steps to reproduce fixed (/)
- Change item definition that should affect multiple item definitions
- Changing multiple item definititons in parallel is prohibited (x)
> Update the top level data type, considering changes in an external/nested sub data type
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-2877
> URL: https://issues.jboss.org/browse/DROOLS-2877
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.11.0.Final
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Labels: drools-tools
> Attachments: Screenshot from 2018-08-31 14-59-52.png, itemDef-dependency.dmn
>
>
> User is able to achieve inconsistent state in *Manage custom data type dialog* See the attached picture. There is changed top level itemDefinition *Address* to *Adress111* however the itemDefinition *Person* stil shows it address field as *Adress*, it should be *Adress111* too.
> h2. Steps to reproduce
> - Open the attached model
> - Invoke manage custom data type dialog
> - Change the Address item definition as shown in picture
> -- Person item definition should update its fields
> - Reopen the manage dialog
> - Person will still have field of *Adress* type
> - Click edito to this field
> -- Nothing selected will be shown
> -- It should select *Adress111*
> h2. Acceptance test
> - Steps to reproduce fixed (/)
> - Change item definition that should affect multiple item definitions (/)
> - Changing multiple item definititons in parallel is prohibited (x)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-9447) NPE in ejb client and clean shutdown ERROR [org.jboss.ejb.client.invocation] (default task-8) EJBCLIENT000509: Unexpected exception processing EJB request: java.lang.NullPointerException
by tommaso borgato (JIRA)
[ https://issues.jboss.org/browse/WFLY-9447?page=com.atlassian.jira.plugin.... ]
tommaso borgato updated WFLY-9447:
----------------------------------
Affects Version/s: 14.0.1.Final
> NPE in ejb client and clean shutdown ERROR [org.jboss.ejb.client.invocation] (default task-8) EJBCLIENT000509: Unexpected exception processing EJB request: java.lang.NullPointerException
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9447
> URL: https://issues.jboss.org/browse/WFLY-9447
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 14.0.1.Final, 11.0.0.CR1
> Reporter: Radoslav Husar
>
> {noformat}
> ESC[0m13:59:55,004 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0211: Suspending server with 15000 ms timeout.
> ESC[0mESC[0m13:59:55,006 INFO [org.jboss.as.ejb3] (management-handler-thread - 1) WFLYEJB0493: EJB subsystem suspension complete
> ESC[0mESC[0m13:59:55,008 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> ESC[0mESC[0m13:59:55,027 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0019: Host default-host stopping
> ESC[0mESC[0m13:59:55,028 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 72) MODCLUSTER000002: Initiating mod_cluster shutdown
> ESC[0mESC[0m13:59:55,039 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel ejb
> ESC[0mESC[0m13:59:55,039 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel ejb
> ESC[0mESC[0m13:59:55,039 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel ejb
> ESC[0mESC[0m13:59:55,040 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel ejb
> ESC[0mESC[0m13:59:55,040 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel ejb
> ESC[0mESC[0m13:59:55,040 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel ejb
> ESC[0mESC[0m13:59:55,042 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 74) ISPN000029: Passivating all entries to disk
> ESC[0mESC[0m13:59:55,046 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 74) ISPN000030: Passivated 2 entries in 3 milliseconds
> ESC[0mESC[0m13:59:55,055 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> ESC[0mESC[0m13:59:55,055 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 74) WFLYCLINF0003: Stopped twocluster-terminus.jar cache from ejb container
> ESC[0m13:59:55,057 DEBUG [org.jboss.ejb.client.invocation] (pool-1-thread-1) Calling invoke(module = /twocluster-forwarder-tx/ForwardingStatefulSBImpl, strong affinity = Cluster "ejb-forwarder", weak affinity = Node "clusterA-node0"):
> ESC[0m13:59:55,059 INFO [org.jboss.as.test.clustering.twoclusters.bean.forwarding.AbstractForwardingStatefulSBImpl] (default task-124) getSerialAndIncrement() called on forwarding node clusterA-node0
> ESC[0mESC[31m13:59:55,062 ERROR [org.jboss.ejb.client.invocation] (default task-8) EJBCLIENT000509: Unexpected exception processing EJB request: java.lang.NullPointerException
> at org.jboss.as.ejb3.deployment.DeploymentRepository.getStartedModules(DeploymentRepository.java:202)
> at org.jboss.as.ejb3.remote.AssociationImpl.findEJB(AssociationImpl.java:382)
> at org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:115)
> at org.jboss.ejb.protocol.remote.EJBServerChannel$ReceiverImpl.handleInvocationRequest(EJBServerChannel.java:450)
> at org.jboss.ejb.protocol.remote.EJBServerChannel$ReceiverImpl.handleMessage(EJBServerChannel.java:188)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Appears in https://github.com/jbossas/jboss-eap7/pull/2446
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-2877) Update the top level data type, considering changes in an external/nested sub data type
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2877?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2877:
--------------------------------
Description:
User is able to achieve inconsistent state in *Manage custom data type dialog* See the attached picture. There is changed top level itemDefinition *Address* to *Adress111* however the itemDefinition *Person* stil shows it address field as *Adress*, it should be *Adress111* too.
h2. Steps to reproduce
- Open the attached model
- Invoke manage custom data type dialog
- Change the Address item definition as shown in picture
-- Person item definition should update its fields
- Reopen the manage dialog
- Person will still have field of *Adress* type
- Click edito to this field
-- Nothing selected will be shown
-- It should select *Adress111*
h2. Acceptance test
- Steps to reproduce fixed (/)
- Change item definition that should affect multiple item definitions
- Changing multiple item definititons in parallel is prohibited (x)
was:
User is able to achieve inconsistent state in *Manage custom data type dialog* See the attached picture. There is changed top level itemDefinition *Address* to *Adress111* however the itemDefinition *Person* stil shows it address field as *Adress*, it should be *Adress111* too.
h2. Steps to reproduce
- Open the attached model
- Invoke manage custom data type dialog
- Change the Address item definition as shown in picture
-- Person item definition should update its fields
- Reopen the manage dialog
- Person will still have field of *Adress* type
- Click edito to this field
-- Nothing selected will be shown
-- It should select *Adress111*
h2. Acceptance test
- Steps to reproduce fixed
- Change item definition that should affect multiple item definitions
- Changing multiple item definititons in parallel is prohibited (x)
> Update the top level data type, considering changes in an external/nested sub data type
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-2877
> URL: https://issues.jboss.org/browse/DROOLS-2877
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.11.0.Final
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Labels: drools-tools
> Attachments: Screenshot from 2018-08-31 14-59-52.png, itemDef-dependency.dmn
>
>
> User is able to achieve inconsistent state in *Manage custom data type dialog* See the attached picture. There is changed top level itemDefinition *Address* to *Adress111* however the itemDefinition *Person* stil shows it address field as *Adress*, it should be *Adress111* too.
> h2. Steps to reproduce
> - Open the attached model
> - Invoke manage custom data type dialog
> - Change the Address item definition as shown in picture
> -- Person item definition should update its fields
> - Reopen the manage dialog
> - Person will still have field of *Adress* type
> - Click edito to this field
> -- Nothing selected will be shown
> -- It should select *Adress111*
> h2. Acceptance test
> - Steps to reproduce fixed (/)
> - Change item definition that should affect multiple item definitions
> - Changing multiple item definititons in parallel is prohibited (x)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months