September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1301) Add remote API call to deploy kie artifact from a specific maven repo.

by Hiram Chirino (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1301?page=com.atlassian.jira.plugi... ] Hiram Chirino reassigned DROOLS-1301: ------------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > Add remote API call to deploy kie artifact from a specific maven repo. > ---------------------------------------------------------------------- > > Key: DROOLS-1301 > URL: https://issues.jboss.org/browse/DROOLS-1301 > Project: Drools > Issue Type: Feature Request > Reporter: Hiram Chirino > Assignee: Mario Fusco > > We want to build a camel OSE example which needs to deploy kie artifacts to a BRMS server. We want to avoid having to require a user from having to setup and deploy this artifacts to mvn repo. > We could have our example pod host a mvn repo with the kie artifacts deployed to it. It would be nice to have the API call the requests the sever to the deploy the artifact GAV to also pass along the the mvn repo URL to the pod hosting the kie artifacts. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7184) The quickstart ejb-multi-server can't invoke the AppTwo via alias an ERROR is logged

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-7184: -------------------------------------- Summary: The quickstart ejb-multi-server can't invoke the AppTwo via alias an ERROR is logged Key: WFLY-7184 URL: https://issues.jboss.org/browse/WFLY-7184 Project: WildFly Issue Type: Bug Reporter: Wolf-Dieter Fink Assignee: Wolf-Dieter Fink The invocation with direct naming in the Bean worked correct. After that the same bean should be invoked via alias "java:global/AliasAppTwo" and this will fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7183) 'name' attribute missing in XSD while required by web subsystem parser

by Peter Palaga (JIRA)

Peter Palaga created WFLY-7183: ---------------------------------- Summary: 'name' attribute missing in XSD while required by web subsystem parser Key: WFLY-7183 URL: https://issues.jboss.org/browse/WFLY-7183 Project: WildFly Issue Type: Bug Reporter: Peter Palaga Assignee: Peter Palaga Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1365939 , originaly reported by [~paramjindal] While configuring the global valve using the following article : https://access.redhat.com/solutions/379813 It is mandatory that the "name" attribute of valve must match the "auth-method" that is specified in the "WEB-INF/web.xml". So "name" attribute is mandatory to configure this valve. but it is not mentioned in the schema of valve as shown below : <xs:element name="valve"> <xs:complexType> <xs:sequence> <xs:element name="param" minOccurs="0" maxOccurs="unbounded" type="paramType" /> </xs:sequence> <xs:attribute name="class-name" type="xs:string" use="required" /> <xs:attribute name="module" type="xs:string" use="required" /> <xs:attribute name="enabled" default="true" type="xs:boolean" /> </xs:complexType> </xs:element> Version-Release number of selected component (if applicable): -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7182) The quickstart ejb-multi-server can't invoke the AppTwo via alias an ERROR is logged

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/WFLY-7182?page=com.atlassian.jira.plugin.... ] Wolf-Dieter Fink reassigned WFLY-7182: -------------------------------------- Assignee: Wolf-Dieter Fink (was: Jason Greene) > The quickstart ejb-multi-server can't invoke the AppTwo via alias an ERROR is logged > ------------------------------------------------------------------------------------ > > Key: WFLY-7182 > URL: https://issues.jboss.org/browse/WFLY-7182 > Project: WildFly > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > > The invocation with direct naming in the Bean worked correct. After that the same bean should be invoked via alias "java:global/AliasAppTwo" and this will fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7182) The quickstart ejb-multi-server can't invoke the AppTwo via alias an ERROR is logged

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-7182: -------------------------------------- Summary: The quickstart ejb-multi-server can't invoke the AppTwo via alias an ERROR is logged Key: WFLY-7182 URL: https://issues.jboss.org/browse/WFLY-7182 Project: WildFly Issue Type: Bug Reporter: Wolf-Dieter Fink Assignee: Jason Greene The invocation with direct naming in the Bean worked correct. After that the same bean should be invoked via alias "java:global/AliasAppTwo" and this will fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7181) Review security-property resource in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7181?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7181: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Review security-property resource in Elytron subsystem > ------------------------------------------------------ > > Key: WFLY-7181 > URL: https://issues.jboss.org/browse/WFLY-7181 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Minor > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7181) Review security-property resource in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7181: ---------------------------------- Summary: Review security-property resource in Elytron subsystem Key: WFLY-7181 URL: https://issues.jboss.org/browse/WFLY-7181 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Minor See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7180) Review filesystem-realm resource in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7180?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7180: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Review filesystem-realm resource in Elytron subsystem > ----------------------------------------------------- > > Key: WFLY-7180 > URL: https://issues.jboss.org/browse/WFLY-7180 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Minor > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7180) Review filesystem-realm resource in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7180: ---------------------------------- Summary: Review filesystem-realm resource in Elytron subsystem Key: WFLY-7180 URL: https://issues.jboss.org/browse/WFLY-7180 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Minor See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7179) Review custom-modifiable-realm resource in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7179: ---------------------------------- Summary: Review custom-modifiable-realm resource in Elytron subsystem Key: WFLY-7179 URL: https://issues.jboss.org/browse/WFLY-7179 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Minor See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7178) Review empty-role-decoder resource in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7178?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7178: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Review empty-role-decoder resource in Elytron subsystem > ------------------------------------------------------- > > Key: WFLY-7178 > URL: https://issues.jboss.org/browse/WFLY-7178 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7178) Review empty-role-decoder resource in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7178: ---------------------------------- Summary: Review empty-role-decoder resource in Elytron subsystem Key: WFLY-7178 URL: https://issues.jboss.org/browse/WFLY-7178 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7177) Review provider-loader resource in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7177?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7177: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Review provider-loader resource in Elytron subsystem > ---------------------------------------------------- > > Key: WFLY-7177 > URL: https://issues.jboss.org/browse/WFLY-7177 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Minor > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7177) Review provider-loader resource in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7177: ---------------------------------- Summary: Review provider-loader resource in Elytron subsystem Key: WFLY-7177 URL: https://issues.jboss.org/browse/WFLY-7177 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Minor See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7176) Review x500-attribute-principal-decoder resource in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7176?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7176: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Review x500-attribute-principal-decoder resource in Elytron subsystem > --------------------------------------------------------------------- > > Key: WFLY-7176 > URL: https://issues.jboss.org/browse/WFLY-7176 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7176) Review x500-attribute-principal-decoder resource in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7176: ---------------------------------- Summary: Review x500-attribute-principal-decoder resource in Elytron subsystem Key: WFLY-7176 URL: https://issues.jboss.org/browse/WFLY-7176 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7175) Complex type server-ssl-context in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7175?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7175: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Complex type server-ssl-context in Elytron subsystem > ---------------------------------------------------- > > Key: WFLY-7175 > URL: https://issues.jboss.org/browse/WFLY-7175 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > Elytron subsystem uses complex type in server-ssl-context resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7175) Complex type server-ssl-context in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7175: ---------------------------------- Summary: Complex type server-ssl-context in Elytron subsystem Key: WFLY-7175 URL: https://issues.jboss.org/browse/WFLY-7175 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Elytron subsystem uses complex type in server-ssl-context resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7174) Complex type jdbc-realm in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7174?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7174: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Complex type jdbc-realm in Elytron subsystem > -------------------------------------------- > > Key: WFLY-7174 > URL: https://issues.jboss.org/browse/WFLY-7174 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > Elytron subsystem uses complex type in jdbc-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7174) Complex type jdbc-realm in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7174: ---------------------------------- Summary: Complex type jdbc-realm in Elytron subsystem Key: WFLY-7174 URL: https://issues.jboss.org/browse/WFLY-7174 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Elytron subsystem uses complex type in jdbc-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7173) Complex type ldap-realm in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7173?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7173: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Complex type ldap-realm in Elytron subsystem > -------------------------------------------- > > Key: WFLY-7173 > URL: https://issues.jboss.org/browse/WFLY-7173 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > Elytron subsystem uses complex type in ldap-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7173) Complex type ldap-realm in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7173: ---------------------------------- Summary: Complex type ldap-realm in Elytron subsystem Key: WFLY-7173 URL: https://issues.jboss.org/browse/WFLY-7173 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Elytron subsystem uses complex type in ldap-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7172) Complex type properties-realm in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7172: ---------------------------------- Summary: Complex type properties-realm in Elytron subsystem Key: WFLY-7172 URL: https://issues.jboss.org/browse/WFLY-7172 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7172) Complex type properties-realm in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7172?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7172: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Complex type properties-realm in Elytron subsystem > -------------------------------------------------- > > Key: WFLY-7172 > URL: https://issues.jboss.org/browse/WFLY-7172 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7171) Complex type security-domain in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7171?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7171: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Complex type security-domain in Elytron subsystem > ------------------------------------------------- > > Key: WFLY-7171 > URL: https://issues.jboss.org/browse/WFLY-7171 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > Elytron subsystem uses complex type in security-domain resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7171) Complex type security-domain in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7171: ---------------------------------- Summary: Complex type security-domain in Elytron subsystem Key: WFLY-7171 URL: https://issues.jboss.org/browse/WFLY-7171 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Elytron subsystem uses complex type in security-domain resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7170) Complex type mechanism-provider-filtering-sasl-server-factory in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7170?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7170: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Complex type mechanism-provider-filtering-sasl-server-factory in Elytron subsystem > ---------------------------------------------------------------------------------- > > Key: WFLY-7170 > URL: https://issues.jboss.org/browse/WFLY-7170 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > Elytron subsystem uses complex type in mechanism-provider-filtering-sasl-server-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7170) Complex type mechanism-provider-filtering-sasl-server-factory in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7170: ---------------------------------- Summary: Complex type mechanism-provider-filtering-sasl-server-factory in Elytron subsystem Key: WFLY-7170 URL: https://issues.jboss.org/browse/WFLY-7170 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Elytron subsystem uses complex type in mechanism-provider-filtering-sasl-server-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7169) Complex type configurable-sasl-server-factory in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7169?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7169: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Complex type configurable-sasl-server-factory in Elytron subsystem > ------------------------------------------------------------------ > > Key: WFLY-7169 > URL: https://issues.jboss.org/browse/WFLY-7169 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > Elytron subsystem uses complex type in configurable-sasl-server-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7169) Complex type configurable-sasl-server-factory in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7169: ---------------------------------- Summary: Complex type configurable-sasl-server-factory in Elytron subsystem Key: WFLY-7169 URL: https://issues.jboss.org/browse/WFLY-7169 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Elytron subsystem uses complex type in configurable-sasl-server-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7168) Complex type sasl-authentication-factory in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7168: ---------------------------------- Summary: Complex type sasl-authentication-factory in Elytron subsystem Key: WFLY-7168 URL: https://issues.jboss.org/browse/WFLY-7168 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Elytron subsystem uses complex type in sasl-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7168) Complex type sasl-authentication-factory in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7168?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7168: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Complex type sasl-authentication-factory in Elytron subsystem > ------------------------------------------------------------- > > Key: WFLY-7168 > URL: https://issues.jboss.org/browse/WFLY-7168 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > Elytron subsystem uses complex type in sasl-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7167) Complex type simple-permission-mapper in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7167?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7167: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Complex type simple-permission-mapper in Elytron subsystem > ---------------------------------------------------------- > > Key: WFLY-7167 > URL: https://issues.jboss.org/browse/WFLY-7167 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > Elytron subsystem uses complex type in simple-permission-mapper resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7167) Complex type simple-permission-mapper in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7167: ---------------------------------- Summary: Complex type simple-permission-mapper in Elytron subsystem Key: WFLY-7167 URL: https://issues.jboss.org/browse/WFLY-7167 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Elytron subsystem uses complex type in simple-permission-mapper resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7166) Complex type key-store in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7166?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7166: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Complex type key-store in Elytron subsystem > ------------------------------------------- > > Key: WFLY-7166 > URL: https://issues.jboss.org/browse/WFLY-7166 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > Elytron subsystem uses complex type in key-store resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7164) Complex type http-authentication-factory in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7164?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7164: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Complex type http-authentication-factory in Elytron subsystem > ------------------------------------------------------------- > > Key: WFLY-7164 > URL: https://issues.jboss.org/browse/WFLY-7164 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > Elytron subsystem uses complex type in http-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7165) Complex type configurable-http-server-mechanism-factory in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7165?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7165: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Complex type configurable-http-server-mechanism-factory in Elytron subsystem > ---------------------------------------------------------------------------- > > Key: WFLY-7165 > URL: https://issues.jboss.org/browse/WFLY-7165 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > Elytron subsystem uses complex type configurable-http-server-mechanism-factory which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7166) Complex type key-store in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7166: ---------------------------------- Summary: Complex type key-store in Elytron subsystem Key: WFLY-7166 URL: https://issues.jboss.org/browse/WFLY-7166 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Elytron subsystem uses complex type in key-store resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7165) Complex type configurable-http-server-mechanism-factory in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7165: ---------------------------------- Summary: Complex type configurable-http-server-mechanism-factory in Elytron subsystem Key: WFLY-7165 URL: https://issues.jboss.org/browse/WFLY-7165 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Elytron subsystem uses complex type configurable-http-server-mechanism-factory which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7164) Complex type http-authentication-factory in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7164: ---------------------------------- Summary: Complex type http-authentication-factory in Elytron subsystem Key: WFLY-7164 URL: https://issues.jboss.org/browse/WFLY-7164 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Elytron subsystem uses complex type in http-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7163) Relative ordering of webfragments causes an IllegalStateException

by Sverre Boschman (JIRA)

Sverre Boschman created WFLY-7163: ------------------------------------- Summary: Relative ordering of webfragments causes an IllegalStateException Key: WFLY-7163 URL: https://issues.jboss.org/browse/WFLY-7163 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 9.0.2.Final, 11.0.0.Alpha1 Environment: Issue found on 9.0.2; testcase made against master (11.0.0.Alpha1-SNAPSHOT) Reporter: Sverre Boschman Assignee: Stuart Douglas Priority: Minor Attachments: undertow_webfragment_test.zip Caused by: java.lang.IllegalStateException: WFLYUT0047: Relative ordering conflict with JAR: <jarname>.jar at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.resolveOrder(WarMetaDataProcessor.java:717) at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.deploy(WarMetaDataProcessor.java:212) ... 6 more -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7160) Test for all JCA flush operations

by Jan Martiska (JIRA)

[ https://issues.jboss.org/browse/WFLY-7160?page=com.atlassian.jira.plugin.... ] Jan Martiska updated WFLY-7160: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9211 (was: https://issues.jboss.org/browse/WFLY-7160) > Test for all JCA flush operations > --------------------------------- > > Key: WFLY-7160 > URL: https://issues.jboss.org/browse/WFLY-7160 > Project: WildFly > Issue Type: Task > Components: Test Suite > Affects Versions: 10.0.0.Final > Reporter: Jan Martiska > Assignee: Jan Martiska > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7159) Too complex Elytron Domain Model

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7159?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-7159. ------------------------------------ Fix Version/s: 11.0.0.Alpha1 Resolution: Rejected I am rejecting this on the basis that it is too broad. There are valid points in here so I recommend individual issues for the individual concerns so we can address them all individually, not all issues raised automatically point to refactoring a single subsystem. > Too complex Elytron Domain Model > -------------------------------- > > Key: WFLY-7159 > URL: https://issues.jboss.org/browse/WFLY-7159 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > User experience with Elytron domain model is sub-optimal. > It's hard to define correctly complex attributes in the Elytron Subsystem configuration. It's much simpler to write the CLI with primitive attributes instead. Also the Management console is not able to generate forms for complex-types automatically. > 1) Domain model of subsystem is too flat. Every resource (realms, mappers, factories ...) is located at the base level of Elytron subsystem. Then it is hard to orientate in subsystem since it does not have deeper structure. > Suggestion: > It can be structuralized similar as PicketBox subsystem. There could be some subresources like realms, domains etc. > 2) Elytron subsystem contains a lot of complex types which strongly complicate setting of attributes for resources. It mainly affects > * {{add}} operation - there is insufficient support from CLI since tab button not sufficiently works. It is also non-intuitive and error-prone when all setting is mixed to one difficult command. > * {{write-attribute}} operation - using write-attribute for some values from complex inner attribute is really hard - e.g. set particular value for some inner attribute of complex object stored in list. > It is different aproach than most of other subsystems uses. > Suggestion: > Replace complex attributes with child resources. > This could be also discussed with UX team. Once this domain model will be released in WildFly/EAP then it will be very hard to rewrite it do to backward compatibility. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1300) result of rule execution in STREAM mode are different between PHREAK and RETEOO

by Hiroko Miura (JIRA)

Hiroko Miura created DROOLS-1300: ------------------------------------ Summary: result of rule execution in STREAM mode are different between PHREAK and RETEOO Key: DROOLS-1300 URL: https://issues.jboss.org/browse/DROOLS-1300 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.4.0.Final Reporter: Hiroko Miura Assignee: Mario Fusco Priority: Critical Fix For: 6.5.0.Final Attachments: rules-reproducer.zip Customer is developing rules and runs it as CEP in STREAM mode. When executing it with same facts , the results (remaining objects in working memory) are different between PHREAK and RETEOO. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7161) EJB with defined specific security domain which is different than the one used for undertow fails when using with elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7161?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7161: ----------------------------------- Priority: Major (was: Critical) > EJB with defined specific security domain which is different than the one used for undertow fails when using with elytron > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7161 > URL: https://issues.jboss.org/browse/WFLY-7161 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Radim Hatlapatka > Assignee: Darran Lofthouse > > When having deployment with EJB which is invoked from servlet and the EJB has defined specific security domain to use via {{@SecurityDomain}} annotation, the ejb method invocation fails when there is defined elytron security domain for undertow and old security domain for EJBs with \[1\]. > Note when having both security domains setup only using old security subsystems, the access is allowed as expected. > Marking as critical as this should work. If it is not considered supported use case then there should be at least shown proper warning in logs explaining what is wrong. > \[1\] > {noformat} > 09:30:03,749 ERROR [org.jboss.as.ejb3.invocation] (default task-25) WFLYEJB0034: EJB Invocation failed on component SecuredEjb for method public java.lang.String org.jboss.qa.management.web.resources.SecuredEjb.securedText(): javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public java.lang.String org.jboss.qa.management.web.resources.SecuredEjb.securedText() of bean: SecuredEjb is not allowed > at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:134) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:74) > at org.jboss.qa.management.web.resources.SecuredEjb$$$view6.securedText(Unknown Source) > at org.jboss.qa.management.web.resources.ServletWithSecuredEjb.doGet(ServletWithSecuredEjb.java:27) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.lambda$handleRequest$0(ElytronRunAsHandler.java:56) > at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:395) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:188) > at org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.handleRequest(ElytronRunAsHandler.java:55) > at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810) > 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) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7159) Too complex Elytron Domain Model

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7159?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7159: ----------------------------------- Priority: Major (was: Critical) > Too complex Elytron Domain Model > -------------------------------- > > Key: WFLY-7159 > URL: https://issues.jboss.org/browse/WFLY-7159 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > User experience with Elytron domain model is sub-optimal. > It's hard to define correctly complex attributes in the Elytron Subsystem configuration. It's much simpler to write the CLI with primitive attributes instead. Also the Management console is not able to generate forms for complex-types automatically. > 1) Domain model of subsystem is too flat. Every resource (realms, mappers, factories ...) is located at the base level of Elytron subsystem. Then it is hard to orientate in subsystem since it does not have deeper structure. > Suggestion: > It can be structuralized similar as PicketBox subsystem. There could be some subresources like realms, domains etc. > 2) Elytron subsystem contains a lot of complex types which strongly complicate setting of attributes for resources. It mainly affects > * {{add}} operation - there is insufficient support from CLI since tab button not sufficiently works. It is also non-intuitive and error-prone when all setting is mixed to one difficult command. > * {{write-attribute}} operation - using write-attribute for some values from complex inner attribute is really hard - e.g. set particular value for some inner attribute of complex object stored in list. > It is different aproach than most of other subsystems uses. > Suggestion: > Replace complex attributes with child resources. > This could be also discussed with UX team. Once this domain model will be released in WildFly/EAP then it will be very hard to rewrite it do to backward compatibility. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7143) Unsafe Elytron role/permission mapping

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7143?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7143: ---------------------------------- Yes, add constant-permission-mapper sounds much better then to have part of permission as blacklist (LoginPermission) and part as whitelist (others). > Unsafe Elytron role/permission mapping > -------------------------------------- > > Key: WFLY-7143 > URL: https://issues.jboss.org/browse/WFLY-7143 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Blocker > > Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then. > The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role. > {code:xml} > <mappers> > <simple-permission-mapper name="login-permission-mapper"> > <permission-mapping roles="All"> > <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/> > </permission-mapping> > </simple-permission-mapper> > <constant-role-mapper name="constant-roles" roles="All"/> > </mappers> > {code} > We have to make the default server configuration secure for users. > *Suggestions for improvement:* > * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles > * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7162) Elytron filtering-key-store:write-attribute cause NPE

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7162?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-6105 to WFLY-7162: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7162 (was: JBEAP-6105) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR5) > Elytron filtering-key-store:write-attribute cause NPE > ----------------------------------------------------- > > Key: WFLY-7162 > URL: https://issues.jboss.org/browse/WFLY-7162 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > Trying to update filtering-key-store cause NPE > {code} > [standalone@localhost:9990 /] /subsystem=elytron/filtering-key-store=filteringKeyStore:add(key-store=server, alias-filter=undertow) > {"outcome" => "success"} > [standalone@localhost:9990 /] /subsystem=elytron/filtering-key-store=filteringKeyStore:write-attribute(name=alias-filter,value=management) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException", > "rolled-back" => true > } > {code} > Stacktrace: > {code} > 09:51:45,250 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 10) WFLYCTL0013: Operation ("write-attribute") failed - address: ([ > ("subsystem" => "elytron"), > ("filtering-key-store" => "filteringKeyStore") > ]): java.lang.NullPointerException > at org.wildfly.extension.elytron.FilteringKeyStoreDefinition$WriteAttributeHandler.getParentServiceName(FilteringKeyStoreDefinition.java:174) > at org.jboss.as.controller.RestartParentWriteAttributeHandler.applyUpdateToRuntime(RestartParentWriteAttributeHandler.java:57) > at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7140) Injection with @EJB is not working as expected with CDI (REST) beans

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-7140?page=com.atlassian.jira.plugin.... ] Martin Kouba commented on WFLY-7140: ------------------------------------ For the record, {{org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices}} (responsible for @EJB injection) is using {{org.jboss.as.naming.deployment.ContextNames}} which obviously does not support this jboss-specific "ejb" namespace. So the only solution I see is to detect this namespace and perform a simple {{new InitialContext().lookup(name)}}. > Injection with @EJB is not working as expected with CDI (REST) beans > -------------------------------------------------------------------- > > Key: WFLY-7140 > URL: https://issues.jboss.org/browse/WFLY-7140 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, EJB > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > The injection with @EJB should work the same way in a Rest service (CDI Bean) as it does in a Servlet. > @EJB(lookup = "ejb:jboss-ejb-multi-server-app-one/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne") > is not working correct if used in a CDI Bean in the reproducer example. > Reproducer can be found here: > git@github.com:wfink/jboss-eap-quickstarts.git > BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection > SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app) > see ejb-multi-server/README-reproducerEJB-injection -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2064) JDBC_PING: make subclass of FILE_PING

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2064?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2064. ---------------------------- Resolution: Done > JDBC_PING: make subclass of FILE_PING > ------------------------------------- > > Key: JGRP-2064 > URL: https://issues.jboss.org/browse/JGRP-2064 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > This way, zombie removal would be possible, e.g. attributes {{remove_old_coords_on_view_change}} and {{remove_all_files_on_view_change}} would be usable. > Currently, JDBC_PING extends Discovery only, not FILE_PING -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7161) EJB with defined specific security domain which is different than the one used for undertow fails when using with elytron

by Radim Hatlapatka (JIRA)

Radim Hatlapatka created WFLY-7161: -------------------------------------- Summary: EJB with defined specific security domain which is different than the one used for undertow fails when using with elytron Key: WFLY-7161 URL: https://issues.jboss.org/browse/WFLY-7161 Project: WildFly Issue Type: Bug Components: Security Reporter: Radim Hatlapatka Assignee: Darran Lofthouse Priority: Critical When having deployment with EJB which is invoked from servlet and the EJB has defined specific security domain to use via {{@SecurityDomain}} annotation, the ejb method invocation fails when there is defined elytron security domain for undertow and old security domain for EJBs with \[1\]. Note when having both security domains setup only using old security subsystems, the access is allowed as expected. Marking as critical as this should work. If it is not considered supported use case then there should be at least shown proper warning in logs explaining what is wrong. \[1\] {noformat} 09:30:03,749 ERROR [org.jboss.as.ejb3.invocation] (default task-25) WFLYEJB0034: EJB Invocation failed on component SecuredEjb for method public java.lang.String org.jboss.qa.management.web.resources.SecuredEjb.securedText(): javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public java.lang.String org.jboss.qa.management.web.resources.SecuredEjb.securedText() of bean: SecuredEjb is not allowed at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:134) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:74) at org.jboss.qa.management.web.resources.SecuredEjb$$$view6.securedText(Unknown Source) at org.jboss.qa.management.web.resources.ServletWithSecuredEjb.doGet(ServletWithSecuredEjb.java:27) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.lambda$handleRequest$0(ElytronRunAsHandler.java:56) at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:395) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:188) at org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.handleRequest(ElytronRunAsHandler.java:55) at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810) 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) {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7140) Injection with @EJB is not working as expected with CDI (REST) beans

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7140?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-7140: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1377705 Bugzilla Update: Perform > Injection with @EJB is not working as expected with CDI (REST) beans > -------------------------------------------------------------------- > > Key: WFLY-7140 > URL: https://issues.jboss.org/browse/WFLY-7140 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, EJB > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > The injection with @EJB should work the same way in a Rest service (CDI Bean) as it does in a Servlet. > @EJB(lookup = "ejb:jboss-ejb-multi-server-app-one/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne") > is not working correct if used in a CDI Bean in the reproducer example. > Reproducer can be found here: > git@github.com:wfink/jboss-eap-quickstarts.git > BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection > SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app) > see ejb-multi-server/README-reproducerEJB-injection -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1498) Different shutdown messages depending on reason for shutdown

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1498?page=com.atlassian.jira.plugi... ] Peter Palaga updated WFCORE-1498: --------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1328673, https://bugzilla.redhat.com/show_bug.cgi?id=1116086 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1328673) > Different shutdown messages depending on reason for shutdown > ------------------------------------------------------------ > > Key: WFCORE-1498 > URL: https://issues.jboss.org/browse/WFCORE-1498 > Project: WildFly Core > Issue Type: Feature Request > Components: Server > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Labels: 2.2 > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > Use different output for SIGTERM vs shutdown op vs abort vs various flavors of managed domain shutdown. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7160) Test for all JCA flush operations

by Jan Martiska (JIRA)

