[JBoss JIRA] (WFCORE-593) Inconsistent DMR response structure
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-593?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet resolved WFCORE-593.
--------------------------------------
Fix Version/s: 1.0.0.Beta1
Resolution: Cannot Reproduce Bug
> Inconsistent DMR response structure
> -----------------------------------
>
> Key: WFCORE-593
> URL: https://issues.jboss.org/browse/WFCORE-593
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: ehsavoie Hugonnet
> Fix For: 1.0.0.Beta1
>
>
> {noformat}
> {
> "address" => [
> ("profile" => "full"),
> ("subsystem" => "ejb3"),
> ("service" => "*")
> ],
> "operation" => "read-resource-description"
> }
> {
> "outcome" => "success",
> "result" => {
> "outcome" => "failed",
> "failure-description" => "JBAS014883: No resource definition is registered for address [
> (\"profile\" => \"full\"),
> (\"subsystem\" => \"ejb3\"),
> (\"service\" => \"*\")
> ]",
> "rolled-back" => true
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFCORE-593) Inconsistent DMR response structure
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-593?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFCORE-593:
------------------------------------------
Can't reproduce it against current WildFly.
> Inconsistent DMR response structure
> -----------------------------------
>
> Key: WFCORE-593
> URL: https://issues.jboss.org/browse/WFCORE-593
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: ehsavoie Hugonnet
>
> {noformat}
> {
> "address" => [
> ("profile" => "full"),
> ("subsystem" => "ejb3"),
> ("service" => "*")
> ],
> "operation" => "read-resource-description"
> }
> {
> "outcome" => "success",
> "result" => {
> "outcome" => "failed",
> "failure-description" => "JBAS014883: No resource definition is registered for address [
> (\"profile\" => \"full\"),
> (\"subsystem\" => \"ejb3\"),
> (\"service\" => \"*\")
> ]",
> "rolled-back" => true
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-4289?page=com.atlassian.jira.plugin.... ]
Tomas Hofman reassigned WFLY-4289:
----------------------------------
Assignee: Tomas Hofman (was: Alessio Soldano)
> Authentication bug on one-way JAX-WS methods
> --------------------------------------------
>
> Key: WFLY-4289
> URL: https://issues.jboss.org/browse/WFLY-4289
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web Services
> Affects Versions: 8.2.0.Final
> Reporter: Jakub Grabowski
> Assignee: Tomas Hofman
>
> 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL.
> 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation.
> 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal.
> 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected.
> It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4426) do not revertReloadRequired unless reload was required
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-4426?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-4426:
------------------------------
Priority: Minor (was: Major)
> do not revertReloadRequired unless reload was required
> ------------------------------------------------------
>
> Key: WFLY-4426
> URL: https://issues.jboss.org/browse/WFLY-4426
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 9.0.0.Alpha1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Minor
> Fix For: 9.0.0.Beta1
>
>
> HornetQReloadRequiredHandlers will call context.reloadRequired() if there performRuntime method is called and a HornetQ server service is installed.
> In turn, it calls context.revertReloadRequired() in their rollbackRuntime if a HornetQ server service is installed.
> However it is possible that at boot time, there is not HornetQ server installed when the performRuntime is installed (so context.reloadRequired is not called).
> Then if an operation fails at boot time and the HornetQReloadRequiredHandlers op is rolled back, there will then be an installed HornetQ server and context.revertReloadRequired() will be called.
> This generated a NPE before WFCORE-591 but it is also a programming error to call context.revertReloadRequired() in a OSH if context.reloadRequired() has not been called beforehands
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4426) do not revertReloadRequired unless reload was required
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-4426:
---------------------------------
Summary: do not revertReloadRequired unless reload was required
Key: WFLY-4426
URL: https://issues.jboss.org/browse/WFLY-4426
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 9.0.0.Alpha1
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 9.0.0.Beta1
HornetQReloadRequiredHandlers will call context.reloadRequired() if there performRuntime method is called and a HornetQ server service is installed.
In turn, it calls context.revertReloadRequired() in their rollbackRuntime if a HornetQ server service is installed.
However it is possible that at boot time, there is not HornetQ server installed when the performRuntime is installed (so context.reloadRequired is not called).
Then if an operation fails at boot time and the HornetQReloadRequiredHandlers op is rolled back, there will then be an installed HornetQ server and context.revertReloadRequired() will be called.
This generated a NPE before WFCORE-591 but it is also a programming error to call context.revertReloadRequired() in a OSH if context.reloadRequired() has not been called beforehands
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFCORE-596) ObjectTypeValidator should give a more meaningful error message.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-596?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFCORE-596:
------------------------------------
Description:
Presently the error is reported as: -
{code}
throw new OperationFailedException("invalid type key");
{code}
If you are making a call with a complex object type you have no idea as to what is really wrong.
> ObjectTypeValidator should give a more meaningful error message.
> ----------------------------------------------------------------
>
> Key: WFCORE-596
> URL: https://issues.jboss.org/browse/WFCORE-596
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha19
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> Presently the error is reported as: -
> {code}
> throw new OperationFailedException("invalid type key");
> {code}
> If you are making a call with a complex object type you have no idea as to what is really wrong.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4424) NullPointerException in AbstractCommonConfigResolver.resolveEndpointConfig
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-4424?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-4424:
---------------------------------------
Gytis, please try with https://github.com/asoldano/wildfly/tree/WFLY-4424 , which has a tentative fix for the issue (https://github.com/asoldano/wildfly/commit/393681028b247ae49d9b56dd73b334...). If it solves the problem here as I expect, I can have the new Phase IDs added to wildfly-core and eventually send a proper PR for this jira. Thanks.
> NullPointerException in AbstractCommonConfigResolver.resolveEndpointConfig
> --------------------------------------------------------------------------
>
> Key: WFLY-4424
> URL: https://issues.jboss.org/browse/WFLY-4424
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Reporter: Gytis Trikleris
> Assignee: Alessio Soldano
>
> Lately we started to get following exception in our XTS tests:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."xtstest.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."xtstest.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "xtstest.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.NullPointerException
> at org.jboss.ws.common.configuration.AbstractCommonConfigResolver.resolveEndpointConfig(AbstractCommonConfigResolver.java:129)
> at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_HANDLER.processAnnotation(WSIntegrationProcessorJAXWS_HANDLER.java:95)
> at org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:74)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> ... 5 more
> {code}
> It is intermittent and seems to be caused by some sort of race condition.
> It started to happen once this commit was introduced: https://github.com/wildfly/wildfly/commit/c0c1e82d8472e1b29c679380d5e0aea...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months