[JBoss JIRA] (WFBUILD-34) Use the same groupId:artifactId[:type[:classifier[:version]]] format everywhere
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-34?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFBUILD-34:
--------------------------------------
This introduces an issue where JBoss Modules expects {{groupId:artifactId:version[:classifier]}}.
> Use the same groupId:artifactId[:type[:classifier[:version]]] format everywhere
> -------------------------------------------------------------------------------
>
> Key: WFBUILD-34
> URL: https://issues.jboss.org/browse/WFBUILD-34
> Project: WildFly Build Tools
> Issue Type: Enhancement
> Reporter: Peter Palaga
> Assignee: Stuart Douglas
> Fix For: 1.2.8.Final
>
>
> This both a usability issue and a feature request.
> On the usability side, the artifact formats in module.xml files vs. in feature-pack-build.xml files are not the same:
> * `{{groupId:artifactId\[:version\[:classifier]]}}` in module.xml files
> * `{{groupId:artifactId\[:type\[:classifier]]}}` in feature-pack-build.xml files
> The missing feature is the impossibility to define type/extension in module.xml files and the impossibility to had code version in feature-pack-build.xml files
> The current proposal is to use the same {{groupId:artifactId\[:type\[:classifier\[:version]]]}} format in both kinds of files.
> The proposal is backwards incompatible for module.xml files. But given that the support for hardcoded versions in module.xml files was added just 11 days ago, this will probably impact just a few users.
> I am not sure what artifact format is used by JBoss modules. Maybe `{{groupId:artifactId\[:version\[:classifier]]}}` is taken from there?
> WDYT [~swd847]?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2313) Bad synchronization of ClassAwareObjectStore list of concreteStores can cause ConcurrentModificationException or ArrayIndexOutOfBoundsException while getting session objects
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2313?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-2313:
--------------------------------
Sprint: 2018 Week 05-06
> Bad synchronization of ClassAwareObjectStore list of concreteStores can cause ConcurrentModificationException or ArrayIndexOutOfBoundsException while getting session objects
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2313
> URL: https://issues.jboss.org/browse/DROOLS-2313
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.5.0.Final, 7.6.0.Final
> Reporter: Donatien RIVIERE
> Assignee: Mario Fusco
> Attachments: KieSessionConcurrentTest.java
>
>
> If a thread requests for session objects (using kieSession.getObjects() with or without filters) while another one is inserting objects +*of different concrete classes*+, there is a chance that a new ConcreteObjectStore is added to the concreteStores list at the same time and cause concurrent exception.
> Example when using kieSession.getObjects().*iterator()* :
> {noformat}
> Exception in thread "QueryingThread" java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at org.drools.core.common.ClassAwareObjectStore$CompositeObjectIterator.fetchNextIterator(ClassAwareObjectStore.java:556)
> at org.drools.core.common.ClassAwareObjectStore$AbstractCompositeIterator.nextIterator(ClassAwareObjectStore.java:513)
> at org.drools.core.common.ClassAwareObjectStore$AbstractCompositeIterator.fetchNext(ClassAwareObjectStore.java:499)
> at org.drools.core.common.ClassAwareObjectStore$AbstractCompositeIterator.<init>(ClassAwareObjectStore.java:494)
> at org.drools.core.common.ClassAwareObjectStore$AbstractCompositeIterator.<init>(ClassAwareObjectStore.java:487)
> at org.drools.core.common.ClassAwareObjectStore$AbstractCompositeIterator.<init>(ClassAwareObjectStore.java:478)
> at org.drools.core.common.ClassAwareObjectStore$CompositeObjectIterator.<init>(ClassAwareObjectStore.java:546)
> at org.drools.core.common.ClassAwareObjectStore$CompositeObjectIterator.<init>(ClassAwareObjectStore.java:544)
> at org.drools.core.common.ClassAwareObjectStore.iterateObjects(ClassAwareObjectStore.java:186)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl$ObjectStoreWrapper.iterator(StatefulKnowledgeSessionImpl.java:679)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl$ObjectStoreWrapper.toArray(StatefulKnowledgeSessionImpl.java:710)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl$ObjectStoreWrapper.toArray(StatefulKnowledgeSessionImpl.java:695)
> at ft.drools.KieSessionConcurrentTest.lambda$0(KieSessionConcurrentTest.java:125)
> {noformat}
> Example when using kieSession.getObjects().*toArray()* :
> {noformat}
> Exception in thread "QueryingThread" java.lang.ArrayIndexOutOfBoundsException: 1
> at org.drools.core.impl.StatefulKnowledgeSessionImpl$ObjectStoreWrapper.toArray(StatefulKnowledgeSessionImpl.java:711)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl$ObjectStoreWrapper.toArray(StatefulKnowledgeSessionImpl.java:695)
> at ft.drools.KieSessionConcurrentTest.lambda$0(KieSessionConcurrentTest.java:125)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2313) Bad synchronization of ClassAwareObjectStore list of concreteStores can cause ConcurrentModificationException or ArrayIndexOutOfBoundsException while getting session objects
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2313?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-2313.
---------------------------------
Resolution: Done
Fixed by https://github.com/kiegroup/drools/commit/91cb991a4db283ac00eaa2e16d606d7...
> Bad synchronization of ClassAwareObjectStore list of concreteStores can cause ConcurrentModificationException or ArrayIndexOutOfBoundsException while getting session objects
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2313
> URL: https://issues.jboss.org/browse/DROOLS-2313
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.5.0.Final, 7.6.0.Final
> Reporter: Donatien RIVIERE
> Assignee: Mario Fusco
> Attachments: KieSessionConcurrentTest.java
>
>
> If a thread requests for session objects (using kieSession.getObjects() with or without filters) while another one is inserting objects +*of different concrete classes*+, there is a chance that a new ConcreteObjectStore is added to the concreteStores list at the same time and cause concurrent exception.
> Example when using kieSession.getObjects().*iterator()* :
> {noformat}
> Exception in thread "QueryingThread" java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at org.drools.core.common.ClassAwareObjectStore$CompositeObjectIterator.fetchNextIterator(ClassAwareObjectStore.java:556)
> at org.drools.core.common.ClassAwareObjectStore$AbstractCompositeIterator.nextIterator(ClassAwareObjectStore.java:513)
> at org.drools.core.common.ClassAwareObjectStore$AbstractCompositeIterator.fetchNext(ClassAwareObjectStore.java:499)
> at org.drools.core.common.ClassAwareObjectStore$AbstractCompositeIterator.<init>(ClassAwareObjectStore.java:494)
> at org.drools.core.common.ClassAwareObjectStore$AbstractCompositeIterator.<init>(ClassAwareObjectStore.java:487)
> at org.drools.core.common.ClassAwareObjectStore$AbstractCompositeIterator.<init>(ClassAwareObjectStore.java:478)
> at org.drools.core.common.ClassAwareObjectStore$CompositeObjectIterator.<init>(ClassAwareObjectStore.java:546)
> at org.drools.core.common.ClassAwareObjectStore$CompositeObjectIterator.<init>(ClassAwareObjectStore.java:544)
> at org.drools.core.common.ClassAwareObjectStore.iterateObjects(ClassAwareObjectStore.java:186)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl$ObjectStoreWrapper.iterator(StatefulKnowledgeSessionImpl.java:679)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl$ObjectStoreWrapper.toArray(StatefulKnowledgeSessionImpl.java:710)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl$ObjectStoreWrapper.toArray(StatefulKnowledgeSessionImpl.java:695)
> at ft.drools.KieSessionConcurrentTest.lambda$0(KieSessionConcurrentTest.java:125)
> {noformat}
> Example when using kieSession.getObjects().*toArray()* :
> {noformat}
> Exception in thread "QueryingThread" java.lang.ArrayIndexOutOfBoundsException: 1
> at org.drools.core.impl.StatefulKnowledgeSessionImpl$ObjectStoreWrapper.toArray(StatefulKnowledgeSessionImpl.java:711)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl$ObjectStoreWrapper.toArray(StatefulKnowledgeSessionImpl.java:695)
> at ft.drools.KieSessionConcurrentTest.lambda$0(KieSessionConcurrentTest.java:125)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-6460) JSON-P 1.1 Support
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6460?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-6460:
-------------------------------------
[~rsvoboda] The main reason we didn't use the spec JAR was the {{org.glassfish:javax.json}} library shaded both the API and implementation together. I'm not sure why they did that, but in 1.1 the changed it to only include the implementation.
I don't really know anything about the {{Automatic-Module-Name}} stuff. I just renamed what [~ctomc] had there. Maybe he can explain that part a bit.
It might be too late to rename the repo unfortunately. I think we only named it that because that's artifact id is javax.json.
> JSON-P 1.1 Support
> ------------------
>
> Key: WFLY-6460
> URL: https://issues.jboss.org/browse/WFLY-6460
> Project: WildFly
> Issue Type: Sub-task
> Components: EE
> Reporter: David Lloyd
> Assignee: James Perkins
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9788) EJB over HTTP fails...
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9788?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-9788:
------------------------------
Attachment: Icon indicating the project type.url
> EJB over HTTP fails...
> ----------------------
>
> Key: WFLY-9788
> URL: https://issues.jboss.org/browse/WFLY-9788
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Final
> Reporter: Heiko Lettmann
> Priority: Blocker
> Attachments: Icon indicating the project type.url, Test.zip
>
>
> I stumbled over the issue WFLY-9573. Then I updated to wildfly-http-client-1.0.9.Final which made a few invocations work. There I discovered another issue. I attached a modified Quickstart version to demonstrate it!
> Exception is on the client side:
> Exception in thread "main" javax.ejb.EJBException: java.io.IOException: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
> at org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:128)
> at org.wildfly.httpclient.ejb.HttpInvocationHandler.lambda$handleInternal$0(HttpInvocationHandler.java:130)
> 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)
> Caused by: java.io.IOException: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
> at org.wildfly.httpclient.ejb.HttpInvocationHandler$1.getRequestContent(HttpInvocationHandler.java:204)
> at org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:126)
> ... 4 more
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
> at org.wildfly.httpclient.ejb.HttpInvocationHandler$1.getRequestContent(HttpInvocationHandler.java:178)
> ... 5 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months