Jan Martiska created WFLY-7160: ---------------------------------- Summary: Test for all JCA flush operations Key: WFLY-7160 URL: https://issues.jboss.org/browse/WFLY-7160 Project: WildFly Issue Type: Task Components: Test Suite Affects Versions: 10.0.0.Final Reporter: Jan Martiska Assignee: Jan Martiska -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6784) Add possibility to enable websocket compression via management model

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-6784?page=com.atlassian.jira.plugin.... ] Ingo Weiss updated WFLY-6784: ----------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9148 (was: https://github.com/wildfly/wildfly/pull/9016) > Add possibility to enable websocket compression via management model > -------------------------------------------------------------------- > > Key: WFLY-6784 > URL: https://issues.jboss.org/browse/WFLY-6784 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Radim Hatlapatka > Assignee: Ingo Weiss > Priority: Critical > Labels: downstream_dependency > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > In EAP 6 the websockets compression was enabled by default allowing to use pre-deflate compression when requested by client. > There is support for it in Undertow but there is no option to enable it in WildFly 10. This option should be added to WildFly and should probably set by default to true as that would be consistent with default behaviour when using WebSockets with EAP 6.4. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7159) Too complex Elytron Domain Model

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7159: ---------------------------------- Summary: Too complex Elytron Domain Model Key: WFLY-7159 URL: https://issues.jboss.org/browse/WFLY-7159 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical User experience with Elytron domain model is sub-optimal. It's hard to define correctly complex attributes in the Elytron Subsystem configuration. It's much simpler to write the CLI with primitive attributes instead. Also the Management console is not able to generate forms for complex-types automatically. 1) Domain model of subsystem is too flat. Every resource (realms, mappers, factories ...) is located at the base level of Elytron subsystem. Then it is hard to orientate in subsystem since it does not have deeper structure. Suggestion: It can be structuralized similar as PicketBox subsystem. There could be some subresources like realms, domains etc. 2) Elytron subsystem contains a lot of complex types which strongly complicate setting of attributes for resources. It mainly affects * {{add}} operation - there is insufficient support from CLI since tab button not sufficiently works. It is also non-intuitive and error-prone when all setting is mixed to one difficult command. * {{write-attribute}} operation - using write-attribute for some values from complex inner attribute is really hard - e.g. set particular value for some inner attribute of complex object stored in list. It is different aproach than most of other subsystems uses. Suggestion: Replace complex attributes with child resources. This could be also discussed with UX team. Once this domain model will be released in WildFly/EAP then it will be very hard to rewrite it do to backward compatibility. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7158) Working with multiple keys in key store

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-6099 to WFLY-7158: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7158 (was: JBEAP-6099) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR5) > Working with multiple keys in key store > --------------------------------------- > > Key: WFLY-7158 > URL: https://issues.jboss.org/browse/WFLY-7158 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key). > That is pretty inconvinient. Probably introducing alias attribute on key-manager would be more intuitive solution to this situation. > {code} > /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ] Edson Tirelli reassigned DROOLS-987: ------------------------------------ Assignee: Maciej Swiderski (was: Marco Rietveld) > Errors in Phreak under heavy and multi threaded load > ----------------------------------------------------- > > Key: DROOLS-987 > URL: https://issues.jboss.org/browse/DROOLS-987 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final, 6.4.0.Final > Environment: linux > Java 7 > kernel 3.16 > Reporter: Jose Cavieres > Assignee: Maciej Swiderski > Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz > > > Several threads are started, each one starts 1 jbpm process containing rule(s) task(s). > If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%. > Aparently the setFocus method used by rule tasks is related to the problem. > The most comon error is: > Caused by: java.lang.NullPointerException > at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141) > at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80) > at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295) > at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266) > at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361) > at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334) > at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317) > at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358) > at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7157) Audit @Ignore-d clustering integration tests

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-7157: ------------------------------------ Summary: Audit @Ignore-d clustering integration tests Key: WFLY-7157 URL: https://issues.jboss.org/browse/WFLY-7157 Project: WildFly Issue Type: Task Components: Clustering Affects Versions: 10.1.0.CR1 Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 11.0.0.Alpha1 Recently stumbling upon an @Ignore-d test which would have caught a regression, we need to audit ignored clustering tests, e.g. some are referencing already fixed issues. {noformat} [rhusar@syrah clustering]$ git grep @Ignore src/test/java/org/jboss/as/test/clustering/cluster/ejb/remote/RemoteFailoverTestCase.java: @Ignore("WFLY-3532") src/test/java/org/jboss/as/test/clustering/cluster/ejb/stateful/StatefulFailoverTestCase.java: @Ignore("WFLY-835 @Resource UserTransaction error when file passivation store is selected") src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/CoarseSessionPassivationTestCase.java:@Ignore("WFLY-6624") src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/FineSessionPassivationTestCase.java:@Ignore("WFLY-6624") src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/passivation/ClusterPassivationTestCase.java: @Ignore("JBPAPP-8774") src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726") src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726") src/test/java/org/jboss/as/test/clustering/single/jdbcstore/TransactionalJdbcStoreTestCase.java:@Ignore("https://issues.jboss.org/browse/ISPN-604") src/test/java/org/jboss/as/test/clustering/xsite/XSiteSimpleTestCase.java: @Ignore("https://issues.jboss.org/browse/WFLY-5239") {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1810) PeriodicSizeRotatingFileHandler's are always replaced during boot

by Panagiotis Sotiropoulos (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1810?page=com.atlassian.jira.plugi... ] Panagiotis Sotiropoulos closed WFCORE-1810. ------------------------------------------- Resolution: Duplicate Issue Duplicate of WFCORE-1018 > PeriodicSizeRotatingFileHandler's are always replaced during boot > ----------------------------------------------------------------- > > Key: WFCORE-1810 > URL: https://issues.jboss.org/browse/WFCORE-1810 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Panagiotis Sotiropoulos > Assignee: James Perkins > Fix For: 2.0.0.CR6 > > > A {{periodic-size-rotating-file-handler}} will be replaced during the subsystem add operation. This could be an issue with {{async-handler}}'s where the handler may see the old handler that was closed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4908) Redeploy dependent ear fails with duplicate resource error for persistence unit

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-4908?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-4908. ------------------------------ Closing as I believe that this is complete. > Redeploy dependent ear fails with duplicate resource error for persistence unit > ------------------------------------------------------------------------------- > > Key: WFLY-4908 > URL: https://issues.jboss.org/browse/WFLY-4908 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 8.2.0.Final, 9.0.0.CR2, 9.0.0.Final, 10.0.0.CR4 > Environment: OS: > Debian GNU/Linux 8.0 (jessie) > Linux 3.16.0-4-amd64 x86_64 GNU/Linux > JVM: > java version "1.8.0_45" > Java(TM) SE Runtime Environment (build 1.8.0_45-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) > Wildfly: > 9.0.0.Final > Reporter: Юрий Витковский > Assignee: Scott Marlow > Fix For: 10.1.0.CR1, 10.1.0.Final > > > I have two EARs: > {code} > module1.ear > | > +--ejb.jar > | > +--META-INF > | > +--persistence.xml with persistence unit "module1-pu" > {code} > and > {code} > module2.ear > | > +--META-INF > | | > | +--jboss-all.xml > | > +--ejb.jar > | > +--META-INF > | > +--persistence.xml with persistence unit "module2-pu" > {code} > module2.ear/META-INF/jboss-all.xml contains: > {code:xml} > <jboss xmlns="urn:jboss:1.0"> > <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0"> > <dependency name="module1.ear" /> > </jboss-deployment-dependencies> > </jboss> > {code} > When I redeploy module1.ear, module2.ear not redeployed automatically with error: *java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource module2.ear/ejb.jar#module2-pu* (on wildfly 8.2.0.Final: *java.lang.IllegalStateException: JBAS014666: Duplicate resource module2.ear/ejb.jar#module2-pu*) > Full redeploy log: > {code} > 09:11:31,425 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'module2.ear/ejb.jar#module2-pu' > 09:11:31,426 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service 'module2.ear/ejb.jar#module2-pu' > 09:11:31,431 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'module1.ear/ejb.jar#module1-pu' > 09:11:31,434 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service 'module1.ear/ejb.jar#module1-pu' > 09:11:31,437 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0208: Stopped subdeployment (runtime-name: ejb.jar) in 17ms > 09:11:31,438 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment module1.ear (runtime-name: module1.ear) in 18ms > 09:11:31,495 INFO [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0009: Undeployed "module1.ear" (runtime-name: "module1.ear") > 09:11:31,495 INFO [org.jboss.as.controller] (management-handler-thread - 3) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."module1.ear".deploymentCompleteService (missing) dependents: [service jboss.deployment.unit."module2.ear".PARSE, service jboss.deployment.subunit."module2.ear"."ejb.jar".PARSE] > > > 09:11:31,558 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /opt/wildfly/standalone/data/content/69/baf0eeab47c006bc1f3d99b21b4355fac62d13/content > 09:11:43,170 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /opt/wildfly/standalone/data/content/69/baf0eeab47c006bc1f3d99b21b4355fac62d13/content > 09:11:43,266 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "module1.ear" (runtime-name: "module1.ear") > 09:11:43,268 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0207: Starting subdeployment (runtime-name: "ejb.jar") > 09:11:43,273 INFO [org.jboss.as.jpa] (MSC service thread 1-1) WFLYJPA0002: Read persistence.xml for module1-pu > 09:11:43,289 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 'module1.ear/ejb.jar#module1-pu' > 09:11:43,289 INFO [org.hibernate.jpa.internal.util.LogHelper] (ServerService Thread Pool -- 63) HHH000204: Processing PersistenceUnitInfo [ > name: module1-pu > ...] > 09:11:43,292 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0010: Starting Persistence Unit (phase 2 of 2) Service 'module1.ear/ejb.jar#module1-pu' > 09:11:43,293 INFO [org.hibernate.dialect.Dialect] (ServerService Thread Pool -- 63) HHH000400: Using dialect: org.hibernate.dialect.H2Dialect > 09:11:43,293 WARN [org.hibernate.dialect.H2Dialect] (ServerService Thread Pool -- 63) HHH000431: Unable to determine H2 database version, certain features may not work > 09:11:43,294 INFO [org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory] (ServerService Thread Pool -- 63) HHH000397: Using ASTQueryTranslatorFactory > 09:11:43,296 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0070: Deployment restart detected for deployment module2.ear, performing full redeploy instead. > 09:11:43,296 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0070: Deployment restart detected for deployment ejb.jar, performing full redeploy instead. > 09:11:43,296 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0208: Stopped subdeployment (runtime-name: ejb.jar) in 0ms > 09:11:43,297 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment module2.ear (runtime-name: module2.ear) in 1ms > 09:11:43,298 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "module2.ear" (runtime-name: "module2.ear") > 09:11:43,299 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0207: Starting subdeployment (runtime-name: "ejb.jar") > 09:11:43,300 INFO [org.jboss.as.jpa] (MSC service thread 1-2) WFLYJPA0002: Read persistence.xml for module2-pu > 09:11:43,307 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 'module2.ear/ejb.jar#module2-pu' > 09:11:43,308 INFO [org.hibernate.jpa.internal.util.LogHelper] (ServerService Thread Pool -- 63) HHH000204: Processing PersistenceUnitInfo [ > name: module2-pu > ...] > 09:11:43,312 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."module2.ear"."ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."module2.ear"."ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "ejb.jar" of deployment "module2.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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) > Caused by: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource module2.ear/ejb.jar#module2-pu > at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:248) > at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:143) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addManagementConsole(PersistenceUnitServiceHandler.java:1128) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseTwo(PersistenceUnitServiceHandler.java:704) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:289) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleJarDeployment(PersistenceUnitServiceHandler.java:162) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:133) > at org.jboss.as.jpa.processor.PersistenceCompleteInstallProcessor.deploy(PersistenceCompleteInstallProcessor.java:55) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > ... 5 more > > > 09:11:43,376 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "module1.ear" (runtime-name : "module1.ear") > 09:11:43,376 INFO [org.jboss.as.controller] (management-handler-thread - 2) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.subunit."module2.ear"."ejb.jar" (unavailable) dependents: [service jboss.deployment.unit."module2.ear".PARSE] > service jboss.deployment.subunit."module2.ear"."ejb.jar".STRUCTURE (unavailable) dependents: [service jboss.deployment.unit."module2.ear".PARSE] > service jboss.deployment.subunit."module2.ear"."ejb.jar".deploymentCompleteService (missing) dependents: [service jboss.deployment.unit."module2.ear".deploymentCompleteService] > WFLYCTL0185: Newly corrected services: > service jboss.deployment.unit."module1.ear".deploymentCompleteService (new available) > WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."module2.ear"."ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."module2.ear"."ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "ejb.jar" of deployment "module2.ear" > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBAS-8164) Move jboss-ha-server-* jars from common/lib to server/all/lib

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBAS-8164?page=com.atlassian.jira.plugin.... ] Scott Marlow resolved JBAS-8164. -------------------------------- Resolution: Out of Date > Move jboss-ha-server-* jars from common/lib to server/all/lib > ------------------------------------------------------------- > > Key: JBAS-8164 > URL: https://issues.jboss.org/browse/JBAS-8164 > Project: Application Server 3 4 5 and 6 > Issue Type: Bug > Components: Clustering > Affects Versions: 6.0.0.M3 > Reporter: Paul Ferraro > Assignee: Scott Marlow > Fix For: No Release > > Attachments: JBAS-8164.patch > > > Currently, the build puts the following jars into common/lib: > jboss-ha-server-api.jar > jboss-ha-server-cache-jbc.jar > jboss-ha-server-cache-spi.jar > jboss-ha-server-core.jar > This will likely cause classloader issues, especially for classes that extend/implement jbosscache or jgroups classes (e.g. CacheManager, ChannelFactory), since these jars reside in server/all/lib -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBAS-8164) Move jboss-ha-server-* jars from common/lib to server/all/lib

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBAS-8164?page=com.atlassian.jira.plugin.... ] Scott Marlow closed JBAS-8164. ------------------------------ > Move jboss-ha-server-* jars from common/lib to server/all/lib > ------------------------------------------------------------- > > Key: JBAS-8164 > URL: https://issues.jboss.org/browse/JBAS-8164 > Project: Application Server 3 4 5 and 6 > Issue Type: Bug > Components: Clustering > Affects Versions: 6.0.0.M3 > Reporter: Paul Ferraro > Assignee: Scott Marlow > Fix For: No Release > > Attachments: JBAS-8164.patch > > > Currently, the build puts the following jars into common/lib: > jboss-ha-server-api.jar > jboss-ha-server-cache-jbc.jar > jboss-ha-server-cache-spi.jar > jboss-ha-server-core.jar > This will likely cause classloader issues, especially for classes that extend/implement jbosscache or jgroups classes (e.g. CacheManager, ChannelFactory), since these jars reside in server/all/lib -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4908) Redeploy dependent ear fails with duplicate resource error for persistence unit

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4908?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4908: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1370112 Bugzilla Update: Perform > Redeploy dependent ear fails with duplicate resource error for persistence unit > ------------------------------------------------------------------------------- > > Key: WFLY-4908 > URL: https://issues.jboss.org/browse/WFLY-4908 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 8.2.0.Final, 9.0.0.CR2, 9.0.0.Final, 10.0.0.CR4 > Environment: OS: > Debian GNU/Linux 8.0 (jessie) > Linux 3.16.0-4-amd64 x86_64 GNU/Linux > JVM: > java version "1.8.0_45" > Java(TM) SE Runtime Environment (build 1.8.0_45-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) > Wildfly: > 9.0.0.Final > Reporter: Юрий Витковский > Assignee: Scott Marlow > Fix For: 10.1.0.CR1, 10.1.0.Final > > > I have two EARs: > {code} > module1.ear > | > +--ejb.jar > | > +--META-INF > | > +--persistence.xml with persistence unit "module1-pu" > {code} > and > {code} > module2.ear > | > +--META-INF > | | > | +--jboss-all.xml > | > +--ejb.jar > | > +--META-INF > | > +--persistence.xml with persistence unit "module2-pu" > {code} > module2.ear/META-INF/jboss-all.xml contains: > {code:xml} > <jboss xmlns="urn:jboss:1.0"> > <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0"> > <dependency name="module1.ear" /> > </jboss-deployment-dependencies> > </jboss> > {code} > When I redeploy module1.ear, module2.ear not redeployed automatically with error: *java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource module2.ear/ejb.jar#module2-pu* (on wildfly 8.2.0.Final: *java.lang.IllegalStateException: JBAS014666: Duplicate resource module2.ear/ejb.jar#module2-pu*) > Full redeploy log: > {code} > 09:11:31,425 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'module2.ear/ejb.jar#module2-pu' > 09:11:31,426 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service 'module2.ear/ejb.jar#module2-pu' > 09:11:31,431 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'module1.ear/ejb.jar#module1-pu' > 09:11:31,434 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service 'module1.ear/ejb.jar#module1-pu' > 09:11:31,437 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0208: Stopped subdeployment (runtime-name: ejb.jar) in 17ms > 09:11:31,438 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment module1.ear (runtime-name: module1.ear) in 18ms > 09:11:31,495 INFO [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0009: Undeployed "module1.ear" (runtime-name: "module1.ear") > 09:11:31,495 INFO [org.jboss.as.controller] (management-handler-thread - 3) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."module1.ear".deploymentCompleteService (missing) dependents: [service jboss.deployment.unit."module2.ear".PARSE, service jboss.deployment.subunit."module2.ear"."ejb.jar".PARSE] > > > 09:11:31,558 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /opt/wildfly/standalone/data/content/69/baf0eeab47c006bc1f3d99b21b4355fac62d13/content > 09:11:43,170 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /opt/wildfly/standalone/data/content/69/baf0eeab47c006bc1f3d99b21b4355fac62d13/content > 09:11:43,266 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "module1.ear" (runtime-name: "module1.ear") > 09:11:43,268 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0207: Starting subdeployment (runtime-name: "ejb.jar") > 09:11:43,273 INFO [org.jboss.as.jpa] (MSC service thread 1-1) WFLYJPA0002: Read persistence.xml for module1-pu > 09:11:43,289 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 'module1.ear/ejb.jar#module1-pu' > 09:11:43,289 INFO [org.hibernate.jpa.internal.util.LogHelper] (ServerService Thread Pool -- 63) HHH000204: Processing PersistenceUnitInfo [ > name: module1-pu > ...] > 09:11:43,292 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0010: Starting Persistence Unit (phase 2 of 2) Service 'module1.ear/ejb.jar#module1-pu' > 09:11:43,293 INFO [org.hibernate.dialect.Dialect] (ServerService Thread Pool -- 63) HHH000400: Using dialect: org.hibernate.dialect.H2Dialect > 09:11:43,293 WARN [org.hibernate.dialect.H2Dialect] (ServerService Thread Pool -- 63) HHH000431: Unable to determine H2 database version, certain features may not work > 09:11:43,294 INFO [org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory] (ServerService Thread Pool -- 63) HHH000397: Using ASTQueryTranslatorFactory > 09:11:43,296 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0070: Deployment restart detected for deployment module2.ear, performing full redeploy instead. > 09:11:43,296 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0070: Deployment restart detected for deployment ejb.jar, performing full redeploy instead. > 09:11:43,296 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0208: Stopped subdeployment (runtime-name: ejb.jar) in 0ms > 09:11:43,297 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment module2.ear (runtime-name: module2.ear) in 1ms > 09:11:43,298 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "module2.ear" (runtime-name: "module2.ear") > 09:11:43,299 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0207: Starting subdeployment (runtime-name: "ejb.jar") > 09:11:43,300 INFO [org.jboss.as.jpa] (MSC service thread 1-2) WFLYJPA0002: Read persistence.xml for module2-pu > 09:11:43,307 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 'module2.ear/ejb.jar#module2-pu' > 09:11:43,308 INFO [org.hibernate.jpa.internal.util.LogHelper] (ServerService Thread Pool -- 63) HHH000204: Processing PersistenceUnitInfo [ > name: module2-pu > ...] > 09:11:43,312 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."module2.ear"."ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."module2.ear"."ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "ejb.jar" of deployment "module2.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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) > Caused by: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource module2.ear/ejb.jar#module2-pu > at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:248) > at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:143) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addManagementConsole(PersistenceUnitServiceHandler.java:1128) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseTwo(PersistenceUnitServiceHandler.java:704) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:289) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleJarDeployment(PersistenceUnitServiceHandler.java:162) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:133) > at org.jboss.as.jpa.processor.PersistenceCompleteInstallProcessor.deploy(PersistenceCompleteInstallProcessor.java:55) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > ... 5 more > > > 09:11:43,376 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "module1.ear" (runtime-name : "module1.ear") > 09:11:43,376 INFO [org.jboss.as.controller] (management-handler-thread - 2) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.subunit."module2.ear"."ejb.jar" (unavailable) dependents: [service jboss.deployment.unit."module2.ear".PARSE] > service jboss.deployment.subunit."module2.ear"."ejb.jar".STRUCTURE (unavailable) dependents: [service jboss.deployment.unit."module2.ear".PARSE] > service jboss.deployment.subunit."module2.ear"."ejb.jar".deploymentCompleteService (missing) dependents: [service jboss.deployment.unit."module2.ear".deploymentCompleteService] > WFLYCTL0185: Newly corrected services: > service jboss.deployment.unit."module1.ear".deploymentCompleteService (new available) > WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."module2.ear"."ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."module2.ear"."ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "ejb.jar" of deployment "module2.ear" > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1288) KieModuleMetaData: Enhance to return a collection of "function" definitons

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1288?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-1288: ------------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > KieModuleMetaData: Enhance to return a collection of "function" definitons > -------------------------------------------------------------------------- > > Key: DROOLS-1288 > URL: https://issues.jboss.org/browse/DROOLS-1288 > Project: Drools > Issue Type: Feature Request > Affects Versions: 7.0.0.Beta1 > Reporter: Michael Anstis > Assignee: Mario Fusco > Priority: Minor > > Functions used in DRL need to be in the same file as the DRL using them; otherwise they need to be imported. Guvnor 5.x built a single {{String}} containing the definition of *all* assets in a project to {{PackageBuilder}} (IIRC) so all functions were always in the same file as any consuming DRL. > In 6.x we add individual files to {{KieBuilder}} and hence functions are (more than likely) in different files to the DRL using them. Classes used by a specific file need to be imported (if they are not in the same package). Functions will now also need to be imported. > This request is to enhance {{KieModuleMetaData}} to return a collection of functions so that we can populate these in the {{DataModelOracle}} passed to the client and used to drive the "Import Data Object" screen on editors. We'd need to enhance the DMO and related "import" screens to handle functions. [~nheron] is to raise a GUVNOR JIRA for such enhancement. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1288) KieModuleMetaData: Enhance to return a collection of "function" definitons

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1288?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-1288: ---------------------------------- Component/s: core engine > KieModuleMetaData: Enhance to return a collection of "function" definitons > -------------------------------------------------------------------------- > > Key: DROOLS-1288 > URL: https://issues.jboss.org/browse/DROOLS-1288 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 7.0.0.Beta1 > Reporter: Michael Anstis > Assignee: Mario Fusco > Priority: Minor > > Functions used in DRL need to be in the same file as the DRL using them; otherwise they need to be imported. Guvnor 5.x built a single {{String}} containing the definition of *all* assets in a project to {{PackageBuilder}} (IIRC) so all functions were always in the same file as any consuming DRL. > In 6.x we add individual files to {{KieBuilder}} and hence functions are (more than likely) in different files to the DRL using them. Classes used by a specific file need to be imported (if they are not in the same package). Functions will now also need to be imported. > This request is to enhance {{KieModuleMetaData}} to return a collection of functions so that we can populate these in the {{DataModelOracle}} passed to the client and used to drive the "Import Data Object" screen on editors. We'd need to enhance the DMO and related "import" screens to handle functions. [~nheron] is to raise a GUVNOR JIRA for such enhancement. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7156) UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown

by Scott Marlow (JIRA)

Scott Marlow created WFLY-7156: ---------------------------------- Summary: UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown Key: WFLY-7156 URL: https://issues.jboss.org/browse/WFLY-7156 Project: WildFly Issue Type: Feature Request Components: JPA / Hibernate Affects Versions: 10.1.0.Final Environment: *AppServer:* WildFly 10.1.0.Final *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar Reporter: Scott Marlow Assignee: Scott Marlow Fix For: 11.0.0.Alpha1 As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. *The obtained defect:* A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) *FIX:* We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... _Changes_: The method getSynchronizationType returns declared synchronization type. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7142) check for SynchronizationType.UNSYNCHRONIZED when processing persistence unit / context references from deployment descriptors

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7142?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-7142: ------------------------------- Fix Version/s: 11.0.0.Alpha1 > check for SynchronizationType.UNSYNCHRONIZED when processing persistence unit / context references from deployment descriptors > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-7142 > URL: https://issues.jboss.org/browse/WFLY-7142 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 11.0.0.Alpha1 > > > See org.jboss.as.jpa.processor.PersistenceRefProcessor.getPersistenceContextRefs() which should check for SynchronizationType.UNSYNCHRONIZED. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7130) PersistenceProperty specified in @PersistenceContext should be passed to the created EntityManager

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7130?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-7130: ------------------------------- Fix Version/s: 11.0.0.Alpha1 > PersistenceProperty specified in @PersistenceContext should be passed to the created EntityManager > --------------------------------------------------------------------------------------------------- > > Key: WFLY-7130 > URL: https://issues.jboss.org/browse/WFLY-7130 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: JBoss AS7 7.1.1.Final, 10.1.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 11.0.0.Alpha1 > > > While working on the unit test for WFLY-7075, I noticed that PersistenceContext properties are not being passed correctly to the Injected EntityManager, we should fix that. > For Example: > {quote} > @PersistenceContext(type = PersistenceContextType.TRANSACTION, unitName = "mypc", properties={@PersistenceProperty(name="wildfly.jpa.allowjoinedunsync", value="true")}) > private EntityManager allowjoinedunsyncEm; > {quote} > Is passing an incorrect form of the property values. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-7075: ------------------------------- Fix Version/s: 11.0.0.Alpha1 > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Fix For: 11.0.0.Alpha1 > > Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7108) UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7108?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-7108: ------------------------------- Fix Version/s: 11.0.0.Alpha1 > UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7108 > URL: https://issues.jboss.org/browse/WFLY-7108 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 11.0.0.Alpha1 > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1810) PeriodicSizeRotatingFileHandler's are always replaced during boot

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1810?page=com.atlassian.jira.plugi... ] James Perkins edited comment on WFCORE-1810 at 9/20/16 12:00 PM: ----------------------------------------------------------------- [~panossot] Does this issue still exist? It looks like it was resolved in WFCORE-1018. was (Author: jamezp): Does this issue still exist? It looks like it was resolved in WFCORE-1018. > PeriodicSizeRotatingFileHandler's are always replaced during boot > ----------------------------------------------------------------- > > Key: WFCORE-1810 > URL: https://issues.jboss.org/browse/WFCORE-1810 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Panagiotis Sotiropoulos > Assignee: James Perkins > Fix For: 2.0.0.CR6 > > > A {{periodic-size-rotating-file-handler}} will be replaced during the subsystem add operation. This could be an issue with {{async-handler}}'s where the handler may see the old handler that was closed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-433) Support verification of a users certificate against an LDAP Server

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-433?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-433: -------------------------------------- I am thinking for this issue using the serial number. Or any other information we can pull from the cert to search for the LDAP entry. The LDAP KeyStore you have written will also be an alternative so I think that covers using LDAP as a trust store. > Support verification of a users certificate against an LDAP Server > ------------------------------------------------------------------ > > Key: ELY-433 > URL: https://issues.jboss.org/browse/ELY-433 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms, SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Fix For: 1.1.0.Beta10 > > > LDAP realm should be able to authenticate user using user certificate. > This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-433) Support verification of a users certificate against an LDAP Server

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-433?page=com.atlassian.jira.plugin.sy... ] Jan Kalina edited comment on ELY-433 at 9/20/16 11:50 AM: ---------------------------------------------------------- It is possible to do this by two ways: * To use LDAP as trust-store and to have a whole certificate of user in database * To have a CA in trust-store and authenticate users by certificate serial number (Apache HTTP server do it by this way) * Not mentioning a possibility to use same property of certificate signed by CA Which way(s) do we want to support? was (Author: honza889): It is possible to do this by two ways: * To use LDAP as trust-store and authenticate directly by whole certificate * To have a CA in trust-store and authenticate users by certificate serial number (Apache HTTP server do it by this way) Which way(s) do we want to support? > Support verification of a users certificate against an LDAP Server > ------------------------------------------------------------------ > > Key: ELY-433 > URL: https://issues.jboss.org/browse/ELY-433 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms, SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Fix For: 1.1.0.Beta10 > > > LDAP realm should be able to authenticate user using user certificate. > This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-433) Support verification of a users certificate against an LDAP Server

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-433?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-433: -------------------------------- It is possible to do this by two ways: * To use LDAP as trust-store and authenticate directly by whole certificate * To have a CA in trust-store and authenticate users by certificate serial number (Apache HTTP server do it by this way) Which way(s) do we want to support? > Support verification of a users certificate against an LDAP Server > ------------------------------------------------------------------ > > Key: ELY-433 > URL: https://issues.jboss.org/browse/ELY-433 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms, SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Fix For: 1.1.0.Beta10 > > > LDAP realm should be able to authenticate user using user certificate. > This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1810) PeriodicSizeRotatingFileHandler's are always replaced during boot

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1810?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-1810: --------------------------------------- Does this issue still exist? It looks like it was resolved in WFCORE-1018. > PeriodicSizeRotatingFileHandler's are always replaced during boot > ----------------------------------------------------------------- > > Key: WFCORE-1810 > URL: https://issues.jboss.org/browse/WFCORE-1810 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Panagiotis Sotiropoulos > Assignee: James Perkins > Fix For: 2.0.0.CR6 > > > A {{periodic-size-rotating-file-handler}} will be replaced during the subsystem add operation. This could be an issue with {{async-handler}}'s where the handler may see the old handler that was closed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7123) Use elytron ssl-context for undertow default https listener

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7123?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7123: -------------------------------------- Assignee: Darran Lofthouse (was: Stuart Douglas) > Use elytron ssl-context for undertow default https listener > ----------------------------------------------------------- > > Key: WFLY-7123 > URL: https://issues.jboss.org/browse/WFLY-7123 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > > Default undertow https listener use legacy ssl context in standalone-elytron.xml . > {code} > <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/> > {code} > Once elytron becomes default security solution in wildfly it has to use elytron ssl context. In meantime prepare such configuration in standalone-elytron.xml > {code} > <https-listener name="https" socket-binding="https" ssl-context="elytron-ssl-context" enable-http2="true"/> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6700) MBeanServer.isRegistered() fails when the security manager is enabled

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6700?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-6700: -------------------------------------- Assignee: Brian Stansberry (was: Jason Greene) > MBeanServer.isRegistered() fails when the security manager is enabled > --------------------------------------------------------------------- > > Key: WFLY-6700 > URL: https://issues.jboss.org/browse/WFLY-6700 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Reporter: Derek Horton > Assignee: Brian Stansberry > > Calling MBeanServer.isRegistered() in a servlet fails with the following error when the security manager is enabled: > :WFSM000001: Permission check failed (permission "("org.jboss.as.controller.access.rbac.RunAsRolePermission" "org.jboss.as.controller.access.rbac.RunAsRolePermission.SUPERUSER")" in code source "(vfs:/content/SimpleWar.war/WEB-INF/classes <no signer certificates>)" of "null") > The code looks like the following: > final MBeanServer server = ManagementFactory.getPlatformMBeanServer(); > final ObjectName mbeanName = new ObjectName("ima.test:type=imaTest"); > System.out.println("*** calling MBeanServer.isRegistered() - "+server.isRegistered(mbeanName)); > The META-INF/jboss-permissions.xml looks like the following: > <?xml version="1.0" encoding="UTF-8"?> > <permissions xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="7"> > <permission> > <class-name>javax.management.MBeanServerPermission</class-name> > <name>createMBeanServer</name> > </permission> > <permission> > <class-name>org.jboss.as.controller.access.rbac.RunAsRolePermission</class-name> > <name>*</name> > </permission> > </permissions> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7145) Key-store atttribute read-only occures in xsd, but not in model

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-7145?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-7145: ----------------------------------- Component/s: Security > Key-store atttribute read-only occures in xsd, but not in model > --------------------------------------------------------------- > > Key: WFLY-7145 > URL: https://issues.jboss.org/browse/WFLY-7145 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > There is a attribute {{read-only}} mentioned in XSD. > {code} > <xs:attribute name="read-only" type="xs:boolean" > use="optional" default="false"> > <xs:annotation> > <xs:documentation> > When set to 'true' this attribute prevents the in-memory > representation of the file from being written back to the file. > </xs:documentation> > </xs:annotation> > </xs:attribute> > {code} > But not in model. Therefore can't be used. Is that feature related to modifiable realms, which was deffered to 7.2? So probably should be removed from XSD? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7155) Update Hibernate to 5.0.11

