[JBoss JIRA] (WFCORE-1448) AttributeParser for ObjectListAttributeDefinitions doesn't differentiate between empty and absent object lists
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1448?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1448:
-------------------------------------
Fix Version/s: 3.0.0.Alpha1
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1477
> AttributeParser for ObjectListAttributeDefinitions doesn't differentiate between empty and absent object lists
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1448
> URL: https://issues.jboss.org/browse/WFCORE-1448
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 3.0.0.Alpha1
>
>
> Attributes of type ObjectList are left undefined when their enclosing element is empty, which makes it impossible to differentiate an empty object list from an unspecified one.
> The ability to distinguish the two scenarios is important in the security manager subsystem. Consider this configuration:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:security-manager:1.0">
> <deployment-permissions>
> <mininum-set>
> ....
> </minimum-set>
> </deployment-permissions>
> </subsystem>
> {code}
> The maximum-set is absent and this case we want to use a default set with AllPermission. Now consider another configuration:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:security-manager:1.0">
> <deployment-permissions>
> <mininum-set/>
> <maximum-set/>
> </deployment-permissions>
> </subsystem>
> {code}
> In this case, maximum-set has been specified but it is empty, which means the admin/user deliberately wants to use an emtpy set, possibly to enforce that no deployments with special permissions requirements get deployed.
> The problem is that both scenarios result in an undefined attribute for the maximum-set, which means that the default AllPermission set ends up being used in both cases. The parser doesn't initialize the attribute with an empty list when the enclosing element is present but is empty. So in the end, both approaches result in an undefined attribute.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6444) Apache http classes not found
by Andrei Ivanov (JIRA)
Andrei Ivanov created WFLY-6444:
-----------------------------------
Summary: Apache http classes not found
Key: WFLY-6444
URL: https://issues.jboss.org/browse/WFLY-6444
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.Final, 10.1.0.Final
Reporter: Andrei Ivanov
Assignee: Jason Greene
Attachments: wildfly-httpclient-test.zip
Hi,
I've created a trivial JAX-RS application with a CDI producer for a RestEasy JAX-RS client proxy.
I also need to customize the HTTP engine a bit.
The app deploys fine on JBoss 7.1.1.
Trying to upgrade to WildFly 10.0, I got a weird error:
{noformat}
DEBUG [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 2) Catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error while loading class siteaccess.web.backend.service.RestEasyClientProducer
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:186)
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:194)
at org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotatedType(FastAnnotatedTypeLoader.java:113)
at org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.createContext(FastAnnotatedTypeLoader.java:102)
at org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotatedType(FastAnnotatedTypeLoader.java:91)
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:97)
at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:65)
at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:62)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.NoClassDefFoundError: org/apache/http/conn/socket/LayeredConnectionSocketFactory
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
at java.lang.Class.getDeclaredConstructors(Class.java:2020)
at org.jboss.weld.annotated.slim.backed.SecurityActions.getDeclaredConstructors(SecurityActions.java:57)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedConstructors.computeValue(BackedAnnotatedType.java:163)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedConstructors.computeValue(BackedAnnotatedType.java:160)
at org.jboss.weld.util.LazyValueHolder.get(LazyValueHolder.java:35)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$EagerlyInitializedLazyValueHolder.<init>(BackedAnnotatedType.java:156)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedConstructors.<init>(BackedAnnotatedType.java:160)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedConstructors.<init>(BackedAnnotatedType.java:160)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.<init>(BackedAnnotatedType.java:61)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.of(BackedAnnotatedType.java:44)
at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.load(ClassTransformer.java:83)
at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.load(ClassTransformer.java:80)
at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3527)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2319)
at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2282)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2197)
at com.google.common.cache.LocalCache.get(LocalCache.java:3937)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3941)
at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4824)
at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74)
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:175)
... 14 more
Caused by: java.lang.ClassNotFoundException: org.apache.http.conn.socket.LayeredConnectionSocketFactory from [Module "deployment.wildfly-httpclient-test.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
... 38 more
{noformat}
I've upgraded Weld to 2.3.3 and the http client jars to the latest versions (using details from https://developer.jboss.org/thread/242798).
Now I get the exception for a different class:
{noformat}
Caused by: java.lang.ClassNotFoundException: org.apache.http.protocol.HttpContext from [Module "deployment.wildfly-httpclient-test.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
... 38 more
{noformat}
I'm getting this exception also when testing with an unmodified WildFly 10.1 snapshot ( Build #2244 (Mar 24, 2016 1:10:44 PM) from https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/)
I've first asked for help on the [forum|https://developer.jboss.org/thread/268871], but got no answers :(
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBEE-161) BeanELResolver does not support methods that use varargs
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JBEE-161?page=com.atlassian.jira.plugin.s... ]
Scott Marlow commented on JBEE-161:
-----------------------------------
released jboss-el-api_2.2_spec-1.0.6.Final
> BeanELResolver does not support methods that use varargs
> --------------------------------------------------------
>
> Key: JBEE-161
> URL: https://issues.jboss.org/browse/JBEE-161
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-el-api
> Environment: jboss-el-api_2.2_spec-1.0.4.Final-redhat-1
> Reporter: Ingo Weiss
> Assignee: Scott Marlow
> Labels: el
> Fix For: jboss-el-api_3.0_spec-1.0.6.Final
>
> Attachments: beanELResolver4VarArgs.zip
>
>
> When passing BeanELResolver a method that uses varargs, BeanELResolver throws the following exception:
> {code}
> java.lang.IllegalArgumentException: wrong number of arguments
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:834)
> at javax.el.BeanELResolver.invoke(BeanELResolver.java:527)
> at org.apache.el.parser.AstValue.getValue(AstValue.java:156)
> at BeanELResolverTest.readExpressionValue(BeanELResolverTest.java:32)
> at BeanELResolverTest.testMethodWithFixArgumentList(BeanELResolverTest.java:21)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBEE-161) BeanELResolver does not support methods that use varargs
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBEE-161?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on JBEE-161:
----------------------------------------------
Dmitrii Tikhomirov <dtikhomi(a)redhat.com> changed the Status of [bug 1292891|https://bugzilla.redhat.com/show_bug.cgi?id=1292891] from POST to MODIFIED
> BeanELResolver does not support methods that use varargs
> --------------------------------------------------------
>
> Key: JBEE-161
> URL: https://issues.jboss.org/browse/JBEE-161
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-el-api
> Environment: jboss-el-api_2.2_spec-1.0.4.Final-redhat-1
> Reporter: Ingo Weiss
> Assignee: Scott Marlow
> Labels: el
> Fix For: jboss-el-api_3.0_spec-1.0.6.Final
>
> Attachments: beanELResolver4VarArgs.zip
>
>
> When passing BeanELResolver a method that uses varargs, BeanELResolver throws the following exception:
> {code}
> java.lang.IllegalArgumentException: wrong number of arguments
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:834)
> at javax.el.BeanELResolver.invoke(BeanELResolver.java:527)
> at org.apache.el.parser.AstValue.getValue(AstValue.java:156)
> at BeanELResolverTest.readExpressionValue(BeanELResolverTest.java:32)
> at BeanELResolverTest.testMethodWithFixArgumentList(BeanELResolverTest.java:21)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6443) Inconsistent behavior of journal object store for heuristic state
by Tom Jenkinson (JIRA)
Tom Jenkinson created WFLY-6443:
-----------------------------------
Summary: Inconsistent behavior of journal object store for heuristic state
Key: WFLY-6443
URL: https://issues.jboss.org/browse/WFLY-6443
Project: WildFly
Issue Type: Bug
Components: Transactions
Reporter: Tom Jenkinson
Assignee: Michael Musgrove
Priority: Blocker
Fix For: 10.1.0.Final
We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final.
Our test case:
* enlist activemq JMS resource
* enlist test XA resource
* prepare JMS resource
* prepare test XA resource
* commit JMS resource
* commit test XA resource
** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}}
2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}
* probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}}
** expecting one indoubt participant in HEURISTIC state
* calling operation {{recovery}} on all transaction's participants
* do recovery
This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants.
Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6442) Inconsistent behavior of journal object store for heuristic state
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6442?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-6442:
--------------------------------
Fix Version/s: 10.1.0.Final
> Inconsistent behavior of journal object store for heuristic state
> -----------------------------------------------------------------
>
> Key: WFLY-6442
> URL: https://issues.jboss.org/browse/WFLY-6442
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: Ondřej Chaloupka
> Assignee: Michael Musgrove
> Priority: Blocker
> Fix For: 10.1.0.Final
>
>
> We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final.
> Our test case:
> * enlist activemq JMS resource
> * enlist test XA resource
> * prepare JMS resource
> * prepare test XA resource
> * commit JMS resource
> * commit test XA resource
> ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}}
> 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}
> * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}}
> ** expecting one indoubt participant in HEURISTIC state
> * calling operation {{recovery}} on all transaction's participants
> * do recovery
> This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants.
> Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6442) Inconsistent behavior of journal object store for heuristic state
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6442?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson moved JBEAP-4001 to WFLY-6442:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6442 (was: JBEAP-4001)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Transactions
(was: Transactions)
Target Release: (was: 7.0.0.GA)
Affects Version/s: (was: 7.0.0.ER7)
Affects Testing: (was: Regression)
> Inconsistent behavior of journal object store for heuristic state
> -----------------------------------------------------------------
>
> Key: WFLY-6442
> URL: https://issues.jboss.org/browse/WFLY-6442
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: Ondřej Chaloupka
> Assignee: Michael Musgrove
> Priority: Blocker
>
> We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final.
> Our test case:
> * enlist activemq JMS resource
> * enlist test XA resource
> * prepare JMS resource
> * prepare test XA resource
> * commit JMS resource
> * commit test XA resource
> ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}}
> 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}
> * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}}
> ** expecting one indoubt participant in HEURISTIC state
> * calling operation {{recovery}} on all transaction's participants
> * do recovery
> This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants.
> Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6349) JMSXGroupId has no effect on JMSProducer
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6349?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-6349:
-----------------------------------
You are right: there is indeed a bug in Artemis: https://issues.apache.org/jira/browse/ARTEMIS-462.
The workaround is to set the JMSXGroupID on the Message until Artemis fixes this bug.
Note that JMSXGroupSeq is an optional behaviour and your use case is valid. Messages must be grouped using JMSXGroupId regardless of the presence of the JMSXGroupSeq property
> JMSXGroupId has no effect on JMSProducer
> ----------------------------------------
>
> Key: WFLY-6349
> URL: https://issues.jboss.org/browse/WFLY-6349
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Harald Wellmann
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
>
> h3. Scenario
> I'm setting the {{JMSXGroupID}} on a {{JMSProducer}} to achieve message delivery in the correct order. The consumer is a message-driven bean.
> {code}
> JMSProducer producer = context.createProducer();
> producer = producer.setProperty("JMSXGroupID", "sequential");
> producer = producer.setProperty("foo", "bar");
> for (int i = 0; i < 50; i++) {
> msgNumber++;
> String text = "This is message " + msgNumber;
> producer.send(queue, text);
> }
> {code}
> h3. Expected Behaviour
> The messages are received in the correct order, the properties {{JMSXGroupID}} and {{foo}} are set on the receiver side.
> h3. Actual Behaviour
> The messages are received in random order. Property {{foo}} is set, but property {{JMSXGroupID}} is null on the receiver side.
> h3. Workaround
> Create a {{TextMessage}} and set the properties on the message, not on the producer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6441) naming context is not setup when starting the persistence unit
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6441?page=com.atlassian.jira.plugin.... ]
Scott Marlow moved JBEAP-3999 to WFLY-6441:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6441 (was: JBEAP-3999)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JPA / Hibernate
(was: JPA / Hibernate)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 10.0.0.Final
9.0.2.Final
JBoss AS7 7.2.0.Final
JBoss AS7 7.1.1.Final
(was: 7.0.0.GA)
> naming context is not setup when starting the persistence unit
> --------------------------------------------------------------
>
> Key: WFLY-6441
> URL: https://issues.jboss.org/browse/WFLY-6441
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 9.0.2.Final, JBoss AS7 7.2.0.Final, JBoss AS7 7.1.1.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
>
> ookup of env-entry throws NameNotFoundException during persistence unit startup
> Version-Release number of selected component (if applicable):
> How reproducible:
> always
> Steps to Reproduce:
> 1. add env-entry in application.xml
> 2. try to lookup during persistent unit startup, e.g.
> public class MyType implements UserType {
> ...
> @Override
> public int[] sqlTypes() {
> try {
> Object ctx = new InitialContext().lookup("java:app/env");
> log.info("java:app/env from JPA = " + ctx);
> } catch (Exception e) {
> log.error("unable to get java:app/env from JPA", e);
> }
> return new int[] { Types.VARCHAR };
> }
> Actual results:
> NameNotFoundException
> Expected results:
> value of env-entry is available
> Additional info:
> On 21.03.2016 23:47, Stuart Douglas wrote:
> > This should fix it (I think): https://github.com/stuartwdouglas/wildfly/tree/jpa-java-namespace
> >
> > Stuart
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years