[JBoss JIRA] (WFLY-3732) RaOperationUtil cannot handle unusual address formats
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3732?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3732:
-----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1129400|https://bugzilla.redhat.com/show_bug.cgi?id=1129400] from NEW to POST
> RaOperationUtil cannot handle unusual address formats
> -----------------------------------------------------
>
> Key: WFLY-3732
> URL: https://issues.jboss.org/browse/WFLY-3732
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.1.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 9.0.0.Beta1
>
>
> RaOperationUtil is using a very unorthodox method of reading the address of the operation:
> final List<ModelNode> address = operation.get(ModelDescriptionConstants.ADDRESS).asList();
> final String id = address.get(address.size()-1).get(0).asString();
> The issue is the ModelNode returned by "address.get(address.size()-1)".
>
> When you use the CLI, the ModelNode is of ModelType.PROPERTY.
> To create a ModelNode of ModelType.PROPERTY using JSON syntax is difficult. (TBH I'm not sure how to do it.) The syntax in a typical curl command results in a node of ModelType.OBJECT.
> {code}
> "address":[{"subsystem":"resource-adapters"},{"resource-adapter":"my-adapter"}]
> {code}
> That get(0) call fails on ModelType.OBJECT. It's quite the quirk that it works for ModelType.PROPERTY.
> I'll replace that logic with standard stuff using PathAddress.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3732) RaOperationUtil cannot handle unusual address formats
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3732?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-3732.
------------------------------------
Resolution: Out of Date
This isn't a problem in WF; the code is different.
> RaOperationUtil cannot handle unusual address formats
> -----------------------------------------------------
>
> Key: WFLY-3732
> URL: https://issues.jboss.org/browse/WFLY-3732
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.1.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 9.0.0.Beta1
>
>
> RaOperationUtil is using a very unorthodox method of reading the address of the operation:
> final List<ModelNode> address = operation.get(ModelDescriptionConstants.ADDRESS).asList();
> final String id = address.get(address.size()-1).get(0).asString();
> The issue is the ModelNode returned by "address.get(address.size()-1)".
>
> When you use the CLI, the ModelNode is of ModelType.PROPERTY.
> To create a ModelNode of ModelType.PROPERTY using JSON syntax is difficult. (TBH I'm not sure how to do it.) The syntax in a typical curl command results in a node of ModelType.OBJECT.
> {code}
> "address":[{"subsystem":"resource-adapters"},{"resource-adapter":"my-adapter"}]
> {code}
> That get(0) call fails on ModelType.OBJECT. It's quite the quirk that it works for ModelType.PROPERTY.
> I'll replace that logic with standard stuff using PathAddress.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3732) RaOperationUtil cannot handle unusual address formats
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-3732:
--------------------------------------
Summary: RaOperationUtil cannot handle unusual address formats
Key: WFLY-3732
URL: https://issues.jboss.org/browse/WFLY-3732
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA
Affects Versions: 8.1.0.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 9.0.0.Beta1
RaOperationUtil is using a very unorthodox method of reading the address of the operation:
final List<ModelNode> address = operation.get(ModelDescriptionConstants.ADDRESS).asList();
final String id = address.get(address.size()-1).get(0).asString();
The issue is the ModelNode returned by "address.get(address.size()-1)".
When you use the CLI, the ModelNode is of ModelType.PROPERTY.
To create a ModelNode of ModelType.PROPERTY using JSON syntax is difficult. (TBH I'm not sure how to do it.) The syntax in a typical curl command results in a node of ModelType.OBJECT.
{code}
"address":[{"subsystem":"resource-adapters"},{"resource-adapter":"my-adapter"}]
{code}
That get(0) call fails on ModelType.OBJECT. It's quite the quirk that it works for ModelType.PROPERTY.
I'll replace that logic with standard stuff using PathAddress.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3732) RaOperationUtil cannot handle unusual address formats
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3732?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3732:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1129400
> RaOperationUtil cannot handle unusual address formats
> -----------------------------------------------------
>
> Key: WFLY-3732
> URL: https://issues.jboss.org/browse/WFLY-3732
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.1.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 9.0.0.Beta1
>
>
> RaOperationUtil is using a very unorthodox method of reading the address of the operation:
> final List<ModelNode> address = operation.get(ModelDescriptionConstants.ADDRESS).asList();
> final String id = address.get(address.size()-1).get(0).asString();
> The issue is the ModelNode returned by "address.get(address.size()-1)".
>
> When you use the CLI, the ModelNode is of ModelType.PROPERTY.
> To create a ModelNode of ModelType.PROPERTY using JSON syntax is difficult. (TBH I'm not sure how to do it.) The syntax in a typical curl command results in a node of ModelType.OBJECT.
> {code}
> "address":[{"subsystem":"resource-adapters"},{"resource-adapter":"my-adapter"}]
> {code}
> That get(0) call fails on ModelType.OBJECT. It's quite the quirk that it works for ModelType.PROPERTY.
> I'll replace that logic with standard stuff using PathAddress.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFCORE-51) Improve error message for bad/incomplete XML in deployment scanner
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-51?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved WFLY-882 to WFCORE-51:
---------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-51 (was: WFLY-882)
> Improve error message for bad/incomplete XML in deployment scanner
> ------------------------------------------------------------------
>
> Key: WFCORE-51
> URL: https://issues.jboss.org/browse/WFCORE-51
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Filip Nguyen
> Assignee: Emmanuel Hugonnet
> Priority: Trivial
> Attachments: loop-vdb.xml
>
>
> Deploying VDB with invalid XML (closed translator tag). Causes following error:
> [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015009: Scan found incompletely copied file content for deployment standalone/deployments/loop-vdb.xml. Deployment changes will not be processed until all content is complete.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (JBMETA-363) Validation errors with "jboss-web_7_0.xsd
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/JBMETA-363?page=com.atlassian.jira.plugin... ]
Wolfgang Knauf commented on JBMETA-363:
---------------------------------------
First of all: Eclipse cannot find the XSD in the web, because it is not published to the JBoss website. But JBossTools extends the Eclipse schema catalog with all JBoss XSDs. So it finds the XSD there (using the schema location URL as a lookup key).
I think the problem arises because of the way you include e.g. "web-app_3_1.xsd": you use just the XSD name, without a url. This is a "relative path", thus, the Eclipse validator seeks it at the same location as "jboss_web_7_1.xsd", which would be inside some JAR file of the JBossTools schema catalog plugin. But JBossTools does NOT bundle the JavaEE standard schemas, because they are already part of the Eclipse WebTools Platform plugin.
You could work around this by including the JavaEE xsds with a "full path", e.g. "http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd". This full path can be found on the web, and is also a valid lookup key to the Eclipse schema catalog.
Hope that I could clarify my point of view ;-)
> Validation errors with "jboss-web_7_0.xsd
> -----------------------------------------
>
> Key: JBMETA-363
> URL: https://issues.jboss.org/browse/JBMETA-363
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: web
> Affects Versions: 7.0.5.Final, 8.1.0.Beta1
> Environment: Eclipse
> Reporter: Wolfgang Knauf
> Assignee: Jean-Frederic Clere
>
> I tried to create a "jboss-web.xml" file based on the "jboss-web_7_1.xsd"
> As this is not uploaded to the web up to now, I created it with a schema location pointing to my local JBoss 7.2.0Alpha1 snapshot:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee file:///C:/Temp/jboss-as-7.2.0.Alpha1-SNAPSHOT/docs/schema/jboss-web_7_0.xsd"
> version="7.0">
> ...
> </jboss-web>
> Eclipse shows validation errors in the XSD file.
> The first on is:
> sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two
> occurences of 'http://java.sun.com/xml/ns/javaee,descriptionGroup'
> (occurs in javaee_6.xsd, line 88)
> And a lot more of those.
> The file was created as part of https://issues.jboss.org/browse/AS7-1262 - and the one who created it found the same validation error.
> It seems the fix is quite simple:
> "jboss-web_7_0.xsd" contains this import:
> <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="web-app_3_0.xsd"/>
> Change it to:
> <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"/>
> The reason seems to be: "jboss-web_7_0.xsd" imports "jboss-common_6-0.xsd", and this one imports "javaee_6.xsd" with a full schema location.
> The "web-app_3_0.xsd" in "jboss-web_7_0.xsd" has a local schema location, thus the "javaee_6.xsd" import in "web-app_3_0.xsd" points also to local.
> And this seems to cause a duplicate import of the file.
> (might also be an Eclipse valiation bug)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3721) CommandDispatcher hides exceptions
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3721?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-3721:
------------------------------------
I think the clearest strategy is to throw an exception. We should keep this behavior consistent with all of the methods on CommandDispatcher. This also draws a clear distinction between a sender exceptions vs receiver-specific exceptions, the latter of which are exposed by the ExecutionException thrown by Future.get() or CommandResponse.get().
> CommandDispatcher hides exceptions
> ----------------------------------
>
> Key: WFLY-3721
> URL: https://issues.jboss.org/browse/WFLY-3721
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.1.0.Final
> Reporter: Rich DiCroce
> Assignee: Paul Ferraro
>
> The implementations of CommandDispatcher#submitOnCluster and #executeOnCluster completely hide any exceptions that occur while trying to send the command. This makes it very difficult to debug things like serialization exceptions. (Note: In the 8.x branch, the implementation is in ServiceCommandDispatcher. In master, it has moved to ChannelCommandDispatcher, but the code is essentially the same and the issue still exists.)
> Instead of hiding the exception, the implementation should expose the exception to the developer in some way. A couple possibilities:
> - Don't catch the exception.
> - Catch the exception and return a Map with one entry, where the key is the local node and the value is a Future or CommandResponse that contains the exception.
> - Catch the exception and return an empty map, but also log the exception.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3718) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3718?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-3718.
------------------------------
Fix Version/s: 8.2.0.CR1
Resolution: Duplicate Issue
Duplicate of WFLY-3345
> UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3718
> URL: https://issues.jboss.org/browse/WFLY-3718
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: WildFly 8.1.0.Final
> Reporter: Gabor Auth
> Assignee: Paul Ferraro
> Fix For: 8.2.0.CR1
>
>
> 2014-07-30 02:12:30,088 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:62) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
> 2014-07-30 02:12:30,786 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /frontend/images/favicon.ico}: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:711)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:137)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months