[JBoss JIRA] (WFLY-4427) Step status of the failed step by <fail> element becomes COMPLETED.
by Takashi Nishigaya (JIRA)
[ https://issues.jboss.org/browse/WFLY-4427?page=com.atlassian.jira.plugin.... ]
Takashi Nishigaya updated WFLY-4427:
------------------------------------
Attachment: batch-restart-failed.zip
> Step status of the failed step by <fail> element becomes COMPLETED.
> -------------------------------------------------------------------
>
> Key: WFLY-4427
> URL: https://issues.jboss.org/browse/WFLY-4427
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 8.2.0.Final
> Reporter: Takashi Nishigaya
> Assignee: Cheng Fang
> Attachments: batch-restart-failed.zip
>
>
> Assuming the following job definition, if STEP1 returns "1" as the exit status, the job status becomes FAILED. But the step status is COMPLETED.
> {noformat}
> job status: FAILED
> step: STEP1, step status: COMPLETED
> {noformat}
> {noformat}
> <job id="batch-job1" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/jobXML_1_0.xsd ">
> <step id="STEP1">
> <batchlet ref="TestBatchlet1" />
> <next on="0" to="STEP2" />
> <fail on="1" exit-status="FAILED_BY_EXIT_STATUS" />
> </step>
> <step id="STEP2">
> <batchlet ref="TestBatchlet2" />
> </step>
> </job>
> {noformat}
> In this case, we can not restart the failed job from the failed step STEP1.
> This behavior is correct based on the description of 10.8 Restart Processing, 3. a. in JSR 352.
> But it is not expected result.
> {quote}
> 10.8 Restart Processing
> 3. Starting at the restart position, each execution element is re-examined to determine if it should re-execute:
> a. If the execution element is a COMPLETED step that specifies allow-restart-if- complete=false, then follow the transition to the next
> execution element based on the exit status for this step from the previous execution.
> {quote}
> On the other hand, If the STEP1 is failed by throwing an exception, both of the resulting job status and the step status are FAILED.
> {noformat}
> job status: FAILED
> step: STEP1, step status: FAILED
> {noformat}
> In this case, restarting the failed job is correctly executed, because the step status is FAILED.
> I think the step status of the failed step should be FAILED in both cases. But the section "8.6.2 Fail Element" of JSR352 says nothing about what step status value must be exposed after failed.
> This behavior is the same in GlassFish 4 and WildFly 8.2.
> So, I want to know what is the correct specification or intended behavior.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-4427) Step status of the failed step by <fail> element becomes COMPLETED.
by Takashi Nishigaya (JIRA)
Takashi Nishigaya created WFLY-4427:
---------------------------------------
Summary: Step status of the failed step by <fail> element becomes COMPLETED.
Key: WFLY-4427
URL: https://issues.jboss.org/browse/WFLY-4427
Project: WildFly
Issue Type: Bug
Components: Batch
Affects Versions: 8.2.0.Final
Reporter: Takashi Nishigaya
Assignee: Cheng Fang
Assuming the following job definition, if STEP1 returns "1" as the exit status, the job status becomes FAILED. But the step status is COMPLETED.
{noformat}
job status: FAILED
step: STEP1, step status: COMPLETED
{noformat}
{noformat}
<job id="batch-job1" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/jobXML_1_0.xsd ">
<step id="STEP1">
<batchlet ref="TestBatchlet1" />
<next on="0" to="STEP2" />
<fail on="1" exit-status="FAILED_BY_EXIT_STATUS" />
</step>
<step id="STEP2">
<batchlet ref="TestBatchlet2" />
</step>
</job>
{noformat}
In this case, we can not restart the failed job from the failed step STEP1.
This behavior is correct based on the description of 10.8 Restart Processing, 3. a. in JSR 352.
But it is not expected result.
{quote}
10.8 Restart Processing
3. Starting at the restart position, each execution element is re-examined to determine if it should re-execute:
a. If the execution element is a COMPLETED step that specifies allow-restart-if- complete=false, then follow the transition to the next
execution element based on the exit status for this step from the previous execution.
{quote}
On the other hand, If the STEP1 is failed by throwing an exception, both of the resulting job status and the step status are FAILED.
{noformat}
job status: FAILED
step: STEP1, step status: FAILED
{noformat}
In this case, restarting the failed job is correctly executed, because the step status is FAILED.
I think the step status of the failed step should be FAILED in both cases. But the section "8.6.2 Fail Element" of JSR352 says nothing about what step status value must be exposed after failed.
This behavior is the same in GlassFish 4 and WildFly 8.2.
So, I want to know what is the correct specification or intended behavior.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFCORE-597) Where an ObjectTypeAttributeDefinition is in use respect the ResourceOnly setting on contained types for add operations.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-597:
---------------------------------------
Summary: Where an ObjectTypeAttributeDefinition is in use respect the ResourceOnly setting on contained types for add operations.
Key: WFCORE-597
URL: https://issues.jboss.org/browse/WFCORE-597
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Tomaz Cerar
Fix For: 1.0.0.Beta1
If an ObjectTypeAttributeDefinition contains an attribute definition that has ResourceOnly set then it should be filtered from the automatically generated description for the add operation.
This may be more related to lists, I currently have: -
ObjectListAttributeDefinition, which contains ObjectTypeAttributeDefinition, which contains SimpleAttributeDefinition
It is this final SimpleAttributeDefinition that has ResourceOnly set but it is still showing up in the operation description for add.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 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 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)
9 years, 8 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)
9 years, 8 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)
9 years, 8 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)
9 years, 8 months