[JBoss JIRA] (WFLY-9021) Unhelpful failure message if transaction subsystem 'delete' op is run against a non-existent resource on a domain mode server
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9021?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-9021:
-----------------------------------
Description:
In a domain if you run the 'delete' op against an invalid transaction resource you get an invalid failure message about trying to directly call a write op on a server:
{code}
[domain@localhost:9990 /] /host=master/server=server-one/subsystem=transactions/log-store=log-store/transactions=0\:ffff0afc4420\:3b2568af\:594b9528\::delete()
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => "WFLYCTL0249: Operation 'delete' targeted at resource '[
(\"subsystem\" => \"transactions\"),
(\"log-store\" => \"log-store\"),
(\"transactions\" => \"0:ffff0afc4420:3b2568af:594b9528:\")
]' was directly invoked by a user. User operations are not permitted to directly update the persistent configuration of a server in a managed domain.",
"rolled-back" => true
}
{code}
This is because if the resource doesn't exist, the check for mods to non-runtime-only resources is checking the MRR to see if it's runtime only. But this MRR doesn't declare it is so the kernel thinks a direct write to the model is happening and rejects that.
A fix results in the appropriate failure for invoking against a non-existent resource:
{code}
[domain@localhost:9990 /] /host=master/server=server-one/subsystem=transactions/log-store=log-store/transactions=0\:ffff0afc4420\:3b2568af\:594b9528\::delete()
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => "WFLYCTL0216: Management resource '[
(\"subsystem\" => \"transactions\"),
(\"log-store\" => \"log-store\"),
(\"transactions\" => \"0:ffff0afc4420:3b2568af:594b9528:\")
]' not found",
"rolled-back" => true
}
{code}
was:
In a domain if you run the 'delete' op against an invalid transaction resource you get an invalid failure message about trying to directly call a write op on a server:
{code}
[domain@localhost:9990 /] /host=master/server=server-one/subsystem=transactions/log-store=log-store/transactions=0\:ffff0afc4420\:3b2568af\:594b9528\::delete()
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => "WFLYCTL0249: Operation 'delete' targeted at resource '[
(\"subsystem\" => \"transactions\"),
(\"log-store\" => \"log-store\"),
(\"transactions\" => \"0:ffff0afc4420:3b2568af:594b9528:\")
]' was directly invoked by a user. User operations are not permitted to directly update the persistent configuration of a server in a managed domain.",
"rolled-back" => true
}
{code}
This is because if the resource doesn't exist, the check for mods to non-runtime-only resources is checking the MRR to see if its runtime only. But this MRR doesn't declare it is so the kernel thinks a direct write to the model is happening and rejects that.
A fix results in:
{code}
[domain@localhost:9990 /] /host=master/server=server-one/subsystem=transactions/log-store=log-store/transactions=0\:ffff0afc4420\:3b2568af\:594b9528\::delete()
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => "WFLYCTL0216: Management resource '[
(\"subsystem\" => \"transactions\"),
(\"log-store\" => \"log-store\"),
(\"transactions\" => \"0:ffff0afc4420:3b2568af:594b9528:\")
]' not found",
"rolled-back" => true
}
{code}
> Unhelpful failure message if transaction subsystem 'delete' op is run against a non-existent resource on a domain mode server
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9021
> URL: https://issues.jboss.org/browse/WFLY-9021
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> In a domain if you run the 'delete' op against an invalid transaction resource you get an invalid failure message about trying to directly call a write op on a server:
> {code}
> [domain@localhost:9990 /] /host=master/server=server-one/subsystem=transactions/log-store=log-store/transactions=0\:ffff0afc4420\:3b2568af\:594b9528\::delete()
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "WFLYCTL0249: Operation 'delete' targeted at resource '[
> (\"subsystem\" => \"transactions\"),
> (\"log-store\" => \"log-store\"),
> (\"transactions\" => \"0:ffff0afc4420:3b2568af:594b9528:\")
> ]' was directly invoked by a user. User operations are not permitted to directly update the persistent configuration of a server in a managed domain.",
> "rolled-back" => true
> }
> {code}
> This is because if the resource doesn't exist, the check for mods to non-runtime-only resources is checking the MRR to see if it's runtime only. But this MRR doesn't declare it is so the kernel thinks a direct write to the model is happening and rejects that.
> A fix results in the appropriate failure for invoking against a non-existent resource:
> {code}
> [domain@localhost:9990 /] /host=master/server=server-one/subsystem=transactions/log-store=log-store/transactions=0\:ffff0afc4420\:3b2568af\:594b9528\::delete()
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"transactions\"),
> (\"log-store\" => \"log-store\"),
> (\"transactions\" => \"0:ffff0afc4420:3b2568af:594b9528:\")
> ]' not found",
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9022) Unhelpful failure message if transaction subsystem 'delete' op is run against a non-existent resource on a domain mode server
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-9022:
--------------------------------------
Summary: Unhelpful failure message if transaction subsystem 'delete' op is run against a non-existent resource on a domain mode server
Key: WFLY-9022
URL: https://issues.jboss.org/browse/WFLY-9022
Project: WildFly
Issue Type: Bug
Components: Transactions
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
In a domain if you run the 'delete' op against an invalid transaction resource you get an invalid failure message about trying to directly call a write op on a server:
{code}
[domain@localhost:9990 /] /host=master/server=server-one/subsystem=transactions/log-store=log-store/transactions=0\:ffff0afc4420\:3b2568af\:594b9528\::delete()
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => "WFLYCTL0249: Operation 'delete' targeted at resource '[
(\"subsystem\" => \"transactions\"),
(\"log-store\" => \"log-store\"),
(\"transactions\" => \"0:ffff0afc4420:3b2568af:594b9528:\")
]' was directly invoked by a user. User operations are not permitted to directly update the persistent configuration of a server in a managed domain.",
"rolled-back" => true
}
{code}
This is because if the resource doesn't exist, the check for mods to non-runtime-only resources is checking the MRR to see if it's runtime only. But this MRR doesn't declare it is so the kernel thinks a direct write to the model is happening and rejects that.
A fix results in the appropriate failure for invoking against a non-existent resource:
{code}
[domain@localhost:9990 /] /host=master/server=server-one/subsystem=transactions/log-store=log-store/transactions=0\:ffff0afc4420\:3b2568af\:594b9528\::delete()
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => "WFLYCTL0216: Management resource '[
(\"subsystem\" => \"transactions\"),
(\"log-store\" => \"log-store\"),
(\"transactions\" => \"0:ffff0afc4420:3b2568af:594b9528:\")
]' not found",
"rolled-back" => true
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9021) Unhelpful failure message if transaction subsystem 'delete' op is run against a non-existent resource on a domain mode server
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-9021:
--------------------------------------
Summary: Unhelpful failure message if transaction subsystem 'delete' op is run against a non-existent resource on a domain mode server
Key: WFLY-9021
URL: https://issues.jboss.org/browse/WFLY-9021
Project: WildFly
Issue Type: Bug
Components: Transactions
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
In a domain if you run the 'delete' op against an invalid transaction resource you get an invalid failure message about trying to directly call a write op on a server:
{code}
[domain@localhost:9990 /] /host=master/server=server-one/subsystem=transactions/log-store=log-store/transactions=0\:ffff0afc4420\:3b2568af\:594b9528\::delete()
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => "WFLYCTL0249: Operation 'delete' targeted at resource '[
(\"subsystem\" => \"transactions\"),
(\"log-store\" => \"log-store\"),
(\"transactions\" => \"0:ffff0afc4420:3b2568af:594b9528:\")
]' was directly invoked by a user. User operations are not permitted to directly update the persistent configuration of a server in a managed domain.",
"rolled-back" => true
}
{code}
This is because if the resource doesn't exist, the check for mods to non-runtime-only resources is checking the MRR to see if its runtime only. But this MRR doesn't declare it is so the kernel thinks a direct write to the model is happening and rejects that.
A fix results in:
{code}
[domain@localhost:9990 /] /host=master/server=server-one/subsystem=transactions/log-store=log-store/transactions=0\:ffff0afc4420\:3b2568af\:594b9528\::delete()
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => "WFLYCTL0216: Management resource '[
(\"subsystem\" => \"transactions\"),
(\"log-store\" => \"log-store\"),
(\"transactions\" => \"0:ffff0afc4420:3b2568af:594b9528:\")
]' not found",
"rolled-back" => true
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9020) Wildfly 10 - JPA Entity deserialization problem on @Transient field
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-9020?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos updated WFLY-9020:
----------------------------------------
Priority: Minor (was: Major)
> Wildfly 10 - JPA Entity deserialization problem on @Transient field
> -------------------------------------------------------------------
>
> Key: WFLY-9020
> URL: https://issues.jboss.org/browse/WFLY-9020
> Project: WildFly
> Issue Type: Bug
> Components: Application Client
> Affects Versions: 10.0.0.Final
> Environment: Windows 7, Eclipselink 2.6.4 integration, Widlfly 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Stuart Douglas
> Priority: Minor
>
> In Wildfly 10,
> We have some system tests that sporadically fail when the client of the application loads an entity, connected to other sub-entities, where one of these sub-entities has a @Transient field.
> In Particular, we have an entity Attributes that has a field of the form:
> {panel}
> @Transient
> private Map<String, String> attributeMap = new TreeMap<String, String>();
> {panel}
> The root cause of the deserialization problem is of the form:
> {panel}
> Caused by: an exception which occurred:
> in object of type java.util.TreeMap
> in field attributeMap
> in object of type basepackage.entity.Attributes
> in field attributes
> in object of type basepackage.entity.SubEntityB
> in element at index [0] of size [1]
> in field delegate
> in object of type org.eclipse.persistence.internal.indirection.jdk8.IndirectList
> in field loadUnits
> in object of type basepackage.entity.ParentEntityA
> {panel}
> The de-serialization execution stack looks as follows:
> {panel}
> Caused by: java.io.OptionalDataException
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:147)
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:135)
> at org.jboss.marshalling.MarshallerObjectInputStream.readObjectOverride(MarshallerObjectInputStream.java:53)
> at org.jboss.marshalling.river.RiverObjectInputStream.readObjectOverride(RiverObjectInputStream.java:307)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:367)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2567)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2583)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2508)
> at java.util.TreeMap.readObject(TreeMap.java:2454)
> at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:307)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:180)
> at org.jboss.marshalling.river.RiverUnmarshaller.readCollectionData(RiverUnmarshaller.java:776)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:675)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.jboss.ejb.client.remoting.MethodInvocationResponseHandler$MethodInvocationResultProducer.getResult(MethodInvocationResponseHandler.java:104)
> {panel}
> We are using the following cliean library:
> {panel}
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-client-all</artifactId>
> <version>10.0.0.Final</version>
> <scope>test</scope>
> <optional>true</optional>
> <exclusions>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-commons</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-core-client</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-jms-client</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-hqclient-protocol</artifactId>
> </exclusion>
> <exclusion>
> <groupId> org.slf4j</groupId>
> <artifactId>jcl-over-slf4j</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> {panel}
> Currently no sample application exists to reproduce the issue.
> On weblogic the deserialization process goes without incident.
> Could the @Transient annotation and the eventual (empty map vs popuated attribtues map) play a role on this issue?
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9020) Wildfly 10 - JPA Entity deserialization problem on @Transient field
by Nuno Godinho de Matos (JIRA)
Nuno Godinho de Matos created WFLY-9020:
-------------------------------------------
Summary: Wildfly 10 - JPA Entity deserialization problem on @Transient field
Key: WFLY-9020
URL: https://issues.jboss.org/browse/WFLY-9020
Project: WildFly
Issue Type: Bug
Components: Application Client
Affects Versions: 10.0.0.Final
Environment: Windows 7, Eclipselink 2.6.4 integration, Widlfly 10.0.0.Final
Reporter: Nuno Godinho de Matos
Assignee: Stuart Douglas
In Wildfly 10,
We have some system tests that sporadically fail when the client of the application loads an entity, connected to other sub-entities, where one of these sub-entities has a @Transient field.
In Particular, we have an entity Attributes that has a field of the form:
{panel}
@Transient
private Map<String, String> attributeMap = new TreeMap<String, String>();
{panel}
The root cause of the deserialization problem is of the form:
{panel}
Caused by: an exception which occurred:
in object of type java.util.TreeMap
in field attributeMap
in object of type basepackage.entity.Attributes
in field attributes
in object of type basepackage.entity.SubEntityB
in element at index [0] of size [1]
in field delegate
in object of type org.eclipse.persistence.internal.indirection.jdk8.IndirectList
in field loadUnits
in object of type basepackage.entity.ParentEntityA
{panel}
The de-serialization execution stack looks as follows:
{panel}
Caused by: java.io.OptionalDataException
at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:147)
at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:135)
at org.jboss.marshalling.MarshallerObjectInputStream.readObjectOverride(MarshallerObjectInputStream.java:53)
at org.jboss.marshalling.river.RiverObjectInputStream.readObjectOverride(RiverObjectInputStream.java:307)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:367)
at java.util.TreeMap.buildFromSorted(TreeMap.java:2567)
at java.util.TreeMap.buildFromSorted(TreeMap.java:2583)
at java.util.TreeMap.buildFromSorted(TreeMap.java:2508)
at java.util.TreeMap.readObject(TreeMap.java:2454)
at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:307)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:180)
at org.jboss.marshalling.river.RiverUnmarshaller.readCollectionData(RiverUnmarshaller.java:776)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:675)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.jboss.ejb.client.remoting.MethodInvocationResponseHandler$MethodInvocationResultProducer.getResult(MethodInvocationResponseHandler.java:104)
{panel}
We are using the following cliean library:
{panel}
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-client-all</artifactId>
<version>10.0.0.Final</version>
<scope>test</scope>
<optional>true</optional>
<exclusions>
<exclusion>
<groupId>org.apache.activemq</groupId>
<artifactId>artemis-commons</artifactId>
</exclusion>
<exclusion>
<groupId>org.apache.activemq</groupId>
<artifactId>artemis-core-client</artifactId>
</exclusion>
<exclusion>
<groupId>org.apache.activemq</groupId>
<artifactId>artemis-jms-client</artifactId>
</exclusion>
<exclusion>
<groupId>org.apache.activemq</groupId>
<artifactId>artemis-hqclient-protocol</artifactId>
</exclusion>
<exclusion>
<groupId> org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
</exclusion>
</exclusions>
</dependency>
{panel}
Currently no sample application exists to reproduce the issue.
On weblogic the deserialization process goes without incident.
Could the @Transient annotation and the eventual (empty map vs popuated attribtues map) play a role on this issue?
Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9019) Welcome page features a screenshot of running WildFly as root
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-9019?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-9019:
-------------------------------------
It might be best to just list the commands too rather than using a screen shot. Having text would be beneficial to the visually impaired as well.
> Welcome page features a screenshot of running WildFly as root
> -------------------------------------------------------------
>
> Key: WFLY-9019
> URL: https://issues.jboss.org/browse/WFLY-9019
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Reporter: David Lloyd
> Assignee: Harald Pehl
> Priority: Critical
> Attachments: image-2017-06-28-12-27-00-808.png
>
>
> This image appears on the welcome page of a fresh WildFly install when you access the admin console port:
> !image-2017-06-28-12-27-00-808.png!
> Users should not normally run WildFly as root, so this should probably be changed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9019) Welcome page features a screenshot of running WildFly as root
by David Lloyd (JIRA)
David Lloyd created WFLY-9019:
---------------------------------
Summary: Welcome page features a screenshot of running WildFly as root
Key: WFLY-9019
URL: https://issues.jboss.org/browse/WFLY-9019
Project: WildFly
Issue Type: Bug
Reporter: David Lloyd
Priority: Critical
Attachments: image-2017-06-28-12-27-00-808.png
This image appears on the welcome page of a fresh WildFly install when you access the admin console port:
!image-2017-06-28-12-27-00-808.png|thumbnail!
Users should not normally run WildFly as root, so this should probably be changed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months