by Frank Langelage (JIRA)

[ https://issues.jboss.org/browse/WFLY-7155?page=com.atlassian.jira.plugin.... ] Frank Langelage commented on WFLY-7155: --------------------------------------- PR for 10.x is https://github.com/wildfly/wildfly/pull/9209 > Update Hibernate to 5.0.11 > -------------------------- > > Key: WFLY-7155 > URL: https://issues.jboss.org/browse/WFLY-7155 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Affects Versions: 10.2.0.Final, 11.0.0.Alpha1 > Reporter: Frank Langelage > Assignee: Scott Marlow > Fix For: 10.2.0.Final, 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7155) Update Hibernate to 5.0.11

by Frank Langelage (JIRA)

Frank Langelage created WFLY-7155: ------------------------------------- Summary: Update Hibernate to 5.0.11 Key: WFLY-7155 URL: https://issues.jboss.org/browse/WFLY-7155 Project: WildFly Issue Type: Component Upgrade Components: JPA / Hibernate Affects Versions: 10.2.0.Final, 11.0.0.Alpha1 Reporter: Frank Langelage Assignee: Scott Marlow Fix For: 10.2.0.Final, 11.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ] Scott Marlow commented on JASSIST-261: -------------------------------------- I have no suggestions myself. Would it make sense to ask the OpenJDK team working on Jigsaw for help? There is also a survey at [https://www.surveymonkey.de/r/JDK9EA], looking for feedback on experiences with JDK9. > Issue with javassist on jdk 9b112 > --------------------------------- > > Key: JASSIST-261 > URL: https://issues.jboss.org/browse/JASSIST-261 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Environment: Javassist with jdk 9b112 > Reporter: Hoang Chuong Tran > Assignee: Shigeru Chiba > > I am migrating a project to java 9, which also uses javassist to generate runtime code. > One test of mine fails on jdk 9b112 while it passes on jdk 8u77. > {noformat} > import static javassist.CtClass.voidType; > import java.lang.reflect.Method; > import java.lang.reflect.Modifier; > import java.util.HashMap; > import java.util.Map; > import org.junit.Test; > import javassist.ClassClassPath; > import javassist.ClassPool; > import javassist.CtClass; > import javassist.CtField; > import javassist.CtMethod; > import javassist.CtNewMethod; > public class MyTests { > public static class MyObject { > protected Object field; > Object getField() {return field;} > public void setField(Object field) {} > } > @Test > public void test() throws InstantiationException, IllegalAccessException { > Class<? extends MyObject> clazz = compile(MyObject.class); > clazz.newInstance().setField(null); > } > /** Compile a transfer class */ > public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) { > // Determine class setters > Map<String, Method> setters = extractSetters(targetClass); > ClassPool classPool = ClassPool.getDefault(); > classPool.insertClassPath(new ClassClassPath(targetClass)); > try { > // Compile a new transfer class on the fly > CtClass baseClass = classPool.get(MyObject.class.getName()); > CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass); > for(Method originalSetter : setters.values()) { > // Create a field to hold the attribute > Class<?> fieldClass = originalSetter.getParameterTypes()[0]; > CtClass fieldType = classPool.get(fieldClass.getName()); > String fieldName = originalSetter.getName().substring(3); > CtField field = new CtField(fieldType, fieldName, proxyClass); > proxyClass.addField(field); > // Create a setter method to set that field > CtClass[] parameters = new CtClass[] { fieldType }; > String setterBody = "{ System.out.println(\"Hello World\"); }"; > CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass); > proxyClass.addMethod(setter); > } > Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain()); > return javaClass; > } catch(Exception e) { > throw new RuntimeException("Failure during transfer compilation for " + targetClass, e); > } > } > /** Extract setter methods from a class */ > public static Map<String, Method> extractSetters(Class<?> cls) { > Map<String, Method> setters = new HashMap<String, Method>(); > for(Method method : cls.getMethods()) { > // Lookup setter methods > if(method.getName().startsWith("set")) { > // Only public setters > int modifiers = method.getModifiers(); > if(Modifier.isPublic(modifiers)) { > Class<?>[] exceptions = method.getExceptionTypes(); > Class<?>[] parameters = method.getParameterTypes(); > Class<?> returnType = method.getReturnType(); > if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) { > setters.put(method.getName(), method); > } > } > } > } > return setters; > } > } > {noformat} > On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. > On jdk 9b112, I got the following exception > {noformat} > java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject > at MyTests.compile(MyTests.java:68) > at MyTests.test(MyTests.java:29) > at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: javassist.NotFoundException: java.lang.Object > at javassist.ClassPool.get(ClassPool.java:450) > at MyTests.compile(MyTests.java:51) > ... 24 more > {noformat} > I suspect that is due to the jigsaw integration into the jdk. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7154) poor description of session-timeout, maximum-session-cache-size attributes

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-7154?page=com.atlassian.jira.plugin.... ] Ilia Vassilev reassigned WFLY-7154: ----------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > poor description of session-timeout, maximum-session-cache-size attributes > -------------------------------------------------------------------------- > > Key: WFLY-7154 > URL: https://issues.jboss.org/browse/WFLY-7154 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Minor > > Describe more properly in model/XSD client-ssl-context and server-ssl-context attributes: > * session-timeout > Should be timeout specified in seconds? > What does default value mean? > Negative values could be restricted on model level. > {code} > "session-timeout" => { > "type" => INT, > "description" => "The timeout for SSL sessions.", > "expressions-allowed" => true, > "nillable" => true, > "default" => 0, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > {code} > <xs:attribute name="session-timeout" type="xs:int" default="0"> > <xs:annotation> > <xs:documentation> > The timeout for SSL sessions. > </xs:documentation> > </xs:annotation> > </xs:attribute> > {code} > * maximum-session-cache-size > What does default value 0 mean? > Negative values could be restricted on model level > {code} > "maximum-session-cache-size" => { > "type" => INT, > "description" => "The maximum number of SSL sessions to be cached.", > "expressions-allowed" => true, > "nillable" => true, > "default" => 0, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > {code} > <xs:attribute name="maximum-session-cache-size" type="xs:int" default="0"> > <xs:annotation> > <xs:documentation> > The maximum number of SSL sessions in the cache. > </xs:documentation> > </xs:annotation> > </xs:attribute> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7075: ------------------------------------ Excellent to hear, thank you very much for reporting this issue and related ones as well. Thanks also for supplying the patches as well, even though we didn't get to discuss further whether you would do a pull request with them. On your next contribution(s), we can try harder, to get your code changes in. > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7154) poor description of session-timeout, maximum-session-cache-size attributes

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7154?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-6091 to WFLY-7154: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7154 (was: JBEAP-6091) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR5) > poor description of session-timeout, maximum-session-cache-size attributes > -------------------------------------------------------------------------- > > Key: WFLY-7154 > URL: https://issues.jboss.org/browse/WFLY-7154 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Minor > > Describe more properly in model/XSD client-ssl-context and server-ssl-context attributes: > * session-timeout > Should be timeout specified in seconds? > What does default value mean? > Negative values could be restricted on model level. > {code} > "session-timeout" => { > "type" => INT, > "description" => "The timeout for SSL sessions.", > "expressions-allowed" => true, > "nillable" => true, > "default" => 0, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > {code} > <xs:attribute name="session-timeout" type="xs:int" default="0"> > <xs:annotation> > <xs:documentation> > The timeout for SSL sessions. > </xs:documentation> > </xs:annotation> > </xs:attribute> > {code} > * maximum-session-cache-size > What does default value 0 mean? > Negative values could be restricted on model level > {code} > "maximum-session-cache-size" => { > "type" => INT, > "description" => "The maximum number of SSL sessions to be cached.", > "expressions-allowed" => true, > "nillable" => true, > "default" => 0, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > {code} > <xs:attribute name="maximum-session-cache-size" type="xs:int" default="0"> > <xs:annotation> > <xs:documentation> > The maximum number of SSL sessions in the cache. > </xs:documentation> > </xs:annotation> > </xs:attribute> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1810) PeriodicSizeRotatingFileHandler's are always replaced during boot

by Panagiotis Sotiropoulos (JIRA)

Panagiotis Sotiropoulos created WFCORE-1810: ----------------------------------------------- Summary: PeriodicSizeRotatingFileHandler's are always replaced during boot Key: WFCORE-1810 URL: https://issues.jboss.org/browse/WFCORE-1810 Project: WildFly Core Issue Type: Bug Components: Logging Reporter: Panagiotis Sotiropoulos Assignee: James Perkins Fix For: 2.0.0.CR6 A {{periodic-size-rotating-file-handler}} will be replaced during the subsystem add operation. This could be an issue with {{async-handler}}'s where the handler may see the old handler that was closed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1299) DROOLS-778 is back with 6.4.0

by Christoph Schachinger (JIRA)

Christoph Schachinger created DROOLS-1299: --------------------------------------------- Summary: DROOLS-778 is back with 6.4.0 Key: DROOLS-1299 URL: https://issues.jboss.org/browse/DROOLS-1299 Project: Drools Issue Type: Sub-task Components: core engine Affects Versions: 6.4.0.Final Reporter: Christoph Schachinger Assignee: Mario Fusco Issue DROOLS-778 is back again with version 6.4.0.FINAL -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-778) Deserialization error: java.io.InvalidClassException: org.drools.base.evaluators.StrEvaluatorDefinition$StrEvaluator; no valid constructor

by Christoph Schachinger (JIRA)

[ https://issues.jboss.org/browse/DROOLS-778?page=com.atlassian.jira.plugin... ] Christoph Schachinger commented on DROOLS-778: ---------------------------------------------- The issue is back with 6.4.0. We are serialising the knowledge-packages and deserializing them (for a quicker startup). This stars breaking with 6.4 for thouse rules which have the "str" operation in their WHEN condition. > Deserialization error: java.io.InvalidClassException: org.drools.base.evaluators.StrEvaluatorDefinition$StrEvaluator; no valid constructor > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-778 > URL: https://issues.jboss.org/browse/DROOLS-778 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 5.5.0.Final > Environment: Windows 7; Java 6; Drools 5.5.0.Final (incl. drools-core, drools-compiler, drools-spring and drools-camel) > Reporter: Philip McWilliams > Assignee: Mario Fusco > Fix For: 6.0.0.Final > > > I am seeking to compile rules at build-time and then save (serialize) the output to disk. At deployment, I then wish to build a knowledge base from the deserialized knowledge packages (rather than by re-compiling the source rules files). > In general this works ... unless I use the "str" operator in an LHS. This operator is implemented by the *org.drools.base.evaluators.StrEvaluatorDefinition$StrEvaluator* class and this class does not appear to deserialize properly. > A round trip exercise on my local machine always fails with this error: > {code} > java.io.InvalidClassException: org.drools.base.evaluators.StrEvaluatorDefinition$StrEvaluator; org.drools.base.evaluators.StrEvaluatorDefinition$StrEvaluator; no valid constructor > {code} > My serialization/deserialization code is standard ... to serialize: > {code} > private void saveOutput(KnowledgeBuilder kbuilder) throws IOException { > Collection<KnowledgePackage> kpkgs = kbuilder.getKnowledgePackages(); > String outputFilename = outputFile == null ? "" : outputFile.trim(); > if (outputFilename.isEmpty()) { > outputFilename = project.getBasedir() + "target/classes/drools.drlx"; > } > ObjectOutputStream out = null; > try { > getLog().info("Saving compiled Drools output to " + outputFilename); > out = new ObjectOutputStream(new FileOutputStream(outputFilename)); > out.writeObject(kpkgs); > } finally { > if (out != null) { > out.close(); > } > } > } > {code} > ... to deserialize: > {code} > private Collection<KnowledgePackage> deserializeKnowledgePackages(Resource[] knowledgePackageObjects) throws IOException, ClassNotFoundException { > Collection<KnowledgePackage> knowledgePackages = new ArrayList<KnowledgePackage>(); > for (Resource knowledgePackageObject : knowledgePackageObjects) { > LOG.info("Deserializing pre-compiled package " + knowledgePackageObject.getFilename()); > ObjectInputStream in = null; > try { > in = new ObjectInputStream(knowledgePackageObject.getInputStream()); > // The input stream might contain an individual package or a collection. > knowledgePackages.addAll((Collection<KnowledgePackage>) in.readObject()); > } finally { > if (in != null) { > in.close(); > } > } > } > return knowledgePackages; > } > {code} > My workaround is to avoid using the "str" operator. > *Apologies*: I have *not* checked version 6.2.0.Final because I have not yet worked out what versions of the Drools Spring and Camel modules to use (for 5.5.0.Final they were all versioned identically). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-623: -------------------------------------- Sorry, didn't read Honza's question fully ;-) > Checking for anonymous principal by name is insufficient > -------------------------------------------------------- > > Key: ELY-623 > URL: https://issues.jboss.org/browse/ELY-623 > Project: WildFly Elytron > Issue Type: Bug > Reporter: David Lloyd > Assignee: Jan Kalina > > In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}: > {noformat} > + if (AnonymousPrincipal.getInstance().getName().equals(name)) { > + if (! context.authorizeAnonymous(false)) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null); > + } > + } else { > + if (! (context.importIdentity(this) && context.authorize(name, authorize))) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null); > + } > } > {noformat} > Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7153) Inconsistency of resources *-ssl-context in model vs. XSD

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7153?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-6089 to WFLY-7153: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7153 (was: JBEAP-6089) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR5) > Inconsistency of resources *-ssl-context in model vs. XSD > --------------------------------------------------------- > > Key: WFLY-7153 > URL: https://issues.jboss.org/browse/WFLY-7153 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > * in client-ssl-context there is attribute {{security-domain}} in XSD, which is not in model. In case of client-ssl-context this probably does not make sense and reaaly should't be in XSD, neither. > * in both *-ssl-context there is provider in XSD and provider-loader in model. Sync it please. Probably possibility to specify both could be useful. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Viacheslav Astapkovich (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich edited comment on WFLY-7075 at 9/20/16 8:38 AM: ----------------------------------------------------------------------- I have tried latest changes - all works perfectly ) I also check properties overriding: {code:title=properties overriding} @PersistenceContext(properties={@PersistenceProperty(name="wildfly.jpa.allowjoinedunsync", value="false")}) private EntityManager em; {code} it also works as expected. was (Author: veselroger): I have tried latest changes - all works perfectly ) I also check properties overriding - it also works as expected. > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7152) Activate CDI request context during task execution

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-7152?page=com.atlassian.jira.plugin.... ] Martin Kouba reassigned WFLY-7152: ---------------------------------- Assignee: David Lloyd (was: Stuart Douglas) > Activate CDI request context during task execution > -------------------------------------------------- > > Key: WFLY-7152 > URL: https://issues.jboss.org/browse/WFLY-7152 > Project: WildFly > Issue Type: Feature Request > Components: CDI / Weld, EE > Reporter: Martin Kouba > Assignee: David Lloyd > > This is not required by any spec (CDI, Concurrency Utilities for Java EE). But it might be useful. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Viacheslav Astapkovich (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich commented on WFLY-7075: ---------------------------------------------- I have tried latest changes - all works perfectly ) I also check properties overriding - it also works as expected. > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7152) Activate CDI request context during task execution

by Jive JIRA Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7152?page=com.atlassian.jira.plugin.... ] Jive JIRA Integration updated WFLY-7152: ---------------------------------------- Forum Reference: https://developer.jboss.org/message/963025#963025 > Activate CDI request context during task execution > -------------------------------------------------- > > Key: WFLY-7152 > URL: https://issues.jboss.org/browse/WFLY-7152 > Project: WildFly > Issue Type: Feature Request > Components: CDI / Weld, EE > Reporter: Martin Kouba > Assignee: Stuart Douglas > > This is not required by any spec (CDI, Concurrency Utilities for Java EE). But it might be useful. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7152) Activate CDI request context during task execution

by Martin Kouba (JIRA)

Martin Kouba created WFLY-7152: ---------------------------------- Summary: Activate CDI request context during task execution Key: WFLY-7152 URL: https://issues.jboss.org/browse/WFLY-7152 Project: WildFly Issue Type: Feature Request Components: CDI / Weld, EE Reporter: Martin Kouba Assignee: Stuart Douglas This is not required by any spec (CDI, Concurrency Utilities for Java EE). But it might be useful. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7150) EJB injection with indirection via web.xml is ignored

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7150?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-7150: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1377705 Bugzilla Update: Perform > EJB injection with indirection via web.xml is ignored > ----------------------------------------------------- > > Key: WFLY-7150 > URL: https://issues.jboss.org/browse/WFLY-7150 > Project: WildFly > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > If a web application contains a Servlet and a REST service (as CDI Bean) with an @EJB(lookup="java:comp/env/xxxx") injection for a indirection via web.xml/jboss-web.xml the CDI Bean will ignore it without any message whereas the Servlet inject the EJB proxy as expected. > This approach is used to be able to change/adjust the target EJB by changing the DD and not the application code. > Reproducer can be found here: > git@github.com:wfink/jboss-eap-quickstarts.git > BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection2 > SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app) > see ejb-multi-server/README-reproducerEJB-injection -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1728) Pretty-printing XML validation errors

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1728?page=com.atlassian.jira.plugi... ] Miroslav Novak updated WFCORE-1728: ----------------------------------- Tester: Miroslav Novak > Pretty-printing XML validation errors > ------------------------------------- > > Key: WFCORE-1728 > URL: https://issues.jboss.org/browse/WFCORE-1728 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Server > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > Toby Crawley from Bob McWhirter's team has developed a small library for creating nicer feedback messages when xml parsing errors are found, based on analysis of the xsd.[1] He has done some work on integrating this library into WildFly for parsing the server/domain config documents and has proposed adding it in.[2] > [1] http://post-office.corp.redhat.com/archives/jboss-tag-public/2016-June/ms... > [2] http://lists.jboss.org/pipermail/wildfly-dev/2016-July/005280.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1793) add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1793?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet updated WFCORE-1793: -------------------------------------- Fix Version/s: (was: 3.0.0.Alpha8) > add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path > ------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1793 > URL: https://issues.jboss.org/browse/WFCORE-1793 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha8 > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > > Upon overwriting content in managed exploded deployments on wildfly-core, the following errors are produced: > {{CLI}} > {code}[standalone@localhost:9990 /] deploy /home/mjurc/testing/eap7-204/jboss-kitchensink-ear.ear > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy > {"outcome" => "success"} > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode > {"outcome" => "success"} > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy > {"outcome" => "success"} > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=true) > { > "outcome" => "failed", > "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", > "rolled-back" => true > } > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=false) > { > "outcome" => "failed", > "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", > "rolled-back" => true > } > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}]) > { > "outcome" => "failed", > "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", > "rolled-back" => true > }{code} > {{Server}} > {code}09:41:36,029 WARN [org.jboss.as.repository] (management-handler-thread - 5) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content7797527203290314566/content/test.txt > 09:45:27,505 WARN [org.jboss.as.repository] (management-handler-thread - 12) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content721393778736298367/content/test.txt > 09:45:36,352 WARN [org.jboss.as.repository] (management-handler-thread - 10) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content344811471223714239/content/test.txt{code} > This issue does not seem to arise when the content is passed to the server by input stream index. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1793) add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1793?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet reopened WFCORE-1793: --------------------------------------- The issue was in 2 parts, looks like only the first was fixed by the PR > add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path > ------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1793 > URL: https://issues.jboss.org/browse/WFCORE-1793 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha8 > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Alpha8 > > > Upon overwriting content in managed exploded deployments on wildfly-core, the following errors are produced: > {{CLI}} > {code}[standalone@localhost:9990 /] deploy /home/mjurc/testing/eap7-204/jboss-kitchensink-ear.ear > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy > {"outcome" => "success"} > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode > {"outcome" => "success"} > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy > {"outcome" => "success"} > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=true) > { > "outcome" => "failed", > "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", > "rolled-back" => true > } > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=false) > { > "outcome" => "failed", > "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", > "rolled-back" => true > } > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}]) > { > "outcome" => "failed", > "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", > "rolled-back" => true > }{code} > {{Server}} > {code}09:41:36,029 WARN [org.jboss.as.repository] (management-handler-thread - 5) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content7797527203290314566/content/test.txt > 09:45:27,505 WARN [org.jboss.as.repository] (management-handler-thread - 12) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content721393778736298367/content/test.txt > 09:45:36,352 WARN [org.jboss.as.repository] (management-handler-thread - 10) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content344811471223714239/content/test.txt{code} > This issue does not seem to arise when the content is passed to the server by input stream index. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7148) Excessive loopback connections on Windows

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7148?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-7148: ----------------------------------- please test on 10.1.0 to verify. also what do you mean by loopback connections? it does create as many threads, which result in file handles, but not connections, at least not on start. > Excessive loopback connections on Windows > ----------------------------------------- > > Key: WFLY-7148 > URL: https://issues.jboss.org/browse/WFLY-7148 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.2.0.Final > Reporter: Johan Persson > Assignee: Jason Greene > > Using WildFly 8.2.0 on Windows, an excessive amount of loopback connections are established upon application server start. The amount of connections is roughly equal to io-threads*2 > <subsystem xmlns="urn:jboss:domain:io:1.1"> > <worker name="default" io-threads="1000"/> > <buffer-pool name="default"/> > </subsystem> > (we are seeing ~2000 connections using io-threads=1000). The same configuration doesn't cause this issue on linux (We see 1000 I/O-threads on both windows and linux, but much fewer connections on linux). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7151) EJB injection with indirection via web.xml is ignored

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-7151: -------------------------------------- Summary: EJB injection with indirection via web.xml is ignored Key: WFLY-7151 URL: https://issues.jboss.org/browse/WFLY-7151 Project: WildFly Issue Type: Bug Reporter: Wolf-Dieter Fink Assignee: Jason Greene If a web application contains a Servlet and a REST service (as CDI Bean) with an @EJB(lookup="java:comp/env/xxxx") injection for a indirection via web.xml/jboss-web.xml the CDI Bean will ignore it without any message whereas the Servlet inject the EJB proxy as expected. This approach is used to be able to change/adjust the target EJB by changing the DD and not the application code. Reproducer can be found here: git@github.com:wfink/jboss-eap-quickstarts.git BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection2 SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app) see ejb-multi-server/README-reproducerEJB-injection -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7150) EJB injection with indirection via web.xml is ignored

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-7150: -------------------------------------- Summary: EJB injection with indirection via web.xml is ignored Key: WFLY-7150 URL: https://issues.jboss.org/browse/WFLY-7150 Project: WildFly Issue Type: Bug Reporter: Wolf-Dieter Fink Assignee: Jason Greene If a web application contains a Servlet and a REST service (as CDI Bean) with an @EJB(lookup="java:comp/env/xxxx") injection for a indirection via web.xml/jboss-web.xml the CDI Bean will ignore it without any message whereas the Servlet inject the EJB proxy as expected. This approach is used to be able to change/adjust the target EJB by changing the DD and not the application code. Reproducer can be found here: git@github.com:wfink/jboss-eap-quickstarts.git BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection2 SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app) see ejb-multi-server/README-reproducerEJB-injection -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2640) Unable to add cached-connection-manager after removing it once

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-2640?page=com.atlassian.jira.plugin.... ] Ingo Weiss commented on WFLY-2640: ---------------------------------- I discussed this with Stefano and this is by design. The pull request hides the {{:remove()}} and {{:add()}} operations from the CLI's auto-complete and operation names. > Unable to add cached-connection-manager after removing it once > -------------------------------------------------------------- > > Key: WFLY-2640 > URL: https://issues.jboss.org/browse/WFLY-2640 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Masafumi Miura > Assignee: Ingo Weiss > > {{<cached-connection-manager>}} is enabled in jca subsystem by default: > {code:xml} > <subsystem xmlns="urn:jboss:domain:jca:1.1"> > ... > <cached-connection-manager /> > </subsystem> > {code} > However, it is unable to re-enable {{<cached-connection-manager>}} once it is disabled. CLI command fails to add it due to duplicate resource. > {code} > [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:remove > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone@localhost:9990 /] :reload > { > "outcome" => "success", > "result" => undefined > } > [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:add > { > "outcome" => "failed", > "failure-description" => "JBAS014803: Duplicate resource [ > (\"subsystem\" => \"jca\"), > (\"cached-connection-manager\" => \"cached-connection-manager\") > ]", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1809) JBoss CLI patch command doesn't honor custom configuration location

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1809?page=com.atlassian.jira.plugi... ] Alexey Loubyansky moved JBEAP-6085 to WFCORE-1809: -------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1809 (was: JBEAP-6085) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Patching (was: Patching) Affects Version/s: 3.0.0.Alpha8 (was: 7.0.1.GA) (was: 7.0.2.GA) > JBoss CLI patch command doesn't honor custom configuration location > ------------------------------------------------------------------- > > Key: WFCORE-1809 > URL: https://issues.jboss.org/browse/WFCORE-1809 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 3.0.0.Alpha8 > Reporter: Alexey Loubyansky > > Suppose we are using custom standalone directory(example: standalone_dev) and if we try to rollback applied CP patch, with "--rest-configuration=true" option, it always restore configuration files from default location(JBOSS_HOME/standalone) not from the "standalone_dev" directory. I can see same result when I try to rollback patch through management console and through JBoss CLI in connected mode. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1809) JBoss CLI patch command doesn't honor custom configuration location

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1809?page=com.atlassian.jira.plugi... ] Alexey Loubyansky reassigned WFCORE-1809: ----------------------------------------- Assignee: Alexey Loubyansky > JBoss CLI patch command doesn't honor custom configuration location > ------------------------------------------------------------------- > > Key: WFCORE-1809 > URL: https://issues.jboss.org/browse/WFCORE-1809 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 3.0.0.Alpha8 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > > Suppose we are using custom standalone directory(example: standalone_dev) and if we try to rollback applied CP patch, with "--rest-configuration=true" option, it always restore configuration files from default location(JBOSS_HOME/standalone) not from the "standalone_dev" directory. I can see same result when I try to rollback patch through management console and through JBoss CLI in connected mode. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-623: --------------------------------- No, I disagree. It is far more useful to accept a string name. To acquire the anonymous identity, it's best to just query the security domain for it. If we want a method which authorizes an anonymous run-as, then we'd probably just get the anonymous identity and authorize it, or else make a convenience method on SecurityDomain to do that. > Checking for anonymous principal by name is insufficient > -------------------------------------------------------- > > Key: ELY-623 > URL: https://issues.jboss.org/browse/ELY-623 > Project: WildFly Elytron > Issue Type: Bug > Reporter: David Lloyd > Assignee: Jan Kalina > > In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}: > {noformat} > + if (AnonymousPrincipal.getInstance().getName().equals(name)) { > + if (! context.authorizeAnonymous(false)) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null); > + } > + } else { > + if (! (context.importIdentity(this) && context.authorize(name, authorize))) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null); > + } > } > {noformat} > Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7038) License files issues

