[JBoss JIRA] (WFCORE-1879) Master HC should reject registration attempts by slaves that have any management API version greater than its own
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1879:
----------------------------------------
Summary: Master HC should reject registration attempts by slaves that have any management API version greater than its own
Key: WFCORE-1879
URL: https://issues.jboss.org/browse/WFCORE-1879
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Ken Wills
(Note: It's possible we already do this, or that somehow we effectively do due to things blowing up if the rule is broken.)
We have always had a rule that the DC must be running the latest version of the software. If it isn't it can't reliably manage slaves as it cannot know how the slaves will interpret the operations it sends to them, and slaves will assume that the master is sending operations that are tailored to the management API versions it sent when it registered.
I do not believe the software actually enforces this requirement though. With the more complex use cases that WFCORE-338 will introduce we need to make this more formal.
When a slave first contacts a master it provides its kernel API version with the HostInfo data it sends over and then later in the registration process it provides the subsystem API versions for all the extensions the master provided. Both of these points provide an opportunity for version comparison.
When an HC rejects registration by a slave, we have a mechanism for propogating an error code to the slave to help it understand and report the problem (e.g. the remote HC is not master or it is running in admin-only mode.) We should try to expand that mechanism to include this case, rather than failing with a general unspecified error.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7304) Compensations subsystem
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7304?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-7304:
-----------------------------------
Why whole new subsystem? having sub resource in transactions subsystem doesn't cut it?
> Compensations subsystem
> -----------------------
>
> Key: WFLY-7304
> URL: https://issues.jboss.org/browse/WFLY-7304
> Project: WildFly
> Issue Type: Task
> Components: Transactions
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> Currently compensations bootstrap happens in the transactions subsystem. It registers deployment processor to scan the annotations and add the dependencies if necessary. This is not expensive and doesn't cause any issues other than adding the dependencies to the transactions subsystem. However, I'm currently finishing off the recovery implementation and more bootstrap logic will be needed. In addition, two more recovery modules will have to be registered: one for the participant (a new one) and one for the coordinator (from XTS). This will require to add XTS dependency too.
> The whole compensations bootstrapping will not need a lot of code. However, I'm thinking maybe it would be good to pull it out to the separate subsystem in order to maintain the separation of concerns.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7349) configurable-sasl-server-factory cannot set mechanism information
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7349?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7349:
-----------------------------
Description:
sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following factory in chain but with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
*The problem is,* if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}
Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)
was:
sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
*The problem is,* if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}
Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)
> configurable-sasl-server-factory cannot set mechanism information
> -----------------------------------------------------------------
>
> Key: WFLY-7349
> URL: https://issues.jboss.org/browse/WFLY-7349
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Attachments: sasl-test.xml, SaslTestCase.java
>
>
> sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following factory in chain but with rewriting of the server name.
> In this chain is also *SetMechanismInformationSaslServerFactory*, which call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
> *The problem is,* if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
> The chain of SaslServerFactories:
> {code:java}
> AuthenticationTimeoutSSF
> TrustManagerSSF
> AuthenticationCompleteSSF
> SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
> ServerNameSSF
> ProtocolSSF
> SetMechanismInformationSSF => cbh => "Too late to set" => return null
> SecurityProviderSSF
> {code}
> Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7349) configurable-sasl-server-factory cannot set mechanism information
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7349?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7349:
-----------------------------
Description:
sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
The problem is, if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}
Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)
was:
sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
The problem is, if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}
> configurable-sasl-server-factory cannot set mechanism information
> -----------------------------------------------------------------
>
> Key: WFLY-7349
> URL: https://issues.jboss.org/browse/WFLY-7349
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Attachments: sasl-test.xml, SaslTestCase.java
>
>
> sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
> In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
> The problem is, if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
> The chain of SaslServerFactories:
> {code:java}
> AuthenticationTimeoutSSF
> TrustManagerSSF
> AuthenticationCompleteSSF
> SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
> ServerNameSSF
> ProtocolSSF
> SetMechanismInformationSSF => cbh => "Too late to set" => return null
> SecurityProviderSSF
> {code}
> Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7349) configurable-sasl-server-factory cannot set mechanism information
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7349?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7349:
-----------------------------
Description:
sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
*The problem is,* if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}
Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)
was:
sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
The problem is, if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}
Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)
> configurable-sasl-server-factory cannot set mechanism information
> -----------------------------------------------------------------
>
> Key: WFLY-7349
> URL: https://issues.jboss.org/browse/WFLY-7349
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Attachments: sasl-test.xml, SaslTestCase.java
>
>
> sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
> In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
> *The problem is,* if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
> The chain of SaslServerFactories:
> {code:java}
> AuthenticationTimeoutSSF
> TrustManagerSSF
> AuthenticationCompleteSSF
> SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
> ServerNameSSF
> ProtocolSSF
> SetMechanismInformationSSF => cbh => "Too late to set" => return null
> SecurityProviderSSF
> {code}
> Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7349) configurable-sasl-server-factory cannot set mechanism information
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7349?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7349:
-----------------------------
Attachment: sasl-test.xml
SaslTestCase.java
> configurable-sasl-server-factory cannot set mechanism information
> -----------------------------------------------------------------
>
> Key: WFLY-7349
> URL: https://issues.jboss.org/browse/WFLY-7349
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Attachments: sasl-test.xml, SaslTestCase.java
>
>
> sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
> In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
> The problem is, if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
> The chain of SaslServerFactories:
> {code:java}
> AuthenticationTimeoutSSF
> TrustManagerSSF
> AuthenticationCompleteSSF
> SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
> ServerNameSSF
> ProtocolSSF
> SetMechanismInformationSSF => cbh => "Too late to set" => return null
> SecurityProviderSSF
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7349) configurable-sasl-server-factory cannot set mechanism information
by Jan Kalina (JIRA)
Jan Kalina created WFLY-7349:
--------------------------------
Summary: configurable-sasl-server-factory cannot set mechanism information
Key: WFLY-7349
URL: https://issues.jboss.org/browse/WFLY-7349
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Jan Kalina
Assignee: Jan Kalina
sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
The problem is, if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7304) Compensations subsystem
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/WFLY-7304?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on WFLY-7304:
---------------------------------------
I doubt it, but not sure how to confirm it.
The only functionality for this was to add dependency on org.jboss.narayana.compensations module, if deployment had a certain annotation. It was a part of transactions subsystem, but it wasn't configurable in any way.
> Compensations subsystem
> -----------------------
>
> Key: WFLY-7304
> URL: https://issues.jboss.org/browse/WFLY-7304
> Project: WildFly
> Issue Type: Task
> Components: Transactions
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> Currently compensations bootstrap happens in the transactions subsystem. It registers deployment processor to scan the annotations and add the dependencies if necessary. This is not expensive and doesn't cause any issues other than adding the dependencies to the transactions subsystem. However, I'm currently finishing off the recovery implementation and more bootstrap logic will be needed. In addition, two more recovery modules will have to be registered: one for the participant (a new one) and one for the coordinator (from XTS). This will require to add XTS dependency too.
> The whole compensations bootstrapping will not need a lot of code. However, I'm thinking maybe it would be good to pull it out to the separate subsystem in order to maintain the separation of concerns.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1336) Globals variables are not present in Globals Data View
by Tomas David (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1336?page=com.atlassian.jira.plugi... ]
Tomas David updated DROOLS-1336:
--------------------------------
Description:
I just create this issue since this is problem which is present for very long time but I can't find the corresponding issue in Bugzilla or Jira.
If global variables are used in drools project and it is debugged. No global variables are present in Global Data View.
was:
I just create this issue since this is problem which is present for very long time but I can't find corresponding issue in Bugzilla or Jira.
If global variables are used in drools project and it is debugged. No global variables are present in Global Data View.
> Globals variables are not present in Globals Data View
> ------------------------------------------------------
>
> Key: DROOLS-1336
> URL: https://issues.jboss.org/browse/DROOLS-1336
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Reporter: Tomas David
> Assignee: Robert (Bob) Brodt
> Labels: reported-by-qe
> Attachments: globals.png
>
>
> I just create this issue since this is problem which is present for very long time but I can't find the corresponding issue in Bugzilla or Jira.
> If global variables are used in drools project and it is debugged. No global variables are present in Global Data View.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1336) Globals variables are not present in Globals Data View
by Tomas David (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1336?page=com.atlassian.jira.plugi... ]
Tomas David updated DROOLS-1336:
--------------------------------
Description:
I just create this issue since this is problem which is present for very long time but I can't find corresponding issue in Bugzilla or Jira.
If global variables are used in drools project and it is debugged. No global variables are present in Global Data View.
was:
I just create this issue since this is problem which is present for very long time but I can't find
corresponding issue in Bugzilla or Jira.
If global variables are used in drools project and it is debugged. No global variables are present in Global Data View.
> Globals variables are not present in Globals Data View
> ------------------------------------------------------
>
> Key: DROOLS-1336
> URL: https://issues.jboss.org/browse/DROOLS-1336
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Reporter: Tomas David
> Assignee: Robert (Bob) Brodt
> Labels: reported-by-qe
> Attachments: globals.png
>
>
> I just create this issue since this is problem which is present for very long time but I can't find corresponding issue in Bugzilla or Jira.
> If global variables are used in drools project and it is debugged. No global variables are present in Global Data View.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months