October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9489) Remove need for application-security-domain mapping

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-9489: -------------------------------------- Summary: Remove need for application-security-domain mapping Key: WFLY-9489 URL: https://issues.jboss.org/browse/WFLY-9489 Project: WildFly Issue Type: Feature Request Components: Web (Undertow) Affects Versions: 11.0.0.Final Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 12.0.0.Alpha1 The application-security-domain resource was added to map from the security domain specified within the deployment to a WildFly Elytron authentication factory with some additional related configuration. It should be possible to define all of this within a deployment descriptor. Additionally the subsystem includes a default-security-domain attribute, it should likely contain some default Elytron configuration options. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1781) Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1781?page=com.atlassian.jira.plugi... ] Petr Široký updated DROOLS-1781: -------------------------------- Labels: java9 (was: ) > Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin > ------------------------------------------------------------------------------------ > > Key: DROOLS-1781 > URL: https://issues.jboss.org/browse/DROOLS-1781 > Project: Drools > Issue Type: Task > Components: build > Affects Versions: 7.4.1.Final > Reporter: Petr Široký > Assignee: Petr Široký > Labels: java9 > > SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1781) Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin

by Petr Široký (JIRA)

Petr Široký created DROOLS-1781: ----------------------------------- Summary: Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin Key: DROOLS-1781 URL: https://issues.jboss.org/browse/DROOLS-1781 Project: Drools Issue Type: Task Components: build Affects Versions: 7.4.1.Final Reporter: Petr Široký Assignee: Petr Široký SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9488) WeldDeployment initialisation error causes session fail-over to fail.

by Klaasjan Brand (JIRA)

