[JBoss JIRA] (WFLY-3384) Problem with ServiceBasedNamingStore and JNDIView.
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3384?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned WFLY-3384:
----------------------------------
Assignee: Paul Ferraro (was: Eduardo Martins)
> Problem with ServiceBasedNamingStore and JNDIView.
> --------------------------------------------------
>
> Key: WFLY-3384
> URL: https://issues.jboss.org/browse/WFLY-3384
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Environment: WildFly8.0.0, JDK8
> Reporter: Sławomir Wojtasiak
> Assignee: Paul Ferraro
>
> Some of the registered services are bound to the JNDI using the BinderService and the dependency mechanism to run the binder as soon as the main service runs. At this point everything works like a harm; services are registered and started successfully. But there is a little inconsistency, at least from the JNDI point of view which leads to a specific problem.
> Let's take a look at the following services:
> {quote}
> jboss.clustering.group.ejb.dist@a59ab61 State: UP (Uses: BinderService => JNDI: jboss.naming.context.java.jboss.clustering.group.ejb.dist)
> jboss.clustering.group.ejb@60e172ee State: DOWN (Uses: BinderService => JNDI: jboss.naming.context.java.jboss.clustering.group.ejb)
> {quote}
> As you can see they share the same path in the naming context (*jboss.naming.context.java.jboss.clustering.group.ejb*.dist). The second service _jboss.naming.context.java.jboss.clustering.group.ejb_ is a parent naming context to the first one: _jboss.naming.context.java.jboss.clustering.group.ejb.dist_. To make matters worse they do not depend on themselves, so when _jboss.clustering.group.ejb.dist_ is requested to be started (for instance by _jboss.clustering.providers.ejb.dist_ service) it starts immediately but _jboss.clustering.group.ejb_ is left in the WAITING state (It's ON_DEMAND service.). It leads to a situation where only the _jboss.clustering.group.ejb.dist_ service is registered in the naming context, but both services exist in the service registry.
> Such naming conflict can be a problem when for example we have to traverse through the naming context using ServiceBasedNamingStore as a naming provider. (JNDIView is a good example here, but I also managed to reproduce the problem when I messed up something with the remoting configuration. I don't remember details now.)
> JNDIView uses Context.list("") method in order to get the first level from the naming context. So in case of the _jboss.clustering.group.ejb.dist_ service the traverse path would be as follows:
> context.list("") -> returns "clustering"
> context.lookup( "clustering" ) returns NamingContext("clustering") because there is no service "jboss.clustering".
> NamingContext("clustering").list("") -> returns "group"
> NamingContext("clustering").lookup( "group" ) returns NamingContext("clustering/group") because there is no service "jboss.clustering.group".
> NamingContext("clustering/group").list("") -> returns "ejb"
> NamingContext("clustering/group").lookup("ejb") -> Fails!
> It fails with an _NameNotFoundException_ simply because the first thing the ServiceBasedNamingStore component does is to check if there is the _jboss.naming.context.java.jboss.clustering.group.ejb_ service in the service registry. It is available in the registry so ServiceBasedNamingStore decides to get the destination service instance the BinderService (_jboss.naming.context.java.jboss.clustering.group.ejb_) should point to. Service _jboss.clustering.group.ejb_ hasn't been started yet so its dependant the BinderService (_jboss.naming.context.java.jboss.clustering.group.ejb.dist_) couldn't resolve the injections and as so the BinderService does not point to the destination _jboss.clustering.group.ejb_ service instance. In the result, it ends with the exception because ServiceBasedNamingStore is not able to return the reference to the service the JNDI name _jboss.naming.context.java.jboss.clustering.group.ejb_ should point to. Notice that everything would be OK if there weren't running _jboss.naming.context.java.jboss.clustering.group.ejb.dist_ service, because Context.list("") ignores the _jboss.naming.context.java.jboss.clustering.group.ejb_ service as an unbound one.
> Anyway even if the service _jboss.naming.context.java.jboss.clustering.group.ejb_ was started properly and the naming context pointed to the _jboss.clustering.group.ejb_ service, it would lead to a different problem. The name _jboss.naming.context.java.jboss.clustering.group.ejb.dist_ wouldn't be found at all, because the _jboss.naming.context.java.jboss.clustering.group.ejb_ name would be treated as the end of the path while traversing using the Context.list("") method.
> It's probably a problem with the service naming convention, but anyway it is not an isolated case. There are a lot of services that follow the same naming rules but fortunately they are not registered in the naming context (yet?). For instance:
> {quote}
> jboss.clustering.group.hibernate.entity
> jboss.clustering.group.hibernate.timestamps
> jboss.clustering.group.hibernate
> {quote}
> Introducing something like a value aware NamingContext would also do the trick, but it's not natural for the JNDI.
> Anyway, it can be fixed in many ways, so for now I decided just to ignore such problematic services in the JNDIViewOperation just to avoid the exception.
> If anyone needs a workaround:
> Class: org.jboss.as.naming.management.JndiViewOperation
> jar: wildflay-naming-8.0.0.Final.jar
> Before (Line: 134):
> {code:title=org.jboss.as.naming.management.JndiViewOperation.java|borderStyle=solid}
> final Object value;
> if(context instanceof NamingContext) {
> value = ((NamingContext)context).lookup(pair.getName(), false);
> } else {
> value = context.lookup(pair.getName());
> }
> {code}
> After:
> {code:title=org.jboss.as.naming.management.JndiViewOperation.java|borderStyle=solid}
> Object value;
> try {
> if(context instanceof NamingContext) {
> value = ((NamingContext)context).lookup(pair.getName(), false);
> } else {
> value = context.lookup(pair.getName());
> }
> } catch( NameNotFoundException exc ) {
> value = null;
> }
> {code}
> It is the original exception:
> {noformat}
> 23:44:29,133 ERROR [stderr] (XNIO-1 task-8) javax.naming.NameNotFoundException: Error looking up clustering/group/ejb, service service jboss.naming.context.java.jboss.clustering.group.ejb is not started
> 23:44:29,133 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:133)
> 23:44:29,133 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> 23:44:29,134 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
> 23:44:29,134 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> 23:44:29,134 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:136)
> 23:44:29,134 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:144)
> 23:44:29,135 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:144)
> 23:44:29,135 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation.access$0(JndiViewOperation.java:125)
> 23:44:29,135 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:75)
> 23:44:29,135 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591)
> 23:44:29,136 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469)
> 23:44:29,136 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273)
> 23:44:29,142 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268)
> 23:44:29,142 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272)
> 23:44:29,143 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146)
> 23:44:29,145 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:169)
> 23:44:29,147 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> 23:44:29,150 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> 23:44:29,151 ERROR [stderr] (XNIO-1 task-8) at java.security.AccessController.doPrivileged(Native Method)
> 23:44:29,151 ERROR [stderr] (XNIO-1 task-8) at javax.security.auth.Subject.doAs(Subject.java:422)
> 23:44:29,151 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94)
> 23:44:29,152 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> 23:44:29,152 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> 23:44:29,153 ERROR [stderr] (XNIO-1 task-8) at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:50)
> 23:44:29,153 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:77)
> 23:44:29,154 ERROR [stderr] (XNIO-1 task-8) at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> 23:44:29,154 ERROR [stderr] (XNIO-1 task-8) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
> 23:44:29,156 ERROR [stderr] (XNIO-1 task-8) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> 23:44:29,157 ERROR [stderr] (XNIO-1 task-8) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-695) Add ability to disable rules
by Stephen Slaboda (JIRA)
[ https://issues.jboss.org/browse/DROOLS-695?page=com.atlassian.jira.plugin... ]
Stephen Slaboda commented on DROOLS-695:
----------------------------------------
I think I was misunderstanding how kmodule.xml works (since I've never had need to use it). I had thought it was something that would packaged in the META-INF of the jar(s) that actually run the KieSessions, etc. I now understand (I hope?) that the kmodule resides in the META-INF of the jar(s) generated by the workbench as part of the workbench's build/deploy process. If I am actually understanding this correctly now, then I think that would fit our needs perfectly.
> Add ability to disable rules
> ----------------------------
>
> Key: DROOLS-695
> URL: https://issues.jboss.org/browse/DROOLS-695
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.CR4
> Environment: RedHat Linux 6.3 x86_64; Firefox 10.0.5
> Reporter: Stephen Slaboda
> Labels: drools-wb
>
> Many times while working on rules, it would be helpful to be able to disable other rules. Reasons for doing this would be:
> -Testing outside of the workbench (ensure your process using Drools activates certain rules, without the clutter of other rules firing)
> -Turn off rules if it is determined that they are impacitng the operational environment
> -Allow development of rules in the same space while not breaking the build/deploy of rules
> -Allow for inclusion of rules in the operation system that do not run until approved, while still allowing other updates to occur in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-695) Add ability to disable rules
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-695?page=com.atlassian.jira.plugin... ]
Michael Anstis commented on DROOLS-695:
---------------------------------------
The intent would be that the Workbench would have tooling to edit the kmodule.xml with the rules you want to disable/enable.
However it operated yuo'd need to rebuild the KJAR (whether the workbench excludes certain "disabled" rules or whether the kmodule defines what rules to disable at runtime).
Mark has chatted to me about this before. We used to have something called "Build Selectors" in 5.x of the web tooling; which filtered the rules compiled into the deployment unit.
Mark wanted to replace this mechanism with something in kmodule that would filter rules at runtime (as opposed to "build selectors" that worked at compile/author/design time).
> Add ability to disable rules
> ----------------------------
>
> Key: DROOLS-695
> URL: https://issues.jboss.org/browse/DROOLS-695
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.CR4
> Environment: RedHat Linux 6.3 x86_64; Firefox 10.0.5
> Reporter: Stephen Slaboda
> Labels: drools-wb
>
> Many times while working on rules, it would be helpful to be able to disable other rules. Reasons for doing this would be:
> -Testing outside of the workbench (ensure your process using Drools activates certain rules, without the clutter of other rules firing)
> -Turn off rules if it is determined that they are impacitng the operational environment
> -Allow development of rules in the same space while not breaking the build/deploy of rules
> -Allow for inclusion of rules in the operation system that do not run until approved, while still allowing other updates to occur in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-695) Add ability to disable rules
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-695?page=com.atlassian.jira.plugin... ]
Michael Anstis edited comment on DROOLS-695 at 1/21/15 3:29 PM:
----------------------------------------------------------------
The intent would be that the Workbench would have tooling to edit the kmodule.xml with the rules you want to disable/enable.
How ever it operated you'd need to rebuild the KJAR (whether the workbench excludes certain "disabled" rules or whether the kmodule defines what rules to disable at runtime).
Mark has chatted to me about this before. We used to have something called "Build Selectors" in 5.x of the web tooling; which filtered the rules compiled into the deployment unit.
Mark wanted to replace this mechanism with something in kmodule that would filter rules at runtime (as opposed to "build selectors" that worked at compile/author/design time).
was (Author: manstis):
The intent would be that the Workbench would have tooling to edit the kmodule.xml with the rules you want to disable/enable.
However it operated yuo'd need to rebuild the KJAR (whether the workbench excludes certain "disabled" rules or whether the kmodule defines what rules to disable at runtime).
Mark has chatted to me about this before. We used to have something called "Build Selectors" in 5.x of the web tooling; which filtered the rules compiled into the deployment unit.
Mark wanted to replace this mechanism with something in kmodule that would filter rules at runtime (as opposed to "build selectors" that worked at compile/author/design time).
> Add ability to disable rules
> ----------------------------
>
> Key: DROOLS-695
> URL: https://issues.jboss.org/browse/DROOLS-695
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.CR4
> Environment: RedHat Linux 6.3 x86_64; Firefox 10.0.5
> Reporter: Stephen Slaboda
> Labels: drools-wb
>
> Many times while working on rules, it would be helpful to be able to disable other rules. Reasons for doing this would be:
> -Testing outside of the workbench (ensure your process using Drools activates certain rules, without the clutter of other rules firing)
> -Turn off rules if it is determined that they are impacitng the operational environment
> -Allow development of rules in the same space while not breaking the build/deploy of rules
> -Allow for inclusion of rules in the operation system that do not run until approved, while still allowing other updates to occur in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBMETA-384) jboss-web_8_0.xsd imports web-app_3_1.xsd with wrong namespce
by Denis Golovin (JIRA)
Denis Golovin created JBMETA-384:
------------------------------------
Summary: jboss-web_8_0.xsd imports web-app_3_1.xsd with wrong namespce
Key: JBMETA-384
URL: https://issues.jboss.org/browse/JBMETA-384
Project: JBoss Metadata
Issue Type: Bug
Components: web
Reporter: Denis Golovin
Assignee: Jean-Frederic Clere
Eclipse validation reports error in xsd file:
{code}src-resolve.4.2: Error resolving component 'javaee:string'. It was detected that 'javaee:string' is in
namespace 'http://xmlns.jcp.org/xml/ns/javaee', but components from this namespace are not
referenceable from schema document 'file:///home/eskimo/workspace/javaee-mars/a1/WebContent/WEB-
INF/jboss-web_8_0.xsd'. If this is the incorrect namespace, perhaps the prefix of 'javaee:string' needs to
be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'file:///
home/eskimo/workspace/javaee-mars/a1/WebContent/WEB-INF/jboss-web_8_0.xsd'.{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-695) Add ability to disable rules
by Stephen Slaboda (JIRA)
[ https://issues.jboss.org/browse/DROOLS-695?page=com.atlassian.jira.plugin... ]
Stephen Slaboda commented on DROOLS-695:
----------------------------------------
I think our preference would be to be able to use the Drools workbench to modify which rules are disabled/enabled and then perform a build/deploy in the project editor and use a KieScanner to pick up the change (as we currently do to dynamically apply other rule changes from the workbench). This would remove the need to perform a new build/deployment of our product with an updated META-INF/kmodule.xml.
> Add ability to disable rules
> ----------------------------
>
> Key: DROOLS-695
> URL: https://issues.jboss.org/browse/DROOLS-695
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.CR4
> Environment: RedHat Linux 6.3 x86_64; Firefox 10.0.5
> Reporter: Stephen Slaboda
> Labels: drools-wb
>
> Many times while working on rules, it would be helpful to be able to disable other rules. Reasons for doing this would be:
> -Testing outside of the workbench (ensure your process using Drools activates certain rules, without the clutter of other rules firing)
> -Turn off rules if it is determined that they are impacitng the operational environment
> -Allow development of rules in the same space while not breaking the build/deploy of rules
> -Allow for inclusion of rules in the operation system that do not run until approved, while still allowing other updates to occur in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-695) Add ability to disable rules
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-695?page=com.atlassian.jira.plugin... ]
Michael Anstis commented on DROOLS-695:
---------------------------------------
[~mark.proctor] This, I believe, relates to the "selectors" you've spoken about before whereby the kmodule.xml includes meta-data to include/exclude rules.
> Add ability to disable rules
> ----------------------------
>
> Key: DROOLS-695
> URL: https://issues.jboss.org/browse/DROOLS-695
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.CR4
> Environment: RedHat Linux 6.3 x86_64; Firefox 10.0.5
> Reporter: Stephen Slaboda
> Labels: drools-wb
>
> Many times while working on rules, it would be helpful to be able to disable other rules. Reasons for doing this would be:
> -Testing outside of the workbench (ensure your process using Drools activates certain rules, without the clutter of other rules firing)
> -Turn off rules if it is determined that they are impacitng the operational environment
> -Allow development of rules in the same space while not breaking the build/deploy of rules
> -Allow for inclusion of rules in the operation system that do not run until approved, while still allowing other updates to occur in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-695) Add ability to disable rules
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-695?page=com.atlassian.jira.plugin... ]
Michael Anstis updated DROOLS-695:
----------------------------------
Summary: Add ability to disable rules (was: Add ability to disable rules in the workbench)
> Add ability to disable rules
> ----------------------------
>
> Key: DROOLS-695
> URL: https://issues.jboss.org/browse/DROOLS-695
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.CR4
> Environment: RedHat Linux 6.3 x86_64; Firefox 10.0.5
> Reporter: Stephen Slaboda
> Labels: drools-wb
>
> Many times while working on rules, it would be helpful to be able to disable other rules. Reasons for doing this would be:
> -Testing outside of the workbench (ensure your process using Drools activates certain rules, without the clutter of other rules firing)
> -Turn off rules if it is determined that they are impacitng the operational environment
> -Allow development of rules in the same space while not breaking the build/deploy of rules
> -Allow for inclusion of rules in the operation system that do not run until approved, while still allowing other updates to occur in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months