[JBoss JIRA] (DROOLS-1228) Entry point update halts the rule Engine
by mithun singh (JIRA)
mithun singh created DROOLS-1228:
------------------------------------
Summary: Entry point update halts the rule Engine
Key: DROOLS-1228
URL: https://issues.jboss.org/browse/DROOLS-1228
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.3.0.Final
Environment: Linux, JBOSS 6.3 EAP, Java 8, Drools 6.2
Reporter: mithun singh
Assignee: Mario Fusco
Priority: Blocker
Attachments: structure.png
1. A Stateful session is created.
2. Facts are loaded to stateful session and after successful loading into session we initiate "*fireUntilHault()*" inorder to fire the rules, where we have about 38 rules.
3. We have configured a queue inorder to receive messages from source system and load the relevant facts into the session by retrieving the entry point from the session, update the fact and set focus to the relevant agenda group.
4. We are not able to update the fact using *"EntryPoint.update(Fact)"*. We could see that this occurs if the rule Engine starts firing facts and we subsequently update the fact in the session.
5. According to drools, rule engine will handle the sequence of updates and firing of rules accordingly.
6. But rule engine comes to halt state and there is no exception related to this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JGRP-2088) ArrayIndexOutOfBoundsException on ClassConfigurator.get()
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2088?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2088:
---------------------------
Fix Version/s: 3.6.11
4.0
> ArrayIndexOutOfBoundsException on ClassConfigurator.get()
> ---------------------------------------------------------
>
> Key: JGRP-2088
> URL: https://issues.jboss.org/browse/JGRP-2088
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Manuel Dominguez Sarmiento
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.xml
>
>
> See the following stack trace:
> [ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1
> java.lang.ArrayIndexOutOfBoundsException: -1
> at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161)
> at org.jgroups.Message.readHeader(Message.java:936)
> at org.jgroups.Message.readFrom(Message.java:811)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712)
> at org.jgroups.protocols.TP.receive(TP.java:1654)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:745)
> Stepping through the code with the debugger shows that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException
> return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic));
> See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1227) Drools cannot be configured to expire Events properly
by Cristobal Arellano (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1227?page=com.atlassian.jira.plugi... ]
Cristobal Arellano commented on DROOLS-1227:
--------------------------------------------
My suggestion is to fix this issue by performing the following change in "org.drools.core.time.TemporalDependencyMatrix" in line 63:
62: // no useful info based on the temporal distance calculation, so return 1 (minimun expiration)
63: expiration = 1;
64: } else if( expiration != Long.MAX_VALUE ) {
> Drools cannot be configured to expire Events properly
> -----------------------------------------------------
>
> Key: DROOLS-1227
> URL: https://issues.jboss.org/browse/DROOLS-1227
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.Final
> Environment: Windows, Java SE 1.8
> Reporter: Cristobal Arellano
> Assignee: Mark Proctor
> Priority: Critical
>
> Hello,
> I want to configure Drools (CEP) to expire events when no longer needed. There are two scenarios:
> ==SCENARIO A==
> I configured Event with no explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is automatically calculated based on the constrains. If there is a rule with no temporal constraints, the expiration is INFINITE. The following example shows the scenario:
> dialect "mvel"
> declare Event
> @role(event)
> end
> rule "ExampleRule1"
> when
> ( $a : Event(name == "event a")
> then
> System.out.println("ExampleRule1Triggered");
> end
> rule "ExampleRule2"
> when
> ( $a : Event(name == "event a") ) and
> ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
> then
> System.out.println("ExampleRule2Triggered");
> end
> With the previous Event definition:
> * If only ExampleRule1 loaded, expires INFINITE. Expected expires 0. ERROR?
> * If ExampleRule1 loaded and ExampleRule2 loaded, expires 15s. Expected expires 15. OK!
> To solve this situation a tried the following scenario:
> == SCENARIO B==
> I configured Event with explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is not taken into account because it is overriden by the explicit expires. The following example shows the scenario:
> dialect "mvel"
> declare Event
> @role(event)
> @expires(0s)
> end
> rule "ExampleRule1"
> when
> ( $a : Event(name == "event a")
> then
> System.out.println("ExampleRule1Triggered");
> end
> rule "ExampleRule2"
> when
> ( $a : Event(name == "event a") ) and
> ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
> then
> System.out.println("ExampleRule2Triggered");
> end
> With the previous Event definition:
> * ExampleRule1 is triggered and event removed. OK!
> * ExampleRule2 is not triggered inserting two events because the first one expires. ERROR?
> I suppose that SCENARIO B is not factible because explicit expires overrides implicit expires (according to issue DROOLS-586).
> Could you please help me to solve this situation? Should Drools set inferred expiration time to 1ms when there are rules with no temporal constraints?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1227) Drools cannot be configured to expire Events properly
by Cristobal Arellano (JIRA)
Cristobal Arellano created DROOLS-1227:
------------------------------------------
Summary: Drools cannot be configured to expire Events properly
Key: DROOLS-1227
URL: https://issues.jboss.org/browse/DROOLS-1227
Project: Drools
Issue Type: Feature Request
Affects Versions: 6.2.0.Final
Environment: Windows, Java SE 1.8
Reporter: Cristobal Arellano
Assignee: Mark Proctor
Priority: Critical
Hello,
I want to configure Drools (CEP) to expire events when no longer needed. There are two scenarios:
==SCENARIO A==
I configured Event with no explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is automatically calculated based on the constrains. If there is a rule with no temporal constraints, the expiration is INFINITE. The following example shows the scenario:
dialect "mvel"
declare Event
@role(event)
end
rule "ExampleRule1"
when
( $a : Event(name == "event a")
then
System.out.println("ExampleRule1Triggered");
end
rule "ExampleRule2"
when
( $a : Event(name == "event a") ) and
( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
then
System.out.println("ExampleRule2Triggered");
end
With the previous Event definition:
* If only ExampleRule1 loaded, expires INFINITE. Expected expires 0. ERROR?
* If ExampleRule1 loaded and ExampleRule2 loaded, expires 15s. Expected expires 15. OK!
To solve this situation a tried the following scenario:
== SCENARIO B==
I configured Event with explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is not taken into account because it is overriden by the explicit expires. The following example shows the scenario:
dialect "mvel"
declare Event
@role(event)
@expires(0s)
end
rule "ExampleRule1"
when
( $a : Event(name == "event a")
then
System.out.println("ExampleRule1Triggered");
end
rule "ExampleRule2"
when
( $a : Event(name == "event a") ) and
( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
then
System.out.println("ExampleRule2Triggered");
end
With the previous Event definition:
* ExampleRule1 is triggered and event removed. OK!
* ExampleRule2 is not triggered inserting two events because the first one expires. ERROR?
I suppose that SCENARIO B is not factible because explicit expires overrides implicit expires (according to issue DROOLS-586).
Could you please help me to solve this situation? Should Drools set inferred expiration time to 1ms when there are rules with no temporal constraints?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1227) Drools cannot be configured to expire Events properly
by Cristobal Arellano (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1227?page=com.atlassian.jira.plugi... ]
Cristobal Arellano updated DROOLS-1227:
---------------------------------------
Issue Type: Bug (was: Feature Request)
> Drools cannot be configured to expire Events properly
> -----------------------------------------------------
>
> Key: DROOLS-1227
> URL: https://issues.jboss.org/browse/DROOLS-1227
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.Final
> Environment: Windows, Java SE 1.8
> Reporter: Cristobal Arellano
> Assignee: Mark Proctor
> Priority: Critical
>
> Hello,
> I want to configure Drools (CEP) to expire events when no longer needed. There are two scenarios:
> ==SCENARIO A==
> I configured Event with no explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is automatically calculated based on the constrains. If there is a rule with no temporal constraints, the expiration is INFINITE. The following example shows the scenario:
> dialect "mvel"
> declare Event
> @role(event)
> end
> rule "ExampleRule1"
> when
> ( $a : Event(name == "event a")
> then
> System.out.println("ExampleRule1Triggered");
> end
> rule "ExampleRule2"
> when
> ( $a : Event(name == "event a") ) and
> ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
> then
> System.out.println("ExampleRule2Triggered");
> end
> With the previous Event definition:
> * If only ExampleRule1 loaded, expires INFINITE. Expected expires 0. ERROR?
> * If ExampleRule1 loaded and ExampleRule2 loaded, expires 15s. Expected expires 15. OK!
> To solve this situation a tried the following scenario:
> == SCENARIO B==
> I configured Event with explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is not taken into account because it is overriden by the explicit expires. The following example shows the scenario:
> dialect "mvel"
> declare Event
> @role(event)
> @expires(0s)
> end
> rule "ExampleRule1"
> when
> ( $a : Event(name == "event a")
> then
> System.out.println("ExampleRule1Triggered");
> end
> rule "ExampleRule2"
> when
> ( $a : Event(name == "event a") ) and
> ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
> then
> System.out.println("ExampleRule2Triggered");
> end
> With the previous Event definition:
> * ExampleRule1 is triggered and event removed. OK!
> * ExampleRule2 is not triggered inserting two events because the first one expires. ERROR?
> I suppose that SCENARIO B is not factible because explicit expires overrides implicit expires (according to issue DROOLS-586).
> Could you please help me to solve this situation? Should Drools set inferred expiration time to 1ms when there are rules with no temporal constraints?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-5739) Subject not populated with groups/roles when authenticated via JASPIC
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-5739?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero updated WFLY-5739:
-----------------------------------------------
Attachment: CustomAuth.zip
picketbox.zip
Hi [~stoty2], I've tested the patch and I confirm it works. However, it still doesn't restore groups
for a given CallerPrincipalCallback called with a principal stored from an earlier request (enabling "javax.servlet.http.registerSession").
To reproduce, compile and deploy CustomAuth war. Update PicketBox module with my attached picketbox.zip (compiled from your GH commit) and follow the steps below:
- Go to /index.jsp and you'll see a login form. Enter anything and a page with the the specified name will be shown. Do a GET request and you'll see the roles are restored.
- You'll be able to see /protected.jsp, which requires "admin" role.
- Now go to /TestServlet. A NullPointerException will be shown, cause groups are not restored.
- Going to /TestServlet?username=Guillermo correctly propagates roles thanks to your patch.
> Subject not populated with groups/roles when authenticated via JASPIC
> ---------------------------------------------------------------------
>
> Key: WFLY-5739
> URL: https://issues.jboss.org/browse/WFLY-5739
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.CR4
> Reporter: Arjan t
> Assignee: Darran Lofthouse
> Labels: jacc, jaspic
> Attachments: CustomAuth.zip, picketbox.zip
>
>
> After having authenticated via JASPIC, requesting the current {{Subject}} via JACC and then using that for permission checks fails.
> For instance the following code will always set {{hasAccess}} to false given that "/protected/*" requires a role and the authenticated user is in that role:
> {code:java}
> Subject subject = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container");
>
> boolean hasAccess = Policy.getPolicy().implies(
> new ProtectionDomain(
> new CodeSource(null, (Certificate[]) null),
> null, null,
> subject.getPrincipals().toArray(new Principal[subject.getPrincipals().size()])
> ),
> new WebResourcePermission("/protected/Servlet", "GET"))
> ;
> {code}
> As it appears, the problem originates from the fact that {{subject.getPrincipals()}} does not contain the roles.
> This can be traced back to {{org.jboss.security.auth.callback.JASPICallbackHandler.handleCallBack}}, where it becomes clear that the roles are only put into the "util", but not in the "authenticatedSubject":
> {code:java}
> String[] rolesArray = groupPrincipalCallback.getGroups();
> int sizeOfRoles = rolesArray != null ? rolesArray.length : 0;
>
> if( sizeOfRoles > 0 )
> {
> List<Role> rolesList = new ArrayList<Role>();
> for( int i = 0; i < sizeOfRoles ; i++ )
> {
> Role role = new SimpleRole( rolesArray[ i ] );
> rolesList.add( role );
> }
> RoleGroup roles = new SimpleRoleGroup( SecurityConstants.ROLES_IDENTIFIER, rolesList );
> // if the current security context already has roles, we merge them with the incoming roles.
> RoleGroup currentRoles = currentSC.getUtil().getRoles();
> // *** ROLES ARE ONLY SET HERE ***
> if (currentRoles != null) {
> currentRoles.addAll(roles.getRoles());
> }
> else {
> currentSC.getUtil().setRoles( roles );
> }
> }
> // *** BELOW THIS LINE ROLES ARE NOT REFERENCED ANYMORE
> // *** SUBJECT IS NOT POPULATED WITH ANY ROLE INFO
> Subject subject = groupPrincipalCallback.getSubject();
> if( subject != null )
> {
> // if the current security context already has an associated subject, we merge it with the incoming subject.
> Subject currentSubject = currentSC.getSubjectInfo().getAuthenticatedSubject();
> if (currentSubject != null) {
> subject.getPrincipals().addAll(currentSubject.getPrincipals());
> subject.getPublicCredentials().addAll(currentSubject.getPublicCredentials());
> subject.getPrivateCredentials().addAll(currentSubject.getPrivateCredentials());
> }
> currentSC.getSubjectInfo().setAuthenticatedSubject(subject);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JGRP-2088) ArrayIndexOutOfBoundsException on ClassConfigurator.get()
by Manuel Dominguez Sarmiento (JIRA)
Manuel Dominguez Sarmiento created JGRP-2088:
------------------------------------------------
Summary: ArrayIndexOutOfBoundsException on ClassConfigurator.get()
Key: JGRP-2088
URL: https://issues.jboss.org/browse/JGRP-2088
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.10
Reporter: Manuel Dominguez Sarmiento
Assignee: Bela Ban
Attachments: jgroups.xml
See the following stack trace:
[ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1
java.lang.ArrayIndexOutOfBoundsException: -1
at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161)
at org.jgroups.Message.readHeader(Message.java:936)
at org.jgroups.Message.readFrom(Message.java:811)
at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712)
at org.jgroups.protocols.TP.receive(TP.java:1654)
at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
at java.lang.Thread.run(Thread.java:745)
Stepping through the code with the debugger should that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException
return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic));
See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JGRP-2088) ArrayIndexOutOfBoundsException on ClassConfigurator.get()
by Manuel Dominguez Sarmiento (JIRA)
[ https://issues.jboss.org/browse/JGRP-2088?page=com.atlassian.jira.plugin.... ]
Manuel Dominguez Sarmiento updated JGRP-2088:
---------------------------------------------
Description:
See the following stack trace:
[ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1
java.lang.ArrayIndexOutOfBoundsException: -1
at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161)
at org.jgroups.Message.readHeader(Message.java:936)
at org.jgroups.Message.readFrom(Message.java:811)
at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712)
at org.jgroups.protocols.TP.receive(TP.java:1654)
at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
at java.lang.Thread.run(Thread.java:745)
Stepping through the code with the debugger shows that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException
return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic));
See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine.
was:
See the following stack trace:
[ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1
java.lang.ArrayIndexOutOfBoundsException: -1
at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161)
at org.jgroups.Message.readHeader(Message.java:936)
at org.jgroups.Message.readFrom(Message.java:811)
at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712)
at org.jgroups.protocols.TP.receive(TP.java:1654)
at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
at java.lang.Thread.run(Thread.java:745)
Stepping through the code with the debugger should that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException
return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic));
See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine.
> ArrayIndexOutOfBoundsException on ClassConfigurator.get()
> ---------------------------------------------------------
>
> Key: JGRP-2088
> URL: https://issues.jboss.org/browse/JGRP-2088
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Manuel Dominguez Sarmiento
> Assignee: Bela Ban
> Attachments: jgroups.xml
>
>
> See the following stack trace:
> [ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1
> java.lang.ArrayIndexOutOfBoundsException: -1
> at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161)
> at org.jgroups.Message.readHeader(Message.java:936)
> at org.jgroups.Message.readFrom(Message.java:811)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712)
> at org.jgroups.protocols.TP.receive(TP.java:1654)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:745)
> Stepping through the code with the debugger shows that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException
> return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic));
> See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1615) Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1615?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1615:
----------------------------------------
Fix Version/s: 3.0.0.Alpha4
Assignee: Jorge Solorzano
Resolution: Done
> Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh
> ------------------------------------------------------------------
>
> Key: WFCORE-1615
> URL: https://issues.jboss.org/browse/WFCORE-1615
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 3.0.0.Alpha2
> Reporter: Jorge Solorzano
> Assignee: Jorge Solorzano
> Priority: Trivial
> Fix For: 3.0.0.Alpha4
>
>
> To make both scripts more consistent in terms of functionality.
> Changes include:
> * Add LSB INIT INFO
> * Validate user and permisions.
> * Make output of status more standard.
> * Improve output messages.
> * Include WFCORE-1604
> Tested enviroments:
> * CentOS 6.8
> * CentOS 7.2
> * Fedora 24 Server
> The script should be functional on both pre-systemd and systemd without weird behaivior.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1604) Fail-fast start up init.d scripts on error
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1604?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1604:
----------------------------------------
Assignee: Jorge Solorzano (was: Tomaz Cerar)
> Fail-fast start up init.d scripts on error
> ------------------------------------------
>
> Key: WFCORE-1604
> URL: https://issues.jboss.org/browse/WFCORE-1604
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 3.0.0.Alpha1
> Environment: Debian/Ubuntu - Red Hat/Fedora
> Reporter: Jorge Solorzano
> Assignee: Jorge Solorzano
> Priority: Optional
> Fix For: 3.0.0.Alpha4
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Now that WildFly creates an startup-marker we can detect an error before timeout of the init.d startup scripts and detect if the error is from timeout or from an error in application server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months