November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5728) Wrong behavior of migration command when expressions are used

by Ondřej Chaloupka (JIRA)

Ondřej Chaloupka created WFLY-5728: -------------------------------------- Summary: Wrong behavior of migration command when expressions are used Key: WFLY-5728 URL: https://issues.jboss.org/browse/WFLY-5728 Project: WildFly Issue Type: Bug Components: IIOP Reporter: Ondřej Chaloupka Assignee: Tomasz Adamski If I use expressions in jacorb subsystem then migration to iiop-openjdk is not fully ok. I have troubles with following attributes to be migrated correctly - {{giop-version}} - {{transactions}} - {{export-corbaloc}} - {{add-component-via-interceptor}} For {{giop-versions}} there is strange string written to element after migration. For {{export-corbaloc}} and {{add-component-via-interceptor}} the value is changed directly to default one without considering the existence of the expression. For {{transactions}} the expression is left but the default value is not changed from {{on}} to {{full}}. This thing of some enum change values could be problem of other properties as well (maybe). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5716) Wrong handling of request context for remote EJB calls

by Ste Gr (JIRA)

[ https://issues.jboss.org/browse/WFLY-5716?page=com.atlassian.jira.plugin.... ] Ste Gr commented on WFLY-5716: ------------------------------ I can confirm, that this commit fixes the error. Thanks. > Wrong handling of request context for remote EJB calls > ------------------------------------------------------ > > Key: WFLY-5716 > URL: https://issues.jboss.org/browse/WFLY-5716 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, EJB > Affects Versions: 9.0.0.Final, 10.0.0.CR4 > Reporter: Ste Gr > Assignee: Martin Kouba > Attachments: wfly5716.zip > > > Two applications deployed to Wildfly. The first one provides a singleton remote ejb which uses request scoped beans (in this case a RESOURCE_LOCAL entity manager manged by a CDI producer/disposer, but +all+ request scoped beans are affected). The second application uses that EJB to get some data only accessible by the first application. > A request is made to the second app from a browser. The app will get the remote EJB and invokes two methods on it. The first method produces the entity manager, accesses the database and returns the result. The entity manager will be disposed again. The second method won't produce a new entity manager but tries to re-use the one from the previous invokation. This fails as the entity manager was disposed. > If the same use-case is made using the first app everythings works as desired. But it doesn't look right (or the request context is joined because it is the same application). It produces the the entity manager on the first invocation and closes it as soon as the whole request made from the browser is completed. Thats why the second invokation has a valid entity manager to work with. > I don't know the spec but: > - either the first EJB invokation from second app to first app is not allowed to dispose the request context (all the request scoped beans) > - or each invokation must get its own request context (entity manager must be produced and disposed again). > I've made a [stackoverflow thread|http://stackoverflow.com/q/33826720/1741604] which shows some code examples. > (JBoss AS 7.1.3.Final is also affected but it is not available in 'affected version/s') -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5170) WildFlySecurityManager throws exception by some tests with security manager

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-5170?page=com.atlassian.jira.plugin.... ] Ivo Studensky updated WFLY-5170: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/8425 > WildFlySecurityManager throws exception by some tests with security manager > --------------------------------------------------------------------------- > > Key: WFLY-5170 > URL: https://issues.jboss.org/browse/WFLY-5170 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Marek Kopecký > Assignee: Ivo Studensky > > *Description of problem:* > WildFlySecurityManager throws ExceptionInInitializerError exception by some tests with security manager. > *Affected tests found so far:* > * org.jboss.as.test.integration.batch.deployment.JobControlTestCase#testStop > * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20MessageSelectorTestCase#retestMessageSelectors > * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20QueueTestCase#testEjb20MDB > * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase#testEjb20TopicMDBs > * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB21TestCase#testSimple21MDB > * org.jboss.as.test.integration.ejb.pool.lifecycle.PooledEJBLifecycleTestCase#testMDB > * org.jboss.as.test.xts.annotation.compensationScoped.CompensationScopedTestCase#shouldSeeDifferentValuesInDifferentTransactions > * org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteReadOnly > * org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorSimple > *Steps to Reproduce for MDB20QueueTestCase:* > # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=MDB20QueueTestCase > *Actual results:* > {noformat} > testEjb20MDB(org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20QueueTestCase) Time elapsed: 0.094 sec <<< ERROR! > java.lang.ExceptionInInitializerError: null > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273) > at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:496) > at java.lang.System.getProperty(System.java:717) > at java.lang.Integer.getInteger(Integer.java:1101) > at java.lang.Integer.getInteger(Integer.java:1057) > at org.jboss.as.test.shared.TimeoutUtil.<clinit>(TimeoutUtil.java:39) > at org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20QueueTestCase.testEjb20MDB(MDB20QueueTestCase.java:110) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-877) Redirection (<, <<) do not work in CLI

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-877?page=com.atlassian.jira.plugin... ] Alexey Loubyansky updated WFCORE-877: ------------------------------------- Fix Version/s: 2.0.3.Final (was: 2.0.0.CR7) > Redirection (<, <<) do not work in CLI > -------------------------------------- > > Key: WFCORE-877 > URL: https://issues.jboss.org/browse/WFCORE-877 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Marek Kopecký > Assignee: Joe Wertz > Priority: Blocker > Fix For: 2.0.3.Final > > > *Description of problem:* > Redirection (<, <<) do not work in CLI > *How reproducible:* > Always > *Steps to Reproduce:* > # echo ":shutdown" > c > # ./jboss-cli.sh -c < c > *Actual results:* > You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. > *Expected results:* > ":shutdown" command will be executed > *Another steps to reproduce:* > # cd bin > # ./standalone.sh & > # ./jboss-cli.sh -c command=/core-service=management/security-realm=ApplicationRealm/authentication=local:remove > # ./jboss-cli.sh -c command=/core-service=management/security-realm=ManagementRealm/authentication=local:remove > # ./jboss-cli.sh -c command=:shutdown > # ./add-user.sh -u bob -p admin123$ -s > # ./standalone.sh & > # {noformat}./jboss-cli.sh -c <<EOF > bob > admin123$ > batch > :shutdown > run-batch > EOF{noformat} > *Actual results:* > Unexpected command 'bob'. Type 'help --commands' for the list of supported commands. > *Expected results:* > ":shutdown" command will be executed > *Additional info:* > Regression against 6.4.0 > Regression against 7.0.0.DR7 > Bugzilla from 6x > * https://bugzilla.redhat.com/show_bug.cgi?id=961425 > Customer cases (EAP 6x): > * https://access.redhat.com/support/cases/#/case/00904577 > * https://access.redhat.com/support/cases/#/case/00889193 > * https://access.redhat.com/support/cases/#/case/00910827 > * https://access.redhat.com/support/cases/#/case/00910848 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1160) Definition of capabilities where the service return type is generic.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1160?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-1160: ------------------------------------------ Now I remember - sorry for the noise - it does have the problem. It is possible to define the InjectedValue strongly typed - however you hit a compilation problem as soon as you attempt the injection. > Definition of capabilities where the service return type is generic. > -------------------------------------------------------------------- > > Key: WFCORE-1160 > URL: https://issues.jboss.org/browse/WFCORE-1160 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Labels: affects_elytron > > Within Elytron we have the following interface: - > {code} > public interface SecurityFactory<T> {} > {code} > It is desirable to define capabilities where the generic type is specified so that as we wire together the various services we can be sure the correct SecurityFactory services are injected in the correct locations. > As it stands our only option is going to be a runtime check so incorrectly wired SecurityFactory references will only occur late. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-990) Allow jitting of constraints using custom operators

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-990: ---------------------------------- Summary: Allow jitting of constraints using custom operators Key: DROOLS-990 URL: https://issues.jboss.org/browse/DROOLS-990 Project: Drools Issue Type: Enhancement Reporter: Mario Fusco Assignee: Mario Fusco At the moment constraints using custom operators (including temporal ones used by CEP) cannot be jitted and then be evaluated in compiled mode. It is required to allow jitting also for this type of constraints. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1981) Request.execute() acquires unneeded lock

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1981?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1981: -------------------------------- Ditto for {{GroupRequest.get()}} and {{UnicastRequest.get()}} > Request.execute() acquires unneeded lock > ---------------------------------------- > > Key: JGRP-1981 > URL: https://issues.jboss.org/browse/JGRP-1981 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > {{Request.execute()}} at one point calls {{responsesComplete()}} which calls {{ConditionVar.waitFor()}}, and both methods acquire the lock. The first lock acquition is not required. > The effect is minimal as acquiring an already acquired lock is cheap. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1160) Definition of capabilities where the service return type is generic.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1160?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-1160: ------------------------------------------ Actually MSC doesn't have that problem - not sure why I though it did. > Definition of capabilities where the service return type is generic. > -------------------------------------------------------------------- > > Key: WFCORE-1160 > URL: https://issues.jboss.org/browse/WFCORE-1160 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Labels: affects_elytron > > Within Elytron we have the following interface: - > {code} > public interface SecurityFactory<T> {} > {code} > It is desirable to define capabilities where the generic type is specified so that as we wire together the various services we can be sure the correct SecurityFactory services are injected in the correct locations. > As it stands our only option is going to be a runtime check so incorrectly wired SecurityFactory references will only occur late. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1988) MessageDispatcher::sendMessageWithFuture with RequestOptions null

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1988?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1988. ---------------------------- Resolution: Done > MessageDispatcher::sendMessageWithFuture with RequestOptions null > ----------------------------------------------------------------- > > Key: JGRP-1988 > URL: https://issues.jboss.org/browse/JGRP-1988 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.6 > Reporter: matias sm > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > In MessageDispatcher::sendMessageWithFuture there are some validations to check the case of RequestOptions options being null. However, if one calls that method with a null RequestOptions argument, the execution ends in failure (with a NPE in the resulting future) [1]. > The point is, either the validations are unnecessary and should exist a preconditions check at the beginning of the method, or it should set a (documented) default RequestOptions so the sending can be completed. > [1] the source of the NPE is UnicastRequest::sendRequest when trying to access the RequestOptions's getMode method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1988) MessageDispatcher::sendMessageWithFuture with RequestOptions null

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1988?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1988: -------------------------------- I fixed this by providing a SYNC RequestOptions argument when null. I also issue a warning null options are almost certainly not what the caller wanted. > MessageDispatcher::sendMessageWithFuture with RequestOptions null > ----------------------------------------------------------------- > > Key: JGRP-1988 > URL: https://issues.jboss.org/browse/JGRP-1988 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.6 > Reporter: matias sm > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > In MessageDispatcher::sendMessageWithFuture there are some validations to check the case of RequestOptions options being null. However, if one calls that method with a null RequestOptions argument, the execution ends in failure (with a NPE in the resulting future) [1]. > The point is, either the validations are unnecessary and should exist a preconditions check at the beginning of the method, or it should set a (documented) default RequestOptions so the sending can be completed. > [1] the source of the NPE is UnicastRequest::sendRequest when trying to access the RequestOptions's getMode method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2015