[JBoss JIRA] (WFCORE-1109) After a successful start up allow an interceptor to be called
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1109?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-1109.
--------------------------------------
Resolution: Duplicate Issue
Resolving as a duplicate as WFCORE-1405 will cover this.
> After a successful start up allow an interceptor to be called
> -------------------------------------------------------------
>
> Key: WFCORE-1109
> URL: https://issues.jboss.org/browse/WFCORE-1109
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Shaun Appleton
>
> On start-up some other systems need to be notified that the start-up was successful.
> This is a request to allow an interceptor to be defined in the standalone*.xml file that could be called on a successful start-up.
> If the startup was unsuccessful ie had any errors the interceptor would not be called.
> Whether the startup is successful can be found out by the following cli command
> /core-service=management:read-boot-errors
> So the information on whether to call the interceptor or not is already known.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1065) ClasspathKieProject should not deal ".jar" always like a file
by Tomas Cerny (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1065?page=com.atlassian.jira.plugi... ]
Tomas Cerny commented on DROOLS-1065:
-------------------------------------
One workaround seems to be JRebel, that one translates Jar to target/classes and seems to do its job to pass through well
> ClasspathKieProject should not deal ".jar" always like a file
> -------------------------------------------------------------
>
> Key: DROOLS-1065
> URL: https://issues.jboss.org/browse/DROOLS-1065
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Beta1
> Reporter: Petr Široký
> Assignee: Petr Široký
> Fix For: 7.0.0.Final
>
>
> Originally reported and fixed by David Santos (thanks!) via https://github.com/droolsjbpm/drools/pull/511
> Description:
> Some containers allow deployments of artifacts in "expanded" mode (instead of a unique jar/ear/war/... file, al artifacts are deployed full decompressed, so they are directories). This is default with last JBoss Tools and Wildfly (unless you use compressed option for deployments). In that case drools fails to load jar contents.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1419) Operations helper should not add attributes to operations that weren't specifically defined
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1419?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1419:
------------------------------------------
Brian Stansberry
2:55 PM
I don't get what the bug is
James R Perkins
2:56 PM
If you were to use the Operations.createReadResourceOperation(someAddress).get("recursive-depth").set(5) it wouldn't work because by default it sets recursive=false.
> Operations helper should not add attributes to operations that weren't specifically defined
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-1419
> URL: https://issues.jboss.org/browse/WFCORE-1419
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: James Perkins
> Assignee: James Perkins
>
> The {{org.jboss.as.controller.client.helpers.Operations}} helper adds the {{recursive}} attribute the the {{read-resource}} operation regardless of whether or not the user specified if the operation should be recursive. This attribute should not be set by default.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month