[JBoss JIRA] (JBMETA-367) CLONE - XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBMETA-367?page=com.atlassian.jira.plugin... ]
Viacheslav Kabanovich commented on JBMETA-367:
----------------------------------------------
https://github.com/wildfly/wildfly/pull/5560
> CLONE - XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
> -------------------------------------------------------------------------------------------
>
> Key: JBMETA-367
> URL: https://issues.jboss.org/browse/JBMETA-367
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Elias Ross
>
> When attempting to write a (seemingly) valid jboss-deployment-structure.xml using the schema in ./docs, my document fails to validate.
> This is because of the settings used in the XSD. Have these XSDs been used to validate actual documents? By setting unqualified to 'qualified' then the documents will probably validate.
> $ git grep elementFormDefault..unqualified
> jboss-deployment-dependencies-1_0.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_0.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_1.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_2.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_0.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_1.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_2.xsd: elementFormDefault="unqualified"
> jboss-jpa_1_0.xsd: elementFormDefault="unqualified"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2596) JASPI Web layer problems
by István Tóth (JIRA)
István Tóth created WFLY-2596:
---------------------------------
Summary: JASPI Web layer problems
Key: WFLY-2596
URL: https://issues.jboss.org/browse/WFLY-2596
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.0.0.CR1
Environment: Fedora 19, x86_64
Reporter: István Tóth
Assignee: Stuart Douglas
I have found several problems in the current (master, trunk) Wildfly JASPI Web layer implementation
Undertow related:
----------------------
* It does not support pre-emptive authentication:
When the ServerAuthenticationModule returns AUTH_SUCCESS and null userPrincipal, it should let the request fall through unathenticated, instead it is rejected.
* It does not call secureResponse when the authentication was unsuccessful
* It does not populate the org.jboss.security.SecurityContext, only the undertow Account structure.
* It does not support the wrapper feature (Spec 3.8.3.5 and B.9)
The attached pull request aims to fix the first three issues.
Credits: This patch is based on Arjan Tijms' analysis, and suggested patches for the Jboss 7.X valve based authentitactor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2525) Atmosphere connection fails using long-polling transport (probable regression from WFLY-2416)
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2525?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-2525.
----------------------------------
Fix Version/s: 8.0.0.CR1
Resolution: Done
> Atmosphere connection fails using long-polling transport (probable regression from WFLY-2416)
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-2525
> URL: https://issues.jboss.org/browse/WFLY-2525
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: wildfly-8.0.0.Beta2-SNAPSHOT build #786 (undertow 1.0.0.beta23)
> atmosphere chat-multiroom sample:
> https://github.com/Atmosphere/atmosphere-samples/tree/master/samples/chat...
> Reporter: John Teller
> Assignee: Stuart Douglas
> Fix For: 8.0.0.CR1
>
>
> In previous Atmosphere tests with undertow beta20, attempting to connect using websocket transport failed, then fell back successfully to long-polling. In latest test with undertow beta23, websocket transport now works correctly, but attempting to connect using long-polling transport now results in the following error:
> 2013-11-17 21:57:32,857 ERROR [org.atmosphere.cpr.AtmosphereFramework] (default task-6) AtmosphereFramework exception: java.lang.IllegalStateException: UT010026: Async is not supported for this request, as not all filters or Servlets were marked as supporting async
> at io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:909) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:503) [atmosphere-runtime-2.0.3.jar:2.0.3]
> at org.atmosphere.container.Servlet30CometSupport.suspend(Servlet30CometSupport.java:128) [atmosphere-runtime-2.0.3.jar:2.0.3]
> at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:103) [atmosphere-runtime-2.0.3.jar:2.0.3]
> at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1684) [atmosphere-runtime-2.0.3.jar:2.0.3]
> at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:198) [atmosphere-runtime-2.0.3.jar:2.0.3]
> at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:184) [atmosphere-runtime-2.0.3.jar:2.0.3]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:114) [undertow-websockets-jsr-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:637) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-2593:
------------------------------------
fix will probably be something like:
{code}
private boolean hasQuery(PathElement element) {
boolean result = false;
final PersistenceUnitService puService = persistenceUnitRegistry.getPersistenceUnitService(puName);
final Statistics stats = getStatistics();
if (stats != null && puService != null) {
final String scopedPUName = puService.getScopedPersistenceUnitName();
final String unqualifiedQueryName = element.getValue();
result = getQueryNames().contains(unqualifiedQueryName)
}
return result;
}
{code}
> Memory leak in JBoss AS / Hibernate JPA integration
> ---------------------------------------------------
>
> Key: WFLY-2593
> URL: https://issues.jboss.org/browse/WFLY-2593
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: No Release
> Environment: JBoss 7.1.1
> JBoss EAP 6.2 beta
> Reporter: Michael Kozak
> Assignee: Scott Marlow
> Priority: Critical
> Fix For: No Release
>
> Attachments: jmxp.ear.ear, jmxp.tar.gz
>
>
> The leak exists in AS integration code with Hibernate JPA.
> When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements.
> The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found.
> Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do.
> This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2595) Logging DUP leaking class loaders
by James Perkins (JIRA)
James Perkins created WFLY-2595:
-----------------------------------
Summary: Logging DUP leaking class loaders
Key: WFLY-2595
URL: https://issues.jboss.org/browse/WFLY-2595
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
Priority: Critical
Fix For: 8.0.0.CR1
When a new {{LogContext}} is created for per-deployment logging the class loader is registered as the key. On undeploy the {{LogContext}} should be removed, but the wrong {{LogContext}}t is retrieved due to the caller class loader being used rather than the TCCL.
The use of the caller class loader is for filtering out system dependencies from the deployment so the correct {{LogContext}} is retrieved from the selector.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2507) InflowFlatTestCase and InflowJarTestCase are failing on Windows
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-2507?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen commented on WFLY-2507:
---------------------------------------
[~emmartins], feel free to assign to [~jeff.zhang]] if you don't have the cycles
> InflowFlatTestCase and InflowJarTestCase are failing on Windows
> ---------------------------------------------------------------
>
> Key: WFLY-2507
> URL: https://issues.jboss.org/browse/WFLY-2507
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Reporter: Brian Stansberry
> Assignee: Eduardo Martins
> Fix For: 8.0.0.CR1
>
>
> Tests are consisently failing on Windows but not on Linux:
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI...
> Typically that would indicate a problem that manifests when tests are run in a different order; i.e. one test leaving behind something that impacts another.
> I suspect what's happening here is an RA is getting left behind and these tests are finding the wrong one and making assertions against it.
> Note this in the test is used to find the RA id:
> Set<String> ids = repository.getResourceAdapters();
> {code}
> assertNotNull(ids);
> System.out.println("////RA" + ids.toString());
> String piId = getElementContaining(ids, "MultipleResourceAdapter");
> {code}
> The test logging shows there are two RAs that would match:
> 03:45:54,709 INFO [stdout] (pool-1-thread-4) ////RA[org.jboss.as.test.integration.jca.rar.MultipleResourceAdapter#27, org.jboss.as.test.integration.jca.rar.MultipleResourceAdapter#28]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months