[JBoss JIRA] (WFLY-9567) Setting 'eclipselink.archive.factory' property should NOT depend on 'eclipselink.target-server' being set
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-9567?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-9567:
------------------------------------
Cool, got merged for WildFly 12.0! :) This should have no impact on current applications using older versions of EclipseLink, however, applications using EclipseLink 2.7.1+, no longer should have to set the eclipselink.archive.factory via a system property.
Applications that set their own eclipselink.archive.factory, will also still function the same. Updated code:
{code}
public void addProviderProperties(Map properties, PersistenceUnitMetadata pu) {
if (!pu.getProperties().containsKey(ECLIPSELINK_ARCHIVE_FACTORY)) {
properties.put(ECLIPSELINK_ARCHIVE_FACTORY, JBossArchiveFactoryImpl.class.getName());
}
if (!pu.getProperties().containsKey(ECLIPSELINK_TARGET_SERVER)) {
properties.put(ECLIPSELINK_TARGET_SERVER, WildFlyServerPlatform.class.getName());
}
if (!pu.getProperties().containsKey(ECLIPSELINK_LOGGING_LOGGER)) {
properties.put(ECLIPSELINK_LOGGING_LOGGER, JBossLogger.class.getName());
}
}
{code}
> Setting 'eclipselink.archive.factory' property should NOT depend on 'eclipselink.target-server' being set
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9567
> URL: https://issues.jboss.org/browse/WFLY-9567
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Lukas Jungmann
> Assignee: Scott Marlow
> Fix For: 12.0.0.CR1
>
>
> After applying patch from https://bugs.eclipse.org/bugs/show_bug.cgi?id=414974 on EclipseLink side and removing 'eclipselink.archive.factory' from WildFly's JVM options, 99,9% of tests started to fail on the server.
> Problem is that majority of our PU's do have set 'eclipselink.target-server' property (for various reasons) - in this case container as of[1] won't pass its 'eclipselink.archive.factory' to EclipseLink and deployments fail with:
> {noformat}
> [EL Severe]: 2017-11-23 13:14:31.974--ServerSession(1652754085)--Local Exception Stack:
> Exception [EclipseLink-28014] (Eclipse Persistence Services - 2.7.1.qualifier): org.eclipse.persistence.exceptions.EntityManagerSetupException
> Exception Description: Exception was thrown while processing property [eclipselink.descriptor.customizer.Project] with value [org.eclipse.persistence.testing.models.jpa.advanced.Customizer].
> Internal Exception: java.lang.ClassNotFoundException: Project from [Module "deployment.eclipselink-advanced-model.ear.eclipselink-advanced-model_ejb.jar" from Service Module Loader]
> at org.eclipse.persistence.exceptions.EntityManagerSetupException.failedWhileProcessingProperty(EntityManagerSetupException.java:199)
> at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.processDescriptorCustomizers(EntityManagerSetupImpl.java:2941)
> ...
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: Project from [Module "deployment.eclipselink-advanced-model.ear.eclipselink-advanced-model_ejb.jar" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getClassForName(PrivilegedAccessHelper.java:165)
> at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.findClass(EntityManagerSetupImpl.java:1321)
> at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.processDescriptorCustomizers(EntityManagerSetupImpl.java:2938)
> ... 82 more
> {noformat}
> [1]: https://github.com/wildfly/wildfly/blob/a10034a/jpa/eclipselink/src/main/...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9567) Setting 'eclipselink.archive.factory' property should NOT depend on 'eclipselink.target-server' being set
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-9567?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-9567:
-------------------------------
Fix Version/s: 12.0.0.CR1
(was: 13.0.0.Beta1)
> Setting 'eclipselink.archive.factory' property should NOT depend on 'eclipselink.target-server' being set
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9567
> URL: https://issues.jboss.org/browse/WFLY-9567
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Lukas Jungmann
> Assignee: Scott Marlow
> Fix For: 12.0.0.CR1
>
>
> After applying patch from https://bugs.eclipse.org/bugs/show_bug.cgi?id=414974 on EclipseLink side and removing 'eclipselink.archive.factory' from WildFly's JVM options, 99,9% of tests started to fail on the server.
> Problem is that majority of our PU's do have set 'eclipselink.target-server' property (for various reasons) - in this case container as of[1] won't pass its 'eclipselink.archive.factory' to EclipseLink and deployments fail with:
> {noformat}
> [EL Severe]: 2017-11-23 13:14:31.974--ServerSession(1652754085)--Local Exception Stack:
> Exception [EclipseLink-28014] (Eclipse Persistence Services - 2.7.1.qualifier): org.eclipse.persistence.exceptions.EntityManagerSetupException
> Exception Description: Exception was thrown while processing property [eclipselink.descriptor.customizer.Project] with value [org.eclipse.persistence.testing.models.jpa.advanced.Customizer].
> Internal Exception: java.lang.ClassNotFoundException: Project from [Module "deployment.eclipselink-advanced-model.ear.eclipselink-advanced-model_ejb.jar" from Service Module Loader]
> at org.eclipse.persistence.exceptions.EntityManagerSetupException.failedWhileProcessingProperty(EntityManagerSetupException.java:199)
> at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.processDescriptorCustomizers(EntityManagerSetupImpl.java:2941)
> ...
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: Project from [Module "deployment.eclipselink-advanced-model.ear.eclipselink-advanced-model_ejb.jar" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getClassForName(PrivilegedAccessHelper.java:165)
> at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.findClass(EntityManagerSetupImpl.java:1321)
> at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.processDescriptorCustomizers(EntityManagerSetupImpl.java:2938)
> ... 82 more
> {noformat}
> [1]: https://github.com/wildfly/wildfly/blob/a10034a/jpa/eclipselink/src/main/...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (REMJMX-157) Resource Leak in RemotingConnector
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-157?page=com.atlassian.jira.plugin... ]
Darran Lofthouse reassigned REMJMX-157:
---------------------------------------
Assignee: (was: Darran Lofthouse)
> Resource Leak in RemotingConnector
> ----------------------------------
>
> Key: REMJMX-157
> URL: https://issues.jboss.org/browse/REMJMX-157
> Project: Remoting JMX
> Issue Type: Bug
> Reporter: Stefan Mocken
>
> If opening a Connection fails for any reason, the Endpoint is not closed.
> So in a corrosponding thread dump for every failed connection there will be the following dead entries:
> ############################################################
> "Remoting "endpoint" Accept" #215802 daemon prio=5 os_prio=0 tid=0x00007f48dc21a000 nid=0x4e8e runnable [0x00007f48894d6000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x00000000f01d1d10> (a sun.nio.ch.Util$3)
> - locked <0x00000000f01d1d00> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00000000f01d1be8> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
> "Remoting "endpoint" I/O-1" #215801 daemon prio=5 os_prio=0 tid=0x00007f48dc08c000 nid=0x4e8d runnable [0x00007f4885ea0000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x00000000f01cc188> (a sun.nio.ch.Util$3)
> - locked <0x00000000f01cc178> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00000000f01cc060> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
> ############################################################
> NitinRanjan suggested to patch
> the close() method of RemotingConnector.java which is responsible for closing the endpoint threads and others.
> In case of connection not established the state is UNUSED which makes the close method to return without closing the endpoint thread.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (REMJMX-157) Resource Leak in RemotingConnector
by Stefan Mocken (JIRA)
[ https://issues.jboss.org/browse/REMJMX-157?page=com.atlassian.jira.plugin... ]
Stefan Mocken commented on REMJMX-157:
--------------------------------------
No, i just tested up to Wildfly10.
> Resource Leak in RemotingConnector
> ----------------------------------
>
> Key: REMJMX-157
> URL: https://issues.jboss.org/browse/REMJMX-157
> Project: Remoting JMX
> Issue Type: Bug
> Reporter: Stefan Mocken
> Assignee: Darran Lofthouse
>
> If opening a Connection fails for any reason, the Endpoint is not closed.
> So in a corrosponding thread dump for every failed connection there will be the following dead entries:
> ############################################################
> "Remoting "endpoint" Accept" #215802 daemon prio=5 os_prio=0 tid=0x00007f48dc21a000 nid=0x4e8e runnable [0x00007f48894d6000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x00000000f01d1d10> (a sun.nio.ch.Util$3)
> - locked <0x00000000f01d1d00> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00000000f01d1be8> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
> "Remoting "endpoint" I/O-1" #215801 daemon prio=5 os_prio=0 tid=0x00007f48dc08c000 nid=0x4e8d runnable [0x00007f4885ea0000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x00000000f01cc188> (a sun.nio.ch.Util$3)
> - locked <0x00000000f01cc178> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00000000f01cc060> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
> ############################################################
> NitinRanjan suggested to patch
> the close() method of RemotingConnector.java which is responsible for closing the endpoint threads and others.
> In case of connection not established the state is UNUSED which makes the close method to return without closing the endpoint thread.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (REMJMX-157) Resource Leak in RemotingConnector
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-157?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on REMJMX-157:
-----------------------------------------
Have you tested this using the latest version of Remoting JMX included in WildFly 11? There have been some changes in relation to connection and endpoint handling in that release that may have already had an impact here.
> Resource Leak in RemotingConnector
> ----------------------------------
>
> Key: REMJMX-157
> URL: https://issues.jboss.org/browse/REMJMX-157
> Project: Remoting JMX
> Issue Type: Bug
> Reporter: Stefan Mocken
> Assignee: Darran Lofthouse
>
> If opening a Connection fails for any reason, the Endpoint is not closed.
> So in a corrosponding thread dump for every failed connection there will be the following dead entries:
> ############################################################
> "Remoting "endpoint" Accept" #215802 daemon prio=5 os_prio=0 tid=0x00007f48dc21a000 nid=0x4e8e runnable [0x00007f48894d6000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x00000000f01d1d10> (a sun.nio.ch.Util$3)
> - locked <0x00000000f01d1d00> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00000000f01d1be8> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
> "Remoting "endpoint" I/O-1" #215801 daemon prio=5 os_prio=0 tid=0x00007f48dc08c000 nid=0x4e8d runnable [0x00007f4885ea0000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x00000000f01cc188> (a sun.nio.ch.Util$3)
> - locked <0x00000000f01cc178> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00000000f01cc060> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
> ############################################################
> NitinRanjan suggested to patch
> the close() method of RemotingConnector.java which is responsible for closing the endpoint threads and others.
> In case of connection not established the state is UNUSED which makes the close method to return without closing the endpoint thread.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9853) NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration
by Petr Jurak (JIRA)
[ https://issues.jboss.org/browse/WFLY-9853?page=com.atlassian.jira.plugin.... ]
Petr Jurak moved SECURITY-864 to WFLY-9853:
-------------------------------------------
Project: WildFly (was: PicketBox )
Key: WFLY-9853 (was: SECURITY-864)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: Security
(was: PicketBox)
> NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9853
> URL: https://issues.jboss.org/browse/WFLY-9853
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Chao Wang
> Assignee: Stefan Guilhen
>
> "NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration" is recorded in server.log during quickstart example run by changing log level:
> {noformat}
> <logger category="org.jboss.as.security">
> <level name="TRACE"/>
> </logger>
> <logger category="org.jboss.security">
> <level name="TRACE"/>
> </logger>
> {noformat}
> See detailed description in community discussion [#907134|https://developer.jboss.org/message/907134]
> I choose Jira component picketbox since the exception is titled as "PBOX000293: Exception caught: javax.naming.NameNotFoundException"
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months