by Petr Sakař (JIRA)

[ https://issues.jboss.org/browse/WFLY-7038?page=com.atlassian.jira.plugin.... ] Petr Sakař reopened WFLY-7038: ------------------------------ Assignee: Petr Sakař (was: Paul Gier) Another issues found > License files issues > -------------------- > > Key: WFLY-7038 > URL: https://issues.jboss.org/browse/WFLY-7038 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 10.1.0.Final > Reporter: Petr Sakař > Assignee: Petr Sakař > Fix For: 11.0.0.Alpha1 > > > Various problems with licenses were found. > - bsd.txt file contains BSD license template > - some licenses are incorrect -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7149) Unable to remove elytron subsystem with defined properties-realm

by Radim Hatlapatka (JIRA)

Radim Hatlapatka created WFLY-7149: -------------------------------------- Summary: Unable to remove elytron subsystem with defined properties-realm Key: WFLY-7149 URL: https://issues.jboss.org/browse/WFLY-7149 Project: WildFly Issue Type: Bug Components: Security Reporter: Radim Hatlapatka Assignee: Darran Lofthouse Priority: Critical When having elytron subsystem with only defined property-realm and calling remove on the subsystem, it fails due unsatisfied dependencies \[1\]. The subsystem is created from scratch with no dependencies outside of the subsystem => it shouldn't fail to remove. \[1\] {noformat} [standalone@localhost:9990 /] /subsystem=elytron:remove { "outcome" => "failed", "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: Service elytron.security-properties was depended upon by service org.wildfly.security.security-realm.elytron-security Service elytron.core-service was depended upon by service org.wildfly.security.security-realm.elytron-security", "rolled-back" => true } {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7148) Excessive loopback connections on Windows

by Johan Persson (JIRA)

Johan Persson created WFLY-7148: ----------------------------------- Summary: Excessive loopback connections on Windows Key: WFLY-7148 URL: https://issues.jboss.org/browse/WFLY-7148 Project: WildFly Issue Type: Bug Affects Versions: 8.2.0.Final Reporter: Johan Persson Assignee: Jason Greene Using WildFly 8.2.0 on Windows, an excessive amount of loopback connections are established upon application server start. The amount of connections is roughly equal to io-threads*2 <subsystem xmlns="urn:jboss:domain:io:1.1"> <worker name="default" io-threads="1000"/> <buffer-pool name="default"/> </subsystem> (we are seeing ~2000 connections using io-threads=1000). The same configuration doesn't cause this issue on linux (We see 1000 I/O-threads on both windows and linux, but much fewer connections on linux). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-623: -------------------------------------- +1 something like that, we only actually have a single instance of the AnonymousPrinicpal > Checking for anonymous principal by name is insufficient > -------------------------------------------------------- > > Key: ELY-623 > URL: https://issues.jboss.org/browse/ELY-623 > Project: WildFly Elytron > Issue Type: Bug > Reporter: David Lloyd > Assignee: Jan Kalina > > In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}: > {noformat} > + if (AnonymousPrincipal.getInstance().getName().equals(name)) { > + if (! context.authorizeAnonymous(false)) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null); > + } > + } else { > + if (! (context.importIdentity(this) && context.authorize(name, authorize))) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null); > + } > } > {noformat} > Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7143) Unsafe Elytron role/permission mapping

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7143?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7143: ---------------------------------------- [~honza889] Can you please look at options for a constant permission mapper? I think the LoginPermission does need to be defined in the configuration as there could be cases where identities in a security domain should not be able to authenticate. > Unsafe Elytron role/permission mapping > -------------------------------------- > > Key: WFLY-7143 > URL: https://issues.jboss.org/browse/WFLY-7143 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Blocker > > Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then. > The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role. > {code:xml} > <mappers> > <simple-permission-mapper name="login-permission-mapper"> > <permission-mapping roles="All"> > <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/> > </permission-mapping> > </simple-permission-mapper> > <constant-role-mapper name="constant-roles" roles="All"/> > </mappers> > {code} > We have to make the default server configuration secure for users. > *Suggestions for improvement:* > * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles > * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7143) Unsafe Elytron role/permission mapping

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7143?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7143: -------------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Unsafe Elytron role/permission mapping > -------------------------------------- > > Key: WFLY-7143 > URL: https://issues.jboss.org/browse/WFLY-7143 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Blocker > > Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then. > The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role. > {code:xml} > <mappers> > <simple-permission-mapper name="login-permission-mapper"> > <permission-mapping roles="All"> > <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/> > </permission-mapping> > </simple-permission-mapper> > <constant-role-mapper name="constant-roles" roles="All"/> > </mappers> > {code} > We have to make the default server configuration secure for users. > *Suggestions for improvement:* > * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles > * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6924) driver-module-name not writable through the cli

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-6924?page=com.atlassian.jira.plugin.... ] Stefano Maestri resolved WFLY-6924. ----------------------------------- Resolution: Rejected > driver-module-name not writable through the cli > ----------------------------------------------- > > Key: WFLY-6924 > URL: https://issues.jboss.org/browse/WFLY-6924 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.0.0.Final > Reporter: trippstowe > Assignee: Stefano Maestri > Priority: Minor > > this used to work with previous versions > /subsystem=datasources/jdbc-driver=mysql/:write-attribute(name=driver-module-name,value=com.mysql.jdbc) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0048: Attribute driver-module-name is not writable", > "rolled-back" => true > } -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7147) Standardize access to node1's address in the test suite

by Jan Martiska (JIRA)

[ https://issues.jboss.org/browse/WFLY-7147?page=com.atlassian.jira.plugin.... ] Jan Martiska moved JBEAP-6082 to WFLY-7147: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7147 (was: JBEAP-6082) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) Affects Version/s: 10.0.0.Final (was: 7.1.0.DR4) > Standardize access to node1's address in the test suite > ------------------------------------------------------- > > Key: WFLY-7147 > URL: https://issues.jboss.org/browse/WFLY-7147 > Project: WildFly > Issue Type: Task > Components: Test Suite > Affects Versions: 10.0.0.Final > Reporter: Jan Martiska > Assignee: Jan Martiska > > Multinode tests in the TS which need to obtain the address of node1, do it in various non-standardized ways, it would be nice to standardize that. JBEAP-5998 added the possibility to obtain node1 address from {{TestSuiteEnvironment}} class, this issue will try to update the existing tests where it is appropriate. > In addition, let's fix {{ClusteredJPA2LCTestCase}} which currently fails when running with node1 set, because the test assumes it is always 127.0.0.1. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2640) Unable to add cached-connection-manager after removing it once

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-2640?page=com.atlassian.jira.plugin.... ] Lin Gao commented on WFLY-2640: ------------------------------- I think the problem of this issue is that the {{:remove()}} and {{:add()}} operations should be disabled. > Unable to add cached-connection-manager after removing it once > -------------------------------------------------------------- > > Key: WFLY-2640 > URL: https://issues.jboss.org/browse/WFLY-2640 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Masafumi Miura > Assignee: Ingo Weiss > > {{<cached-connection-manager>}} is enabled in jca subsystem by default: > {code:xml} > <subsystem xmlns="urn:jboss:domain:jca:1.1"> > ... > <cached-connection-manager /> > </subsystem> > {code} > However, it is unable to re-enable {{<cached-connection-manager>}} once it is disabled. CLI command fails to add it due to duplicate resource. > {code} > [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:remove > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone@localhost:9990 /] :reload > { > "outcome" => "success", > "result" => undefined > } > [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:add > { > "outcome" => "failed", > "failure-description" => "JBAS014803: Duplicate resource [ > (\"subsystem\" => \"jca\"), > (\"cached-connection-manager\" => \"cached-connection-manager\") > ]", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7126) No log messages comming from Elytron

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-7126?page=com.atlassian.jira.plugin.... ] Ingo Weiss reassigned WFLY-7126: -------------------------------- Assignee: Ingo Weiss (was: Darran Lofthouse) > No log messages comming from Elytron > ------------------------------------ > > Key: WFLY-7126 > URL: https://issues.jboss.org/browse/WFLY-7126 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Critical > > Elytron functionality is not covered (sufficiently) by log messages. > The log messages are cornerstone for customers when they're investigating configuration or functional issues. > Even when enabling {{TRACE}} log-level I was seeing No log messages coming from Elytron when I was configuring web authentication. When authentication fails it's not clear what's wrong - if password is invalid or permission mapper doesn't work or something else happened. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7126) No log messages comming from Elytron

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-7126?page=com.atlassian.jira.plugin.... ] Ingo Weiss commented on WFLY-7126: ---------------------------------- Got it. I will see what I can do here. > No log messages comming from Elytron > ------------------------------------ > > Key: WFLY-7126 > URL: https://issues.jboss.org/browse/WFLY-7126 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > > Elytron functionality is not covered (sufficiently) by log messages. > The log messages are cornerstone for customers when they're investigating configuration or functional issues. > Even when enabling {{TRACE}} log-level I was seeing No log messages coming from Elytron when I was configuring web authentication. When authentication fails it's not clear what's wrong - if password is invalid or permission mapper doesn't work or something else happened. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7146) Elytron, regex-name-validating-rewriter - 'match' attribute required and unclear description

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7146?page=com.atlassian.jira.plugin.... ] Jan Kalina moved JBEAP-6077 to WFLY-7146: ----------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7146 (was: JBEAP-6077) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: (was: 7.1.0.DR4) > Elytron, regex-name-validating-rewriter - 'match' attribute required and unclear description > -------------------------------------------------------------------------------------------- > > Key: WFLY-7146 > URL: https://issues.jboss.org/browse/WFLY-7146 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > Attribute 'match' is required when adding 'regex-name-validating-rewriter' although when reading the resource description via CLI, I can see that it has defined default value (true) and in [XSD file|https://github.com/wildfly-security/elytron-subsystem/blob/1.0.0.Alp...] it is not stated as a 'required'. Try: > {code} > /subsystem=elytron/regex-name-validating-rewriter=nameRewriter:add(pattern=".*") > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0172: match is required", > "rolled-back" => true > } > {code} > When you try to add also with 'match' attribute then rewriter is added successfully. > Also - the 'match' attribute description in CLI is not quite clear: > {code} > /subsystem=elytron/regex-name-validating-rewriter=nameRewriter:read-resource-description > ... > "match" => { > "type" => BOOLEAN, > "description" => "Should names that match the pattern be rejected or names that don't", > "expressions-allowed" => true, > "nillable" => false, > "default" => true, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > ... > {code} > After reading the description I still don't know what happens when pattern matches the name and value of 'match' attribute is set to 'true' - will it be rejected or not? > Expected behaviour: > # 'match' attribute to be arbitrary (or change XSD so it is in sync with model) > # more clear description of 'match' attribute -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7145) Key-store atttribute read-only occures in xsd, but not in model

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7145?page=com.atlassian.jira.plugin.... ] Jan Kalina moved JBEAP-6074 to WFLY-7145: ----------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7145 (was: JBEAP-6074) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > Key-store atttribute read-only occures in xsd, but not in model > --------------------------------------------------------------- > > Key: WFLY-7145 > URL: https://issues.jboss.org/browse/WFLY-7145 > Project: WildFly > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > There is a attribute {{read-only}} mentioned in XSD. > {code} > <xs:attribute name="read-only" type="xs:boolean" > use="optional" default="false"> > <xs:annotation> > <xs:documentation> > When set to 'true' this attribute prevents the in-memory > representation of the file from being written back to the file. > </xs:documentation> > </xs:annotation> > </xs:attribute> > {code} > But not in model. Therefore can't be used. Is that feature related to modifiable realms, which was deffered to 7.2? So probably should be removed from XSD? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7140) Injection with @EJB is not working as expected with CDI (REST) beans

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/WFLY-7140?page=com.atlassian.jira.plugin.... ] Tomas Remes commented on WFLY-7140: ----------------------------------- There is test available at https://github.com/tremes/wildfly/tree/ejb_lookup_test > Injection with @EJB is not working as expected with CDI (REST) beans > -------------------------------------------------------------------- > > Key: WFLY-7140 > URL: https://issues.jboss.org/browse/WFLY-7140 > Project: WildFly > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > The injection with @EJB should work the same way in a Rest service (CDI Bean) as it does in a Servlet. > @EJB(lookup = "ejb:jboss-ejb-multi-server-app-one/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne") > is not working correct if used in a CDI Bean in the reproducer example. > Reproducer can be found here: > git@github.com:wfink/jboss-eap-quickstarts.git > BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection > SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app) > see ejb-multi-server/README-reproducerEJB-injection -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7140) Injection with @EJB is not working as expected with CDI (REST) beans

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/WFLY-7140?page=com.atlassian.jira.plugin.... ] Tomas Remes updated WFLY-7140: ------------------------------ Component/s: CDI / Weld EJB > Injection with @EJB is not working as expected with CDI (REST) beans > -------------------------------------------------------------------- > > Key: WFLY-7140 > URL: https://issues.jboss.org/browse/WFLY-7140 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, EJB > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > The injection with @EJB should work the same way in a Rest service (CDI Bean) as it does in a Servlet. > @EJB(lookup = "ejb:jboss-ejb-multi-server-app-one/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne") > is not working correct if used in a CDI Bean in the reproducer example. > Reproducer can be found here: > git@github.com:wfink/jboss-eap-quickstarts.git > BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection > SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app) > see ejb-multi-server/README-reproducerEJB-injection -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ] Jan Kalina edited comment on ELY-623 at 9/20/16 1:54 AM: --------------------------------------------------------- Ok, so should I change input parameter of this method from "String name" to "Principal" ? (I dont see way to improve this without API change...) was (Author: honza889): Ok, so should I change input parameter of this method from "String name" to "Principal" ? > Checking for anonymous principal by name is insufficient > -------------------------------------------------------- > > Key: ELY-623 > URL: https://issues.jboss.org/browse/ELY-623 > Project: WildFly Elytron > Issue Type: Bug > Reporter: David Lloyd > Assignee: Jan Kalina > > In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}: > {noformat} > + if (AnonymousPrincipal.getInstance().getName().equals(name)) { > + if (! context.authorizeAnonymous(false)) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null); > + } > + } else { > + if (! (context.importIdentity(this) && context.authorize(name, authorize))) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null); > + } > } > {noformat} > Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ] Jan Kalina edited comment on ELY-623 at 9/20/16 1:54 AM: --------------------------------------------------------- Ok, so should I change input parameter of this method (createRunAsIdentity) from "String name" to "Principal" ? (I dont see way to improve this without API change...) was (Author: honza889): Ok, so should I change input parameter of this method from "String name" to "Principal" ? (I dont see way to improve this without API change...) > Checking for anonymous principal by name is insufficient > -------------------------------------------------------- > > Key: ELY-623 > URL: https://issues.jboss.org/browse/ELY-623 > Project: WildFly Elytron > Issue Type: Bug > Reporter: David Lloyd > Assignee: Jan Kalina > > In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}: > {noformat} > + if (AnonymousPrincipal.getInstance().getName().equals(name)) { > + if (! context.authorizeAnonymous(false)) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null); > + } > + } else { > + if (! (context.importIdentity(this) && context.authorize(name, authorize))) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null); > + } > } > {noformat} > Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-623: -------------------------------- Ok, so should I change input parameter of this method from "String name" to "Principal" ? > Checking for anonymous principal by name is insufficient > -------------------------------------------------------- > > Key: ELY-623 > URL: https://issues.jboss.org/browse/ELY-623 > Project: WildFly Elytron > Issue Type: Bug > Reporter: David Lloyd > Assignee: Jan Kalina > > In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}: > {noformat} > + if (AnonymousPrincipal.getInstance().getName().equals(name)) { > + if (! context.authorizeAnonymous(false)) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null); > + } > + } else { > + if (! (context.importIdentity(this) && context.authorize(name, authorize))) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null); > + } > } > {noformat} > Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-141) StringIndexOutOfBoundsException throw while formatting log with truncation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-141?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on LOGMGR-141: ------------------------------------------------ Fedor Gavrilov <fgavrilo(a)redhat.com> changed the Status of [bug 1350757|https://bugzilla.redhat.com/show_bug.cgi?id=1350757] from NEW to ASSIGNED > StringIndexOutOfBoundsException throw while formatting log with truncation > -------------------------------------------------------------------------- > > Key: LOGMGR-141 > URL: https://issues.jboss.org/browse/LOGMGR-141 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.1.0.Beta1 > > > When value in left-justified field is longer than maximum width following exception is thrown: > {code} > java.lang.StringIndexOutOfBoundsException > at java.lang.AbstractStringBuilder.delete(AbstractStringBuilder.java:733) > at java.lang.StringBuilder.delete(StringBuilder.java:244) > at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:212) > at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:83) > at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:32) > at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:46) > at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:302) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310) > at org.jboss.logmanager.Logger.logRaw(Logger.java:719) > at org.jboss.logmanager.Logger.log(Logger.java:670) > at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:50) > at org.jboss.logging.Logger.logf(Logger.java:2096) > {code} > Steps to Reproduce: > 1. Configure formatter with left-justified field with maximum width: > {code} > /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter,value="%d{HH:mm:ss,SSS} %-5p [%c{1.}] [%-20.-20t] %s%E%n") > {code} > (in the example above thread name should be truncated to 20 characters, left-justified) > 2. Write a log from a thread which has a name containg 21 characters or more. During server startup logs are written by "MSC service thread 1-7" thread. > It seems there is an error in {{org.jboss.logmanager.formatters.Formatters()}} class, line 212. There is: > {code:java} > builder.delete(oldLen, overflow + 1); > {code} > but should be: > {code:java} > builder.delete(oldLen, oldLen + overflow); > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7144) HTTP/1.1 request without Host header should be reported with 400 (Bad request)

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7144?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved JBEAP-6073 to WFLY-7144: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7144 (was: JBEAP-6073) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Web (Undertow) (was: Web (Undertow)) Affects Version/s: (was: 7.1.0.DR4) > HTTP/1.1 request without Host header should be reported with 400 (Bad request) > ------------------------------------------------------------------------------ > > Key: WFLY-7144 > URL: https://issues.jboss.org/browse/WFLY-7144 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > For a HTTP/1.1 client request there is requirement that it has defined Host header either with empty or non-empty value, see RFC 2616 [here|https://tools.ietf.org/html/rfc2616#section-14.23], [here|https://tools.ietf.org/html/rfc2616#section-5.2] and [here|https://tools.ietf.org/html/rfc2616#section-19.6.1.1]. > If client performs the HTTP/1.1 request with no Host header defined, server MUST response with 400 (Bad request): > {quote} > Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 > request does not include a Host request-header. > {quote} > Currently EAP7 response with actual page content when HTTP/1.1 request without Host header is performed, try: > {code} > telnet localhost 8080 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > GET / HTTP/1.1 > {code} > Expected behaviour: server respondes with 400 (Bad request) as specification says so. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1773) SynchServerOperation pulls down more config than necessary during slave reconnection to DC

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1773?page=com.atlassian.jira.plugi... ] Ken Wills commented on WFCORE-1773: ----------------------------------- This turned out to be a bug in the cached-dc persister, so it was in fact not storing enough, rather than 'pulling down too much,' on a reconnect. Fix should be incoming. > SynchServerOperation pulls down more config than necessary during slave reconnection to DC > ------------------------------------------------------------------------------------------ > > Key: WFCORE-1773 > URL: https://issues.jboss.org/browse/WFCORE-1773 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Ken Wills > Assignee: Ken Wills > > When a slave disconnects and reconnects to the DC for the first time, a complete copy of the domain config is sent. If the slave is using the default ignore-unused-configuration semantics, it still adds all of the additional configuration. > An additional side issue is the full-ha subsystems are being added in reverse order. > More detail in comments here https://github.com/wildfly/wildfly-core/pull/1754. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7143) Unsafe Elytron role/permission mapping

by Josef Cacek (JIRA)

