[JBoss JIRA] (WFLY-3189) Error validating jboss-ejb3.xml.
by Michael Hauke (JIRA)
[ https://issues.jboss.org/browse/WFLY-3189?page=com.atlassian.jira.plugin.... ]
Michael Hauke edited comment on WFLY-3189 at 9/2/14 10:32 AM:
--------------------------------------------------------------
I managed to get Eclipse validate an instance of "jboss-ejb3.xml" by modifying the JBoss Tools Eclipse plugin "org.jboss.tools.as.catalog_3.0.0.Beta3-v20140718-1832-B70.jar". I'll try to attach a patch containing the changes.
I added entries to "plugin.xml" for "http://www.jboss.com/xml/ns/javaee" and "urn:clustering:1.0" (we use the "clustering" element; I did not find a XSD for that in the plugin or the JBoss distribution), removed all schema locations in "schema" and "import" elements from "jboss-ejb3-2_0.xsd", "jboss-ejb3-spec-2_0.xsd", "jboss-ejb-security_1_0.xsd" (and "jboss-ejb-security_1_1.xsd) (all in schema/xsd) and added a "jboss-ejb-clustering_1_0.xsd" modeled after "jboss-ejb-security_1_0.xsd".
With that plugin Eclipse can validate a "jboss-ejb3.xml" instance but it still gets confused by "clustering" and "security" both being a "assembly-descriptor-entry". Whichever comes first is ok, whichever comes second is not.
I get around that with the "jboss-ejb3.xml" instance using another XSD which pulls in the others.
This XSD looks like:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.jboss.com/xml/ns/javaee" xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:javaee="http://java.sun.com/xml/ns/javaee" elementFormDefault="qualified"
attributeFormDefault="unqualified" version="2.0">
<xs:include schemaLocation="http://www.jboss.com/xml/ns/javaee" />
<xs:import namespace="http://java.sun.com/xml/ns/javaee" />
<xs:import namespace="urn:clustering:1.0" />
<xs:import namespace="urn:security" />
</xs:schema>
{code}
My "jboss-ejb3.xml" instance looks like:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:c="urn:clustering:1.0"
xmlns:s="urn:security" version="3.1" impl-version="2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee jboss-ejb-jar.xsd">
<assembly-descriptor>
<s:security>
<ejb-name>*</ejb-name>
<s:security-domain>someDomain</s:security-domain>
<s:run-as-principal>somePrincipal</s:run-as-principal>
</s:security>
<c:clustering>
<ejb-name>SomeBean</ejb-name>
<c:clustered>true</c:clustered>
</c:clustering>
</assembly-descriptor>
</jboss:ejb-jar>
{code}
was (Author: mchlhke):
I managed to get Eclipse validate an instance of "jboss-ejb3.xml" by modifying the JBoss Tools Eclipse plugin "org.jboss.tools.as.catalog_3.0.0.Beta3-v20140718-1832-B70.jar". I'll try to attach a patch containing the changes.
I added entries to "plugin.xml" for "http://www.jboss.com/xml/ns/javaee" and "urn:clustering:1.0" (we use the "clustering" element; I did not find a XSD for that in the plugin or the JBoss distribution), removed all schema locations in "schema" and "import" elements from "jboss-ejb3-2_0.xsd", "jboss-ejb3-spec-2_0.xsd", "jboss-ejb-security_1_0.xsd" (and "jboss-ejb-security_1_1.xsd) (all in schema/xsd) and added a "jboss-ejb-clustering_1_0.xsd" modeled after "jboss-ejb-security_1_0.xsd".
With that plugin Eclipse can validate a "jboss-ejb3.xml" instance but it still gets confused by "clustering" and "security" both being a "assembly-descriptor-entry". Whichever comes first is ok, whichever comes second is not.
I get around that with the "jboss-ejb3.xml" instance using another XSD which pulls in the others.
This XSD looks like:
{quote}
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.jboss.com/xml/ns/javaee" xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:javaee="http://java.sun.com/xml/ns/javaee" elementFormDefault="qualified"
attributeFormDefault="unqualified" version="2.0">
<xs:include schemaLocation="http://www.jboss.com/xml/ns/javaee" />
<xs:import namespace="http://java.sun.com/xml/ns/javaee" />
<xs:import namespace="urn:clustering:1.0" />
<xs:import namespace="urn:security" />
</xs:schema>
{quote}
My "jboss-ejb3.xml" instance looks like:
{quote}
<?xml version="1.0" encoding="UTF-8"?>
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:c="urn:clustering:1.0"
xmlns:s="urn:security" version="3.1" impl-version="2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee jboss-ejb-jar.xsd">
<assembly-descriptor>
<s:security>
<ejb-name>*</ejb-name>
<s:security-domain>someDomain</s:security-domain>
<s:run-as-principal>somePrincipal</s:run-as-principal>
</s:security>
<c:clustering>
<ejb-name>SomeBean</ejb-name>
<c:clustered>true</c:clustered>
</c:clustering>
</assembly-descriptor>
</jboss:ejb-jar>
{quote}
> Error validating jboss-ejb3.xml.
> --------------------------------
>
> Key: WFLY-3189
> URL: https://issues.jboss.org/browse/WFLY-3189
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Environment: WildFly 8.0.0.Final
> Reporter: shinzey shinzey
> Assignee: David Lloyd
>
> I'm trying to configure code completion for jboss-ejb3.xml with schema, but fail to do that due to the following validation error:
> {noformat}
> src-resolve: Cannot resolve the name 'javaee:jboss-ejb-beanType' to a(n) 'type definition' component. [33]
> src-resolve: Cannot resolve the name 'javaee:jboss-ejb-jarType' to a(n) 'type definition' component. [35]
> src-resolve: Cannot resolve the name 'javaee:jboss-enterprise-beansType' to a(n) 'type definition' component. [37]
> src-resolve: Cannot resolve the name 'javaee:assembly-descriptor-entry' to a(n) 'element declaration' component. [35]
> src-resolve: Cannot resolve the name 'javaee:jboss-assembly-descriptor-bean-entryType' to a(n) 'type definition' component. [39]
> {noformat}
> The jboss-ejb3.xml is quite simple:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss:ejb-jar version="3.1" impl-version="2.0"
> xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
> xmlns:s="urn:security:1.1"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd
> http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd">
> <assembly-descriptor>
> <s:security>
> <ejb-name>*</ejb-name>
> <s:security-domain>testsd</s:security-domain>
> </s:security>
> </assembly-descriptor>
> </jboss:ejb-jar>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (WFLY-3189) Error validating jboss-ejb3.xml.
by Michael Hauke (JIRA)
[ https://issues.jboss.org/browse/WFLY-3189?page=com.atlassian.jira.plugin.... ]
Michael Hauke edited comment on WFLY-3189 at 9/2/14 10:31 AM:
--------------------------------------------------------------
I managed to get Eclipse validate an instance of "jboss-ejb3.xml" by modifying the JBoss Tools Eclipse plugin "org.jboss.tools.as.catalog_3.0.0.Beta3-v20140718-1832-B70.jar". I'll try to attach a patch containing the changes.
I added entries to "plugin.xml" for "http://www.jboss.com/xml/ns/javaee" and "urn:clustering:1.0" (we use the "clustering" element; I did not find a XSD for that in the plugin or the JBoss distribution), removed all schema locations in "schema" and "import" elements from "jboss-ejb3-2_0.xsd", "jboss-ejb3-spec-2_0.xsd", "jboss-ejb-security_1_0.xsd" (and "jboss-ejb-security_1_1.xsd) (all in schema/xsd) and added a "jboss-ejb-clustering_1_0.xsd" modeled after "jboss-ejb-security_1_0.xsd".
With that plugin Eclipse can validate a "jboss-ejb3.xml" instance but it still gets confused by "clustering" and "security" both being a "assembly-descriptor-entry". Whichever comes first is ok, whichever comes second is not.
I get around that with the "jboss-ejb3.xml" instance using another XSD which pulls in the others.
This XSD looks like:
{quote}
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.jboss.com/xml/ns/javaee" xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:javaee="http://java.sun.com/xml/ns/javaee" elementFormDefault="qualified"
attributeFormDefault="unqualified" version="2.0">
<xs:include schemaLocation="http://www.jboss.com/xml/ns/javaee" />
<xs:import namespace="http://java.sun.com/xml/ns/javaee" />
<xs:import namespace="urn:clustering:1.0" />
<xs:import namespace="urn:security" />
</xs:schema>
{quote}
My "jboss-ejb3.xml" instance looks like:
{quote}
<?xml version="1.0" encoding="UTF-8"?>
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:c="urn:clustering:1.0"
xmlns:s="urn:security" version="3.1" impl-version="2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee jboss-ejb-jar.xsd">
<assembly-descriptor>
<s:security>
<ejb-name>*</ejb-name>
<s:security-domain>someDomain</s:security-domain>
<s:run-as-principal>somePrincipal</s:run-as-principal>
</s:security>
<c:clustering>
<ejb-name>SomeBean</ejb-name>
<c:clustered>true</c:clustered>
</c:clustering>
</assembly-descriptor>
</jboss:ejb-jar>
{quote}
was (Author: mchlhke):
I managed to get Eclipse validate an instance of "jboss-ejb3.xml" by modifying the JBoss Tools Eclipse plugin "org.jboss.tools.as.catalog_3.0.0.Beta3-v20140718-1832-B70.jar". I'll try to attach a patch containing the changes.
I added entries to "plugin.xml" for "http://www.jboss.com/xml/ns/javaee" and "urn:clustering:1.0" (we use the "clustering" element; I did not find a XSD for that in the plugin or the JBoss distribution), removed all schema locations in "schema" and "import" elements from "jboss-ejb3-2_0.xsd", "jboss-ejb3-spec-2_0.xsd", "jboss-ejb-security_1_0.xsd" (and "jboss-ejb-security_1_1.xsd) (all in schema/xsd) and added a "jboss-ejb-clustering_1_0.xsd" modeled after "jboss-ejb-security_1_0.xsd".
With that plugin Eclipse can validate a "jboss-ejb3.xml" instance but it still gets confused by "clustering" and "security" both being a "assembly-descriptor-entry". Whichever comes first is ok, whichever comes second is not.
I get around that with the "jboss-ejb3.xml" instance using another XSD which pulls in the others.
This XSD looks like:
{quote}
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.jboss.com/xml/ns/javaee" xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:javaee="http://java.sun.com/xml/ns/javaee" elementFormDefault="qualified"
attributeFormDefault="unqualified" version="2.0">
<xs:include schemaLocation="http://www.jboss.com/xml/ns/javaee" />
<xs:import namespace="http://java.sun.com/xml/ns/javaee" />
<xs:import namespace="urn:clustering:1.0" />
<xs:import namespace="urn:security" />
</xs:schema>
{quote]
My "jboss-ejb3.xml" instance looks like:
{quote}
<?xml version="1.0" encoding="UTF-8"?>
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:c="urn:clustering:1.0"
xmlns:s="urn:security" version="3.1" impl-version="2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee jboss-ejb-jar.xsd">
<assembly-descriptor>
<s:security>
<ejb-name>*</ejb-name>
<s:security-domain>someDomain</s:security-domain>
<s:run-as-principal>somePrincipal</s:run-as-principal>
</s:security>
<c:clustering>
<ejb-name>SomeBean</ejb-name>
<c:clustered>true</c:clustered>
</c:clustering>
</assembly-descriptor>
</jboss:ejb-jar>
{quote}
> Error validating jboss-ejb3.xml.
> --------------------------------
>
> Key: WFLY-3189
> URL: https://issues.jboss.org/browse/WFLY-3189
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Environment: WildFly 8.0.0.Final
> Reporter: shinzey shinzey
> Assignee: David Lloyd
>
> I'm trying to configure code completion for jboss-ejb3.xml with schema, but fail to do that due to the following validation error:
> {noformat}
> src-resolve: Cannot resolve the name 'javaee:jboss-ejb-beanType' to a(n) 'type definition' component. [33]
> src-resolve: Cannot resolve the name 'javaee:jboss-ejb-jarType' to a(n) 'type definition' component. [35]
> src-resolve: Cannot resolve the name 'javaee:jboss-enterprise-beansType' to a(n) 'type definition' component. [37]
> src-resolve: Cannot resolve the name 'javaee:assembly-descriptor-entry' to a(n) 'element declaration' component. [35]
> src-resolve: Cannot resolve the name 'javaee:jboss-assembly-descriptor-bean-entryType' to a(n) 'type definition' component. [39]
> {noformat}
> The jboss-ejb3.xml is quite simple:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss:ejb-jar version="3.1" impl-version="2.0"
> xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
> xmlns:s="urn:security:1.1"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd
> http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd">
> <assembly-descriptor>
> <s:security>
> <ejb-name>*</ejb-name>
> <s:security-domain>testsd</s:security-domain>
> </s:security>
> </assembly-descriptor>
> </jboss:ejb-jar>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (WFLY-3189) Error validating jboss-ejb3.xml.
by Michael Hauke (JIRA)
[ https://issues.jboss.org/browse/WFLY-3189?page=com.atlassian.jira.plugin.... ]
Michael Hauke commented on WFLY-3189:
-------------------------------------
I managed to get Eclipse validate an instance of "jboss-ejb3.xml" by modifying the JBoss Tools Eclipse plugin "org.jboss.tools.as.catalog_3.0.0.Beta3-v20140718-1832-B70.jar". I'll try to attach a patch containing the changes.
I added entries to "plugin.xml" for "http://www.jboss.com/xml/ns/javaee" and "urn:clustering:1.0" (we use the "clustering" element; I did not find a XSD for that in the plugin or the JBoss distribution), removed all schema locations in "schema" and "import" elements from "jboss-ejb3-2_0.xsd", "jboss-ejb3-spec-2_0.xsd", "jboss-ejb-security_1_0.xsd" (and "jboss-ejb-security_1_1.xsd) (all in schema/xsd) and added a "jboss-ejb-clustering_1_0.xsd" modeled after "jboss-ejb-security_1_0.xsd".
With that plugin Eclipse can validate a "jboss-ejb3.xml" instance but it still gets confused by "clustering" and "security" both being a "assembly-descriptor-entry". Whichever comes first is ok, whichever comes second is not.
I get around that with the "jboss-ejb3.xml" instance using another XSD which pulls in the others.
This XSD looks like:
{quote}
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.jboss.com/xml/ns/javaee" xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:javaee="http://java.sun.com/xml/ns/javaee" elementFormDefault="qualified"
attributeFormDefault="unqualified" version="2.0">
<xs:include schemaLocation="http://www.jboss.com/xml/ns/javaee" />
<xs:import namespace="http://java.sun.com/xml/ns/javaee" />
<xs:import namespace="urn:clustering:1.0" />
<xs:import namespace="urn:security" />
</xs:schema>
{quote]
My "jboss-ejb3.xml" instance looks like:
{quote}
<?xml version="1.0" encoding="UTF-8"?>
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:c="urn:clustering:1.0"
xmlns:s="urn:security" version="3.1" impl-version="2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee jboss-ejb-jar.xsd">
<assembly-descriptor>
<s:security>
<ejb-name>*</ejb-name>
<s:security-domain>someDomain</s:security-domain>
<s:run-as-principal>somePrincipal</s:run-as-principal>
</s:security>
<c:clustering>
<ejb-name>SomeBean</ejb-name>
<c:clustered>true</c:clustered>
</c:clustering>
</assembly-descriptor>
</jboss:ejb-jar>
{quote}
> Error validating jboss-ejb3.xml.
> --------------------------------
>
> Key: WFLY-3189
> URL: https://issues.jboss.org/browse/WFLY-3189
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Environment: WildFly 8.0.0.Final
> Reporter: shinzey shinzey
> Assignee: David Lloyd
>
> I'm trying to configure code completion for jboss-ejb3.xml with schema, but fail to do that due to the following validation error:
> {noformat}
> src-resolve: Cannot resolve the name 'javaee:jboss-ejb-beanType' to a(n) 'type definition' component. [33]
> src-resolve: Cannot resolve the name 'javaee:jboss-ejb-jarType' to a(n) 'type definition' component. [35]
> src-resolve: Cannot resolve the name 'javaee:jboss-enterprise-beansType' to a(n) 'type definition' component. [37]
> src-resolve: Cannot resolve the name 'javaee:assembly-descriptor-entry' to a(n) 'element declaration' component. [35]
> src-resolve: Cannot resolve the name 'javaee:jboss-assembly-descriptor-bean-entryType' to a(n) 'type definition' component. [39]
> {noformat}
> The jboss-ejb3.xml is quite simple:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss:ejb-jar version="3.1" impl-version="2.0"
> xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
> xmlns:s="urn:security:1.1"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd
> http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd">
> <assembly-descriptor>
> <s:security>
> <ejb-name>*</ejb-name>
> <s:security-domain>testsd</s:security-domain>
> </s:security>
> </assembly-descriptor>
> </jboss:ejb-jar>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (WFCORE-40) Deadlock while logging
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-40?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFCORE-40:
-----------------------------------
Is there an infinite loop in this situation, i.e. one CPU thread at 100%, or is this method simply frozen? Can you verify that the thread is not making progress?
> Deadlock while logging
> ----------------------
>
> Key: WFCORE-40
> URL: https://issues.jboss.org/browse/WFCORE-40
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Environment: CentOS 6.5 64bit, java7u45 64bit (and 32 bit, the same behavior)
> Reporter: Stefan Schueffler
> Assignee: James Perkins
> Priority: Critical
> Attachments: stack_140901_2254
>
>
> We hit really often a deadlock? in org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474)
> Even if the "StdioContext" belongs to Jboss-Logging, the problem occurs in our production wildfly installation twice to 4 times a day - all threads are deadlocking while trying to log.debug, log.error, or (sometimes) System.out.println from our application code, and wildfly does not respond anymore...
> The partial stacktrace always is similar to this one:
> {code}
> "default task-64" prio=10 tid=0x4c539c00 nid=0x5ef9 waiting for monitor entry [0x495e0000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at java.io.PrintStream.println(PrintStream.java:806)
> - waiting to lock <0x5ee0adf8> (a java.io.PrintStream)
> at org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474)
> at jsp.communications.statuschange.selectStatus_jsp._jspService(selectStatus_jsp.java:413)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82)
> {code}
> While investigating the StdioContext - class, i really wondered whether the used "locking/checking by using a threadlocal" could have worked in a multi-threaded environment (it should have the very same problems as every "double checking" algorithm without proper synchronization).
> If all threads are hanging in this particular lock, only a full wildfly-restart recovers in our case.
> My preferred solution would be a rework of the used org.jboss.stdio. classes, as the used idioms of ThreadLocals for reentrant-checks are at least highly unusual?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3266:
-----------------------------------------------
Panagiotis Sotiropoulos <psotirop(a)redhat.com> changed the Status of [bug 1088463|https://bugzilla.redhat.com/show_bug.cgi?id=1088463] from ASSIGNED to POST
> Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3266
> URL: https://issues.jboss.org/browse/WFLY-3266
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
>
> In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
> The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.
> java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
> at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3266:
-----------------------------------------------
Panagiotis Sotiropoulos <psotirop(a)redhat.com> changed the Status of [bug 1088463|https://bugzilla.redhat.com/show_bug.cgi?id=1088463] from NEW to ASSIGNED
> Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3266
> URL: https://issues.jboss.org/browse/WFLY-3266
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
>
> In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
> The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.
> java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
> at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (WFLY-3492) JSSE configuration in security domain wrongly acceptes empty parameters
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3492?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3492:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1080069|https://bugzilla.redhat.com/show_bug.cgi?id=1080069] from POST to ASSIGNED
> JSSE configuration in security domain wrongly acceptes empty parameters
> -----------------------------------------------------------------------
>
> Key: WFLY-3492
> URL: https://issues.jboss.org/browse/WFLY-3492
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Reporter: Chao Wang
> Assignee: Alexey Loubyansky
>
> Description from https://bugzilla.redhat.com/show_bug.cgi?id=1080069:
> {noformat}
> When adding a jsse configuration in security domain through CLI, it's not persisted correctly.
> Steps to reproduce:
> * Run CLI (./jboss-cli.sh -c) and use this commands to configure new security domain:
> /subsystem=security/security-domain=trust-domain:add
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore=>{password=1234test,url=/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> reload
> * check standalone.xml, where should be sth. like
> <security-domain name="trust-domain">
> <jsse truststore-password="1234test" truststore-url="/home/jcacek/projects/ocsp-check/build/trusted-clients.jks"/>
> </security-domain>
> But there is:
> <security-domain name="trust-domain">
> <jsse/>
> </security-domain>
> {noformat}
> {noformat}
> I had a mistake in the second command, it should be:
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore={password=>1234test,url=>/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> Then it works.
> Nevertheless it's probably still a bug, when the original command returns:
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months