[JBoss JIRA] (WFWIP-53) Differences in ORM exception handling in 5.1 vs 5.3
by Martin Simka (JIRA)
Martin Simka created WFWIP-53:
---------------------------------
Summary: Differences in ORM exception handling in 5.1 vs 5.3
Key: WFWIP-53
URL: https://issues.jboss.org/browse/WFWIP-53
Project: WildFly WIP
Issue Type: Bug
Components: JPA
Reporter: Martin Simka
Assignee: Gail Badner
Priority: Blocker
I see tests failing because {{org.hibernate.hql.internal.ast.QuerySyntaxException}} is wrapped {{java.lang.IllegalArgumentException}}. I know this has been discussed on hibernate-dev mailing but without any outcome.
http://lists.jboss.org/pipermail/hibernate-dev/2018-May/017654.html
{quote}
I've been looking at differences in Hibernate exception handling for
applications that uses "native" (non-JPA) Hibernate when moving from 5.1 to
5.3.
As you know, exception handling changed in 5.2 when hibernate-entitymanager
was merged into hibernate-core. This change is documented in the 5.2
migration guide. [1]
Here is the relevant text:
"org.hibernate.HibernateException now extends
javax.persistence.PersistenceExceptions.
Hibernate methods that "override" methods from their JPA counterparts now
will also throw various JDK defined RuntimeExceptions (such as
IllegalArgumentException, IllegalStateException, etc) as required by the
JPA contract."
While digging into this, I see that a HibernateException thrown when using
5.1 may, in 5.3, be unwrapped, or may be wrapped by a PersistenceException
(or a subclass), IllegalArgumentException, or IllegalStateException,
depending on the particular operation being performed when the
HibernateException is thrown.
The reason why the exceptions may be wrapped or unwrapped is because
Hibernate converts exceptions (via
AbstractSharedSessionContract#exceptionConverter)
for JPA operations which may wrap the HibernateException or throw a
different exception. Hibernate does not convert exceptions from strictly
"native" operations, so those exceptions remain unwrapped.
Here are a couple of examples to illustrate:
1) A HibernateException (org.hibernate.TransientObjectException) was thrown
in 5.1. In 5.3, the same condition can result in
org.hibernate.TransientObjectException
that is either unwrapped, or wrapped by IllegalStateException. I've pushed
a test to my fork to illustrate. [2]
Thrown during Session#save, #saveOrUpdate
In 5.1: org.hibernate.TransientObjectException (unwrapped)
In 5.3: org.hibernate.TransientObjectException (unwrapped)
Thrown during Session#persist, #merge, #flush
In 5.1, org.hibernate.TransientObjectException (unwrapped)
In 5.3, org.hibernate.TransientObjectException wrapped by
IllegalStateException
2) A HibernateException thrown when using 5.1 may be wrapped by a
PersistenceException, even though HibernateException already extends
PersistenceException.
For example, see TransactionTimeoutTest#testTransactionTimeoutFailure:
https://github.com/hibernate/hibernate-orm/blob/master/
hibernate-core/src/test/java/org/hibernate/test/tm/
TransactionTimeoutTest.java#L60-L82
The exception thrown by the test indicates that the transaction timed out.
This exception is important enough that an application might retry the
operation, or at least log for future investigation.
Thrown during Session#persist (or when changed to use Session#merge or
Session#flush):
In 5.1: org.hibernate.TransactionException (unwrapped)
In 5.3: org.hibernate.TransactionException wrapped by javax.persistence.
PersistenceException
Thrown if the test is changed to use Session#save or #saveOrUpdate instead:
In 5.1: org.hibernate.TransactionException (unwrapped)
In 5.3: org.hibernate.TransactionException (unwrapped)
Similarly, by adding some logging, I see that HibernateException objects
can be wrapped by PersistenceException when running the 5.3 hibernate-core
unit tests. Depending on the context, I see that some of the following
exceptions can be wrapped or unwrapped.
org.hibernate.exception.ConstraintViolationException
org.hibernate.exception.DataException
org.hibernate.exception.GenericJDBCException
org.hibernate.exception.SQLGrammarException
org.hibernate.id.IdentifierGenerationException
org.hibernate.loader.custom.NonUniqueDiscoveredSqlAliasException
org.hibernate.PersistentObjectException
org.hibernate.PropertyAccessException
org.hibernate.PropertyValueException
org.hibernate.TransactionException
You can see an example using
org.hibernate.exception.ConstraintViolationException
at [3].
In order to deal with these differences, an application could change the
following (which was appropriate for 5.1):
try {
...
}
catch (HibernateException ex) {
procressHibernateException( ex );
}
to the following for 5.3:
try {
...
}
catch (PersistenceException | IllegalStateException |
IllegalArgumentException ex) {
if ( HibernateException.class.isInstance( ex ) ) {
handleHibernateException( (HibernateException) ex );
}
else if ( HibernateException.class.isInstance( ex.getCause() ) ) {
handleHibernateException( (HibernateException) ex.getCause() );
}
}
IMO, it's a little clumsy having to deal with both wrapped and unwrapped
exceptions. It would be better if exceptions were consistently wrapped, or
consistently unwrapped.
I haven't had much of a chance to think about how we can deal with this,
but one thing that comes to mind is to allow an application to choose a
particular ExceptionConverter implementation. Hibernate would need to be
changed to always convert exceptions (including for strictly native
operations) before returning to the application.
For example, a property, hibernate.exception_converter could be added with
the following values:
jpa - default for JPA applications (org.hibernate.internal.
ExceptionConverterImpl)
native (or legacy?) - default for native applications that does not wrap
HibernateException
fully-qualified class name that implements ExceptionConverter
If users have to make changes to exception handling for 5.3, do you think
they would be willing to change their application to use JPA exceptions
(i.e., hibernate.exception_converter=jpa)?
Comments?
Regards,
Gail
[1] https://github.com/hibernate/hibernate-orm/blob/5.2/migration-guide.adoc
[2] https://github.com/gbadner/hibernate-core/blob/exception-
compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
ORMTransientObjectExceptionUnitTestCase.java
[3] https://github.com/gbadner/hibernate-core/blob/exception-
compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
ORMConstraintViolationExceptionUnitTestCase.java
{quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFWIP-53) Differences in ORM exception handling in 5.1 vs 5.3
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFWIP-53?page=com.atlassian.jira.plugin.s... ]
Martin Simka updated WFWIP-53:
------------------------------
Description:
I see tests failing because {{org.hibernate.hql.internal.ast.QuerySyntaxException}} is wrapped by {{java.lang.IllegalArgumentException}}. I know this has been discussed on hibernate-dev mailing but without any outcome.
http://lists.jboss.org/pipermail/hibernate-dev/2018-May/017654.html
{quote}
I've been looking at differences in Hibernate exception handling for
applications that uses "native" (non-JPA) Hibernate when moving from 5.1 to
5.3.
As you know, exception handling changed in 5.2 when hibernate-entitymanager
was merged into hibernate-core. This change is documented in the 5.2
migration guide. [1]
Here is the relevant text:
"org.hibernate.HibernateException now extends
javax.persistence.PersistenceExceptions.
Hibernate methods that "override" methods from their JPA counterparts now
will also throw various JDK defined RuntimeExceptions (such as
IllegalArgumentException, IllegalStateException, etc) as required by the
JPA contract."
While digging into this, I see that a HibernateException thrown when using
5.1 may, in 5.3, be unwrapped, or may be wrapped by a PersistenceException
(or a subclass), IllegalArgumentException, or IllegalStateException,
depending on the particular operation being performed when the
HibernateException is thrown.
The reason why the exceptions may be wrapped or unwrapped is because
Hibernate converts exceptions (via
AbstractSharedSessionContract#exceptionConverter)
for JPA operations which may wrap the HibernateException or throw a
different exception. Hibernate does not convert exceptions from strictly
"native" operations, so those exceptions remain unwrapped.
Here are a couple of examples to illustrate:
1) A HibernateException (org.hibernate.TransientObjectException) was thrown
in 5.1. In 5.3, the same condition can result in
org.hibernate.TransientObjectException
that is either unwrapped, or wrapped by IllegalStateException. I've pushed
a test to my fork to illustrate. [2]
Thrown during Session#save, #saveOrUpdate
In 5.1: org.hibernate.TransientObjectException (unwrapped)
In 5.3: org.hibernate.TransientObjectException (unwrapped)
Thrown during Session#persist, #merge, #flush
In 5.1, org.hibernate.TransientObjectException (unwrapped)
In 5.3, org.hibernate.TransientObjectException wrapped by
IllegalStateException
2) A HibernateException thrown when using 5.1 may be wrapped by a
PersistenceException, even though HibernateException already extends
PersistenceException.
For example, see TransactionTimeoutTest#testTransactionTimeoutFailure:
https://github.com/hibernate/hibernate-orm/blob/master/
hibernate-core/src/test/java/org/hibernate/test/tm/
TransactionTimeoutTest.java#L60-L82
The exception thrown by the test indicates that the transaction timed out.
This exception is important enough that an application might retry the
operation, or at least log for future investigation.
Thrown during Session#persist (or when changed to use Session#merge or
Session#flush):
In 5.1: org.hibernate.TransactionException (unwrapped)
In 5.3: org.hibernate.TransactionException wrapped by javax.persistence.
PersistenceException
Thrown if the test is changed to use Session#save or #saveOrUpdate instead:
In 5.1: org.hibernate.TransactionException (unwrapped)
In 5.3: org.hibernate.TransactionException (unwrapped)
Similarly, by adding some logging, I see that HibernateException objects
can be wrapped by PersistenceException when running the 5.3 hibernate-core
unit tests. Depending on the context, I see that some of the following
exceptions can be wrapped or unwrapped.
org.hibernate.exception.ConstraintViolationException
org.hibernate.exception.DataException
org.hibernate.exception.GenericJDBCException
org.hibernate.exception.SQLGrammarException
org.hibernate.id.IdentifierGenerationException
org.hibernate.loader.custom.NonUniqueDiscoveredSqlAliasException
org.hibernate.PersistentObjectException
org.hibernate.PropertyAccessException
org.hibernate.PropertyValueException
org.hibernate.TransactionException
You can see an example using
org.hibernate.exception.ConstraintViolationException
at [3].
In order to deal with these differences, an application could change the
following (which was appropriate for 5.1):
try {
...
}
catch (HibernateException ex) {
procressHibernateException( ex );
}
to the following for 5.3:
try {
...
}
catch (PersistenceException | IllegalStateException |
IllegalArgumentException ex) {
if ( HibernateException.class.isInstance( ex ) ) {
handleHibernateException( (HibernateException) ex );
}
else if ( HibernateException.class.isInstance( ex.getCause() ) ) {
handleHibernateException( (HibernateException) ex.getCause() );
}
}
IMO, it's a little clumsy having to deal with both wrapped and unwrapped
exceptions. It would be better if exceptions were consistently wrapped, or
consistently unwrapped.
I haven't had much of a chance to think about how we can deal with this,
but one thing that comes to mind is to allow an application to choose a
particular ExceptionConverter implementation. Hibernate would need to be
changed to always convert exceptions (including for strictly native
operations) before returning to the application.
For example, a property, hibernate.exception_converter could be added with
the following values:
jpa - default for JPA applications (org.hibernate.internal.
ExceptionConverterImpl)
native (or legacy?) - default for native applications that does not wrap
HibernateException
fully-qualified class name that implements ExceptionConverter
If users have to make changes to exception handling for 5.3, do you think
they would be willing to change their application to use JPA exceptions
(i.e., hibernate.exception_converter=jpa)?
Comments?
Regards,
Gail
[1] https://github.com/hibernate/hibernate-orm/blob/5.2/migration-guide.adoc
[2] https://github.com/gbadner/hibernate-core/blob/exception-
compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
ORMTransientObjectExceptionUnitTestCase.java
[3] https://github.com/gbadner/hibernate-core/blob/exception-
compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
ORMConstraintViolationExceptionUnitTestCase.java
{quote}
was:
I see tests failing because {{org.hibernate.hql.internal.ast.QuerySyntaxException}} is wrapped {{java.lang.IllegalArgumentException}}. I know this has been discussed on hibernate-dev mailing but without any outcome.
http://lists.jboss.org/pipermail/hibernate-dev/2018-May/017654.html
{quote}
I've been looking at differences in Hibernate exception handling for
applications that uses "native" (non-JPA) Hibernate when moving from 5.1 to
5.3.
As you know, exception handling changed in 5.2 when hibernate-entitymanager
was merged into hibernate-core. This change is documented in the 5.2
migration guide. [1]
Here is the relevant text:
"org.hibernate.HibernateException now extends
javax.persistence.PersistenceExceptions.
Hibernate methods that "override" methods from their JPA counterparts now
will also throw various JDK defined RuntimeExceptions (such as
IllegalArgumentException, IllegalStateException, etc) as required by the
JPA contract."
While digging into this, I see that a HibernateException thrown when using
5.1 may, in 5.3, be unwrapped, or may be wrapped by a PersistenceException
(or a subclass), IllegalArgumentException, or IllegalStateException,
depending on the particular operation being performed when the
HibernateException is thrown.
The reason why the exceptions may be wrapped or unwrapped is because
Hibernate converts exceptions (via
AbstractSharedSessionContract#exceptionConverter)
for JPA operations which may wrap the HibernateException or throw a
different exception. Hibernate does not convert exceptions from strictly
"native" operations, so those exceptions remain unwrapped.
Here are a couple of examples to illustrate:
1) A HibernateException (org.hibernate.TransientObjectException) was thrown
in 5.1. In 5.3, the same condition can result in
org.hibernate.TransientObjectException
that is either unwrapped, or wrapped by IllegalStateException. I've pushed
a test to my fork to illustrate. [2]
Thrown during Session#save, #saveOrUpdate
In 5.1: org.hibernate.TransientObjectException (unwrapped)
In 5.3: org.hibernate.TransientObjectException (unwrapped)
Thrown during Session#persist, #merge, #flush
In 5.1, org.hibernate.TransientObjectException (unwrapped)
In 5.3, org.hibernate.TransientObjectException wrapped by
IllegalStateException
2) A HibernateException thrown when using 5.1 may be wrapped by a
PersistenceException, even though HibernateException already extends
PersistenceException.
For example, see TransactionTimeoutTest#testTransactionTimeoutFailure:
https://github.com/hibernate/hibernate-orm/blob/master/
hibernate-core/src/test/java/org/hibernate/test/tm/
TransactionTimeoutTest.java#L60-L82
The exception thrown by the test indicates that the transaction timed out.
This exception is important enough that an application might retry the
operation, or at least log for future investigation.
Thrown during Session#persist (or when changed to use Session#merge or
Session#flush):
In 5.1: org.hibernate.TransactionException (unwrapped)
In 5.3: org.hibernate.TransactionException wrapped by javax.persistence.
PersistenceException
Thrown if the test is changed to use Session#save or #saveOrUpdate instead:
In 5.1: org.hibernate.TransactionException (unwrapped)
In 5.3: org.hibernate.TransactionException (unwrapped)
Similarly, by adding some logging, I see that HibernateException objects
can be wrapped by PersistenceException when running the 5.3 hibernate-core
unit tests. Depending on the context, I see that some of the following
exceptions can be wrapped or unwrapped.
org.hibernate.exception.ConstraintViolationException
org.hibernate.exception.DataException
org.hibernate.exception.GenericJDBCException
org.hibernate.exception.SQLGrammarException
org.hibernate.id.IdentifierGenerationException
org.hibernate.loader.custom.NonUniqueDiscoveredSqlAliasException
org.hibernate.PersistentObjectException
org.hibernate.PropertyAccessException
org.hibernate.PropertyValueException
org.hibernate.TransactionException
You can see an example using
org.hibernate.exception.ConstraintViolationException
at [3].
In order to deal with these differences, an application could change the
following (which was appropriate for 5.1):
try {
...
}
catch (HibernateException ex) {
procressHibernateException( ex );
}
to the following for 5.3:
try {
...
}
catch (PersistenceException | IllegalStateException |
IllegalArgumentException ex) {
if ( HibernateException.class.isInstance( ex ) ) {
handleHibernateException( (HibernateException) ex );
}
else if ( HibernateException.class.isInstance( ex.getCause() ) ) {
handleHibernateException( (HibernateException) ex.getCause() );
}
}
IMO, it's a little clumsy having to deal with both wrapped and unwrapped
exceptions. It would be better if exceptions were consistently wrapped, or
consistently unwrapped.
I haven't had much of a chance to think about how we can deal with this,
but one thing that comes to mind is to allow an application to choose a
particular ExceptionConverter implementation. Hibernate would need to be
changed to always convert exceptions (including for strictly native
operations) before returning to the application.
For example, a property, hibernate.exception_converter could be added with
the following values:
jpa - default for JPA applications (org.hibernate.internal.
ExceptionConverterImpl)
native (or legacy?) - default for native applications that does not wrap
HibernateException
fully-qualified class name that implements ExceptionConverter
If users have to make changes to exception handling for 5.3, do you think
they would be willing to change their application to use JPA exceptions
(i.e., hibernate.exception_converter=jpa)?
Comments?
Regards,
Gail
[1] https://github.com/hibernate/hibernate-orm/blob/5.2/migration-guide.adoc
[2] https://github.com/gbadner/hibernate-core/blob/exception-
compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
ORMTransientObjectExceptionUnitTestCase.java
[3] https://github.com/gbadner/hibernate-core/blob/exception-
compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
ORMConstraintViolationExceptionUnitTestCase.java
{quote}
> Differences in ORM exception handling in 5.1 vs 5.3
> ---------------------------------------------------
>
> Key: WFWIP-53
> URL: https://issues.jboss.org/browse/WFWIP-53
> Project: WildFly WIP
> Issue Type: Bug
> Components: JPA
> Reporter: Martin Simka
> Assignee: Gail Badner
> Priority: Blocker
>
> I see tests failing because {{org.hibernate.hql.internal.ast.QuerySyntaxException}} is wrapped by {{java.lang.IllegalArgumentException}}. I know this has been discussed on hibernate-dev mailing but without any outcome.
> http://lists.jboss.org/pipermail/hibernate-dev/2018-May/017654.html
> {quote}
> I've been looking at differences in Hibernate exception handling for
> applications that uses "native" (non-JPA) Hibernate when moving from 5.1 to
> 5.3.
> As you know, exception handling changed in 5.2 when hibernate-entitymanager
> was merged into hibernate-core. This change is documented in the 5.2
> migration guide. [1]
> Here is the relevant text:
> "org.hibernate.HibernateException now extends
> javax.persistence.PersistenceExceptions.
> Hibernate methods that "override" methods from their JPA counterparts now
> will also throw various JDK defined RuntimeExceptions (such as
> IllegalArgumentException, IllegalStateException, etc) as required by the
> JPA contract."
> While digging into this, I see that a HibernateException thrown when using
> 5.1 may, in 5.3, be unwrapped, or may be wrapped by a PersistenceException
> (or a subclass), IllegalArgumentException, or IllegalStateException,
> depending on the particular operation being performed when the
> HibernateException is thrown.
> The reason why the exceptions may be wrapped or unwrapped is because
> Hibernate converts exceptions (via
> AbstractSharedSessionContract#exceptionConverter)
> for JPA operations which may wrap the HibernateException or throw a
> different exception. Hibernate does not convert exceptions from strictly
> "native" operations, so those exceptions remain unwrapped.
> Here are a couple of examples to illustrate:
> 1) A HibernateException (org.hibernate.TransientObjectException) was thrown
> in 5.1. In 5.3, the same condition can result in
> org.hibernate.TransientObjectException
> that is either unwrapped, or wrapped by IllegalStateException. I've pushed
> a test to my fork to illustrate. [2]
> Thrown during Session#save, #saveOrUpdate
> In 5.1: org.hibernate.TransientObjectException (unwrapped)
> In 5.3: org.hibernate.TransientObjectException (unwrapped)
> Thrown during Session#persist, #merge, #flush
> In 5.1, org.hibernate.TransientObjectException (unwrapped)
> In 5.3, org.hibernate.TransientObjectException wrapped by
> IllegalStateException
> 2) A HibernateException thrown when using 5.1 may be wrapped by a
> PersistenceException, even though HibernateException already extends
> PersistenceException.
> For example, see TransactionTimeoutTest#testTransactionTimeoutFailure:
> https://github.com/hibernate/hibernate-orm/blob/master/
> hibernate-core/src/test/java/org/hibernate/test/tm/
> TransactionTimeoutTest.java#L60-L82
> The exception thrown by the test indicates that the transaction timed out.
> This exception is important enough that an application might retry the
> operation, or at least log for future investigation.
> Thrown during Session#persist (or when changed to use Session#merge or
> Session#flush):
> In 5.1: org.hibernate.TransactionException (unwrapped)
> In 5.3: org.hibernate.TransactionException wrapped by javax.persistence.
> PersistenceException
> Thrown if the test is changed to use Session#save or #saveOrUpdate instead:
> In 5.1: org.hibernate.TransactionException (unwrapped)
> In 5.3: org.hibernate.TransactionException (unwrapped)
> Similarly, by adding some logging, I see that HibernateException objects
> can be wrapped by PersistenceException when running the 5.3 hibernate-core
> unit tests. Depending on the context, I see that some of the following
> exceptions can be wrapped or unwrapped.
> org.hibernate.exception.ConstraintViolationException
> org.hibernate.exception.DataException
> org.hibernate.exception.GenericJDBCException
> org.hibernate.exception.SQLGrammarException
> org.hibernate.id.IdentifierGenerationException
> org.hibernate.loader.custom.NonUniqueDiscoveredSqlAliasException
> org.hibernate.PersistentObjectException
> org.hibernate.PropertyAccessException
> org.hibernate.PropertyValueException
> org.hibernate.TransactionException
> You can see an example using
> org.hibernate.exception.ConstraintViolationException
> at [3].
> In order to deal with these differences, an application could change the
> following (which was appropriate for 5.1):
> try {
> ...
> }
> catch (HibernateException ex) {
> procressHibernateException( ex );
> }
> to the following for 5.3:
> try {
> ...
> }
> catch (PersistenceException | IllegalStateException |
> IllegalArgumentException ex) {
> if ( HibernateException.class.isInstance( ex ) ) {
> handleHibernateException( (HibernateException) ex );
> }
> else if ( HibernateException.class.isInstance( ex.getCause() ) ) {
> handleHibernateException( (HibernateException) ex.getCause() );
> }
> }
> IMO, it's a little clumsy having to deal with both wrapped and unwrapped
> exceptions. It would be better if exceptions were consistently wrapped, or
> consistently unwrapped.
> I haven't had much of a chance to think about how we can deal with this,
> but one thing that comes to mind is to allow an application to choose a
> particular ExceptionConverter implementation. Hibernate would need to be
> changed to always convert exceptions (including for strictly native
> operations) before returning to the application.
> For example, a property, hibernate.exception_converter could be added with
> the following values:
> jpa - default for JPA applications (org.hibernate.internal.
> ExceptionConverterImpl)
> native (or legacy?) - default for native applications that does not wrap
> HibernateException
> fully-qualified class name that implements ExceptionConverter
> If users have to make changes to exception handling for 5.3, do you think
> they would be willing to change their application to use JPA exceptions
> (i.e., hibernate.exception_converter=jpa)?
> Comments?
> Regards,
> Gail
> [1] https://github.com/hibernate/hibernate-orm/blob/5.2/migration-guide.adoc
> [2] https://github.com/gbadner/hibernate-core/blob/exception-
> compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
> ORMTransientObjectExceptionUnitTestCase.java
> [3] https://github.com/gbadner/hibernate-core/blob/exception-
> compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
> ORMConstraintViolationExceptionUnitTestCase.java
> {quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski updated WFLY-10280:
--------------------------------------
Workaround Description: (was: set "default-sfsb-cache" after ejb3:remote removal
)
> Can't enable stateful EJB passivation when EJB remote service is removed
> ------------------------------------------------------------------------
>
> Key: WFLY-10280
> URL: https://issues.jboss.org/browse/WFLY-10280
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Bartosz Baranowski
> Attachments: tinyEjbPassivation.war
>
>
> In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug.
> What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default).
> When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry:
> {code}
> 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START]
> service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService]
> service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager]
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski updated WFLY-10280:
--------------------------------------
Priority: Major (was: Minor)
> Can't enable stateful EJB passivation when EJB remote service is removed
> ------------------------------------------------------------------------
>
> Key: WFLY-10280
> URL: https://issues.jboss.org/browse/WFLY-10280
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Bartosz Baranowski
> Attachments: tinyEjbPassivation.war
>
>
> In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug.
> What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default).
> When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry:
> {code}
> 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START]
> service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService]
> service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager]
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2473) [DMN Designer] Function language change inconsistency
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2473?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-2473:
-----------------------------------
Sprint: 2018 Week 23-24
> [DMN Designer] Function language change inconsistency
> -----------------------------------------------------
>
> Key: DROOLS-2473
> URL: https://issues.jboss.org/browse/DROOLS-2473
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Attachments: Screenshot from 2018-04-13 09-13-54.png, Screenshot from 2018-04-13 09-14-00.png, Screenshot from 2018-04-13 09-14-14.png
>
>
> If the function language is changed, the boxed expression table is not rendered as expected.
> h2. PR Acceptance Test
> Change of function language is consistent in rendering
> - Empty function
> - Function with data
> - Function as boxed expression not at top level in the context hierarchy
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3937) Error when running configured wildfly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3937?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-3937 at 6/20/18 3:13 AM:
-------------------------------------------------------------------
The problem is the 'docker build' is creating the standalone_xml_history because it is modifying the config:
{code}
$ docker build -t testing .
Sending build context to Docker daemon 3.026MB
Step 1/2 : FROM jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508: Pulling from jboss/wildfly
469cfcc7a4b3: Already exists
05677e4d61f0: Pull complete
a9520f492457: Pull complete
4d201219d6b1: Pull complete
ea67bbe40b46: Pull complete
Digest: sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
Status: Downloaded newer image for jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
---> be0490eb815b
Step 2/2 : RUN ./wildfly/bin/jboss-cli.sh "embed-server --std-out=echo, /system-property=ee8.preview.mode:add(value=true)"
---> Running in 292ca65b3250
06:26:29,382 INFO [org.jboss.modules] (CLI command executor) JBoss Modules version 1.8.5.Final
06:26:29,450 INFO [org.jboss.msc] (CLI command executor) JBoss MSC version 1.4.2.Final
06:26:29,462 INFO [org.jboss.threads] (CLI command executor) JBoss Threads version 2.3.2.Final
06:26:29,659 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) starting
06:26:31,279 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
06:26:31,309 INFO [org.wildfly.security] (Controller Boot Thread) ELY00001: WildFly Elytron version 1.3.3.Final
06:26:31,366 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
06:26:31,512 INFO [org.jboss.as.patching] (MSC service thread 1-5) WFLYPAT0050: WildFly Full cumulative patch ID is: base, one-off patches include: none
06:26:31,529 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /opt/jboss/wildfly/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
06:26:31,629 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
06:26:31,631 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) started in 2241ms - Started 66 of 80 services (25 services are lazy, passive or on-demand)
{"outcome" => "success"}
06:26:32,244 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) stopped in 18ms
---> a0c206670dde
Removing intermediate container 292ca65b3250
Successfully built a0c206670dde
Successfully tagged testing:latest
{code}
Solution is to clean that up in the Dockerfile:
{code}
FROM jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
RUN ./wildfly/bin/jboss-cli.sh "embed-server --std-out=echo, \
/system-property=ee8.preview.mode:add(value=true)"
RUN rm -rf ./wildfly/standalone/configuration/standalone_xml_history
{code}
[~jmesnil] Perhaps server boot should include a --no-history option and the CLI embed-server command could expose that as a param in order to make it easier to do this kind of thing. (N.B. --read-only-server-config and --no-history would conflict somewhat, as without history things like reload cannot work with a --read-only-server-config server.)
was (Author: brian.stansberry):
The problem is the 'docker build' is creating the standalone_xml_history because it is modifying the config:
{code}
y$ docker build -t testing .
Sending build context to Docker daemon 3.026MB
Step 1/2 : FROM jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508: Pulling from jboss/wildfly
469cfcc7a4b3: Already exists
05677e4d61f0: Pull complete
a9520f492457: Pull complete
4d201219d6b1: Pull complete
ea67bbe40b46: Pull complete
Digest: sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
Status: Downloaded newer image for jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
---> be0490eb815b
Step 2/2 : RUN ./wildfly/bin/jboss-cli.sh "embed-server --std-out=echo, /system-property=ee8.preview.mode:add(value=true)"
---> Running in 292ca65b3250
06:26:29,382 INFO [org.jboss.modules] (CLI command executor) JBoss Modules version 1.8.5.Final
06:26:29,450 INFO [org.jboss.msc] (CLI command executor) JBoss MSC version 1.4.2.Final
06:26:29,462 INFO [org.jboss.threads] (CLI command executor) JBoss Threads version 2.3.2.Final
06:26:29,659 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) starting
06:26:31,279 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
06:26:31,309 INFO [org.wildfly.security] (Controller Boot Thread) ELY00001: WildFly Elytron version 1.3.3.Final
06:26:31,366 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
06:26:31,512 INFO [org.jboss.as.patching] (MSC service thread 1-5) WFLYPAT0050: WildFly Full cumulative patch ID is: base, one-off patches include: none
06:26:31,529 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /opt/jboss/wildfly/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
06:26:31,629 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
06:26:31,631 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) started in 2241ms - Started 66 of 80 services (25 services are lazy, passive or on-demand)
{"outcome" => "success"}
06:26:32,244 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) stopped in 18ms
---> a0c206670dde
Removing intermediate container 292ca65b3250
Successfully built a0c206670dde
Successfully tagged testing:latest
{code}
Solution is to clean that up in the Dockerfile:
{code}
FROM jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
RUN ./wildfly/bin/jboss-cli.sh "embed-server --std-out=echo, \
/system-property=ee8.preview.mode:add(value=true)"
RUN rm -rf ./wildfly/standalone/configuration/standalone_xml_history
{code}
[~jmesnil] Perhaps server boot should include a --no-history option and the CLI embed-server command could expose that as a param in order to make it easier to do this kind of thing. (N.B. --read-only-server-config and --no-history would conflict somewhat, as without history things like reload cannot work with a --read-only-server-config server.)
> Error when running configured wildfly
> -------------------------------------
>
> Key: WFCORE-3937
> URL: https://issues.jboss.org/browse/WFCORE-3937
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 5.0.0.Final
> Reporter: Stephen Buergler
> Assignee: Jeff Mesnil
> Priority: Minor
> Attachments: Dockerfile
>
>
> 08:32:20,676 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0056: Could not rename /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current to /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/20180619-083220673: java.nio.file.DirectoryNotEmptyException: /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current
> ...
> 08:50:08,531 WARN [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0414: Could not create a timestamped backup of current history dir /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current, so it may still include versions from the previous boot.
> To reproduce:
> docker build -t testing .
> docker run --rm -it testing
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3937) Error when running configured wildfly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3937?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-3937 at 6/20/18 3:12 AM:
-------------------------------------------------------------------
The problem is the 'docker build' is creating the standalone_xml_history because it is modifying the config:
{code}
y$ docker build -t testing .
Sending build context to Docker daemon 3.026MB
Step 1/2 : FROM jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508: Pulling from jboss/wildfly
469cfcc7a4b3: Already exists
05677e4d61f0: Pull complete
a9520f492457: Pull complete
4d201219d6b1: Pull complete
ea67bbe40b46: Pull complete
Digest: sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
Status: Downloaded newer image for jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
---> be0490eb815b
Step 2/2 : RUN ./wildfly/bin/jboss-cli.sh "embed-server --std-out=echo, /system-property=ee8.preview.mode:add(value=true)"
---> Running in 292ca65b3250
06:26:29,382 INFO [org.jboss.modules] (CLI command executor) JBoss Modules version 1.8.5.Final
06:26:29,450 INFO [org.jboss.msc] (CLI command executor) JBoss MSC version 1.4.2.Final
06:26:29,462 INFO [org.jboss.threads] (CLI command executor) JBoss Threads version 2.3.2.Final
06:26:29,659 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) starting
06:26:31,279 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
06:26:31,309 INFO [org.wildfly.security] (Controller Boot Thread) ELY00001: WildFly Elytron version 1.3.3.Final
06:26:31,366 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
06:26:31,512 INFO [org.jboss.as.patching] (MSC service thread 1-5) WFLYPAT0050: WildFly Full cumulative patch ID is: base, one-off patches include: none
06:26:31,529 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /opt/jboss/wildfly/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
06:26:31,629 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
06:26:31,631 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) started in 2241ms - Started 66 of 80 services (25 services are lazy, passive or on-demand)
{"outcome" => "success"}
06:26:32,244 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) stopped in 18ms
---> a0c206670dde
Removing intermediate container 292ca65b3250
Successfully built a0c206670dde
Successfully tagged testing:latest
{code}
Solution is to clean that up in the Dockerfile:
{code}
FROM jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
RUN ./wildfly/bin/jboss-cli.sh "embed-server --std-out=echo, \
/system-property=ee8.preview.mode:add(value=true)"
RUN rm -rf ./wildfly/standalone/configuration/standalone_xml_history
{code}
[~jmesnil] Perhaps server boot should include a --no-history option and the CLI embed-server command could expose that as a param in order to make it easier to do this kind of thing. (N.B. --read-only-server-config and --no-history would conflict somewhat, as without history things like reload cannot work with a --read-only-server-config server.)
was (Author: brian.stansberry):
The problem is the 'docker build' is creating the standalone_xml_history because it is modifying the config:
```
y$ docker build -t testing .
Sending build context to Docker daemon 3.026MB
Step 1/2 : FROM jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508: Pulling from jboss/wildfly
469cfcc7a4b3: Already exists
05677e4d61f0: Pull complete
a9520f492457: Pull complete
4d201219d6b1: Pull complete
ea67bbe40b46: Pull complete
Digest: sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
Status: Downloaded newer image for jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
---> be0490eb815b
Step 2/2 : RUN ./wildfly/bin/jboss-cli.sh "embed-server --std-out=echo, /system-property=ee8.preview.mode:add(value=true)"
---> Running in 292ca65b3250
06:26:29,382 INFO [org.jboss.modules] (CLI command executor) JBoss Modules version 1.8.5.Final
06:26:29,450 INFO [org.jboss.msc] (CLI command executor) JBoss MSC version 1.4.2.Final
06:26:29,462 INFO [org.jboss.threads] (CLI command executor) JBoss Threads version 2.3.2.Final
06:26:29,659 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) starting
06:26:31,279 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
06:26:31,309 INFO [org.wildfly.security] (Controller Boot Thread) ELY00001: WildFly Elytron version 1.3.3.Final
06:26:31,366 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
06:26:31,512 INFO [org.jboss.as.patching] (MSC service thread 1-5) WFLYPAT0050: WildFly Full cumulative patch ID is: base, one-off patches include: none
06:26:31,529 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /opt/jboss/wildfly/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
06:26:31,629 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
06:26:31,631 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) started in 2241ms - Started 66 of 80 services (25 services are lazy, passive or on-demand)
{"outcome" => "success"}
06:26:32,244 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) stopped in 18ms
---> a0c206670dde
Removing intermediate container 292ca65b3250
Successfully built a0c206670dde
Successfully tagged testing:latest
```
Solution is to clean that up in the Dockerfile:
```
FROM jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
RUN ./wildfly/bin/jboss-cli.sh "embed-server --std-out=echo, \
/system-property=ee8.preview.mode:add(value=true)"
RUN rm -rf ./wildfly/standalone/configuration/standalone_xml_history
```
[~jmesnil] Perhaps server boot should include a --no-history option and the CLI embed-server command could expose that as a param in order to make it easier to do this kind of thing. (N.B. --read-only-server-config and --no-history would conflict somewhat, as without history things like reload cannot work with a --read-only-server-config server.)
> Error when running configured wildfly
> -------------------------------------
>
> Key: WFCORE-3937
> URL: https://issues.jboss.org/browse/WFCORE-3937
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 5.0.0.Final
> Reporter: Stephen Buergler
> Assignee: Jeff Mesnil
> Priority: Minor
> Attachments: Dockerfile
>
>
> 08:32:20,676 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0056: Could not rename /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current to /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/20180619-083220673: java.nio.file.DirectoryNotEmptyException: /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current
> ...
> 08:50:08,531 WARN [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0414: Could not create a timestamped backup of current history dir /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current, so it may still include versions from the previous boot.
> To reproduce:
> docker build -t testing .
> docker run --rm -it testing
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3937) Error when running configured wildfly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3937?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3937:
------------------------------------------
The problem is the 'docker build' is creating the standalone_xml_history because it is modifying the config:
```
y$ docker build -t testing .
Sending build context to Docker daemon 3.026MB
Step 1/2 : FROM jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508: Pulling from jboss/wildfly
469cfcc7a4b3: Already exists
05677e4d61f0: Pull complete
a9520f492457: Pull complete
4d201219d6b1: Pull complete
ea67bbe40b46: Pull complete
Digest: sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
Status: Downloaded newer image for jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
---> be0490eb815b
Step 2/2 : RUN ./wildfly/bin/jboss-cli.sh "embed-server --std-out=echo, /system-property=ee8.preview.mode:add(value=true)"
---> Running in 292ca65b3250
06:26:29,382 INFO [org.jboss.modules] (CLI command executor) JBoss Modules version 1.8.5.Final
06:26:29,450 INFO [org.jboss.msc] (CLI command executor) JBoss MSC version 1.4.2.Final
06:26:29,462 INFO [org.jboss.threads] (CLI command executor) JBoss Threads version 2.3.2.Final
06:26:29,659 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) starting
06:26:31,279 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
06:26:31,309 INFO [org.wildfly.security] (Controller Boot Thread) ELY00001: WildFly Elytron version 1.3.3.Final
06:26:31,366 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
06:26:31,512 INFO [org.jboss.as.patching] (MSC service thread 1-5) WFLYPAT0050: WildFly Full cumulative patch ID is: base, one-off patches include: none
06:26:31,529 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /opt/jboss/wildfly/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
06:26:31,629 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
06:26:31,631 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) started in 2241ms - Started 66 of 80 services (25 services are lazy, passive or on-demand)
{"outcome" => "success"}
06:26:32,244 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) stopped in 18ms
---> a0c206670dde
Removing intermediate container 292ca65b3250
Successfully built a0c206670dde
Successfully tagged testing:latest
```
Solution is to clean that up in the Dockerfile:
```
FROM jboss/wildfly:13.0.0.Final@sha256:5d667ce3a423eb0402d33730d2ceb6286bc2e245d187baeccda197d562f70508
RUN ./wildfly/bin/jboss-cli.sh "embed-server --std-out=echo, \
/system-property=ee8.preview.mode:add(value=true)"
RUN rm -rf ./wildfly/standalone/configuration/standalone_xml_history
```
[~jmesnil] Perhaps server boot should include a --no-history option and the CLI embed-server command could expose that as a param in order to make it easier to do this kind of thing. (N.B. --read-only-server-config and --no-history would conflict somewhat, as without history things like reload cannot work with a --read-only-server-config server.)
> Error when running configured wildfly
> -------------------------------------
>
> Key: WFCORE-3937
> URL: https://issues.jboss.org/browse/WFCORE-3937
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 5.0.0.Final
> Reporter: Stephen Buergler
> Assignee: Jeff Mesnil
> Priority: Minor
> Attachments: Dockerfile
>
>
> 08:32:20,676 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0056: Could not rename /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current to /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/20180619-083220673: java.nio.file.DirectoryNotEmptyException: /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current
> ...
> 08:50:08,531 WARN [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0414: Could not create a timestamped backup of current history dir /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current, so it may still include versions from the previous boot.
> To reproduce:
> docker build -t testing .
> docker run --rm -it testing
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3937) Error when running configured wildfly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3937?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-3937 at 6/20/18 2:53 AM:
-------------------------------------------------------------------
This works fine for me on my Macbook, docker version 17.09.1-ce-mac42 (which is fairly old as later versions of Docker had bug on OSX.) But Jeff has reproduced it so I'm just mentioning this as a data point.
Never mind; I got distracted and hadn't done the 'docker run --rm -it testing' step!
was (Author: brian.stansberry):
This works fine for me on my Macbook, docker version 17.09.1-ce-mac42 (which is fairly old as later versions of Docker had bug on OSX.) But Jeff has reproduced it so I'm just mentioning this as a data point.
> Error when running configured wildfly
> -------------------------------------
>
> Key: WFCORE-3937
> URL: https://issues.jboss.org/browse/WFCORE-3937
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 5.0.0.Final
> Reporter: Stephen Buergler
> Assignee: Jeff Mesnil
> Priority: Minor
> Attachments: Dockerfile
>
>
> 08:32:20,676 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0056: Could not rename /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current to /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/20180619-083220673: java.nio.file.DirectoryNotEmptyException: /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current
> ...
> 08:50:08,531 WARN [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0414: Could not create a timestamped backup of current history dir /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current, so it may still include versions from the previous boot.
> To reproduce:
> docker build -t testing .
> docker run --rm -it testing
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month