[ https://issues.jboss.org/browse/WFLY-7143?page=com.atlassian.jira.plugin.... ] Josef Cacek updated WFLY-7143: ------------------------------ Description: Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then. The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role. {code:xml} <mappers> <simple-permission-mapper name="login-permission-mapper"> <permission-mapping roles="All"> <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/> </permission-mapping> </simple-permission-mapper> <constant-role-mapper name="constant-roles" roles="All"/> </mappers> {code} We have to make the default server configuration secure for users. *Suggestions for improvement:* * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings was: Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then. The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role. {code:xml} <mappers> <simple-permission-mapper name="login-permission-mapper"> <permission-mapping roles="All"> <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/> </permission-mapping> </simple-permission-mapper> <constant-role-mapper name="constant-roles" roles="All"/> </mappers> {code} We have to make the default server configuration secure for users. *Suggestions for improvement:* * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want to be assigned to some principals/roles * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings > Unsafe Elytron role/permission mapping > -------------------------------------- > > Key: WFLY-7143 > URL: https://issues.jboss.org/browse/WFLY-7143 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Blocker > > Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then. > The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role. > {code:xml} > <mappers> > <simple-permission-mapper name="login-permission-mapper"> > <permission-mapping roles="All"> > <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/> > </permission-mapping> > </simple-permission-mapper> > <constant-role-mapper name="constant-roles" roles="All"/> > </mappers> > {code} > We have to make the default server configuration secure for users. > *Suggestions for improvement:* > * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles > * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7143) Unsafe Elytron role/permission mapping

by Josef Cacek (JIRA)

Josef Cacek created WFLY-7143: --------------------------------- Summary: Unsafe Elytron role/permission mapping Key: WFLY-7143 URL: https://issues.jboss.org/browse/WFLY-7143 Project: WildFly Issue Type: Bug Components: Security Reporter: Josef Cacek Assignee: Darran Lofthouse Priority: Blocker Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then. The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role. {code:xml} <mappers> <simple-permission-mapper name="login-permission-mapper"> <permission-mapping roles="All"> <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/> </permission-mapping> </simple-permission-mapper> <constant-role-mapper name="constant-roles" roles="All"/> </mappers> {code} We have to make the default server configuration secure for users. *Suggestions for improvement:* * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want to be assigned to some principals/roles * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7139) IllegalStateException: WFLYEE0043: Component is stopped

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-7139?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on WFLY-7139: ------------------------------------------- I'm not sure of a more specific exception should be created in this case (such as for example ComponentIsShutdownException) and raised for this particular case. I decided to catch the IllegalStateException and check for the matching message instead. > IllegalStateException: WFLYEE0043: Component is stopped > ------------------------------------------------------- > > Key: WFLY-7139 > URL: https://issues.jboss.org/browse/WFLY-7139 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Alpha1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Labels: clean_undeploy > > Occured on client during remote EJB undeploy failover tests. Scenarios: > eap-7x-failover-ejb-ejbremote-undeploy-dist-async, > eap-7x-failover-ejb-ejbremote-undeploy-repl-async, > eap-7x-failover-ejb-ejbremote-undeploy-repl-sync. > Happened after "Failing node 0 (perf18)" at 2016/08/18 11:59:51:537 and stopped occuring at 2016/08/18 12:06:04:494 just before "Node 3 (perf21) is down". > Stacktrace from client: > {code} > 2016/08/18 11:59:52:694 EDT [ERROR][Runner - 1092] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <java.lang.IllegalStateException: WFLYEE0043: Component is stopped> > java.lang.IllegalStateException: WFLYEE0043: Component is stopped > at org.jboss.as.ee.component.BasicComponent.waitForComponentStart(BasicComponent.java:110) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:194) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) > at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) > at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:383) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > 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 ...asynchronous invocation...(Unknown Source) > at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96) > at org.jboss.ejb.client.EJBClientInvocationContext$1.run(EJBClientInvocationContext.java:282) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:279) > at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64) > at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290) > at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88) > at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290) > at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46) > at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290) > at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142) > at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265) > at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453) > at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204) > at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183) > at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146) > at com.sun.proxy.$Proxy2.getSerialAndIncrement(Unknown Source) > at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:84) > at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52) > at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103) > at java.lang.Thread.run(Thread.java:745) > {code} > Link to client logs: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clust... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7127) CMR collection gets corrupted in 2LC on certain concurrent access

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7127?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7127: ------------------------------------ Please also look at [https://vladmihalcea.com/2015/04/27/how-does-hibernate-read_only-cachecon...] which mentions a test of Hibernate updating read-only cached data. > CMR collection gets corrupted in 2LC on certain concurrent access > ----------------------------------------------------------------- > > Key: WFLY-7127 > URL: https://issues.jboss.org/browse/WFLY-7127 > Project: WildFly > Issue Type: Bug > Components: EJB, JPA / Hibernate, Transactions > Affects Versions: 10.1.0.Final > Environment: Ubuntu Linux 15.10. Java 1.8.0_66 > Reporter: Jari Juslin > Assignee: Scott Marlow > Attachments: infinispan_cmr_corruption_repro.tar.gz, standalone.xml > > > With certain parallel read and write access to same CMR collection it gets corrupted in Hibernate second level cache. After the event of corruption, any read access to that CMR collection ends up in Exception until the cache is cleared manually or Wildfly restarted. > Steps to reproduce: > 1) Make sure the CMR collection is not in cache. > 2) Start a read-only transaction accessing the said collection. > 3) In a separate transaction delete an element from that collection. > 4) End the read-only transaction. > 5) Read the resulting collection. It now throws EntityNotFoundException. > My understanding is that what happens is that the read-only transaction is read-only from the perspective of the database, so the system handles it as such. However, because for the 2LC it is actually a write transaction, when the transaction ends, the contents of the CMR collection visible to this transaction get committed to 2LC. If the write transaction ends before the read-only transaction, the old version of the collection stays in the 2LC. > Now, as the CMR collection contains an element already deleted from the DB, any attempt to manifest the collection results in EntityNotFoundException as the child element no longer exists in the DB. > For sake of repeatibility the test case here manually spawns threads to cause the effect. In real use, of course, this happens randomly when two different threads spawned by Wildfly happen to interleave with exactly a right kind of pattern. > The tar ball contains everything needed to reproduce the bug, including SQL dump of the MySQL/InnoDB database. The easiest way to run the testcase is to take Wildfly 10.1.0.Final and use the provided standalone.xml, add MySQL driver, import the DB with the provided SQL and then deploy the included packaged testcase.ear. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7127) CMR collection gets corrupted in 2LC on certain concurrent access

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7127?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7127: ------------------------------------ I think that the underlying question is whether Hibernate can handle the unexpected database write to "read-only data" and I don't think it can, as that is an optimization that Hibernate is making to avoid handling (external) updates to read-only data. Is that the right question to answer here? > CMR collection gets corrupted in 2LC on certain concurrent access > ----------------------------------------------------------------- > > Key: WFLY-7127 > URL: https://issues.jboss.org/browse/WFLY-7127 > Project: WildFly > Issue Type: Bug > Components: EJB, JPA / Hibernate, Transactions > Affects Versions: 10.1.0.Final > Environment: Ubuntu Linux 15.10. Java 1.8.0_66 > Reporter: Jari Juslin > Assignee: Scott Marlow > Attachments: infinispan_cmr_corruption_repro.tar.gz, standalone.xml > > > With certain parallel read and write access to same CMR collection it gets corrupted in Hibernate second level cache. After the event of corruption, any read access to that CMR collection ends up in Exception until the cache is cleared manually or Wildfly restarted. > Steps to reproduce: > 1) Make sure the CMR collection is not in cache. > 2) Start a read-only transaction accessing the said collection. > 3) In a separate transaction delete an element from that collection. > 4) End the read-only transaction. > 5) Read the resulting collection. It now throws EntityNotFoundException. > My understanding is that what happens is that the read-only transaction is read-only from the perspective of the database, so the system handles it as such. However, because for the 2LC it is actually a write transaction, when the transaction ends, the contents of the CMR collection visible to this transaction get committed to 2LC. If the write transaction ends before the read-only transaction, the old version of the collection stays in the 2LC. > Now, as the CMR collection contains an element already deleted from the DB, any attempt to manifest the collection results in EntityNotFoundException as the child element no longer exists in the DB. > For sake of repeatibility the test case here manually spawns threads to cause the effect. In real use, of course, this happens randomly when two different threads spawned by Wildfly happen to interleave with exactly a right kind of pattern. > The tar ball contains everything needed to reproduce the bug, including SQL dump of the MySQL/InnoDB database. The easiest way to run the testcase is to take Wildfly 10.1.0.Final and use the provided standalone.xml, add MySQL driver, import the DB with the provided SQL and then deploy the included packaged testcase.ear. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7075: ------------------------------------ Please try again with the latest changes on [https://github.com/scottmarlow/wildfly/tree/WFLY-7075_unsyncXPCExtension], the unit test is now properly testing the hint being in persistence.xml and we the hint is now also checked for in the persistence unit definition. > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7075: ------------------------------------ I was able to recreate after correcting my unit test intended to test with a persistence unit in persistence.xml that contains the new hint. > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7075: ------------------------------------ We might need to also check the EntityManagerFactory properties for the hints since I won't always have access to the persistence.xml properties. I think that it is fine that we are passing empty properties in for some cases as per JPA 2.1 spec section 7.9.1 Container Responsibilities: {quote} When the container creates an entity manager, it may pass a map of properties to the persistence provider by using the EntityManagerFactory.createEntityManager(Map map) method. If properties have been specified in the PersistenceContext annotation or the persistence-context-ref deployment descriptor element, this method must be used and the map must include the specified properties. {quote} I'll see if I can recreate with an @Inject. > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7133) Automatically define resource adapter for deployed RARs

by Guillermo González de Agüero (JIRA)

[ https://issues.jboss.org/browse/WFLY-7133?page=com.atlassian.jira.plugin.... ] Guillermo González de Agüero commented on WFLY-7133: ---------------------------------------------------- [~jesper.pedersen] could you please provide some reasoning behind the rejection? I know my first proposal wasn't accurate but what about the operation? Thanks! > Automatically define resource adapter for deployed RARs > ------------------------------------------------------- > > Key: WFLY-7133 > URL: https://issues.jboss.org/browse/WFLY-7133 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Guillermo González de Agüero > Assignee: Jesper Pedersen > > Deploying a RAR file enables the resource adapter for the server, but in order to configure it, you must manually add it to the Resource Adapters subsystem. This is error prone (you can put in invalid "archive name" for the resource adapter and it doesn't complaint) and little user friendly. > From a user perspective and from what can be read from the documentation (https://docs.jboss.org/author/display/WFLY10/Resource+adapters), it seems like the resource adapter is not enabled unless you explicitly define it. > It would be very simpler if RA deployments would be detected and registered as it's done for deployed JDBC drivers. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7132) Deprecate org.slf4j.ext module

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-7132?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-7132: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9202 > Deprecate org.slf4j.ext module > ------------------------------ > > Key: WFLY-7132 > URL: https://issues.jboss.org/browse/WFLY-7132 > Project: WildFly > Issue Type: Task > Reporter: James Perkins > Assignee: James Perkins > > The {{org.slf4j.ext}} module was required by a previous version of Weld. It was mistakenly not marked as {{private}}. No other module requires this dependency. By deprecating we can remove this module in a future release. For some notes on the discussion about this see https://github.com/wildfly/wildfly/pull/9145. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7142) check for SynchronizationType.UNSYNCHRONIZED when processing persistence unit / context references from deployment descriptors

by Scott Marlow (JIRA)

Scott Marlow created WFLY-7142: ---------------------------------- Summary: check for SynchronizationType.UNSYNCHRONIZED when processing persistence unit / context references from deployment descriptors Key: WFLY-7142 URL: https://issues.jboss.org/browse/WFLY-7142 Project: WildFly Issue Type: Feature Request Components: JPA / Hibernate Affects Versions: 10.1.0.Final, 10.0.0.Final Reporter: Scott Marlow Assignee: Scott Marlow See org.jboss.as.jpa.processor.PersistenceRefProcessor.getPersistenceContextRefs() which should check for SynchronizationType.UNSYNCHRONIZED. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7141) Naming subsystem does not expose a proper capability contract

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7141: ---------------------------------- Summary: Naming subsystem does not expose a proper capability contract Key: WFLY-7141 URL: https://issues.jboss.org/browse/WFLY-7141 Project: WildFly Issue Type: Bug Components: Naming Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 Subsystems that currently use JNDI bindings require that the naming subsystem be present. The naming subsystem should expose capabilities for which other subsystems can test for the presence, so they can function in the absence of the naming subsystem. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7075: ------------------------------------ Looks like using "jboss.entity.manager.jndi.name" injection of a transaction scoped EntityManager and use of @Inject to inject the entity manager are passing an empty property list to be used, this is likely why seeing the problem still. > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7075: ------------------------------------ Good to hear from you again. By trying suggested solution, I assume your building with the changes from [https://github.com/scottmarlow/wildfly/tree/WFLY-7075_unsyncXPCExtension]? I agree that applications should be able to set the wildfly.jpa.allowjoinedunsync=true property which I added a unit test for. If that isn't working as expected, we can look to see if I missed something in my code change. How do you inject the entity manager in your application? Via @Inject or @PersistenceContext? > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2092 at 9/19/16 12:35 PM: ---------------------------------------------------------- OK, the issue has been resolved. The main changes are: * MERGE3 now has all members (not just the coords) check for view inconsistencies if {{only_coords_run_consistency_checker}} is false (default) ** (This is done every {{check_interval}} ms) * To determine a merge leader, all actual coordinators are used. If this returns null (because there are no coords), _all_ members will be used * Participants (not just coordinators) are now also allowed to handle merges and install merge views was (Author: belaban): OK, the issue has been resolved. The main changes are: * MERGE3 now has all members (not just the coords) check for view inconsistencies if {{only_coords_run_consistency_checker}} is false (default) ** (This is done every {{check_interval}} ms) * To determine a merge leader, all actual coordiantors are used. If this returns null (because there are no coords), _all_ members will be used * Participants (not just coordinators) are now also allowed to handle merges and install merge views > MERGE3: merge never happens > --------------------------- > > Key: JGRP-2092 > URL: https://issues.jboss.org/browse/JGRP-2092 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > Attachments: jgroups.txt > > > (Reported by Neal Dillman) > In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this. > {noformat} > Host A view: B, X, Y, Z, A (where B should be coordinator) > Host B view: C, Q, R, S, B (where C should be coordinator) > Host C view: A, M, N, O, C (where A should be coordinator) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2092 at 9/19/16 12:32 PM: ---------------------------------------------------------- Hi [~ndillman] {quote} We no longer see the issue as it was worked around with staggering responses for all of the "bulk response" messages (ie: view change, etc). {quote} This may have reduced the chances of such a scenario happening, but I don't think it eliminated it completely. In my next comment, I'll show how such a scenario can be reproduced. Yes, a solution will involve a non-coordinator becoming merge leader, but this requires code changes in 3 places: the merge detection, the merge leader determination and the actual merge. was (Author: belaban): Hi [~ndillman] {quote} We no longer see the issue as it was worked around with staggering responses for all of the "bulk response" messages (ie: view change, etc). {quote} This may have reduced the chances of such a scenario happening, but I don't think it eliminated it completely. In my next comment, I'll show how such a scenario can be reproduced. Yes, a solution will involve a non-coordinator becoming merge leader, but this requires code changes in 3 places: the merge detection, the merge leader determination and the actual merge merge. > MERGE3: merge never happens > --------------------------- > > Key: JGRP-2092 > URL: https://issues.jboss.org/browse/JGRP-2092 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > Attachments: jgroups.txt > > > (Reported by Neal Dillman) > In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this. > {noformat} > Host A view: B, X, Y, Z, A (where B should be coordinator) > Host B view: C, Q, R, S, B (where C should be coordinator) > Host C view: A, M, N, O, C (where A should be coordinator) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7140) Injection with @EJB is not working as expected with CDI (REST) beans

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-7140: -------------------------------------- Summary: Injection with @EJB is not working as expected with CDI (REST) beans Key: WFLY-7140 URL: https://issues.jboss.org/browse/WFLY-7140 Project: WildFly Issue Type: Bug Reporter: Wolf-Dieter Fink Assignee: Jason Greene The injection with @EJB should work the same way in a Rest service (CDI Bean) as it does in a Servlet. @EJB(lookup = "ejb:jboss-ejb-multi-server-app-one/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne") is not working correct if used in a CDI Bean in the reproducer example. Reproducer can be found here: git@github.com:wfink/jboss-eap-quickstarts.git BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app) see ejb-multi-server/README-reproducerEJB-injection -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2086) FD_SOCK is keep trying to create a new socket to the killed server

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2086?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2086. ---------------------------- Resolution: Done > FD_SOCK is keep trying to create a new socket to the killed server > ------------------------------------------------------------------ > > Key: JGRP-2086 > URL: https://issues.jboss.org/browse/JGRP-2086 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.3 > Environment: JDG 6.6.0 (jgroups-3.6.3.Final-redhat-4.jar) > Reporter: Osamu Nagano > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > > In most cases FD_SOCK can detect a killed server immediately. But for unknown reason, FD_SOCK is keep trying to create a new socket to the killed server. As a consequence, installing a new cluster view is delayed until FD_ALL is triggered. > m04_n007_server.log is showing the behaviour. There is 28 nodes (4 machines (m03, ..., m06) and 7 nodes (n001, ..., n007) on each) and all nodes on m03 are killed at the same time on 15:07:34,543. FD_SOCK is keep trying to connect to a killed node saying "socket address for m03_n001/clustered could not be fetched, retrying". > {noformat} > [n007] 15:07:39,543 TRACE [org.jgroups.protocols.FD_SOCK] (Timer-8,shared=udp) m04_n007/clustered: broadcasting SUSPECT message (suspected_mbrs=[m03_n005/clustered, m03_n007/clustered]) > [n007] 15:07:39,544 TRACE [org.jgroups.protocols.FD_SOCK] (INT-20,shared=udp) m04_n007/clustered: received SUSPECT message from m04_n007/clustered: suspects=[m03_n005/clustered, m03_n007/clustered] > [n007] 15:07:39,546 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: socket address for m03_n001/clustered could not be fetched, retrying > [n007] 15:07:40,546 DEBUG [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: ping_dest is m03_n001/clustered, pingable_mbrs=[m03_n001/clustered, m03_n002/clustered, m03_n003/clustered, m03_n004/clustered, m03_n006/clustered, m06_n001/clustered, m06_n002/clustered, m06_n003/clustered, m06_n004/clustered, m06_n005/clustered, m06_n006/clustered, m06_n007/clustered, m05_n001/clustered, m05_n002/clustered, m05_n003/clustered, m05_n004/clustered, m05_n005/clustered, m05_n006/clustered, m05_n007/clustered, m04_n001/clustered, m04_n002/clustered, m04_n003/clustered, m04_n004/clustered, m04_n005/clustered, m04_n006/clustered, m04_n007/clustered] > [n007] 15:07:41,546 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: socket address for m03_n001/clustered could not be fetched, retrying > [n007] 15:07:42,546 DEBUG [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: ping_dest is m03_n001/clustered, pingable_mbrs=[m03_n001/clustered, m03_n002/clustered, m03_n003/clustered, m03_n004/clustered, m03_n006/clustered, m06_n001/clustered, m06_n002/clustered, m06_n003/clustered, m06_n004/clustered, m06_n005/clustered, m06_n006/clustered, m06_n007/clustered, m05_n001/clustered, m05_n002/clustered, m05_n003/clustered, m05_n004/clustered, m05_n005/clustered, m05_n006/clustered, m05_n007/clustered, m04_n001/clustered, m04_n002/clustered, m04_n003/clustered, m04_n004/clustered, m04_n005/clustered, m04_n006/clustered, m04_n007/clustered] > [n007] 15:07:43,547 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: socket address for m03_n001/clustered could not be fetched, retrying > ... > [n007] 15:10:53,700 DEBUG [org.jgroups.protocols.FD_ALL] (Timer-26,shared=udp) haven't received a heartbeat from m03_n005/clustered for 200059 ms, adding it to suspect list > {noformat} > From the TRACE log, you can find an address cache of FD_SOCK has only 23 members. > {noformat} > [n007] 14:40:50,471 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: got cache from m03_n005/clustered: cache is { > m04_n006/clustered=172.20.66.34:9945, > m05_n005/clustered=172.20.66.35:9938, > m06_n004/clustered=172.20.66.36:9931, > m03_n007/clustered=172.20.66.33:9952, > m05_n001/clustered=172.20.66.35:9910, > m06_n005/clustered=172.20.66.36:9938, > m05_n006/clustered=172.20.66.35:9945, > m03_n005/clustered=172.20.66.33:9938, > m05_n004/clustered=172.20.66.35:9931, > m04_n003/clustered=172.20.66.34:9924, > m04_n007/clustered=172.20.66.34:9952, > m05_n002/clustered=172.20.66.35:9917, > m05_n003/clustered=172.20.66.35:9924, > m04_n004/clustered=172.20.66.34:9931, > m06_n001/clustered=172.20.66.36:9910, > m06_n007/clustered=172.20.66.36:9952, > m04_n005/clustered=172.20.66.34:9938, > m04_n001/clustered=172.20.66.34:9910, > m05_n007/clustered=172.20.66.35:9952, > m06_n002/clustered=172.20.66.36:9917, > m06_n006/clustered=172.20.66.36:9945, > m04_n002/clustered=172.20.66.34:9917, > m06_n003/clustered=172.20.66.36:9924} > {noformat} > While pingable_mbrs has all 28 members which is from the current available cluster view. > {noformat} > [n007] 14:40:50,472 DEBUG [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: ping_dest is m03_n005/clustered, pingable_mbrs=[ > m03_n005/clustered, > m03_n007/clustered, > m03_n001/clustered, > m03_n002/clustered, > m03_n003/clustered, > m03_n004/clustered, > m03_n006/clustered, > m06_n001/clustered, > m06_n002/clustered, > m06_n003/clustered, > m06_n004/clustered, > m06_n005/clustered, > m06_n006/clustered, > m06_n007/clustered, > m05_n001/clustered, > m05_n002/clustered, > m05_n003/clustered, > m05_n004/clustered, > m05_n005/clustered, > m05_n006/clustered, > m05_n007/clustered, > m04_n001/clustered, > m04_n002/clustered, > m04_n003/clustered, > m04_n004/clustered, > m04_n005/clustered, > m04_n006/clustered, > m04_n007/clustered] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7126) No log messages comming from Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7126?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7126: ---------------------------------------- We don't have anyone working on this so far but I would suggest start small, make some changes to a small area send in a PR and then get some feedback. This is one of those issues that is a fine line between having enough information for users to diagnose problems whilst at the same time not adding a bottleneck to something that will be invoked a lot within the application server. > No log messages comming from Elytron > ------------------------------------ > > Key: WFLY-7126 > URL: https://issues.jboss.org/browse/WFLY-7126 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > > Elytron functionality is not covered (sufficiently) by log messages. > The log messages are cornerstone for customers when they're investigating configuration or functional issues. > Even when enabling {{TRACE}} log-level I was seeing No log messages coming from Elytron when I was configuring web authentication. When authentication fails it's not clear what's wrong - if password is invalid or permission mapper doesn't work or something else happened. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7126) No log messages comming from Elytron

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-7126?page=com.atlassian.jira.plugin.... ] Ingo Weiss commented on WFLY-7126: ---------------------------------- Hi [~dlofthouse], do you mind if I work on this one? > No log messages comming from Elytron > ------------------------------------ > > Key: WFLY-7126 > URL: https://issues.jboss.org/browse/WFLY-7126 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > > Elytron functionality is not covered (sufficiently) by log messages. > The log messages are cornerstone for customers when they're investigating configuration or functional issues. > Even when enabling {{TRACE}} log-level I was seeing No log messages coming from Elytron when I was configuring web authentication. When authentication fails it's not clear what's wrong - if password is invalid or permission mapper doesn't work or something else happened. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-301) Configuration of individual contexts for http management interface.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-301?page=com.atlassian.jira.plugin... ] Brian Stansberry resolved WFCORE-301. ------------------------------------- Resolution: Duplicate Issue > Configuration of individual contexts for http management interface. > ------------------------------------------------------------------- > > Key: WFCORE-301 > URL: https://issues.jboss.org/browse/WFCORE-301 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Alpha9 > > > At the moment all management requests are handled over the '/management' context, we also have a '/console' context to serve up the files for the admin console. > The '/management' context is secured using standard HTTP mechanisms, this decision was taken so that clients could be written in different languages and all they would need to know is how to use standard authentication mechanisms. Due to problems where web browsers could run malicious scripts cross origin resource sharing is completely disabled for this context. > We need to start to open up the handling of cross origin requests for a couple of reasons: - > - Enabling Keycloak SSO support. > - Alternative console distribution options > The '/management' context is going to be retained as-is for legacy clients, possibly even switched off by default. > A new context can then be added using non-browser based authentication, this could be SSO Keycloak or could be a form of Digest authentication where the response is handled by the console and not the web browser - either way as the browser is bypassed it is no longer at risk of sending malicious cross origin requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2086) FD_SOCK is keep trying to create a new socket to the killed server

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2086?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2086 at 9/19/16 10:37 AM: ---------------------------------------------------------- OK, replacing the HashMap with a LazyRemovalMap fixed this issue. Backporting to 3.6.x ... was (Author: belaban): OK, replacing the HashMap with a LazyRemovalMap fixed this issue. > FD_SOCK is keep trying to create a new socket to the killed server > ------------------------------------------------------------------ > > Key: JGRP-2086 > URL: https://issues.jboss.org/browse/JGRP-2086 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.3 > Environment: JDG 6.6.0 (jgroups-3.6.3.Final-redhat-4.jar) > Reporter: Osamu Nagano > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > > In most cases FD_SOCK can detect a killed server immediately. But for unknown reason, FD_SOCK is keep trying to create a new socket to the killed server. As a consequence, installing a new cluster view is delayed until FD_ALL is triggered. > m04_n007_server.log is showing the behaviour. There is 28 nodes (4 machines (m03, ..., m06) and 7 nodes (n001, ..., n007) on each) and all nodes on m03 are killed at the same time on 15:07:34,543. FD_SOCK is keep trying to connect to a killed node saying "socket address for m03_n001/clustered could not be fetched, retrying". > {noformat} > [n007] 15:07:39,543 TRACE [org.jgroups.protocols.FD_SOCK] (Timer-8,shared=udp) m04_n007/clustered: broadcasting SUSPECT message (suspected_mbrs=[m03_n005/clustered, m03_n007/clustered]) > [n007] 15:07:39,544 TRACE [org.jgroups.protocols.FD_SOCK] (INT-20,shared=udp) m04_n007/clustered: received SUSPECT message from m04_n007/clustered: suspects=[m03_n005/clustered, m03_n007/clustered] > [n007] 15:07:39,546 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: socket address for m03_n001/clustered could not be fetched, retrying > [n007] 15:07:40,546 DEBUG [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: ping_dest is m03_n001/clustered, pingable_mbrs=[m03_n001/clustered, m03_n002/clustered, m03_n003/clustered, m03_n004/clustered, m03_n006/clustered, m06_n001/clustered, m06_n002/clustered, m06_n003/clustered, m06_n004/clustered, m06_n005/clustered, m06_n006/clustered, m06_n007/clustered, m05_n001/clustered, m05_n002/clustered, m05_n003/clustered, m05_n004/clustered, m05_n005/clustered, m05_n006/clustered, m05_n007/clustered, m04_n001/clustered, m04_n002/clustered, m04_n003/clustered, m04_n004/clustered, m04_n005/clustered, m04_n006/clustered, m04_n007/clustered] > [n007] 15:07:41,546 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: socket address for m03_n001/clustered could not be fetched, retrying > [n007] 15:07:42,546 DEBUG [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: ping_dest is m03_n001/clustered, pingable_mbrs=[m03_n001/clustered, m03_n002/clustered, m03_n003/clustered, m03_n004/clustered, m03_n006/clustered, m06_n001/clustered, m06_n002/clustered, m06_n003/clustered, m06_n004/clustered, m06_n005/clustered, m06_n006/clustered, m06_n007/clustered, m05_n001/clustered, m05_n002/clustered, m05_n003/clustered, m05_n004/clustered, m05_n005/clustered, m05_n006/clustered, m05_n007/clustered, m04_n001/clustered, m04_n002/clustered, m04_n003/clustered, m04_n004/clustered, m04_n005/clustered, m04_n006/clustered, m04_n007/clustered] > [n007] 15:07:43,547 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: socket address for m03_n001/clustered could not be fetched, retrying > ... > [n007] 15:10:53,700 DEBUG [org.jgroups.protocols.FD_ALL] (Timer-26,shared=udp) haven't received a heartbeat from m03_n005/clustered for 200059 ms, adding it to suspect list > {noformat} > From the TRACE log, you can find an address cache of FD_SOCK has only 23 members. > {noformat} > [n007] 14:40:50,471 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: got cache from m03_n005/clustered: cache is { > m04_n006/clustered=172.20.66.34:9945, > m05_n005/clustered=172.20.66.35:9938, > m06_n004/clustered=172.20.66.36:9931, > m03_n007/clustered=172.20.66.33:9952, > m05_n001/clustered=172.20.66.35:9910, > m06_n005/clustered=172.20.66.36:9938, > m05_n006/clustered=172.20.66.35:9945, > m03_n005/clustered=172.20.66.33:9938, > m05_n004/clustered=172.20.66.35:9931, > m04_n003/clustered=172.20.66.34:9924, > m04_n007/clustered=172.20.66.34:9952, > m05_n002/clustered=172.20.66.35:9917, > m05_n003/clustered=172.20.66.35:9924, > m04_n004/clustered=172.20.66.34:9931, > m06_n001/clustered=172.20.66.36:9910, > m06_n007/clustered=172.20.66.36:9952, > m04_n005/clustered=172.20.66.34:9938, > m04_n001/clustered=172.20.66.34:9910, > m05_n007/clustered=172.20.66.35:9952, > m06_n002/clustered=172.20.66.36:9917, > m06_n006/clustered=172.20.66.36:9945, > m04_n002/clustered=172.20.66.34:9917, > m06_n003/clustered=172.20.66.36:9924} > {noformat} > While pingable_mbrs has all 28 members which is from the current available cluster view. > {noformat} > [n007] 14:40:50,472 DEBUG [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: ping_dest is m03_n005/clustered, pingable_mbrs=[ > m03_n005/clustered, > m03_n007/clustered, > m03_n001/clustered, > m03_n002/clustered, > m03_n003/clustered, > m03_n004/clustered, > m03_n006/clustered, > m06_n001/clustered, > m06_n002/clustered, > m06_n003/clustered, > m06_n004/clustered, > m06_n005/clustered, > m06_n006/clustered, > m06_n007/clustered, > m05_n001/clustered, > m05_n002/clustered, > m05_n003/clustered, > m05_n004/clustered, > m05_n005/clustered, > m05_n006/clustered, > m05_n007/clustered, > m04_n001/clustered, > m04_n002/clustered, > m04_n003/clustered, > m04_n004/clustered, > m04_n005/clustered, > m04_n006/clustered, > m04_n007/clustered] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2086) FD_SOCK is keep trying to create a new socket to the killed server

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2086?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2086: -------------------------------- OK, replacing the HashMap with a LazyRemovalMap fixed this issue. > FD_SOCK is keep trying to create a new socket to the killed server > ------------------------------------------------------------------ > > Key: JGRP-2086 > URL: https://issues.jboss.org/browse/JGRP-2086 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.3 > Environment: JDG 6.6.0 (jgroups-3.6.3.Final-redhat-4.jar) > Reporter: Osamu Nagano > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > > In most cases FD_SOCK can detect a killed server immediately. But for unknown reason, FD_SOCK is keep trying to create a new socket to the killed server. As a consequence, installing a new cluster view is delayed until FD_ALL is triggered. > m04_n007_server.log is showing the behaviour. There is 28 nodes (4 machines (m03, ..., m06) and 7 nodes (n001, ..., n007) on each) and all nodes on m03 are killed at the same time on 15:07:34,543. FD_SOCK is keep trying to connect to a killed node saying "socket address for m03_n001/clustered could not be fetched, retrying". > {noformat} > [n007] 15:07:39,543 TRACE [org.jgroups.protocols.FD_SOCK] (Timer-8,shared=udp) m04_n007/clustered: broadcasting SUSPECT message (suspected_mbrs=[m03_n005/clustered, m03_n007/clustered]) > [n007] 15:07:39,544 TRACE [org.jgroups.protocols.FD_SOCK] (INT-20,shared=udp) m04_n007/clustered: received SUSPECT message from m04_n007/clustered: suspects=[m03_n005/clustered, m03_n007/clustered] > [n007] 15:07:39,546 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: socket address for m03_n001/clustered could not be fetched, retrying > [n007] 15:07:40,546 DEBUG [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: ping_dest is m03_n001/clustered, pingable_mbrs=[m03_n001/clustered, m03_n002/clustered, m03_n003/clustered, m03_n004/clustered, m03_n006/clustered, m06_n001/clustered, m06_n002/clustered, m06_n003/clustered, m06_n004/clustered, m06_n005/clustered, m06_n006/clustered, m06_n007/clustered, m05_n001/clustered, m05_n002/clustered, m05_n003/clustered, m05_n004/clustered, m05_n005/clustered, m05_n006/clustered, m05_n007/clustered, m04_n001/clustered, m04_n002/clustered, m04_n003/clustered, m04_n004/clustered, m04_n005/clustered, m04_n006/clustered, m04_n007/clustered] > [n007] 15:07:41,546 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: socket address for m03_n001/clustered could not be fetched, retrying > [n007] 15:07:42,546 DEBUG [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: ping_dest is m03_n001/clustered, pingable_mbrs=[m03_n001/clustered, m03_n002/clustered, m03_n003/clustered, m03_n004/clustered, m03_n006/clustered, m06_n001/clustered, m06_n002/clustered, m06_n003/clustered, m06_n004/clustered, m06_n005/clustered, m06_n006/clustered, m06_n007/clustered, m05_n001/clustered, m05_n002/clustered, m05_n003/clustered, m05_n004/clustered, m05_n005/clustered, m05_n006/clustered, m05_n007/clustered, m04_n001/clustered, m04_n002/clustered, m04_n003/clustered, m04_n004/clustered, m04_n005/clustered, m04_n006/clustered, m04_n007/clustered] > [n007] 15:07:43,547 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: socket address for m03_n001/clustered could not be fetched, retrying > ... > [n007] 15:10:53,700 DEBUG [org.jgroups.protocols.FD_ALL] (Timer-26,shared=udp) haven't received a heartbeat from m03_n005/clustered for 200059 ms, adding it to suspect list > {noformat} > From the TRACE log, you can find an address cache of FD_SOCK has only 23 members. > {noformat} > [n007] 14:40:50,471 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: got cache from m03_n005/clustered: cache is { > m04_n006/clustered=172.20.66.34:9945, > m05_n005/clustered=172.20.66.35:9938, > m06_n004/clustered=172.20.66.36:9931, > m03_n007/clustered=172.20.66.33:9952, > m05_n001/clustered=172.20.66.35:9910, > m06_n005/clustered=172.20.66.36:9938, > m05_n006/clustered=172.20.66.35:9945, > m03_n005/clustered=172.20.66.33:9938, > m05_n004/clustered=172.20.66.35:9931, > m04_n003/clustered=172.20.66.34:9924, > m04_n007/clustered=172.20.66.34:9952, > m05_n002/clustered=172.20.66.35:9917, > m05_n003/clustered=172.20.66.35:9924, > m04_n004/clustered=172.20.66.34:9931, > m06_n001/clustered=172.20.66.36:9910, > m06_n007/clustered=172.20.66.36:9952, > m04_n005/clustered=172.20.66.34:9938, > m04_n001/clustered=172.20.66.34:9910, > m05_n007/clustered=172.20.66.35:9952, > m06_n002/clustered=172.20.66.36:9917, > m06_n006/clustered=172.20.66.36:9945, > m04_n002/clustered=172.20.66.34:9917, > m06_n003/clustered=172.20.66.36:9924} > {noformat} > While pingable_mbrs has all 28 members which is from the current available cluster view. > {noformat} > [n007] 14:40:50,472 DEBUG [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: ping_dest is m03_n005/clustered, pingable_mbrs=[ > m03_n005/clustered, > m03_n007/clustered, > m03_n001/clustered, > m03_n002/clustered, > m03_n003/clustered, > m03_n004/clustered, > m03_n006/clustered, > m06_n001/clustered, > m06_n002/clustered, > m06_n003/clustered, > m06_n004/clustered, > m06_n005/clustered, > m06_n006/clustered, > m06_n007/clustered, > m05_n001/clustered, > m05_n002/clustered, > m05_n003/clustered, > m05_n004/clustered, > m05_n005/clustered, > m05_n006/clustered, > m05_n007/clustered, > m04_n001/clustered, > m04_n002/clustered, > m04_n003/clustered, > m04_n004/clustered, > m04_n005/clustered, > m04_n006/clustered, > m04_n007/clustered] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1808) Operation to list dependencies/dependents for a deployment

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1808?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-7136 to WFCORE-1808: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1808 (was: WFLY-7136) Affects Version/s: (was: 10.1.0.Final) > Operation to list dependencies/dependents for a deployment > ---------------------------------------------------------- > > Key: WFCORE-1808 > URL: https://issues.jboss.org/browse/WFCORE-1808 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Guillermo González de Agüero > Assignee: Jason Greene > > If a deployment "A" has a dependency on deployment "B", and "B" is undeployed, "A" automatically changes its status to FAILED. > It's currently not possible to list what dependencies and dependents a deployment has. With two new operations (e.g. dependency-list and dependent-list) on the deployment resource, HAL could provide a confirmation dialog warning the user of side effects when undeploying. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1808) Operation to list dependencies/dependents for a deployment

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1808?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1808: ---------------------------------------- Component/s: Domain Management Assignee: (was: Jason Greene) > Operation to list dependencies/dependents for a deployment > ---------------------------------------------------------- > > Key: WFCORE-1808 > URL: https://issues.jboss.org/browse/WFCORE-1808 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Guillermo González de Agüero > > If a deployment "A" has a dependency on deployment "B", and "B" is undeployed, "A" automatically changes its status to FAILED. > It's currently not possible to list what dependencies and dependents a deployment has. With two new operations (e.g. dependency-list and dependent-list) on the deployment resource, HAL could provide a confirmation dialog warning the user of side effects when undeploying. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7139) IllegalStateException: WFLYEE0043: Component is stopped

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-7139?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz moved JBEAP-6064 to WFLY-7139: -------------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7139 (was: JBEAP-6064) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR3) > IllegalStateException: WFLYEE0043: Component is stopped > ------------------------------------------------------- > > Key: WFLY-7139 > URL: https://issues.jboss.org/browse/WFLY-7139 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Alpha1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Labels: clean_undeploy > > Occured on client during remote EJB undeploy failover tests. Scenarios: > eap-7x-failover-ejb-ejbremote-undeploy-dist-async, > eap-7x-failover-ejb-ejbremote-undeploy-repl-async, > eap-7x-failover-ejb-ejbremote-undeploy-repl-sync. > Happened after "Failing node 0 (perf18)" at 2016/08/18 11:59:51:537 and stopped occuring at 2016/08/18 12:06:04:494 just before "Node 3 (perf21) is down". > Stacktrace from client: > {code} > 2016/08/18 11:59:52:694 EDT [ERROR][Runner - 1092] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <java.lang.IllegalStateException: WFLYEE0043: Component is stopped> > java.lang.IllegalStateException: WFLYEE0043: Component is stopped > at org.jboss.as.ee.component.BasicComponent.waitForComponentStart(BasicComponent.java:110) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:194) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) > at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) > at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:383) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > 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 ...asynchronous invocation...(Unknown Source) > at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96) > at org.jboss.ejb.client.EJBClientInvocationContext$1.run(EJBClientInvocationContext.java:282) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:279) > at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64) > at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290) > at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88) > at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290) > at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46) > at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290) > at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142) > at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265) > at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453) > at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204) > at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183) > at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146) > at com.sun.proxy.$Proxy2.getSerialAndIncrement(Unknown Source) > at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:84) > at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52) > at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103) > at java.lang.Thread.run(Thread.java:745) > {code} > Link to client logs: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clust... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7138) Move security-manager subsystem from WildFly to WildFly Core

by Ondrej Kotek (JIRA)

Ondrej Kotek created WFLY-7138: ---------------------------------- Summary: Move security-manager subsystem from WildFly to WildFly Core Key: WFLY-7138 URL: https://issues.jboss.org/browse/WFLY-7138 Project: WildFly Issue Type: Bug Components: Security Manager Reporter: Ondrej Kotek Assignee: Stefan Guilhen Priority: Critical It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core. More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html...] thread on {{wildfly-dev}} mailing list. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on REMJMX-94: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1264555|https://bugzilla.redhat.com/show_bug.cgi?id=1264555] from ASSIGNED to CLOSED > Memory leak in remoting-jmx > --------------------------- > > Key: REMJMX-94 > URL: https://issues.jboss.org/browse/REMJMX-94 > Project: Remoting JMX > Issue Type: Bug > Affects Versions: 1.1.3.Final > Reporter: Libor Zoubek > Assignee: Darran Lofthouse > Labels: memory_leak > Fix For: 2.0.2.CR1 > > > In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed. > I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps: > 1. start new thread > 2. assign URL classloader to this thread (point it to jboss-client.jar) > 3. connect & disconnect to jmx-remoting endpoint > In this test no classes don't get GCed which after serveral iterations ends up in OOM. > My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org... > I am not sure if memleak is in remoting-jmx or some other underlying stuff. > I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ] Jan Kalina edited comment on ELY-627 at 9/19/16 9:05 AM: --------------------------------------------------------- *To discuss:* Should be Protocol enum removed and Strings used instead? (Alternative: only allow standard names ("TLSv1.2" - with dots) and add Oracle protocol names) was (Author: honza889): *To discuss:* Should be Protocol enum removed and Strings used instead? (Alternative: only allow standard names ("TLSv1.2") and add Oracle protocol names) > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: ELY-627 > URL: https://issues.jboss.org/browse/ELY-627 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.1.0.Beta8 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7134) Upgrade to Wildfly 10.0.0.Final: Messaging System issue

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7134?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-7134. ----------------------------- Assignee: (was: Jeff Mesnil) Resolution: Rejected Please use forums https://developer.jboss.org/en/wildfly for user help with migration. Jira is bug tracker where we track bugs that are confirmed as such not just a user usage problem. > Upgrade to Wildfly 10.0.0.Final: Messaging System issue > ------------------------------------------------------- > > Key: WFLY-7134 > URL: https://issues.jboss.org/browse/WFLY-7134 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Preeta Kuruvilla > Priority: Blocker > Attachments: standalone-full-WL-10.0.Final.xml, standalone-full-WL-8.2.xml > > > Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. > The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. > http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html > The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- > Let me know if this is good. Also I have attached the entire standalone-full.xml with this case. > <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> > <server name="default"> > <security enabled="false"/> > <statistics enabled="true"/> > <security-setting name="#"> > <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > </security-setting> > <address-setting name="#" redistribution-delay="1000" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> > <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> > <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> > <in-vm-connector name="in-vm" server-id="0"/> > <http-acceptor name="http-acceptor" http-listener="default"/> > <http-acceptor name="http-acceptor-throughput" http-listener="default"> > <param name="batch-delay" value="50"/> > <param name="direct-deliver" value="false"/> > </http-acceptor> > <in-vm-acceptor name="in-vm" server-id="0"/> > <jms-queue name="testQueue" entries="java:/queue/test java:jboss/exported/jms/queue/test"/> > <jms-queue name="ISEEOutboundQueue" entries="java:/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> > <jms-queue name="ISEEInboundQueue" entries="java:/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> > <jms-queue name="BEEEAuthorizationsQueue" entries="java:/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> > <jms-queue name="BEEERequisitionsQueue" entries="java:/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> > <jms-queue name="BEEEInboundQueue" entries="java:/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> > <jms-topic name="testTopic" entries="java:/topic/test java:jboss/exported/jms/topic/test"/> > <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> > <connection-factory name="RemoteConnectionFactory" entries="java:/RemoteConnectionFactory java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/> > <pooled-connection-factory name="activemq-ra" transaction="xa" entries="/JmsXA jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> > </server> > </subsystem> > InitialContext is created with parameters - jmsuser, password, and > BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port> > BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory > Issue we face is that after we upgraded to wildfly 10, the messages are not getting in the queues. This is not consistent as once in a while messages are getting processed. > I have attached the below standalone-full.xml for your reference :- > 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. > 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7137) Attribute "required" on key-store makes no difference of behaviour

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7137?page=com.atlassian.jira.plugin.... ] Jan Kalina reassigned WFLY-7137: -------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Attribute "required" on key-store makes no difference of behaviour > ------------------------------------------------------------------ > > Key: WFLY-7137 > URL: https://issues.jboss.org/browse/WFLY-7137 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > > There is attribute {{required}} which can be set on key-store, that should disable check "does keystore file exists?" > {code} > "required" => { > "type" => BOOLEAN, > "description" => "Is the file required to exist at the time the KeyStore service starts?", > "attribute-group" => "file", > "expressions-allowed" => true, > "nillable" => true, > "default" => false, > "requires" => ["path"], > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > However, when I try to use it, there is no difference if {{required}} attribute is set to true or false. > {code} > [standalone@localhost:9990 /] /subsystem=elytron/key-store=server:add(type="jks", path="/path/non-existing", required=false) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.server" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.server: WFLYELY00004: Unable to start the service. > Caused by: java.io.FileNotFoundException: /path/non-existing (No such file or directory)"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.server"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > [standalone@localhost:9990 /] /subsystem=elytron/key-store=server:add(type="jks", path="/path/non-existing", required=true) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.server" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.server: WFLYELY00004: Unable to start the service. > Caused by: java.io.FileNotFoundException: /path/non-existing (No such file or directory)"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.server"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > I have already seen people generating keystores in their app, so I think this option would be useful for them. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1298) MemoryUtil should not fail on Google App Engine with NoClassDefFoundError

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1298: ----------------------------------- Summary: MemoryUtil should not fail on Google App Engine with NoClassDefFoundError Key: DROOLS-1298 URL: https://issues.jboss.org/browse/DROOLS-1298 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 6.4.0.Final, 6.5.0.CR1, 7.0.0.Beta1 Reporter: Geoffrey De Smet Assignee: Mario Fusco Fix For: 7.0.0.Beta2 MemoryUtil throws this exception on Google App Engine: {code} java.lang.NoClassDefFoundError: Could not initialize class com.google.apphosting.runtime.security.shared.stub.java.lang.management.ManagementFactory at org.drools.core.util.MemoryUtil.<clinit>(MemoryUtil.java:33) {code} because the PermGen check goes the wrong way on GAE. In the MemoryUtil code on line 33, we need something like: {code} if (... || isGAE()) { ... } public boolean isGAE() { String p = System.getProperty("com.google.appengine.runtime.environment"); return p != null && !p.equals(""); } {code} On GAE, p is "Development". => act same like isAndroid() On GCE (= plain old OpenJDK), p is null. => act normally On plain Fedora with OpenJDK 8, p is null. => act normally -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7135) WildFly ignores META-INF/services

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-7135?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-7135: ----------------------------------- Indeed by the time the application server starts, the JDK preferences system has already cached the system root. I was thinking about trying to make this work more intelligently but Preferences is really not a very widely-used API so it'd be a lower-priority request. Nevertheless, if a user wanted to contribute the necessary fixes to jboss-modules, I'd accept that patch! > WildFly ignores META-INF/services > --------------------------------- > > Key: WFLY-7135 > URL: https://issues.jboss.org/browse/WFLY-7135 > Project: WildFly > Issue Type: Bug > Affects Versions: 9.0.2.Final > Reporter: Kiran Mohan > Assignee: Jason Greene > Priority: Critical > > Please see the bug description in this forum post > https://developer.jboss.org/thread/272349 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7133) Automatically define resource adapter for deployed RARs

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-7133?page=com.atlassian.jira.plugin.... ] Jesper Pedersen closed WFLY-7133. --------------------------------- Resolution: Rejected > Automatically define resource adapter for deployed RARs > ------------------------------------------------------- > > Key: WFLY-7133 > URL: https://issues.jboss.org/browse/WFLY-7133 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Guillermo González de Agüero > Assignee: Jesper Pedersen > > Deploying a RAR file enables the resource adapter for the server, but in order to configure it, you must manually add it to the Resource Adapters subsystem. This is error prone (you can put in invalid "archive name" for the resource adapter and it doesn't complaint) and little user friendly. > From a user perspective and from what can be read from the documentation (https://docs.jboss.org/author/display/WFLY10/Resource+adapters), it seems like the resource adapter is not enabled unless you explicitly define it. > It would be very simpler if RA deployments would be detected and registered as it's done for deployed JDBC drivers. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7129) Removing XA Datasources via CLI OR DMR does not de-register it from the context without reload.

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-7129?page=com.atlassian.jira.plugin.... ] Kabir Khan reassigned WFLY-7129: -------------------------------- Fix Version/s: 11.0.0.Alpha1 Assignee: shailendra singh (was: Brian Stansberry) Resolution: Done > Removing XA Datasources via CLI OR DMR does not de-register it from the context without reload. > ----------------------------------------------------------------------------------------------- > > Key: WFLY-7129 > URL: https://issues.jboss.org/browse/WFLY-7129 > Project: WildFly > Issue Type: Bug > Components: Domain Management, JCA > Affects Versions: 10.1.0.Final > Reporter: shailendra singh > Assignee: shailendra singh > Priority: Minor > Fix For: 11.0.0.Alpha1 > > > Below is the result of add .. remove ..add operation of XADatasource . > 1. Add - OK > {code:java} > [domain@localhost:9990 /] ./profile=default/subsystem=datasources/xa-data-source=TestXADataSource:add(jndi-name=java\:jboss\/datasources\/oracleXaDatasource,driver-name=oracle-driver.jar) > { > "outcome" => "success", > "result" => undefined, > "server-groups" => undefined > } > {code} > 2. Remove - OK > {code:java} > [domain@localhost:9990 /] ./profile=default/subsystem=datasources/xa-data-source=TestXADataSource:remove() > { > "outcome" => "success", > "result" => undefined, > "server-groups" => undefined > } > {code} > 3. Add - Error is thrown > {code:java} > [domain@localhost:9990 /] ./profile=default/subsystem=datasources/xa-data-source=TestXADataSource:add(jndi-name=java\:jboss\/datasources\/oracleXaDatasource,driver-name=oracle-driver.jar) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.data-source.TestXADataSource' is already registered in context 'profile=default'."}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2034) SASLTest-functional and SASL_SimpleAuthorizingCallbackTest-functional fails on IBM jdk 1.8

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/JGRP-2034?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on JGRP-2034: --------------------------------------- I'll look into it some time next week. > SASLTest-functional and SASL_SimpleAuthorizingCallbackTest-functional fails on IBM jdk 1.8 > ------------------------------------------------------------------------------------------ > > Key: JGRP-2034 > URL: https://issues.jboss.org/browse/JGRP-2034 > Project: JGroups > Issue Type: Bug > Reporter: Ivan Straka > Assignee: Tristan Tarrant > Fix For: 3.6.12 > > > We see these two tests failing on IBM jdk 1.8 > org.jgroups.protocols.SASLTest-functional > org.jgroups.protocols.SASL_SimpleAuthorizingCallbackTest-functional > This issue may be related to https://issues.jboss.org/browse/JGRP-1993 somehow. > There is standard output of tests. > {code} > ------------- testSASLDigestMD5 ----------- > ------------------------------------------------------------------- > GMS: address=A, cluster=SaslTest > ------------------------------------------------------------------- > 521823 [TRACE] GMS: A: no members discovered after 3000 ms: creating cluster as first member > 521823 [DEBUG] GMS: A: installing view [A|0] (1) [A] > 521823 [DEBUG] GMS: A: created cluster (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl > ------------------------------------------------------------------- > GMS: address=B, cluster=SaslTest > ------------------------------------------------------------------- > 521825 [TRACE] GMS: B: discovery took 0 ms, members: 1 rsps (1 coords) [done] > 521826 [DEBUG] GMS: B: sending JOIN(B) to A > 521826 [TRACE] SASL: B: received CHALLENGE from A > 521827 [WARN] SASL: B: failed to validate CHALLENGE from A, token > javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506] > at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506] > at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?] > at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?] > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?] > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?] > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?] > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?] > at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?] > at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?] > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal] > at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal] > Caused by: java.io.IOException: Invalid realm A > at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?] > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506] > ... 16 more > 524826 [WARN] GMS: B: JOIN(B) sent to A timed out (after 3000 ms), on try 1 > 524827 [TRACE] GMS: B: discovery took 1 ms, members: 1 rsps (1 coords) [done] > 524827 [DEBUG] GMS: B: sending JOIN(B) to A > 524828 [TRACE] SASL: B: received CHALLENGE from A > 524828 [WARN] SASL: B: failed to validate CHALLENGE from A, token > javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506] > at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506] > at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?] > at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?] > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?] > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?] > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?] > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?] > at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?] > at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?] > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal] > at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal] > Caused by: java.io.IOException: Invalid realm A > at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?] > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506] > ... 16 more > 526826 [WARN] SASL: failed to validate SaslHeader from B, header: payload=[B@ad737f58 > ------------- testSASLDigestMD5Failure ----------- > ------------------------------------------------------------------- > GMS: address=A, cluster=SaslTest > ------------------------------------------------------------------- > 529863 [TRACE] GMS: A: no members discovered after 3000 ms: creating cluster as first member > 529864 [DEBUG] GMS: A: installing view [A|0] (1) [A] > 529864 [DEBUG] GMS: A: created cluster (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl > ------------------------------------------------------------------- > GMS: address=B, cluster=SaslTest > ------------------------------------------------------------------- > 529866 [TRACE] GMS: B: discovery took 1 ms, members: 1 rsps (1 coords) [done] > 529866 [DEBUG] GMS: B: sending JOIN(B) to A > 529867 [TRACE] SASL: B: received CHALLENGE from A > 529867 [WARN] SASL: B: failed to validate CHALLENGE from A, token > javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506] > at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506] > at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?] > at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?] > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?] > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?] > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?] > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?] > at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?] > at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?] > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal] > at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal] > Caused by: java.io.IOException: Invalid realm A > at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?] > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506] > ... 16 more > 532867 [WARN] GMS: B: JOIN(B) sent to A timed out (after 3000 ms), on try 1 > 532867 [TRACE] GMS: B: discovery took 0 ms, members: 1 rsps (1 coords) [done] > 532867 [DEBUG] GMS: B: sending JOIN(B) to A > 532868 [TRACE] SASL: B: received CHALLENGE from A > 532869 [WARN] SASL: B: failed to validate CHALLENGE from A, token > javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506] > at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506] > at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?] > at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?] > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?] > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?] > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?] > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?] > at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?] > at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?] > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal] > at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal] > Caused by: java.io.IOException: Invalid realm A > at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?] > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506] > ... 16 more > 534867 [WARN] SASL: failed to validate SaslHeader from B, header: payload=[B@6f6c2511 > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-301) Configuration of individual contexts for http management interface.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-301?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFCORE-301: ----------------------------------------- [~brian.stansberry] Status probably was nice to have but not enough time for us to address it ;-) As we have the other issue with plenty of traffic now this one can probably be closed as a duplicate. Also this issue was very focused on configuration of the HTTP management interface, now that we have subsystem support in the host controller as discussed on other threads a better solution may be for a custom subsystem to register it's own handler on the HTTP management interface - that way we don't need generic configuration for this resource. > Configuration of individual contexts for http management interface. > ------------------------------------------------------------------- > > Key: WFCORE-301 > URL: https://issues.jboss.org/browse/WFCORE-301 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Alpha9 > > > At the moment all management requests are handled over the '/management' context, we also have a '/console' context to serve up the files for the admin console. > The '/management' context is secured using standard HTTP mechanisms, this decision was taken so that clients could be written in different languages and all they would need to know is how to use standard authentication mechanisms. Due to problems where web browsers could run malicious scripts cross origin resource sharing is completely disabled for this context. > We need to start to open up the handling of cross origin requests for a couple of reasons: - > - Enabling Keycloak SSO support. > - Alternative console distribution options > The '/management' context is going to be retained as-is for legacy clients, possibly even switched off by default. > A new context can then be added using non-browser based authentication, this could be SSO Keycloak or could be a form of Digest authentication where the response is handled by the console and not the web browser - either way as the browser is bypassed it is no longer at risk of sending malicious cross origin requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2030) GMS: view_ack_collection_timeout delay when last 2 members leave concurrently

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2030?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2030: --------------------------- Fix Version/s: 3.6.12 (was: 4.0) (was: 3.6.11) Moving to 3.6.12 > GMS: view_ack_collection_timeout delay when last 2 members leave concurrently > ----------------------------------------------------------------------------- > > Key: JGRP-2030 > URL: https://issues.jboss.org/browse/JGRP-2030 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.8 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.12 > > > When the coordinator ({{NodeE}}) leaves, it tries to install a new view on behalf of the new coordinator ({{NodeG}}, the last member). > {noformat} > 21:33:26,844 TRACE (ViewHandler,InitialClusterSizeTest-NodeE-42422:) [GMS] InitialClusterSizeTest-NodeE-42422: mcasting view [InitialClusterSizeTest-NodeG-30521|3] (1) [InitialClusterSizeTest-NodeG-30521] (1 mbrs) > 21:33:26,844 TRACE (ViewHandler,InitialClusterSizeTest-NodeE-42422:) [TCP_NIO2] InitialClusterSizeTest-NodeE-42422: sending msg to null, src=InitialClusterSizeTest-NodeE-42422, headers are GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster_name=ISPN] > {noformat} > The message is actually sent later by the bundler, but {{NodeG}} is also sending its {{LEAVE_REQ}} message at the same time. Both nodes try to create a connection to each other, and only {{NodeG}} succeeds: > {noformat} > 21:33:26,844 TRACE (ForkThread-2,InitialClusterSizeTest:) [TCP_NIO2] InitialClusterSizeTest-NodeG-30521: sending msg to InitialClusterSizeTest-NodeE-42422, src=InitialClusterSizeTest-NodeG-30521, headers are GMS: GmsHeader[LEAVE_REQ]: mbr=InitialClusterSizeTest-NodeG-30521, UNICAST3: DATA, seqno=1, conn_id=1, first, TP: [cluster_name=ISPN] > 21:33:26,865 TRACE (Timer-2,InitialClusterSizeTest-NodeG-30521:) [TCP_NIO2] InitialClusterSizeTest-NodeG-30521: sending 1 msgs (83 bytes (0.27% of max_bundle_size) to 1 dests(s): [ISPN:InitialClusterSizeTest-NodeE-42422] > 21:33:26,865 TRACE (Timer-2,InitialClusterSizeTest-NodeE-42422:) [TCP_NIO2] InitialClusterSizeTest-NodeE-42422: sending 1 msgs (91 bytes (0.29% of max_bundle_size) to 1 dests(s): [ISPN] > 21:33:26,865 TRACE (Timer-2,InitialClusterSizeTest-NodeG-30521:) [TCP_NIO2] dest=127.0.0.1:7900 (86 bytes) > 21:33:26,865 TRACE (Timer-2,InitialClusterSizeTest-NodeE-42422:) [TCP_NIO2] dest=127.0.0.1:7920 (94 bytes) > 21:33:26,865 TRACE (Timer-2,InitialClusterSizeTest-NodeE-42422:) [TCP_NIO2] 127.0.0.1:7900: connecting to 127.0.0.1:7920 > 21:33:26,865 TRACE (Timer-2,InitialClusterSizeTest-NodeG-30521:) [TCP_NIO2] 127.0.0.1:7920: connecting to 127.0.0.1:7900 > 21:33:26,866 TRACE (NioConnection.Reader [null],InitialClusterSizeTest-NodeG-30521:) [TCP_NIO2] 127.0.0.1:7920: rejected connection from 127.0.0.1:7900 (connection existed and my address won as it's higher) > 21:33:26,867 TRACE (OOB-1,InitialClusterSizeTest-NodeE-42422:) [TCP_NIO2] InitialClusterSizeTest-NodeE-42422: received [dst: InitialClusterSizeTest-NodeE-42422, src: InitialClusterSizeTest-NodeG-30521 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[LEAVE_REQ]: mbr=InitialClusterSizeTest-NodeG-30521, UNICAST3: DATA, seqno=1, conn_id=1, first, TP: [cluster_name=ISPN] > {noformat} > I'm guessing {{NodeE}} would need a {{STABLE}} round in order to retransmit the {{VIEW}} message, but I'm not sure if the stable round would work, since it already (partially?) installed the new view with {{NodeG}} as the only member. However, I think it should be possible for {{NodeE}} to remove {{NodeG}} from it's {{AckCollector}} once it receives its {{LEAVE_REQ}}, and stop blocking. > This is a minor annoyance a few the Infinispan tests - most of them shut down the nodes serially, so they don't see this delay. > The question is whether the concurrent connection setup can have an impact for other messages as well - e.g. during startup, when there aren't a lot of messages being sent around to trigger retransmission. Could the node that failed to open its connection retry immediately on the connection opened by the other node? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2034) SASLTest-functional and SASL_SimpleAuthorizingCallbackTest-functional fails on IBM jdk 1.8

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2034?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2034: --------------------------- Fix Version/s: 3.6.12 (was: 3.6.11) Moving to 3.6.12 > SASLTest-functional and SASL_SimpleAuthorizingCallbackTest-functional fails on IBM jdk 1.8 > ------------------------------------------------------------------------------------------ > > Key: JGRP-2034 > URL: https://issues.jboss.org/browse/JGRP-2034 > Project: JGroups > Issue Type: Bug > Reporter: Ivan Straka > Assignee: Tristan Tarrant > Fix For: 3.6.12 > > > We see these two tests failing on IBM jdk 1.8 > org.jgroups.protocols.SASLTest-functional > org.jgroups.protocols.SASL_SimpleAuthorizingCallbackTest-functional > This issue may be related to https://issues.jboss.org/browse/JGRP-1993 somehow. > There is standard output of tests. > {code} > ------------- testSASLDigestMD5 ----------- > ------------------------------------------------------------------- > GMS: address=A, cluster=SaslTest > ------------------------------------------------------------------- > 521823 [TRACE] GMS: A: no members discovered after 3000 ms: creating cluster as first member > 521823 [DEBUG] GMS: A: installing view [A|0] (1) [A] > 521823 [DEBUG] GMS: A: created cluster (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl > ------------------------------------------------------------------- > GMS: address=B, cluster=SaslTest > ------------------------------------------------------------------- > 521825 [TRACE] GMS: B: discovery took 0 ms, members: 1 rsps (1 coords) [done] > 521826 [DEBUG] GMS: B: sending JOIN(B) to A > 521826 [TRACE] SASL: B: received CHALLENGE from A > 521827 [WARN] SASL: B: failed to validate CHALLENGE from A, token > javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506] > at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506] > at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?] > at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?] > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?] > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?] > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?] > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?] > at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?] > at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?] > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal] > at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal] > Caused by: java.io.IOException: Invalid realm A > at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?] > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506] > ... 16 more > 524826 [WARN] GMS: B: JOIN(B) sent to A timed out (after 3000 ms), on try 1 > 524827 [TRACE] GMS: B: discovery took 1 ms, members: 1 rsps (1 coords) [done] > 524827 [DEBUG] GMS: B: sending JOIN(B) to A > 524828 [TRACE] SASL: B: received CHALLENGE from A > 524828 [WARN] SASL: B: failed to validate CHALLENGE from A, token > javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506] > at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506] > at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?] > at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?] > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?] > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?] > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?] > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?] > at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?] > at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?] > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal] > at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal] > Caused by: java.io.IOException: Invalid realm A > at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?] > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506] > ... 16 more > 526826 [WARN] SASL: failed to validate SaslHeader from B, header: payload=[B@ad737f58 > ------------- testSASLDigestMD5Failure ----------- > ------------------------------------------------------------------- > GMS: address=A, cluster=SaslTest > ------------------------------------------------------------------- > 529863 [TRACE] GMS: A: no members discovered after 3000 ms: creating cluster as first member > 529864 [DEBUG] GMS: A: installing view [A|0] (1) [A] > 529864 [DEBUG] GMS: A: created cluster (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl > ------------------------------------------------------------------- > GMS: address=B, cluster=SaslTest > ------------------------------------------------------------------- > 529866 [TRACE] GMS: B: discovery took 1 ms, members: 1 rsps (1 coords) [done] > 529866 [DEBUG] GMS: B: sending JOIN(B) to A > 529867 [TRACE] SASL: B: received CHALLENGE from A > 529867 [WARN] SASL: B: failed to validate CHALLENGE from A, token > javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506] > at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506] > at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?] > at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?] > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?] > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?] > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?] > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?] > at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?] > at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?] > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal] > at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal] > Caused by: java.io.IOException: Invalid realm A > at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?] > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506] > ... 16 more > 532867 [WARN] GMS: B: JOIN(B) sent to A timed out (after 3000 ms), on try 1 > 532867 [TRACE] GMS: B: discovery took 0 ms, members: 1 rsps (1 coords) [done] > 532867 [DEBUG] GMS: B: sending JOIN(B) to A > 532868 [TRACE] SASL: B: received CHALLENGE from A > 532869 [WARN] SASL: B: failed to validate CHALLENGE from A, token > javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506] > at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506] > at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?] > at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?] > at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?] > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?] > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?] > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?] > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?] > at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?] > at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?] > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal] > at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal] > Caused by: java.io.IOException: Invalid realm A > at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?] > at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506] > ... 16 more > 534867 [WARN] SASL: failed to validate SaslHeader from B, header: payload=[B@6f6c2511 > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2640) Unable to add cached-connection-manager after removing it once

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-2640?page=com.atlassian.jira.plugin.... ] Ingo Weiss reassigned WFLY-2640: -------------------------------- Assignee: Ingo Weiss > Unable to add cached-connection-manager after removing it once > -------------------------------------------------------------- > > Key: WFLY-2640 > URL: https://issues.jboss.org/browse/WFLY-2640 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Masafumi Miura > Assignee: Ingo Weiss > > {{<cached-connection-manager>}} is enabled in jca subsystem by default: > {code:xml} > <subsystem xmlns="urn:jboss:domain:jca:1.1"> > ... > <cached-connection-manager /> > </subsystem> > {code} > However, it is unable to re-enable {{<cached-connection-manager>}} once it is disabled. CLI command fails to add it due to duplicate resource. > {code} > [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:remove > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone@localhost:9990 /] :reload > { > "outcome" => "success", > "result" => undefined > } > [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:add > { > "outcome" => "failed", > "failure-description" => "JBAS014803: Duplicate resource [ > (\"subsystem\" => \"jca\"), > (\"cached-connection-manager\" => \"cached-connection-manager\") > ]", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7127) CMR collection gets corrupted in 2LC on certain concurrent access

