[JBoss JIRA] (ELY-1351) Elytron - Unable to create security domain without a realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1351?page=com.atlassian.jira.plugin.s... ]
Jan Kalina moved JBEAP-12928 to ELY-1351:
-----------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-1351 (was: JBEAP-12928)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Authentication Server
(was: Security)
Affects Version/s: 1.2.0.Beta1
(was: 7.1.0.ER1)
> Elytron - Unable to create security domain without a realm
> ----------------------------------------------------------
>
> Key: ELY-1351
> URL: https://issues.jboss.org/browse/ELY-1351
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Server
> Affects Versions: 1.2.0.Beta1
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
> Labels: eap7.1.0-to-prd
>
> It's not possible to create an Elytron security domain without a security realm (default-realm attribute is mandatory).
> When an administrator wants to allow just ANONYMOUS access, he/she has to use a dummy security realm to configure such a security domain. It should be possible to have domain without realms too.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (LOGMGR-171) Add a PlatformLoggingMXBean implementation
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-171?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-171:
--------------------------------------
This actually might not be replaceable the more I look at the implementation details. I thought it would working using the standard {{ServiceLoader}} SPI. However this does not seem to be the case. In OpenJDK 8 this always seems to use the {{java.util.logging.LoggingProxyImpl}} which delegates to the {{LogManager.getLoggingMXBean()}}. Currently the {{org.jboss.logmanager.LogManager}} hacks doesn't seem to be setting the correct bean.
While looking at this it does look like {{org.jboss.logmanager.LogManager}} doesn't fully adhere to the {{java.util.logging.LogManager}} contract. At least for the {{getLogger()}} and {{getParentLogger()}} methods. At this point it's likely something we can't change, but it also means the contracts for the {{PlatformLoggingMXBean}} are also incorrect unless there is a way to actually override the default implementation.
> Add a PlatformLoggingMXBean implementation
> ------------------------------------------
>
> Key: LOGMGR-171
> URL: https://issues.jboss.org/browse/LOGMGR-171
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Reporter: James Perkins
> Assignee: James Perkins
>
> The {{LoggingMXBean}} is deprecated in Java 9. The {{PlatformLoggingMXBean}} has been available since Java 7 and should be implemented to be better context aware for JBoss Log Manager.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos edited comment on WFLY-8954 at 8/31/17 12:14 PM:
-----------------------------------------------------------------------
Hi,
As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from...
This branch is called:
WFLY-8954-from-master
I do not have a big time window available to me.
But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components.
And see where I might be bale to override functionality to what you suggest.
The following image is a basic class diagram with the core components that may have to be hacked/overriden to address this issue.
https://drive.google.com/open?id=0B_dEiNBGUsxqX1k1T3pqak1FSnc
Ok, I supect tha to get a hold of the TransactionSynchronizationRegistry we should be using.
I setup a smal rest service to return me the output of:
{panel}
(TransactionSynchronizationRegistry) initContext
.doLookup("java:comp/TransactionSynchronizationRegistry");
{panel}
I get a good result.
{panel}
{"value":{"type":"string","value":"The lookup returned: org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper@edacee0 \r\n timeToRunJndiLookup: 0 ms"}}
{panel}
The jndi lookup looks fast, cannot be measured in ms. If it is always like this it is perfect.
Let us see how the fishing goes.
Many thanks.
was (Author: nuno.godinhomatos):
Hi,
As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from...
This branch is called:
WFLY-8954-from-master
I do not have a big time window available to me.
But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components.
And see where I might be bale to override functionality to what you suggest.
The following image is a basic class diagram with the core components that may have to be hacked/overriden to address this issue.
https://drive.google.com/open?id=0B_dEiNBGUsxqX1k1T3pqak1FSnc
Ok, I supect tha to get a hold of the TransactionSynchronizationRegistry we should be using.
I setup a smal rest service to return me the output of:
{panel}
(TransactionSynchronizationRegistry) initContext
.doLookup("java:comp/TransactionSynchronizationRegistry");
{panel}
I get a good result.
{panel}
{"value":{"type":"string","value":"The lookup returned: org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper@edacee0 "}}
{panel}
Hopefully these jndi lookups within the container are fast.
I have noticed that the MBean server in wildfly, when I clean queus on active MQ is significantly slower than on weblogic. So I am a bit afraid of expensive calls to get resources...
The rest call is taking me 22 ms, on average ... the timing here is too expensive.
Let us see how the fishing goes.
Many thanks.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-9053) AbstractMethodError with Hibernate 5.2
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/WFLY-9053?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on WFLY-9053:
---------------------------------------
[~heruan] the version change I applied has some additional consequences, in particular it now pulls in the JipiJapa integration from WF11. Previously it would bundle the integration component meant for WF10, which was causing the exception you described.
[~andrei.ivanov] excellent question: this has been a very hard choice indeed. The WildFly project is very strict about backwards compatibility, but in the update of Hibernate ORM from 5.1 to 5.2 we had to break one single method's signature.
This change was essential for us (Hibernate team) as we're working on long term improvements and paving the road for very nice improvements in ORM 6, so after much debate we decided that breaking one single method was a reasonable compromise for our users. Since we understand it's not acceptable for everyone, we'll be maintaining 5.1 as well. You can effectively think 5.2 as a stepping stone in preparation for 6.
The "deal breaker" change can be found here:
https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 Search for {{getFlushMode}}.
There are often many more changes of course, but this one affects public API and we believe it might be used quite frequently.
> AbstractMethodError with Hibernate 5.2
> --------------------------------------
>
> Key: WFLY-9053
> URL: https://issues.jboss.org/browse/WFLY-9053
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Giovanni Lovato
> Assignee: Scott Marlow
>
> I'm deploying an EAR specifying in its {{persistence.xml}} to use Hibernate 5.2 as JPA provider:
> {code:xml}
> <property name="jboss.as.jpa.providerModule" value="org.hibernate:5.2" />
> {code}
> Hibernate 5.2 modules are placed in the {{modules}} directory.
> This configuration works in 10.1.0.Final but in 11.0.0.Alpha1 I get this error at deployment:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "oss-application-ear-1.0.0.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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.AbstractMethodError: org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.beanManagerLifeCycle(Ljavax/enterprise/inject/spi/BeanManager;)Ljava/lang/Object;
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.<init>(PhaseOnePersistenceUnitServiceImpl.java:89)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseOne(PersistenceUnitServiceHandler.java:485)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:279)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleEarDeployment(PersistenceUnitServiceHandler.java:228)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:135)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos edited comment on WFLY-8954 at 8/31/17 11:58 AM:
-----------------------------------------------------------------------
Hi,
As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from...
This branch is called:
WFLY-8954-from-master
I do not have a big time window available to me.
But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components.
And see where I might be bale to override functionality to what you suggest.
The following image is a basic class diagram with the core components that may have to be hacked/overriden to address this issue.
https://drive.google.com/open?id=0B_dEiNBGUsxqX1k1T3pqak1FSnc
Ok, I supect tha to get a hold of the TransactionSynchronizationRegistry we should be using.
I setup a smal rest service to return me the output of:
{panel}
(TransactionSynchronizationRegistry) initContext
.doLookup("java:comp/TransactionSynchronizationRegistry");
{panel}
I get a good result.
{panel}
{"value":{"type":"string","value":"The lookup returned: org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper@edacee0 "}}
{panel}
Hopefully these jndi lookups within the container are fast.
I have noticed that the MBean server in wildfly, when I clean queus on active MQ is significantly slower than on weblogic. So I am a bit afraid of expensive calls to get resources...
The rest call is taking me 22 ms, on average ... the timing here is too expensive.
Let us see how the fishing goes.
Many thanks.
was (Author: nuno.godinhomatos):
Hi,
As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from...
This branch is called:
WFLY-8954-from-master
I do not have a big time window available to me.
But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components.
And see where I might be bale to override functionality to what you suggest.
The following image is a basic class diagram with the core components that may have to be hacked/overriden to address this issue.
https://drive.google.com/open?id=0B_dEiNBGUsxqX1k1T3pqak1FSnc
Let us see how the fishing goes.
Many thanks.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos edited comment on WFLY-8954 at 8/31/17 11:31 AM:
-----------------------------------------------------------------------
Hi,
As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from...
This branch is called:
WFLY-8954-from-master
I do not have a big time window available to me.
But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components.
And see where I might be bale to override functionality to what you suggest.
The following image is a basic class diagram with the core components that may have to be hacked/overriden to address this issue.
https://drive.google.com/open?id=0B_dEiNBGUsxqX1k1T3pqak1FSnc
Let us see how the fishing goes.
Many thanks.
was (Author: nuno.godinhomatos):
Hi,
As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from...
This branch is called:
WFLY-8954-from-master
I do not have a big time window available to me.
But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components.
And see where I might be bale to override functionality to what you suggest.
Let us see how the fishing goes.
Many thanks.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3215) Enhance CLI to support Aesh Commands
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3215:
----------------------------------------
Summary: Enhance CLI to support Aesh Commands
Key: WFCORE-3215
URL: https://issues.jboss.org/browse/WFCORE-3215
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
In order to modernize the way to develop CLI commands, CLI needs to support commands developed with aesh 1.0 API. Aesh has been recently re-architectured to expose a Command Runtime that we can integrate in CLI.
The first immediate benefit of this integration is the ability to load aesh based commands exposed by extensions.
The patch command should be a candidate to validate this integration of aesh commands.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months