[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:
-------------------------------------
"jboss-ejb-clustering_1_0.xsd" is missing in the patch, it looks like:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:clustering:1.0" xmlns="urn:clustering:1.0"
xmlns:javaee="http://java.sun.com/xml/ns/javaee"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.0">
<xs:import namespace="http://java.sun.com/xml/ns/javaee"/>
<xs:element name="clustering" type="clusteringType"
substitutionGroup="javaee:assembly-descriptor-entry" />
<xs:complexType name="clusteringType">
<xs:complexContent>
<xs:extension
base="javaee:jboss-assembly-descriptor-bean-entryType">
<xs:sequence>
<xs:element name="clustered" type="xs:string" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>
{code}
> 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
> Attachments: p.patch
>
>
> 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:
-----------------------------------
It seems extremely unlikely that the JVM is stuck in this method. I think it's more likely that the log handler in question is writing to a target (either console or disk) and the write is failing. Because filling in the stack trace is such a time-intensive operation, it has a very high chance of appearing on the stack trace, giving the appearance of no forward progress when actually there is simply a loop of exception throws.
Anyway, now we've confused the issue a bit. I guess the underlying problem is that one thread is writing a bunch of stuff in a loop, monopolizing the lock, while other threads sit and wait for the lock. It's possible that the failure in the one thread is in turn being logged, causing the loop to be infinite, though I would find this surprising as there are safeguards to prevent this behavior.
> 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-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:42 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), added a "jboss-ejb-clustering_1_0.xsd" modeled after "jboss-ejb-security_1_0.xsd" and removed "assembly-descriptor" from the "jboss-ejb-jarType" in "jboss-ejb3-spec-2_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:
{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}
> 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
> Attachments: p.patch
>
>
> 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 Andreas Kaster (JIRA)
[ https://issues.jboss.org/browse/WFCORE-40?page=com.atlassian.jira.plugin.... ]
Andreas Kaster commented on WFCORE-40:
--------------------------------------
_top_ shows a load near 1, i.e. one CPU hanging at 100% (the system has 8 CPU cores)
> 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] (WFBUILD-6) Extract schemas from copy artifacts
by Eduardo Martins (JIRA)
Eduardo Martins created WFBUILD-6:
-------------------------------------
Summary: Extract schemas from copy artifacts
Key: WFBUILD-6
URL: https://issues.jboss.org/browse/WFBUILD-6
Project: WildFly Build Tools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Eduardo Martins
Assignee: Eduardo Martins
Extend the module artifact schema extract feature also to copy artifacts.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months