by Jari Juslin (JIRA)

[ https://issues.jboss.org/browse/WFLY-7127?page=com.atlassian.jira.plugin.... ] Jari Juslin updated WFLY-7127: ------------------------------ Description: With certain parallel read and write access to same CMR collection it gets corrupted in Hibernate second level cache. After the event of corruption, any read access to that CMR collection ends up in Exception until the cache is cleared manually or Wildfly restarted. Steps to reproduce: 1) Make sure the CMR collection is not in cache. 2) Start a read-only transaction accessing the said collection. 3) In a separate transaction delete an element from that collection. 4) End the read-only transaction. 5) Read the resulting collection. It now throws EntityNotFoundException. My understanding is that what happens is that the read-only transaction is read-only from the perspective of the database, so the system handles it as such. However, because for the 2LC it is actually a write transaction, when the transaction ends, the contents of the CMR collection visible to this transaction get committed to 2LC. If the write transaction ends before the read-only transaction, the old version of the collection stays in the 2LC. Now, as the CMR collection contains an element already deleted from the DB, any attempt to manifest the collection results in EntityNotFoundException as the child element no longer exists in the DB. For sake of repeatibility the test case here manually spawns threads to cause the effect. In real use, of course, this happens randomly when two different threads spawned by Wildfly happen to interleave with exactly a right kind of pattern. The tar ball contains everything needed to reproduce the bug, including SQL dump of the MySQL/InnoDB database. The easiest way to run the testcase is to take Wildfly 10.1.0.Final and use the provided standalone.xml, add MySQL driver, import the DB with the provided SQL and then deploy the included packaged testcase.ear. was: With certain parallel read and write access to same CMR collection it gets corrupted in Hibernate second level cache. After the event of corruption, any read access to that CMR collection ends up in Exception until the cache is cleared manually or Wildfly restarted. Steps to reproduce: 1) Make sure the CMR collection is not in cache. 2) Start a read-only transaction accessing the said collection. 3) In a separate transaction delete an element from that collection. 4) End the read-only transaction. 5) Read the resulting collection. It now throws EntityNotFoundException. My understanding is that what happens is that the read-only transaction is read-only from the perspective of the database, so the system handles it as such. However, because for the 2LC it is actually a write transaction, when the transaction ends, the contents of the CMR collection visible to this transaction get committed to 2LC. If the write transaction ends before the read-only transaction, the old version of the collection stays in the 2LC. Now, as the CMR collection contains an element already deleted from the DB, any attempt to manifest the collection results in EntityNotFoundException as the child element no longer exists in the DB. For sake of repeatibility the test case here manually spawns threads to cause the effect. In real use, of course, this happens randomly when two different threads spawned by Wildfly happen to interleave with exactly a right kind of pattern. > CMR collection gets corrupted in 2LC on certain concurrent access > ----------------------------------------------------------------- > > Key: WFLY-7127 > URL: https://issues.jboss.org/browse/WFLY-7127 > Project: WildFly > Issue Type: Bug > Components: EJB, JPA / Hibernate, Transactions > Affects Versions: 10.1.0.Final > Environment: Ubuntu Linux 15.10. Java 1.8.0_66 > Reporter: Jari Juslin > Assignee: Scott Marlow > Attachments: infinispan_cmr_corruption_repro.tar.gz, standalone.xml > > > With certain parallel read and write access to same CMR collection it gets corrupted in Hibernate second level cache. After the event of corruption, any read access to that CMR collection ends up in Exception until the cache is cleared manually or Wildfly restarted. > Steps to reproduce: > 1) Make sure the CMR collection is not in cache. > 2) Start a read-only transaction accessing the said collection. > 3) In a separate transaction delete an element from that collection. > 4) End the read-only transaction. > 5) Read the resulting collection. It now throws EntityNotFoundException. > My understanding is that what happens is that the read-only transaction is read-only from the perspective of the database, so the system handles it as such. However, because for the 2LC it is actually a write transaction, when the transaction ends, the contents of the CMR collection visible to this transaction get committed to 2LC. If the write transaction ends before the read-only transaction, the old version of the collection stays in the 2LC. > Now, as the CMR collection contains an element already deleted from the DB, any attempt to manifest the collection results in EntityNotFoundException as the child element no longer exists in the DB. > For sake of repeatibility the test case here manually spawns threads to cause the effect. In real use, of course, this happens randomly when two different threads spawned by Wildfly happen to interleave with exactly a right kind of pattern. > The tar ball contains everything needed to reproduce the bug, including SQL dump of the MySQL/InnoDB database. The easiest way to run the testcase is to take Wildfly 10.1.0.Final and use the provided standalone.xml, add MySQL driver, import the DB with the provided SQL and then deploy the included packaged testcase.ear. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7137) Attribute "required" on key-store makes no difference of behaviour

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7137?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-6060 to WFLY-7137: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7137 (was: JBEAP-6060) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR4) > Attribute "required" on key-store makes no difference of behaviour > ------------------------------------------------------------------ > > Key: WFLY-7137 > URL: https://issues.jboss.org/browse/WFLY-7137 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > There is attribute {{required}} which can be set on key-store, that should disable check "does keystore file exists?" > {code} > "required" => { > "type" => BOOLEAN, > "description" => "Is the file required to exist at the time the KeyStore service starts?", > "attribute-group" => "file", > "expressions-allowed" => true, > "nillable" => true, > "default" => false, > "requires" => ["path"], > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > However, when I try to use it, there is no difference if {{required}} attribute is set to true or false. > {code} > [standalone@localhost:9990 /] /subsystem=elytron/key-store=server:add(type="jks", path="/path/non-existing", required=false) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.server" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.server: WFLYELY00004: Unable to start the service. > Caused by: java.io.FileNotFoundException: /path/non-existing (No such file or directory)"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.server"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > [standalone@localhost:9990 /] /subsystem=elytron/key-store=server:add(type="jks", path="/path/non-existing", required=true) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.server" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.server: WFLYELY00004: Unable to start the service. > Caused by: java.io.FileNotFoundException: /path/non-existing (No such file or directory)"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.server"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > I have already seen people generating keystores in their app, so I think this option would be useful for them. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1297) MemoryUtil should not fail on Google App Engine with NoClassDefFoundError

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created DROOLS-1297: ---------------------------------------- Summary: MemoryUtil should not fail on Google App Engine with NoClassDefFoundError Key: DROOLS-1297 URL: https://issues.jboss.org/browse/DROOLS-1297 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 7.0.0.Beta1, 6.5.0.CR1, 6.4.0.Final Reporter: Geoffrey De Smet Assignee: Mario Fusco MemoryUtil throws this exception on Google App Engine: {code} java.lang.NoClassDefFoundError: Could not initialize class com.google.apphosting.runtime.security.shared.stub.java.lang.management.ManagementFactory at org.drools.core.util.MemoryUtil.<clinit>(MemoryUtil.java:33) {code} because the PermGen check goes the wrong way on GAE. In the MemoryUtil code on line 33, we need something like: {code} if (... || isGAE()) { ... } public boolean isGAE() { String p = System.getProperty("com.google.appengine.runtime.environment"); return p != null && !p.equals(""); } {code} On GAE, p is "Development". => act same like isAndroid() On GCE (= plain old OpenJDK), p is null. => act normally On plain Fedora with OpenJDK 8, p is null. => act normally -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-405) Add a KeyStore implementation backed by LDAP

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-405?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-405: --------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/480, https://github.com/wildfly-security/elytron-subsystem/pull/210 (was: https://github.com/wildfly-security/wildfly-elytron/pull/480) > Add a KeyStore implementation backed by LDAP > -------------------------------------------- > > Key: ELY-405 > URL: https://issues.jboss.org/browse/ELY-405 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Fix For: 2.0.0.Alpha1 > > > It is possible for private keys, public keys and certificates to all be stored in LDAP - this task is to create a Java KeyStore implementation that can work with this. > LDAP most likely will take a reasonable amount of configuration so it may not be possible to be purely provider based and instead this type of KeyStore may need to be manually configured and instantiated. > Properties could be passed in using the InputStream to initialise the KeyStore but that doesn't help where we may want to pass in factories for connecting to a remote LDAP server. > In addition to the usual keys and certificates the entry types as used for CredentialStore should also be considered. > The implementation should also support manipulation of the entries - in this case this may mean immediate updates to the directory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-433) Support verification of a users certificate against an LDAP Server

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-433?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-433: --------------------------- Description: LDAP realm should be able to authenticate user using user certificate. This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP. was: This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP. > Support verification of a users certificate against an LDAP Server > ------------------------------------------------------------------ > > Key: ELY-433 > URL: https://issues.jboss.org/browse/ELY-433 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms, SSL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta10 > > > LDAP realm should be able to authenticate user using user certificate. > This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-433) Support verification of a users certificate against an LDAP Server

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-433?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-433: ------------------------------ Assignee: Jan Kalina (was: Darran Lofthouse) > Support verification of a users certificate against an LDAP Server > ------------------------------------------------------------------ > > Key: ELY-433 > URL: https://issues.jboss.org/browse/ELY-433 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms, SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Fix For: 1.1.0.Beta10 > > > LDAP realm should be able to authenticate user using user certificate. > This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7024) show-resources operation of jaxrs subsystem must provide more information about end-point

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-7024?page=com.atlassian.jira.plugin.... ] Lin Gao updated WFLY-7024: -------------------------- Description: show-resources operation of jaxrs subsystem must provide more informations about end-point. Information about parameters and returned value should be provided. Example: {code:java} @GET @Path("entity/get") @Produces(MediaType.APPLICATION_JSON) public Person post3(@QueryParam("boolean") @DefaultValue("false") boolean v) { Person per = new Person(); per.setName("per"); per.setFamily("son"); return per; } {code} Actual return value of {{/deployment=jaxrs-eap.war/subsystem=jaxrs:show-resources}}: {noformat} { "resource-class" => "org.resteasy.simple.deployment.AdvancedService", "resource-path" => "/sample/entity/get", "resource-methods" => ["GET /jaxrs-eap/a/sample/entity/get - org.resteasy.simple.deployment.AdvancedService.post3(...)"] }, {noformat} There should be information about "boolean v" parameter and about returned type (Person). --- -jax-rs subsystem should be able to collect some statistics about invocation of end-points (count of invocations, execution time, etc.)- -Some statistics could be be activated and printed, only if end-point is also EJB bean, example:- -/subsystem=ejb3:write-attribute(name=enable-statistics,value=true)- -/deployment=cdiexp-1.0-SNAPSHOT.jar/subsystem=ejb3/stateless-session-bean=Servicer:read-resource(include-runtime=true)- was: show-resources operation of jaxrs subsystem must provide more informations about end-point. Information about parameters and returned value should be provided. Example: {code:java} @GET @Path("entity/get") @Produces(MediaType.APPLICATION_JSON) public Person post3(@QueryParam("boolean") @DefaultValue("false") boolean v) { Person per = new Person(); per.setName("per"); per.setFamily("son"); return per; } {code} Actual return value of {{/deployment=jaxrs-eap.war/subsystem=jaxrs:show-resources}}: {noformat} { "resource-class" => "org.resteasy.simple.deployment.AdvancedService", "resource-path" => "/sample/entity/get", "resource-methods" => ["GET /jaxrs-eap/a/sample/entity/get - org.resteasy.simple.deployment.AdvancedService.post3(...)"] }, {noformat} There should be information about "boolean v" parameter and about returned type (Person). --- jax-rs subsystem should be able to collect some statistics about invocation of end-points (count of invocations, execution time, etc.) Some statistics could be be activated and printed, only if end-point is also EJB bean, example: {noformat} /subsystem=ejb3:write-attribute(name=enable-statistics,value=true) /deployment=cdiexp-1.0-SNAPSHOT.jar/subsystem=ejb3/stateless-session-bean=Servicer:read-resource(include-runtime=true) {noformat} > show-resources operation of jaxrs subsystem must provide more information about end-point > ----------------------------------------------------------------------------------------- > > Key: WFLY-7024 > URL: https://issues.jboss.org/browse/WFLY-7024 > Project: WildFly > Issue Type: Feature Request > Components: REST > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Critical > Original Estimate: 2 days > Remaining Estimate: 2 days > > show-resources operation of jaxrs subsystem must provide more informations about end-point. Information about parameters and returned value should be provided. > Example: > {code:java} > @GET > @Path("entity/get") > @Produces(MediaType.APPLICATION_JSON) > public Person post3(@QueryParam("boolean") @DefaultValue("false") boolean v) { > Person per = new Person(); > per.setName("per"); > per.setFamily("son"); > return per; > } > {code} > Actual return value of {{/deployment=jaxrs-eap.war/subsystem=jaxrs:show-resources}}: > {noformat} > { > "resource-class" => "org.resteasy.simple.deployment.AdvancedService", > "resource-path" => "/sample/entity/get", > "resource-methods" => ["GET /jaxrs-eap/a/sample/entity/get - org.resteasy.simple.deployment.AdvancedService.post3(...)"] > }, > {noformat} > There should be information about "boolean v" parameter and about returned type (Person). > --- > -jax-rs subsystem should be able to collect some statistics about invocation of end-points (count of invocations, execution time, etc.)- > -Some statistics could be be activated and printed, only if end-point is also EJB bean, example:- > -/subsystem=ejb3:write-attribute(name=enable-statistics,value=true)- > -/deployment=cdiexp-1.0-SNAPSHOT.jar/subsystem=ejb3/stateless-session-bean=Servicer:read-resource(include-runtime=true)- -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7024) show-resources operation of jaxrs subsystem must provide more information about end-point

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-7024?page=com.atlassian.jira.plugin.... ] Lin Gao updated WFLY-7024: -------------------------- Summary: show-resources operation of jaxrs subsystem must provide more information about end-point (was: show-resources operation of jaxrs subsystem must provide more informations and statistics about end-point) > show-resources operation of jaxrs subsystem must provide more information about end-point > ----------------------------------------------------------------------------------------- > > Key: WFLY-7024 > URL: https://issues.jboss.org/browse/WFLY-7024 > Project: WildFly > Issue Type: Feature Request > Components: REST > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Critical > Original Estimate: 2 days > Remaining Estimate: 2 days > > show-resources operation of jaxrs subsystem must provide more informations about end-point. Information about parameters and returned value should be provided. > Example: > {code:java} > @GET > @Path("entity/get") > @Produces(MediaType.APPLICATION_JSON) > public Person post3(@QueryParam("boolean") @DefaultValue("false") boolean v) { > Person per = new Person(); > per.setName("per"); > per.setFamily("son"); > return per; > } > {code} > Actual return value of {{/deployment=jaxrs-eap.war/subsystem=jaxrs:show-resources}}: > {noformat} > { > "resource-class" => "org.resteasy.simple.deployment.AdvancedService", > "resource-path" => "/sample/entity/get", > "resource-methods" => ["GET /jaxrs-eap/a/sample/entity/get - org.resteasy.simple.deployment.AdvancedService.post3(...)"] > }, > {noformat} > There should be information about "boolean v" parameter and about returned type (Person). > --- > jax-rs subsystem should be able to collect some statistics about invocation of end-points (count of invocations, execution time, etc.) > Some statistics could be be activated and printed, only if end-point is also EJB bean, example: > {noformat} > /subsystem=ejb3:write-attribute(name=enable-statistics,value=true) > /deployment=cdiexp-1.0-SNAPSHOT.jar/subsystem=ejb3/stateless-session-bean=Servicer:read-resource(include-runtime=true) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1807) CLI config (jboss-cli.xml) is trimming vault-options when it should pass them on as is

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1807?page=com.atlassian.jira.plugi... ] Chao Wang moved JBEAP-6057 to WFCORE-1807: ------------------------------------------ Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1807 (was: JBEAP-6057) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI (was: CLI) Affects Version/s: 3.0.0.Alpha8 (was: 7.0.1.GA) > CLI config (jboss-cli.xml) is trimming vault-options when it should pass them on as is > -------------------------------------------------------------------------------------- > > Key: WFCORE-1807 > URL: https://issues.jboss.org/browse/WFCORE-1807 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha8 > Reporter: Chao Wang > Assignee: Chao Wang > > Vault option is calling trim which is causing issues with custom vault implementation. > The implementation of the vault config parser in the normal EAP config (i.e. in standalone.xml) does not do this. > To provide more details why this is an issue, the custom impl is prepending a string to an executable command. By trimming the command is being mangled: > <vault code="com.example.CommandVault" module="com.example"> > <vault-option name="prependToValue" value="perform_encryption.sh -value "/> > <vault-option name="allowEmptyPassword" value="false"/> > </vault> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Viacheslav Astapkovich (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich updated WFLY-7075: ----------------------------------------- Attachment: Screenshot_10.png > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Viacheslav Astapkovich (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich edited comment on WFLY-7075 at 9/19/16 12:00 AM: ------------------------------------------------------------------------ Sorry for long delay. I have tried to apply suggested solution for our project. And we have next trouble: We have a lot of EntityManager in our beans with default @PersistenceContext declaration (Transactional, Synchronized) We have only one EntityManager with non-default configuration (Extended, Unsynchronized) If we want to choose behavior - we must change all default EntityManager, not our customized EntityManager. Very laborious way for a big project. If we set properties in Persistence.xml for my persistence unit - no changes in properties, because i get list of EntityManager Annotation property only. I can see Persistence.xml property from EntityManagerFactory: !Screenshot_10.png|thumbnail! and !Screenshot_7.png|thumbnail! But i have only target property from annotation in other places: !Screenshot_8.png|thumbnail! and !Screenshot_9.png|thumbnail! was (Author: veselroger): Sorry for long delay. I have tried to apply suggested solution for our project. And we have next trouble: We have a lot of EntityManager in our beans with default @PersistenceContext declaration (Transactional, Synchronized) We have only one EntityManager with non-default configuration (Extended, Unsynchronized) If we want to choose behavior - we must change all default EntityManager, not our customized EntityManager. Very laborious way for a big project. If we set properties in Persistence.xml for my persistence unit - no changes in properties, because i get list of EntityManager Annotation property only. I can see Persistence.xml property from EntityManagerFactory: !Screenshot_7.png|thumbnail! But i have only target property from annotation in other places: !Screenshot_8.png|thumbnail! and !Screenshot_9.png|thumbnail! > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Viacheslav Astapkovich (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich edited comment on WFLY-7075 at 9/18/16 11:56 PM: ------------------------------------------------------------------------ Sorry for long delay. I have tried to apply suggested solution for our project. And we have next trouble: We have a lot of EntityManager in our beans with default @PersistenceContext declaration (Transactional, Synchronized) We have only one EntityManager with non-default configuration (Extended, Unsynchronized) If we want to choose behavior - we must change all default EntityManager, not our customized EntityManager. Very laborious way for a big project. If we set properties in Persistence.xml for my persistence unit - no changes in properties, because i get list of EntityManager Annotation property only. I can see Persistence.xml property from EntityManagerFactory: !Screenshot_7.png|thumbnail! But i have only target property from annotation in other places: !Screenshot_8.png|thumbnail! and !Screenshot_9.png|thumbnail! was (Author: veselroger): Sorry for long delay. I have tried to apply suggested solution for our project. And we have next trouble: We have a lot of EntityManager in our beans with default @PersistenceContext declaration (Transactional, Synchronized) We have only one EntityManager with non-default configuration (Extended, Unsynchronized) If we want to choose behavior - we must change all default EntityManager, not our customized EntityManager. Very laborious way for a big project. If we set properties in Persistence.xml for my persistence unit - no changes in properties, because i get list of EntityManager Annotation property only. I can see this property from EntityManagerFactory: !Screenshot_7.png|thumbnail! But i have only target property from annotation: !Screenshot_8.png|thumbnail! and !Screenshot_9.png|thumbnail! > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5969) io.undertow.servlet.handlers.DefaultServlet will list incorrect directory contents

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5969?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-5969. ---------------------------------- Fix Version/s: 11.0.0.Alpha1 Resolution: Done Was another symptom of incorrect welcome file handling, the fix for WFLY-7105 has also resolved this. > io.undertow.servlet.handlers.DefaultServlet will list incorrect directory contents > ---------------------------------------------------------------------------------- > > Key: WFLY-5969 > URL: https://issues.jboss.org/browse/WFLY-5969 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR5 > Environment: MacOS with Java 8u65 > Reporter: Matthew Casperson > Assignee: Stuart Douglas > Fix For: 11.0.0.Alpha1 > > Attachments: Screen Shot 2016-01-11 at 11.24.34 am.png, Screen Shot 2016-01-11 at 11.24.41 am.png > > > The Untertow DefaultServlet exhibits some odd behaviour when it has been mapped to a subdirectory. > To see this behaviour, build the WAR file from the sample project at https://github.com/mcasperson/wildfly-default-servlet-bug. Deploy to WildFly 10 CR5, and open the link http://localhost:8080/wildfly-default-servlet-bug/static (note no slash on the end of the URL). You'll see the expected directory listing. > !Screen Shot 2016-01-11 at 11.24.41 am.png|thumbnail! > Now open http://localhost:8080/wildfly-default-servlet-bug/static/ (note the slash on the end). You'll actually now be browsing the root directory of the application. > !Screen Shot 2016-01-11 at 11.24.34 am.png|thumbnail! > Now open http://localhost:8080/wildfly-default-servlet-bug/static/static/data.xml (note the double static in the URL). You'll be able to open the XML file. This is not what I would have expected. > Now open http://localhost:8080/wildfly-default-servlet-bug/static/data.xml. You'll get a 404. I would have expected to be able to open the file using this URL. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Viacheslav Astapkovich (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich edited comment on WFLY-7075 at 9/18/16 11:46 PM: ------------------------------------------------------------------------ Sorry for long delay. I have tried to apply suggested solution for our project. And we have next trouble: We have a lot of EntityManager in our beans with default @PersistenceContext declaration (Transactional, Synchronized) We have only one EntityManager with non-default configuration (Extended, Unsynchronized) If we want to choose behavior - we must change all default EntityManager, not our customized EntityManager. Very laborious way for a big project. If we set properties in Persistence.xml for my persistence unit - no changes in properties, because i get list of EntityManager Annotation property only. I can see this property from EntityManagerFactory: !Screenshot_7.png|thumbnail! But i have only target property from annotation: !Screenshot_8.png|thumbnail! and !Screenshot_9.png|thumbnail! was (Author: veselroger): Sorry for long delay. I have tried to apply suggested solution for our project. And we have next trouble: We have a lot of EntityManager in our beans with default @PersistenceContext declaration (Transactional, Synchronized) We have only one EntityManager with non-default configuration (Extended, Unsynchronized) If we want to choose behavior - we must change all default EntityManager, not our customized EntityManager. Very laborious way for a big project. If we set properties in Persistence.xml for my persistence unit - no changes in properties, because i get list of EntityManager Annotation property only. > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Viacheslav Astapkovich (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich updated WFLY-7075: ----------------------------------------- Attachment: Screenshot_7.png Screenshot_8.png Screenshot_9.png > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Viacheslav Astapkovich (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich commented on WFLY-7075: ---------------------------------------------- Sorry for long delay. I have tried to apply suggested solution for our project. And we have next trouble: We have a lot of EntityManager in our beans with default @PersistenceContext declaration (Transactional, Synchronized) We have only one EntityManager with non-default configuration (Extended, Unsynchronized) If we want to choose behavior - we must change all default EntityManager, not our customized EntityManager. Very laborious way for a big project. If we set properties in Persistence.xml for my persistence unit - no changes in properties, because i get list of EntityManager Annotation property only. > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7105) Incorrect redirection after authentization when using elytron

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7105?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-7105. ---------------------------------- Fix Version/s: 11.0.0.Alpha1 Resolution: Done > Incorrect redirection after authentization when using elytron > ------------------------------------------------------------- > > Key: WFLY-7105 > URL: https://issues.jboss.org/browse/WFLY-7105 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Radim Hatlapatka > Assignee: Stuart Douglas > Priority: Critical > Fix For: 11.0.0.Alpha1 > > Attachments: defined-security-domain.war, roles.properties, standalone-elytron-web-tests.xml, users.properties > > > Having web application which uses defined security domain, which is set up using elytron results in incorrect redirection. It is redirecting after authentication done at {{http://localhost:8080/defined-security-domain/user/}} to {{http://localhost:8080/defined-security-domain/user//user/index.jsp}} instead of to {{http://localhost:8080/defined-security-domain/user/index.jsp}}. > Note, when using only old security domain setup without elytron, it works just fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7134) Upgrade to Wildfly 10.0.0.Final: Messaging System issue

