[JBoss JIRA] (WFLY-6971) MDB cannot be deployed after migration due to "DuplicateServiceException: Service jboss.infinispan.ejb."mdb-1.0-SNAPSHOT.jar".config is already registered"
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFLY-6971?page=com.atlassian.jira.plugin.... ]
Panagiotis Sotiropoulos moved JBEAP-5665 to WFLY-6971:
------------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6971 (was: JBEAP-5665)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
JMS
(was: EJB)
(was: JMS)
(was: Migration)
Target Release: (was: 7.1.0.GA)
Affects Version/s: 10.1.0.CR1
(was: 7.1.0.DR2)
> MDB cannot be deployed after migration due to "DuplicateServiceException: Service jboss.infinispan.ejb."mdb-1.0-SNAPSHOT.jar".config is already registered"
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6971
> URL: https://issues.jboss.org/browse/WFLY-6971
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JMS
> Affects Versions: 10.1.0.CR1
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
> Priority: Critical
> Attachments: mdb-1.0-SNAPSHOT.jar, standalone-full-ha.xml_eap6
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> If EAP 7 with (manually) migrated configuration from EAP 6.4.7.CP server is started then MDB deployment fails with:
> {code}
> 14:17:09,432 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".cache-dependencies-installer: org.jboss.msc.service.StartException in service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".cache-dependencies-installer: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_71]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_71]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_71]
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.infinispan.ejb."mdb-1.0-SNAPSHOT.jar".config is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1]
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1]
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1]
> at org.jboss.as.ejb3.cache.distributable.DistributableCacheFactoryBuilderService.installDeploymentUnitDependencies(DistributableCacheFactoryBuilderService.java:93)
> at org.jboss.as.ejb3.deployment.processors.CacheDependenciesProcessor$1.start(CacheDependenciesProcessor.java:50)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1]
> ... 3 more
> {code}
> Problem seems to be configuration of caches in ejb subsystem which looks like:
> {code}
> <subsystem xmlns="urn:jboss:domain:ejb3:4.0">
> ...
> <caches>
> <cache name="simple" aliases="NoPassivationCache"/>
> <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
> <cache name="clustered" passivation-store-ref="infinispan" aliases="StatefulTreeCache"/>
> </caches>
> ...
> </subsystem>
> {code}
> If any of lines:
> {code}
> <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
> <cache name="clustered" passivation-store-ref="infinispan"
> {code}
> is removed or I take default configuration from EAP 7:
> {code}
> <caches>
> <cache name="simple"/>
> <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/>
> </caches>
> {code}
> then MDB is deployed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1718) Handlers within Audit Logger are not removed properly when Audit Logger is removed
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1718?page=com.atlassian.jira.plugi... ]
Kabir Khan commented on WFCORE-1718:
------------------------------------
I think that sounds reasonable, the createHostServerDefinition should probably not do the runtime part.
I don't remember off the top of my head why the logger is shared...
> Handlers within Audit Logger are not removed properly when Audit Logger is removed
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-1718
> URL: https://issues.jboss.org/browse/WFCORE-1718
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha5
> Reporter: Jan Tymel
> Assignee: Brian Stansberry
>
> If Audit Logger is removed, destination handlers (i.e. its child nodes) are not removed properly. They are not present in the config file. They seem to be not removed "internally" though. This leads to a couple of issues:
> 1. It is not possible to remove referenced File/Syslog handlers. If user tries to remove them the _NullPointerException_ is given as a result. Try following commands:
> {{/core-service=management/access=audit/file-handler=file:remove()}}
> {{/core-service=management/access=audit/syslog-handler=my-syslog-handler:remove()}}
> Their output is:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {code}
> 2. AuditLog continues to send auditable events to previously referenced File/Syslog handlers.
> * Create auditable event (e.g. {{/subsystem=logging/logger=com.arjuna:write-attribute(name=level,value=DEBUG)}})
> * See log in the file (WILDFLY_HOME/standalone/data/audit-log.log)
> * See log in the syslog (/var/log/messages)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-5542) Look into using apache's upstream JSTL
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5542?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka edited comment on WFLY-5542 at 8/18/16 6:53 AM:
-----------------------------------------------------------------
I've taken look to some of the differences. Here are some of my findings based on going through the source code diffs (I have been comparing https://svn.apache.org/repos/asf/tomcat/taglibs/standard/trunk in revision {{1756754}} and git@github.com:jboss/jboss-jstl-api_spec.git with latest commit {{ce6adae9663904c958feb856b3c09013c2a2b3da}}):
# missing fix in apache's upstream JSTL for https://bugzilla.redhat.com/show_bug.cgi?id=1320747
# in jboss jstl there is org.apache.taglibs.standard.tag.common.sql.DriverManagerAccessor created as hack needed for using DriverManager in modular environment.
# secure processing can be configured via property in jboss jstl, in apache's upstream JSTL, it is always enforced
The differences above should be checked or added to the apache's upstream JSTL before starting to use it.
was (Author: rhatlapa):
I've taken look to some of the differences. Here are some of my findings based on going through the source code diffs:
# missing fix in apache's upstream JSTL for https://bugzilla.redhat.com/show_bug.cgi?id=1320747
# in jboss jstl there is org.apache.taglibs.standard.tag.common.sql.DriverManagerAccessor created as hack needed for using DriverManager in modular environment.
# secure processing can be configured via property in jboss jstl, in apache's upstream JSTL, it is always enforced
The differences above should be checked or added to the apache's upstream JSTL before starting to use it.
> Look into using apache's upstream JSTL
> --------------------------------------
>
> Key: WFLY-5542
> URL: https://issues.jboss.org/browse/WFLY-5542
> Project: WildFly
> Issue Type: Task
> Components: EE, Web (Undertow)
> Affects Versions: 10.0.0.CR2
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
>
> We are now using forked combination of apache & java.net's version of JSTL.
> We should look into using upstream version if possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-5542) Look into using apache's upstream JSTL
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5542?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka edited comment on WFLY-5542 at 8/18/16 6:53 AM:
-----------------------------------------------------------------
I've taken look to some of the differences. Here are some of my findings based on going through the source code diffs (I have been comparing https://svn.apache.org/repos/asf/tomcat/taglibs/standard/trunk in revision {{1756754}} and {{git@github.com:jboss/jboss-jstl-api_spec.git}} with latest commit {{ce6adae9663904c958feb856b3c09013c2a2b3da}}):
# missing fix in apache's upstream JSTL for https://bugzilla.redhat.com/show_bug.cgi?id=1320747
# in jboss jstl there is org.apache.taglibs.standard.tag.common.sql.DriverManagerAccessor created as hack needed for using DriverManager in modular environment.
# secure processing can be configured via property in jboss jstl, in apache's upstream JSTL, it is always enforced
The differences above should be checked or added to the apache's upstream JSTL before starting to use it.
was (Author: rhatlapa):
I've taken look to some of the differences. Here are some of my findings based on going through the source code diffs (I have been comparing https://svn.apache.org/repos/asf/tomcat/taglibs/standard/trunk in revision {{1756754}} and git@github.com:jboss/jboss-jstl-api_spec.git with latest commit {{ce6adae9663904c958feb856b3c09013c2a2b3da}}):
# missing fix in apache's upstream JSTL for https://bugzilla.redhat.com/show_bug.cgi?id=1320747
# in jboss jstl there is org.apache.taglibs.standard.tag.common.sql.DriverManagerAccessor created as hack needed for using DriverManager in modular environment.
# secure processing can be configured via property in jboss jstl, in apache's upstream JSTL, it is always enforced
The differences above should be checked or added to the apache's upstream JSTL before starting to use it.
> Look into using apache's upstream JSTL
> --------------------------------------
>
> Key: WFLY-5542
> URL: https://issues.jboss.org/browse/WFLY-5542
> Project: WildFly
> Issue Type: Task
> Components: EE, Web (Undertow)
> Affects Versions: 10.0.0.CR2
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
>
> We are now using forked combination of apache & java.net's version of JSTL.
> We should look into using upstream version if possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-5542) Look into using apache's upstream JSTL
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5542?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka commented on WFLY-5542:
----------------------------------------
I've taken look to some of the differences. Here are some of my findings based on going through the source code diffs:
# missing fix in apache's upstream JSTL for https://bugzilla.redhat.com/show_bug.cgi?id=1320747
# in jboss jstl there is org.apache.taglibs.standard.tag.common.sql.DriverManagerAccessor created as hack needed for using DriverManager in modular environment.
# secure processing can be configured via property in jboss jstl, in apache's upstream JSTL, it is always enforced
The differences above should be checked or added to the apache's upstream JSTL before starting to use it.
> Look into using apache's upstream JSTL
> --------------------------------------
>
> Key: WFLY-5542
> URL: https://issues.jboss.org/browse/WFLY-5542
> Project: WildFly
> Issue Type: Task
> Components: EE, Web (Undertow)
> Affects Versions: 10.0.0.CR2
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
>
> We are now using forked combination of apache & java.net's version of JSTL.
> We should look into using upstream version if possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6441) naming context is not setup when starting the persistence unit
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6441?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6441:
-----------------------------------------------
Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1320132|https://bugzilla.redhat.com/show_bug.cgi?id=1320132] from ON_QA to VERIFIED
> naming context is not setup when starting the persistence unit
> --------------------------------------------------------------
>
> Key: WFLY-6441
> URL: https://issues.jboss.org/browse/WFLY-6441
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Affects Versions: JBoss AS7 7.1.1.Final, JBoss AS7 7.2.0.Final, 9.0.2.Final, 10.0.0.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 10.1.0.CR1
>
>
> ookup of env-entry throws NameNotFoundException during persistence unit startup
> Version-Release number of selected component (if applicable):
> How reproducible:
> always
> Steps to Reproduce:
> 1. add env-entry in application.xml
> 2. try to lookup during persistent unit startup, e.g.
> public class MyType implements UserType {
> ...
> @Override
> public int[] sqlTypes() {
> try {
> Object ctx = new InitialContext().lookup("java:app/env");
> log.info("java:app/env from JPA = " + ctx);
> } catch (Exception e) {
> log.error("unable to get java:app/env from JPA", e);
> }
> return new int[] { Types.VARCHAR };
> }
> Actual results:
> NameNotFoundException
> Expected results:
> value of env-entry is available
> Additional info:
> On 21.03.2016 23:47, Stuart Douglas wrote:
> > This should fix it (I think): https://github.com/stuartwdouglas/wildfly/tree/jpa-java-namespace
> >
> > Stuart
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1705) A system dependency path "sun/security/provider/certpath" is missing from wildfly's module.xml
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1705?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1705:
-------------------------------------
Priority: Major (was: Blocker)
> A system dependency path "sun/security/provider/certpath" is missing from wildfly's module.xml
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1705
> URL: https://issues.jboss.org/browse/WFCORE-1705
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules, Server
> Affects Versions: 2.2.0.Final
> Reporter: Peter Nalyvayko
> Assignee: David Lloyd
> Labels: jboss
>
> There is a system dependency path "sun/security/provider/certpath" missing from modules\system\layers\base\sun\jdk\main\module.xml. This is causing class def not found exception when attempting to create an instance of a class from that namespace. The module contents (abbreviated) are shown below. Notice that the path to "sun/security/provider/certpath" is not listed in there:
> {{<module xmlns="urn:jboss:module:1.3" name="sun.jdk">
> <resources>
> <!-- currently jboss modules has not way of importing services from
> classes.jar so we duplicate them here -->
> <resource-root path="service-loader-resources"/>
> </resources>
> <dependencies>
> <module name="sun.scripting" export="true"/>
> <system export="true">
> <paths>
> ...
> <path name="sun/security/action"/>
> <path name="sun/security/pkcs"/>
> <path name="sun/security/x509"/>
> <path name="sun/security"/>
> <path name="sun/security/util"/>
> <path name="sun/security/krb5"/>
> <path name="sun/security/krb5/internal"/>
> <path name="sun/security/pkcs11"/>
> <path name="sun/security/provider"/>
> ...
> </paths>
> <exports>
> <include-set>
> <path name="META-INF/services"/>
> </include-set>
> </exports>
> </system>
> </dependencies>
> </module>
> }}Manually adding the missing system dependency path fixes the issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1718) Handlers within Audit Logger are not removed properly when Audit Logger is removed
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1718?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-1718 at 8/17/16 4:15 PM:
-------------------------------------------------------------------
This can be fixed by having AuditLogLoggerRemoveHandler extend AbstractRemoveStepHandler.
However, as part of doing this we need to review the use of AuditLogLoggerResourceDefinition.createHostServerDefinition. The only use I see of that, the same auditLogger instance is passed to it as is passed to AuditLogLoggerResourceDefinition.createDefinition. So the same logger gets passed to two resources, in one case with 'executeRuntime=true' and another time with 'executeRuntime=false'. In both cases the add handler performs at least some sort of modification of the auditLogger, with executeRuntime controlling exactly what. And in both cases the remove handler is modifying the audit logger. This just seems a bit odd. Intuitively I'd think the AuditLogLoggerResourceDefinition.createHostServerDefinition would not involve any runtime modification at all as the resource is just storing config data on the HC for its use in configuring a server.
[~kabirkhan] WDYT think about the last paragraph ^^^?
was (Author: brian.stansberry):
This can be fixed by having AuditLogLoggerRemoveHandler extend AbstractRemoveStepHandler.
However, as part of doing this we need to review the use of AuditLogLoggerResourceDefinition.createHostServerDefinition. The only use I see of that, the same auditLogger instance is passed to it as is passed to AuditLogLoggerResourceDefinition.createDefinition. So the same logger gets passed to two resources, in one case with 'executeRuntime=true' and another time with 'executeRuntime=false'. In both cases the add handler performs at least some sort of modification of the auditLogger, with executeRuntime controlling exactly what. And in both cases the remove handler is modifying the audit logger. This just seems a bit odd. Intuitively I'd think the AuditLogLoggerResourceDefinition.createHostServerDefinition would not involve any runtime modification at all as the resource is just storing config data on the HC for its use in configuring a server.
> Handlers within Audit Logger are not removed properly when Audit Logger is removed
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-1718
> URL: https://issues.jboss.org/browse/WFCORE-1718
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha5
> Reporter: Jan Tymel
> Assignee: Brian Stansberry
>
> If Audit Logger is removed, destination handlers (i.e. its child nodes) are not removed properly. They are not present in the config file. They seem to be not removed "internally" though. This leads to a couple of issues:
> 1. It is not possible to remove referenced File/Syslog handlers. If user tries to remove them the _NullPointerException_ is given as a result. Try following commands:
> {{/core-service=management/access=audit/file-handler=file:remove()}}
> {{/core-service=management/access=audit/syslog-handler=my-syslog-handler:remove()}}
> Their output is:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {code}
> 2. AuditLog continues to send auditable events to previously referenced File/Syslog handlers.
> * Create auditable event (e.g. {{/subsystem=logging/logger=com.arjuna:write-attribute(name=level,value=DEBUG)}})
> * See log in the file (WILDFLY_HOME/standalone/data/audit-log.log)
> * See log in the syslog (/var/log/messages)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months