[ https://issues.jboss.org/browse/WFLY-9488?page=com.atlassian.jira.plugin.... ] Klaasjan Brand updated WFLY-9488: --------------------------------- Description: At Topicus we've tested one of our Java EE applications to check compatibility with Wildfly session replication. This resulted in deserialization errors when performing a failover test. (WELD-001122: Failed to deserialize annotated type identified with AnnotatedTypeIdentifier) The application is deployed as an EAR archive containing several modules, one of them a WAR which hosts the main web frontend. Point of interest is our application uses Wicket (with Wicket-CDI) to inject CDI resources in Wicket pages. After a debugging session we concluded the "tryToLoadUnknownBackedAnnotatedType" method in the Weld class "SlimAnnotatedType" uses the wrong ResourceLoader when trying to load the class containing an injected object. Further debugging proved the initialisation in the WeldDeployment method "createAndRegisterAdditionalBeanDeploymentArchive" copies all of the ServiceRegistry entries of the parent BeanDeployment to the child, overwriting the already set ResourceLoader. I've attached a patch which prevents the overwriting of the deployment's already set entries. This fixed the replication problems with our application. was: At Topicus we've tested one of our Java EE applications to check compatibility with Wildfly session replication. This resulted in deserialization errors when performing a failover test. (WELD-001122: Failed to deserialize annotated type identified with AnnotatedTypeIdentifier) The application is deployed as an EAR archive containing several modules, one of them a WAR which hosts the main web frontend. Point of interest is our application uses Wicket (with Wicket-CDI) to inject CDI resources in Wicket pages. After a debugging session we concluded the "tryToLoadUnknownBackedAnnotatedType" method in the Weld class "SlimAnnotatedType" uses the wrong ResourceLoader when trying to load the class containing an injected object. Further debugging proved the initialisation in the WeldDeployment method "createAndRegisterAdditionalBeanDeploymentArchive" copies all of the ServiceRegistry entries of the parent BeanDeployment to the child, overwriting the already set ResourceLoader. > WeldDeployment initialisation error causes session fail-over to fail. > --------------------------------------------------------------------- > > Key: WFLY-9488 > URL: https://issues.jboss.org/browse/WFLY-9488 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 11.0.0.Final > Environment: Testen on OS X Sierra with Oracle JDK 1.8.0_152 > Reporter: Klaasjan Brand > Assignee: Martin Kouba > Attachments: serviceregistry.patch > > > At Topicus we've tested one of our Java EE applications to check compatibility with Wildfly session replication. This resulted in deserialization errors when performing a failover test. > (WELD-001122: Failed to deserialize annotated type identified with AnnotatedTypeIdentifier) > The application is deployed as an EAR archive containing several modules, one of them a WAR which hosts the main web frontend. > Point of interest is our application uses Wicket (with Wicket-CDI) to inject CDI resources in Wicket pages. > After a debugging session we concluded the "tryToLoadUnknownBackedAnnotatedType" method in the Weld class "SlimAnnotatedType" uses the wrong ResourceLoader when trying to load the class containing an injected object. > Further debugging proved the initialisation in the WeldDeployment method "createAndRegisterAdditionalBeanDeploymentArchive" copies all of the ServiceRegistry entries of the parent BeanDeployment to the child, overwriting the already set ResourceLoader. > I've attached a patch which prevents the overwriting of the deployment's already set entries. This fixed the replication problems with our application. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9488) WeldDeployment initialisation error causes session fail-over to fail.

by Klaasjan Brand (JIRA)

Klaasjan Brand created WFLY-9488: ------------------------------------ Summary: WeldDeployment initialisation error causes session fail-over to fail. Key: WFLY-9488 URL: https://issues.jboss.org/browse/WFLY-9488 Project: WildFly Issue Type: Bug Components: CDI / Weld Affects Versions: 11.0.0.Final Environment: Testen on OS X Sierra with Oracle JDK 1.8.0_152 Reporter: Klaasjan Brand Assignee: Martin Kouba Attachments: serviceregistry.patch At Topicus we've tested one of our Java EE applications to check compatibility with Wildfly session replication. This resulted in deserialization errors when performing a failover test. (WELD-001122: Failed to deserialize annotated type identified with AnnotatedTypeIdentifier) The application is deployed as an EAR archive containing several modules, one of them a WAR which hosts the main web frontend. Point of interest is our application uses Wicket (with Wicket-CDI) to inject CDI resources in Wicket pages. After a debugging session we concluded the "tryToLoadUnknownBackedAnnotatedType" method in the Weld class "SlimAnnotatedType" uses the wrong ResourceLoader when trying to load the class containing an injected object. Further debugging proved the initialisation in the WeldDeployment method "createAndRegisterAdditionalBeanDeploymentArchive" copies all of the ServiceRegistry entries of the parent BeanDeployment to the child, overwriting the already set ResourceLoader. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9488) WeldDeployment initialisation error causes session fail-over to fail.

by Klaasjan Brand (JIRA)

[ https://issues.jboss.org/browse/WFLY-9488?page=com.atlassian.jira.plugin.... ] Klaasjan Brand updated WFLY-9488: --------------------------------- Attachment: serviceregistry.patch > WeldDeployment initialisation error causes session fail-over to fail. > --------------------------------------------------------------------- > > Key: WFLY-9488 > URL: https://issues.jboss.org/browse/WFLY-9488 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 11.0.0.Final > Environment: Testen on OS X Sierra with Oracle JDK 1.8.0_152 > Reporter: Klaasjan Brand > Assignee: Martin Kouba > Attachments: serviceregistry.patch > > > At Topicus we've tested one of our Java EE applications to check compatibility with Wildfly session replication. This resulted in deserialization errors when performing a failover test. > (WELD-001122: Failed to deserialize annotated type identified with AnnotatedTypeIdentifier) > The application is deployed as an EAR archive containing several modules, one of them a WAR which hosts the main web frontend. > Point of interest is our application uses Wicket (with Wicket-CDI) to inject CDI resources in Wicket pages. > After a debugging session we concluded the "tryToLoadUnknownBackedAnnotatedType" method in the Weld class "SlimAnnotatedType" uses the wrong ResourceLoader when trying to load the class containing an injected object. > Further debugging proved the initialisation in the WeldDeployment method "createAndRegisterAdditionalBeanDeploymentArchive" copies all of the ServiceRegistry entries of the parent BeanDeployment to the child, overwriting the already set ResourceLoader. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1357) TransactionSynchronizer registered as interposed synchronization leads to ordering issue when using hibernate

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1357?page=com.atlassian.jira.plugin... ] Scott Marlow commented on JBJCA-1357: ------------------------------------- You can look at the org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList class in WildFly to see what we did. > TransactionSynchronizer registered as interposed synchronization leads to ordering issue when using hibernate > ------------------------------------------------------------------------------------------------------------- > > Key: JBJCA-1357 > URL: https://issues.jboss.org/browse/JBJCA-1357 > Project: IronJacamar > Issue Type: Bug > Affects Versions: 1.4.5 > Reporter: Alexander Pinske > Attachments: jca-hibernate.zip > > > The TransactionSynchronizer (to cleanup connections) is registered as an interposed synchronization. Hibernate also registers its synchronization (to close the underlying JDBC connection handle) as interposed. > This leads to undefined ordering, which in my case runs the JCA Synch before the Hibernate Synch. This leads to a log of IJ000316 and the connection being killed. > I think that platform specific cleanup should be executed after all application level synchronization have run, therefore it should be registered with the TM (not the TSR). > http://www.ironjacamar.org/doc/roadto12/txtracking.html describes this as an application misbehaviour. But I don't think the application has any means of controlling the ordering in this scenario. > If I do not provide a TSR to the TransactionIntegrationImpl (which would lead to the registration of the TransactionSynchronizer via TransactionManager - thus non-interposed) has the problem that AbstractPool uses the TSR to check if a transaction is actually in progress. > I don't know if my rationale is correct. Could you please comment on the issue? > Thanks! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3384) misleading operations in configuration changes service

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3384?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3384: ------------------------------------------ The globally available operations are available on every resource. Trying to decide if they are relevant for a particular resource and hiding them from the operation list is something to think about some day but it is definitely not something I want getting attention now. > misleading operations in configuration changes service > ------------------------------------------------------ > > Key: WFCORE-3384 > URL: https://issues.jboss.org/browse/WFCORE-3384 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.8.Final > Reporter: Chao Wang > Assignee: ehsavoie Hugonnet > > {noformat} > [standalone@localhost:9990 /] /subsystem=core-management/service=configuration-changes:read-operation-names() > { > "outcome" => "success", > "result" => [ > ... ... > "list-add", > "list-changes", > "list-clear", > "list-get", > "list-remove", > ... ... > {noformat} > Only list-changes is valid operation, other operations shouldn't be there as configuration changes list is expected to be read-only, except for attribute max history. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1357) TransactionSynchronizer registered as interposed synchronization leads to ordering issue when using hibernate

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1357?page=com.atlassian.jira.plugin... ] Scott Marlow commented on JBJCA-1357: ------------------------------------- [https://developer.jboss.org/message/920148#920148] seems related, you could read the entire forum thread if you like. We solved this only in the WildFly application server (as well as the Red Hat EAP product), by adding special ordering code that always executes the IJ interposed synchronization class last. So, with this synchronization ordering solution that is implemented directly in the WildFly code, during beforeCompletion, the IJ sync runs after other interposed syncs. During afterCompletion, the IJ sync runs after other interposed syncs. Since your test case shows that your not running in WildFly, of course, you still see the problem that we solved only for WildFly. Are you using WildFly (or EAP) to run the software where you actually hit JBJCA-1357? > TransactionSynchronizer registered as interposed synchronization leads to ordering issue when using hibernate > ------------------------------------------------------------------------------------------------------------- > > Key: JBJCA-1357 > URL: https://issues.jboss.org/browse/JBJCA-1357 > Project: IronJacamar > Issue Type: Bug > Affects Versions: 1.4.5 > Reporter: Alexander Pinske > Attachments: jca-hibernate.zip > > > The TransactionSynchronizer (to cleanup connections) is registered as an interposed synchronization. Hibernate also registers its synchronization (to close the underlying JDBC connection handle) as interposed. > This leads to undefined ordering, which in my case runs the JCA Synch before the Hibernate Synch. This leads to a log of IJ000316 and the connection being killed. > I think that platform specific cleanup should be executed after all application level synchronization have run, therefore it should be registered with the TM (not the TSR). > http://www.ironjacamar.org/doc/roadto12/txtracking.html describes this as an application misbehaviour. But I don't think the application has any means of controlling the ordering in this scenario. > If I do not provide a TSR to the TransactionIntegrationImpl (which would lead to the registration of the TransactionSynchronizer via TransactionManager - thus non-interposed) has the problem that AbstractPool uses the TSR to check if a transaction is actually in progress. > I don't know if my rationale is correct. Could you please comment on the issue? > Thanks! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1421) Elytron 1.2 user impacting issues

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1421?page=com.atlassian.jira.plugin.s... ] Martin Choma edited comment on ELY-1421 at 10/26/17 9:12 AM: ------------------------------------------------------------- ELY-1406 , fix exposes fail-cache option was (Author: mchoma): ELY-1406 , fix expose fail-cache option > Elytron 1.2 user impacting issues > --------------------------------- > > Key: ELY-1421 > URL: https://issues.jboss.org/browse/ELY-1421 > Project: WildFly Elytron > Issue Type: Tracker > Reporter: Martin Choma > Assignee: Martin Choma > Priority: Trivial > > This issue is for tracking changes in Elytron 1.2 which brings new configuration options to users. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 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 October 2017