by Preeta Kuruvilla (JIRA)

[ https://issues.jboss.org/browse/WFLY-7134?page=com.atlassian.jira.plugin.... ] Preeta Kuruvilla updated WFLY-7134: ----------------------------------- Description: Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- Let me know if this is good. Also I have attached the entire standalone-full.xml with this case. <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> <server name="default"> <security enabled="false"/> <statistics enabled="true"/> <security-setting name="#"> <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> </security-setting> <address-setting name="#" redistribution-delay="1000" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> <in-vm-connector name="in-vm" server-id="0"/> <http-acceptor name="http-acceptor" http-listener="default"/> <http-acceptor name="http-acceptor-throughput" http-listener="default"> <param name="batch-delay" value="50"/> <param name="direct-deliver" value="false"/> </http-acceptor> <in-vm-acceptor name="in-vm" server-id="0"/> <jms-queue name="testQueue" entries="java:/queue/test java:jboss/exported/jms/queue/test"/> <jms-queue name="ISEEOutboundQueue" entries="java:/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> <jms-queue name="ISEEInboundQueue" entries="java:/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> <jms-queue name="BEEEAuthorizationsQueue" entries="java:/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> <jms-queue name="BEEERequisitionsQueue" entries="java:/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> <jms-queue name="BEEEInboundQueue" entries="java:/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> <jms-topic name="testTopic" entries="java:/topic/test java:jboss/exported/jms/topic/test"/> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> <connection-factory name="RemoteConnectionFactory" entries="java:/RemoteConnectionFactory java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/> <pooled-connection-factory name="activemq-ra" transaction="xa" entries="/JmsXA jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> </server> </subsystem> InitialContext is created with parameters - jmsuser, password, and BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port> BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory Issue we face is that after we upgraded to wildfly 10, the messages are not getting in the queues. This is not consistent as once in a while messages are getting processed. I have attached the below standalone-full.xml for your reference :- 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue. was: Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- Let me know if this is good. Also I have attached the entire standalone-full.xml with this case. <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> <server name="default"> <security enabled="false"/> <statistics enabled="true"/> <security-setting name="#"> <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> </security-setting> <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> <in-vm-connector name="in-vm" server-id="0"/> <http-acceptor name="http-acceptor" http-listener="default"/> <http-acceptor name="http-acceptor-throughput" http-listener="default"> <param name="batch-delay" value="50"/> <param name="direct-deliver" value="false"/> </http-acceptor> <in-vm-acceptor name="in-vm" server-id="0"/> <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> </server> </subsystem> InitialContext is created with parameters - jmsuser, password, and BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port> BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory Issue we face is that after we upgraded to wildfly 10, the messages are not getting in the queues. This is not consistent as once in a while messages are getting processed. I have attached the below standalone-full.xml for your reference :- 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue. > Upgrade to Wildfly 10.0.0.Final: Messaging System issue > ------------------------------------------------------- > > Key: WFLY-7134 > URL: https://issues.jboss.org/browse/WFLY-7134 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Preeta Kuruvilla > Assignee: Jeff Mesnil > Priority: Blocker > Attachments: standalone-full-WL-10.0.Final.xml, standalone-full-WL-8.2.xml > > > Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. > The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. > http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html > The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- > Let me know if this is good. Also I have attached the entire standalone-full.xml with this case. > <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> > <server name="default"> > <security enabled="false"/> > <statistics enabled="true"/> > <security-setting name="#"> > <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > </security-setting> > <address-setting name="#" redistribution-delay="1000" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> > <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> > <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> > <in-vm-connector name="in-vm" server-id="0"/> > <http-acceptor name="http-acceptor" http-listener="default"/> > <http-acceptor name="http-acceptor-throughput" http-listener="default"> > <param name="batch-delay" value="50"/> > <param name="direct-deliver" value="false"/> > </http-acceptor> > <in-vm-acceptor name="in-vm" server-id="0"/> > <jms-queue name="testQueue" entries="java:/queue/test java:jboss/exported/jms/queue/test"/> > <jms-queue name="ISEEOutboundQueue" entries="java:/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> > <jms-queue name="ISEEInboundQueue" entries="java:/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> > <jms-queue name="BEEEAuthorizationsQueue" entries="java:/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> > <jms-queue name="BEEERequisitionsQueue" entries="java:/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> > <jms-queue name="BEEEInboundQueue" entries="java:/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> > <jms-topic name="testTopic" entries="java:/topic/test java:jboss/exported/jms/topic/test"/> > <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> > <connection-factory name="RemoteConnectionFactory" entries="java:/RemoteConnectionFactory java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/> > <pooled-connection-factory name="activemq-ra" transaction="xa" entries="/JmsXA jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> > </server> > </subsystem> > InitialContext is created with parameters - jmsuser, password, and > BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port> > BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory > Issue we face is that after we upgraded to wildfly 10, the messages are not getting in the queues. This is not consistent as once in a while messages are getting processed. > I have attached the below standalone-full.xml for your reference :- > 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. > 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-263?page=com.atlassian.jira.plugi... ] Shigeru Chiba closed JASSIST-263. --------------------------------- > ClassPool cannot read generated classes > --------------------------------------- > > Key: JASSIST-263 > URL: https://issues.jboss.org/browse/JASSIST-263 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Reporter: Paul Pogonyshev > Assignee: Shigeru Chiba > Fix For: 3.20.0-GA > > Attachments: JavassistBug.java > > > ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example. > As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-263?page=com.atlassian.jira.plugi... ] Shigeru Chiba resolved JASSIST-263. ----------------------------------- Fix Version/s: 3.20.0-GA Resolution: Done This is not a bug. > ClassPool cannot read generated classes > --------------------------------------- > > Key: JASSIST-263 > URL: https://issues.jboss.org/browse/JASSIST-263 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Reporter: Paul Pogonyshev > Assignee: Shigeru Chiba > Fix For: 3.20.0-GA > > Attachments: JavassistBug.java > > > ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example. > As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-263?page=com.atlassian.jira.plugi... ] Shigeru Chiba commented on JASSIST-263: --------------------------------------- findResource() on your BuildClassLoader returns null. To return something useful, BuildClassLoader has to keep all the bytecode (byte[] arrays) that have been passed to defineClass() so far. findResource() on the BuildClassLoader will return a reference to that bytecode. > ClassPool cannot read generated classes > --------------------------------------- > > Key: JASSIST-263 > URL: https://issues.jboss.org/browse/JASSIST-263 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Reporter: Paul Pogonyshev > Assignee: Shigeru Chiba > Attachments: JavassistBug.java > > > ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example. > As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7135) WildFly ignores META-INF/services

by Kiran Mohan (JIRA)

[ https://issues.jboss.org/browse/WFLY-7135?page=com.atlassian.jira.plugin.... ] Kiran Mohan closed WFLY-7135. ----------------------------- Resolution: Done Turns out the problem is with the Java Preferences class which uses system class loader to load the service provider. I fixed this by writing my own implementation of the Preferences.systemRoot() function where it first checks for a service provider without using the system class loader > WildFly ignores META-INF/services > --------------------------------- > > Key: WFLY-7135 > URL: https://issues.jboss.org/browse/WFLY-7135 > Project: WildFly > Issue Type: Bug > Affects Versions: 9.0.2.Final > Reporter: Kiran Mohan > Assignee: Jason Greene > Priority: Critical > > Please see the bug description in this forum post > https://developer.jboss.org/thread/272349 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7136) Operation to list dependencies/dependents for a deployment

by Guillermo González de Agüero (JIRA)

Guillermo González de Agüero created WFLY-7136: -------------------------------------------------- Summary: Operation to list dependencies/dependents for a deployment Key: WFLY-7136 URL: https://issues.jboss.org/browse/WFLY-7136 Project: WildFly Issue Type: Feature Request Affects Versions: 10.1.0.Final Reporter: Guillermo González de Agüero Assignee: Jason Greene If a deployment "A" has a dependency on deployment "B", and "B" is undeployed, "A" automatically changes its status to FAILED. It's currently not possible to list what dependencies and dependents a deployment has. With two new operations (e.g. dependency-list and dependent-list) on the deployment resource, HAL could provide a confirmation dialog warning the user of side effects when undeploying. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1806) Split DomainModelControllerService into separate services for initializing as a master versus as a slave

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1806: ---------------------------------------- Summary: Split DomainModelControllerService into separate services for initializing as a master versus as a slave Key: WFCORE-1806 URL: https://issues.jboss.org/browse/WFCORE-1806 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 3.0.0.Beta1 This is an aspect of WFCORE-338, although it's valid in its own right as a conceptually cleaner approach to host controller boot. Using different services is a prerequisite to WFCORE-338 as it allows those elements of HC behavior to be started/stopped as a DC candidate is elected or unelected. It also makes it feasible to wire in the service that performs the election. The method that installs the service with MSC will return a Future<Boolean>, with the service setting the future's value at the completion of start(). DMCS during boot can block reading the future, from that confirm that the service completed successfully, and then proceed with the rest of boot. The boolean is basically an ok/not ok signal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7133) Automatically define resource adapter for deployed RARs

by Guillermo González de Agüero (JIRA)

[ https://issues.jboss.org/browse/WFLY-7133?page=com.atlassian.jira.plugin.... ] Guillermo González de Agüero commented on WFLY-7133: ---------------------------------------------------- After reviewing how detected deployed JDBC drivers are made available at runtime (via :installed-drivers-list), I think what's needed there is just the same. A new operation that exposes all the available resource adapters (that would include ActiveMQ, JBDC and JavaMail ones I guess): /subsystem=datasources:installed-resource-adapters-list() Just with that, HAL would be able to present a user with a list of "available" resource adapters and its current settings, with an option to make the configuration persistent by applying it to the management model. > Automatically define resource adapter for deployed RARs > ------------------------------------------------------- > > Key: WFLY-7133 > URL: https://issues.jboss.org/browse/WFLY-7133 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Guillermo González de Agüero > Assignee: Jesper Pedersen > > Deploying a RAR file enables the resource adapter for the server, but in order to configure it, you must manually add it to the Resource Adapters subsystem. This is error prone (you can put in invalid "archive name" for the resource adapter and it doesn't complaint) and little user friendly. > From a user perspective and from what can be read from the documentation (https://docs.jboss.org/author/display/WFLY10/Resource+adapters), it seems like the resource adapter is not enabled unless you explicitly define it. > It would be very simpler if RA deployments would be detected and registered as it's done for deployed JDBC drivers. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7135) WildFly ignores META-INF/services

by Kiran Mohan (JIRA)

Kiran Mohan created WFLY-7135: --------------------------------- Summary: WildFly ignores META-INF/services Key: WFLY-7135 URL: https://issues.jboss.org/browse/WFLY-7135 Project: WildFly Issue Type: Bug Affects Versions: 9.0.2.Final Reporter: Kiran Mohan Assignee: Jason Greene Priority: Critical Please see the bug description in this forum post https://developer.jboss.org/thread/272349 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7134) Upgrade to Wildfly 10.0.0.Final: Messaging System issue

by Preeta Kuruvilla (JIRA)

[ https://issues.jboss.org/browse/WFLY-7134?page=com.atlassian.jira.plugin.... ] Preeta Kuruvilla updated WFLY-7134: ----------------------------------- Description: Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- Let me know if this is good. Also I have attached the entire standalone-full.xml with this case. <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> <server name="default"> <security enabled="false"/> <statistics enabled="true"/> <security-setting name="#"> <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> </security-setting> <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> <in-vm-connector name="in-vm" server-id="0"/> <http-acceptor name="http-acceptor" http-listener="default"/> <http-acceptor name="http-acceptor-throughput" http-listener="default"> <param name="batch-delay" value="50"/> <param name="direct-deliver" value="false"/> </http-acceptor> <in-vm-acceptor name="in-vm" server-id="0"/> <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> </server> </subsystem> InitialContext is created with parameters - jmsuser, password, and BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port> BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory Issue we face is that after we upgraded to wildfly 10, the messages are not getting in the queues. This is not consistent as once in a while messages are getting processed. I have attached the below standalone-full.xml for your reference :- 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue. was: Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- Let me know if this is good. Also I am attaching the entire standalone-full.xml with this case. <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> <server name="default"> <security enabled="false"/> <statistics enabled="true"/> <security-setting name="#"> <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> </security-setting> <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> <in-vm-connector name="in-vm" server-id="0"/> <http-acceptor name="http-acceptor" http-listener="default"/> <http-acceptor name="http-acceptor-throughput" http-listener="default"> <param name="batch-delay" value="50"/> <param name="direct-deliver" value="false"/> </http-acceptor> <in-vm-acceptor name="in-vm" server-id="0"/> <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> </server> </subsystem> InitialContext is created with parameters - jmsuser, password, and BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port> BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory Issue we face is that after we upgraded to wildfly 10, the messages are not getting in the queues. This is not consistent as once in a while messages are getting processed. I have attached the below standalone-full.xml for your reference :- 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue. > Upgrade to Wildfly 10.0.0.Final: Messaging System issue > ------------------------------------------------------- > > Key: WFLY-7134 > URL: https://issues.jboss.org/browse/WFLY-7134 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Preeta Kuruvilla > Assignee: Jeff Mesnil > Priority: Blocker > Attachments: standalone-full-WL-10.0.Final.xml, standalone-full-WL-8.2.xml > > > Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. > The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. > http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html > The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- > Let me know if this is good. Also I have attached the entire standalone-full.xml with this case. > <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> > <server name="default"> > <security enabled="false"/> > <statistics enabled="true"/> > <security-setting name="#"> > <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > </security-setting> > <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> > <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> > <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> > <in-vm-connector name="in-vm" server-id="0"/> > <http-acceptor name="http-acceptor" http-listener="default"/> > <http-acceptor name="http-acceptor-throughput" http-listener="default"> > <param name="batch-delay" value="50"/> > <param name="direct-deliver" value="false"/> > </http-acceptor> > <in-vm-acceptor name="in-vm" server-id="0"/> > <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> > <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> > <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> > <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> > <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> > <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> > <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> > <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> > <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> > <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> > </server> > </subsystem> > InitialContext is created with parameters - jmsuser, password, and > BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port> > BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory > Issue we face is that after we upgraded to wildfly 10, the messages are not getting in the queues. This is not consistent as once in a while messages are getting processed. > I have attached the below standalone-full.xml for your reference :- > 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. > 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7134) Upgrade to Wildfly 10.0.0.Final: Messaging System issue

by Preeta Kuruvilla (JIRA)

[ https://issues.jboss.org/browse/WFLY-7134?page=com.atlassian.jira.plugin.... ] Preeta Kuruvilla updated WFLY-7134: ----------------------------------- Summary: Upgrade to Wildfly 10.0.0.Final: Messaging System issue (was: Wildfly 10.0.0.Final Messaging System issue) > Upgrade to Wildfly 10.0.0.Final: Messaging System issue > ------------------------------------------------------- > > Key: WFLY-7134 > URL: https://issues.jboss.org/browse/WFLY-7134 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Preeta Kuruvilla > Assignee: Jeff Mesnil > Priority: Blocker > Attachments: standalone-full-WL-10.0.Final.xml, standalone-full-WL-8.2.xml > > > Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. > The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. > http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html > The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- > Let me know if this is good. Also I am attaching the entire standalone-full.xml with this case. > <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> > <server name="default"> > <security enabled="false"/> > <statistics enabled="true"/> > <security-setting name="#"> > <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > </security-setting> > <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> > <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> > <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> > <in-vm-connector name="in-vm" server-id="0"/> > <http-acceptor name="http-acceptor" http-listener="default"/> > <http-acceptor name="http-acceptor-throughput" http-listener="default"> > <param name="batch-delay" value="50"/> > <param name="direct-deliver" value="false"/> > </http-acceptor> > <in-vm-acceptor name="in-vm" server-id="0"/> > <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> > <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> > <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> > <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> > <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> > <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> > <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> > <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> > <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> > <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> > </server> > </subsystem> > InitialContext is created with parameters - jmsuser, password, and > BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port> > BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory > Issue we face is that after we upgraded to wildfly 10, the messages are not getting in the queues. This is not consistent as once in a while messages are getting processed. > I have attached the below standalone-full.xml for your reference :- > 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. > 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7134) Wildfly 10.0.0.Final Messaging System issue

by Preeta Kuruvilla (JIRA)

[ https://issues.jboss.org/browse/WFLY-7134?page=com.atlassian.jira.plugin.... ] Preeta Kuruvilla updated WFLY-7134: ----------------------------------- Description: Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- Let me know if this is good. Also I am attaching the entire standalone-full.xml with this case. <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> <server name="default"> <security enabled="false"/> <statistics enabled="true"/> <security-setting name="#"> <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> </security-setting> <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> <in-vm-connector name="in-vm" server-id="0"/> <http-acceptor name="http-acceptor" http-listener="default"/> <http-acceptor name="http-acceptor-throughput" http-listener="default"> <param name="batch-delay" value="50"/> <param name="direct-deliver" value="false"/> </http-acceptor> <in-vm-acceptor name="in-vm" server-id="0"/> <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> </server> </subsystem> InitialContext is created with parameters - jmsuser, password, and BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port> BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory Issue we face is that after we upgraded to wildfly 10, the messages are not getting in the queues. This is not consistent as once in a while messages are getting processed. I have attached the below standalone-full.xml for your reference :- 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue. was: Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- Let me know if this is good. Also I am attaching the entire standalone-full.xml with this case. <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> <server name="default"> <security enabled="false"/> <statistics enabled="true"/> <security-setting name="#"> <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> </security-setting> <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> <in-vm-connector name="in-vm" server-id="0"/> <http-acceptor name="http-acceptor" http-listener="default"/> <http-acceptor name="http-acceptor-throughput" http-listener="default"> <param name="batch-delay" value="50"/> <param name="direct-deliver" value="false"/> </http-acceptor> <in-vm-acceptor name="in-vm" server-id="0"/> <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> </server> </subsystem> InitialContext is created with parameters - jmsuser, password, and BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port> BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory Issue we face is that after we upgraded to wildfly 10, the messages are not going getting in the queues. This is not consistent as once in a while messages are getting processed. I have attached the below standalone-full.xml for your reference :- 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue. > Wildfly 10.0.0.Final Messaging System issue > ------------------------------------------- > > Key: WFLY-7134 > URL: https://issues.jboss.org/browse/WFLY-7134 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Preeta Kuruvilla > Assignee: Jeff Mesnil > Priority: Blocker > Attachments: standalone-full-WL-10.0.Final.xml, standalone-full-WL-8.2.xml > > > Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. > The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. > http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html > The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- > Let me know if this is good. Also I am attaching the entire standalone-full.xml with this case. > <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> > <server name="default"> > <security enabled="false"/> > <statistics enabled="true"/> > <security-setting name="#"> > <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > </security-setting> > <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> > <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> > <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> > <in-vm-connector name="in-vm" server-id="0"/> > <http-acceptor name="http-acceptor" http-listener="default"/> > <http-acceptor name="http-acceptor-throughput" http-listener="default"> > <param name="batch-delay" value="50"/> > <param name="direct-deliver" value="false"/> > </http-acceptor> > <in-vm-acceptor name="in-vm" server-id="0"/> > <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> > <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> > <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> > <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> > <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> > <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> > <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> > <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> > <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> > <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> > </server> > </subsystem> > InitialContext is created with parameters - jmsuser, password, and > BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port> > BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory > Issue we face is that after we upgraded to wildfly 10, the messages are not getting in the queues. This is not consistent as once in a while messages are getting processed. > I have attached the below standalone-full.xml for your reference :- > 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. > 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7131) Wildfly 10.0.0.Final Messaging System issue

by Preeta Kuruvilla (JIRA)

[ https://issues.jboss.org/browse/WFLY-7131?page=com.atlassian.jira.plugin.... ] Preeta Kuruvilla closed WFLY-7131. ---------------------------------- Resolution: Duplicate Issue > Wildfly 10.0.0.Final Messaging System issue > ------------------------------------------- > > Key: WFLY-7131 > URL: https://issues.jboss.org/browse/WFLY-7131 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Preeta Kuruvilla > Assignee: Jeff Mesnil > Priority: Critical > Attachments: standalone-full-WL-10.0.Final.xml, standalone-full-WL-8.2.xml, standalone-full.xml > > > Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. > The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. > http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html > The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- > Let me know if this is good. Also I am attaching the entire standalone-full.xml with this case. > <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> > <server name="default"> > <security enabled="false"/> > <statistics enabled="true"/> > <security-setting name="#"> > <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > </security-setting> > <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> > <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> > <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> > <in-vm-connector name="in-vm" server-id="0"/> > <http-acceptor name="http-acceptor" http-listener="default"/> > <http-acceptor name="http-acceptor-throughput" http-listener="default"> > <param name="batch-delay" value="50"/> > <param name="direct-deliver" value="false"/> > </http-acceptor> > <in-vm-acceptor name="in-vm" server-id="0"/> > <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> > <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> > <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> > <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> > <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> > <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> > <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> > <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> > <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> > <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> > </server> > </subsystem> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7134) Wildfly 10.0.0.Final Messaging System issue

by Preeta Kuruvilla (JIRA)

[ https://issues.jboss.org/browse/WFLY-7134?page=com.atlassian.jira.plugin.... ] Preeta Kuruvilla updated WFLY-7134: ----------------------------------- Attachment: standalone-full-WL-10.0.Final.xml standalone-full-WL-8.2.xml standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.0.Final which has this JMS issue. > Wildfly 10.0.0.Final Messaging System issue > ------------------------------------------- > > Key: WFLY-7134 > URL: https://issues.jboss.org/browse/WFLY-7134 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Preeta Kuruvilla > Assignee: Jeff Mesnil > Priority: Blocker > Attachments: standalone-full-WL-10.0.Final.xml, standalone-full-WL-8.2.xml > > > Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. > The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. > http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html > The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- > Let me know if this is good. Also I am attaching the entire standalone-full.xml with this case. > <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> > <server name="default"> > <security enabled="false"/> > <statistics enabled="true"/> > <security-setting name="#"> > <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > </security-setting> > <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> > <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> > <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> > <in-vm-connector name="in-vm" server-id="0"/> > <http-acceptor name="http-acceptor" http-listener="default"/> > <http-acceptor name="http-acceptor-throughput" http-listener="default"> > <param name="batch-delay" value="50"/> > <param name="direct-deliver" value="false"/> > </http-acceptor> > <in-vm-acceptor name="in-vm" server-id="0"/> > <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> > <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> > <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> > <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> > <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> > <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> > <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> > <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> > <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> > <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> > </server> > </subsystem> > InitialContext is created with parameters - jmsuser, password, and > BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port> > BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory > Issue we face is that after we upgraded to wildfly 10, the messages are not going getting in the queues. This is not consistent as once in a while messages are getting processed. > I have attached the below standalone-full.xml for your reference :- > 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. > 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7134) Wildfly 10.0.0.Final Messaging System issue

by Preeta Kuruvilla (JIRA)

[ https://issues.jboss.org/browse/WFLY-7134?page=com.atlassian.jira.plugin.... ] Preeta Kuruvilla updated WFLY-7134: ----------------------------------- Description: Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- Let me know if this is good. Also I am attaching the entire standalone-full.xml with this case. <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> <server name="default"> <security enabled="false"/> <statistics enabled="true"/> <security-setting name="#"> <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> </security-setting> <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> <in-vm-connector name="in-vm" server-id="0"/> <http-acceptor name="http-acceptor" http-listener="default"/> <http-acceptor name="http-acceptor-throughput" http-listener="default"> <param name="batch-delay" value="50"/> <param name="direct-deliver" value="false"/> </http-acceptor> <in-vm-acceptor name="in-vm" server-id="0"/> <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> </server> </subsystem> InitialContext is created with parameters - jmsuser, password, and BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port> BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory Issue we face is that after we upgraded to wildfly 10, the messages are not going getting in the queues. This is not consistent as once in a while messages are getting processed. I have attached the below standalone-full.xml for your reference :- 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue. was: Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- Let me know if this is good. Also I am attaching the entire standalone-full.xml with this case. <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> <server name="default"> <security enabled="false"/> <statistics enabled="true"/> <security-setting name="#"> <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> </security-setting> <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> <in-vm-connector name="in-vm" server-id="0"/> <http-acceptor name="http-acceptor" http-listener="default"/> <http-acceptor name="http-acceptor-throughput" http-listener="default"> <param name="batch-delay" value="50"/> <param name="direct-deliver" value="false"/> </http-acceptor> <in-vm-acceptor name="in-vm" server-id="0"/> <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> </server> </subsystem> > Wildfly 10.0.0.Final Messaging System issue > ------------------------------------------- > > Key: WFLY-7134 > URL: https://issues.jboss.org/browse/WFLY-7134 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Preeta Kuruvilla > Assignee: Jeff Mesnil > Priority: Blocker > > Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. > The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. > http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html > The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- > Let me know if this is good. Also I am attaching the entire standalone-full.xml with this case. > <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> > <server name="default"> > <security enabled="false"/> > <statistics enabled="true"/> > <security-setting name="#"> > <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > </security-setting> > <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> > <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> > <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> > <in-vm-connector name="in-vm" server-id="0"/> > <http-acceptor name="http-acceptor" http-listener="default"/> > <http-acceptor name="http-acceptor-throughput" http-listener="default"> > <param name="batch-delay" value="50"/> > <param name="direct-deliver" value="false"/> > </http-acceptor> > <in-vm-acceptor name="in-vm" server-id="0"/> > <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> > <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> > <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> > <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> > <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> > <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> > <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> > <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> > <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> > <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> > </server> > </subsystem> > InitialContext is created with parameters - jmsuser, password, and > BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port> > BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory > Issue we face is that after we upgraded to wildfly 10, the messages are not going getting in the queues. This is not consistent as once in a while messages are getting processed. > I have attached the below standalone-full.xml for your reference :- > 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine. > 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7134) Wildfly 10.0.0.Final Messaging System issue

by Preeta Kuruvilla (JIRA)

[ https://issues.jboss.org/browse/WFLY-7134?page=com.atlassian.jira.plugin.... ] Preeta Kuruvilla updated WFLY-7134: ----------------------------------- Description: Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- Let me know if this is good. Also I am attaching the entire standalone-full.xml with this case. <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> <server name="default"> <security enabled="false"/> <statistics enabled="true"/> <security-setting name="#"> <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> </security-setting> <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> <in-vm-connector name="in-vm" server-id="0"/> <http-acceptor name="http-acceptor" http-listener="default"/> <http-acceptor name="http-acceptor-throughput" http-listener="default"> <param name="batch-delay" value="50"/> <param name="direct-deliver" value="false"/> </http-acceptor> <in-vm-acceptor name="in-vm" server-id="0"/> <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> </server> </subsystem> > Wildfly 10.0.0.Final Messaging System issue > ------------------------------------------- > > Key: WFLY-7134 > URL: https://issues.jboss.org/browse/WFLY-7134 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Preeta Kuruvilla > Assignee: Jeff Mesnil > Priority: Blocker > > Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker. > The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis. > http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html > The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:- > Let me know if this is good. Also I am attaching the entire standalone-full.xml with this case. > <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> > <server name="default"> > <security enabled="false"/> > <statistics enabled="true"/> > <security-setting name="#"> > <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > </security-setting> > <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> > <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/> > <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/> > <in-vm-connector name="in-vm" server-id="0"/> > <http-acceptor name="http-acceptor" http-listener="default"/> > <http-acceptor name="http-acceptor-throughput" http-listener="default"> > <param name="batch-delay" value="50"/> > <param name="direct-deliver" value="false"/> > </http-acceptor> > <in-vm-acceptor name="in-vm" server-id="0"/> > <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/> > <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/> > <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/> > <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/> > <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/> > <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/> > <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/> > <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> > <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/> > <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> > </server> > </subsystem> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 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 September 2016