[JBoss JIRA] (DROOLS-696) KnowledgeBaseAdapter is Externalizable, but doesn't have the default constructor
by Pavlo Romanenko (JIRA)
Pavlo Romanenko created DROOLS-696:
--------------------------------------
Summary: KnowledgeBaseAdapter is Externalizable, but doesn't have the default constructor
Key: DROOLS-696
URL: https://issues.jboss.org/browse/DROOLS-696
Project: Drools
Issue Type: Bug
Affects Versions: 6.2.0.CR4
Reporter: Pavlo Romanenko
Assignee: Mark Proctor
https://issues.jboss.org/browse/DROOLS-671 - KnowledgeBaseAdapter was made Externalizable, but it doesn't have a default constructor.
Now I during KnowledgeBaseAdapter serialization I get:
"InvalidClassException: org.drools.impl.adapters.KnowledgeBaseAdapter; no valid constructor"
StackTrace:
java.io.InvalidClassException: org.drools.impl.adapters.KnowledgeBaseAdapter; no valid constructor
at java.io.ObjectStreamClass$ExceptionInfo.newInvalidClassException(ObjectStreamClass.java:150)
at java.io.ObjectStreamClass.checkDeserialize(ObjectStreamClass.java:768)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1772)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-3369) Performance issue of jaxws-client on JDK 1.7.0_55
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-3369?page=com.atlassian.jira.plugin.... ]
Rostislav Svoboda reopened WFLY-3369:
-------------------------------------
Re-openning after discussion on irc.
This affects JDK8 too - https://bugs.openjdk.java.net/browse/JDK-8044726
Data from https://github.com/jimma/jdk7u40-httpurlconnection-issue test
{code}
-------------------------------------------------------------------
***** Test with java version : 1.7.0_25 *****
!!! connection.setFixedLengthStreamingMode() has been set !!!
CallNum: [300] SuccessNUM: [300] Time: [198] Total getOutputStream Time : [57]
-------------------------------------------------------------------
***** Test with java version : 1.7.0_25 *****
!!! connection.setFixedLengthStreamingMode() is NOT set !!!
CallNum: [300] SuccessNUM: [300] Time: [151] Total getOutputStream Time : [21]
***** Test with java version : 1.7.0_67 *****
!!! connection.setFixedLengthStreamingMode() has been set !!!
CallNum: [300] SuccessNUM: [300] Time: [638] Total getOutputStream Time : [641]
-------------------------------------------------------------------
***** Test with java version : 1.7.0_67 *****
!!! connection.setFixedLengthStreamingMode() is NOT set !!!
CallNum: [300] SuccessNUM: [300] Time: [155] Total getOutputStream Time : [21]
***** Test with java version : 1.8.0_20 *****
!!! connection.setFixedLengthStreamingMode() has been set !!!
CallNum: [300] SuccessNUM: [300] Time: [587] Total getOutputStream Time : [633]
-------------------------------------------------------------------
***** Test with java version : 1.8.0_20 *****
!!! connection.setFixedLengthStreamingMode() is NOT set !!!
CallNum: [300] SuccessNUM: [300] Time: [187] Total getOutputStream Time : [13]
{code}
> Performance issue of jaxws-client on JDK 1.7.0_55
> -------------------------------------------------
>
> Key: WFLY-3369
> URL: https://issues.jboss.org/browse/WFLY-3369
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: JBoss AS7 7.1.1.Final
> Environment: Red Hat Enterprise 6.4, Solaris 10, JBoss AS 7.1.3
> Reporter: Zhang Boya
> Assignee: Jim Ma
>
> Assume that a JAX-WS deploys on somewhere else, developer generates the JAX-WS client side classes by using wsdl2java tools. These classes have been exported as 'exmaple-ws-client.jar'. When developer needs to access this JAX-WS in their web application, this JAR file would be published with WAR file together. By default, the JBoss AS would supply an instance of CXF's implementation for the JAX-WS client when web application be deployed to JBoss AS. The class name of this JAX-WS client would be 'org.apache.cxf.jaxws.JaxWsClientProxy'. The JAX-WS invocations of client side got a very bad performance since I upgraded JDK from 1.7.0_25 to 1.7.0_55, especially on Solaris.
--
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:
---------------------------------------
[~devyndraen] Correct. The kmodule.xml resides in the META-INF folder of the KJAR generated from 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
[JBoss JIRA] (DROOLS-185) ClassCastException at ConditionEvaluator
by Liu Yan (JIRA)
[ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin... ]
Liu Yan edited comment on DROOLS-185 at 1/22/15 1:50 AM:
---------------------------------------------------------
In hope my case could help you and others, I past some pseud code here:
In java:
ClassA extends ClassBase
ClassB extends ClassBase
In DRL:
rule prepare
when
$base: ClassBase()
then
update($base);
end
rule process
when
$B: ClassB()
then
$B.doThings_ClassB_Specific()
end
The CCE would likely be something like ClassA can't cast to ClassB at update($base) in rule prepare.
When I first saw this, it's pretty odd because ClassA never appeared anywhere. My work was blocked here for 2 days, finally I tried to comment out "rule process" and the CCE disappeared. This give me some idea of how this happen.
was (Author: oscar_cqu):
In hope my case could help you and others, I past some pseud code here:
In java:
ClassA extends ClassBase
ClassB extends ClassBase
In DRL:
rule prepare
when
$base: ClassBase()
then
update($base);
end
rule process
when
$B: ClassB()
then
$B.doThings_ClassB_Specific()
end
The CCE would likely be something like ClassB can't cast to ClassA at update($base) in rule prepare.
When I first saw this, it's pretty odd because ClassA never appeared anywhere. My work was blocked here for 2 days, finally I tried to comment out "rule process" and the CCE disappeared. This give me some idea of how this happen.
> ClassCastException at ConditionEvaluator
> ----------------------------------------
>
> Key: DROOLS-185
> URL: https://issues.jboss.org/browse/DROOLS-185
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final
> Reporter: Sergey Alaev
> Assignee: Mario Fusco
>
> Stacktrace:
> Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
> at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
> at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
> at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
> at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
> at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
> at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
> at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> Reason:
> ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
> Given following:
> interface A {
> String getString();
> }
> interface B {
> String getString();
> }
> class X implements B, A {}
> class Y implements A{}
> rule "test rule"
> when:
> A(string != null)
> then:
> end
> When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
> Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
> Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
> Quickfix: use following declaration of class X:
> class X implements A, B {}
> Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-185) ClassCastException at ConditionEvaluator
by Liu Yan (JIRA)
[ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin... ]
Liu Yan commented on DROOLS-185:
--------------------------------
In hope my case could help you and others, I past some pseud code here:
In java:
ClassA extends ClassBase
ClassB extends ClassBase
In DRL:
rule prepare
when
$base: ClassBase()
then
update($base);
end
rule process
when
$B: ClassB()
then
$B.doThings_ClassB_Specific()
end
The CCE would likely be something like ClassB can't cast to ClassA at update($base) in rule prepare.
When I first saw this, it's pretty odd because ClassA never appeared anywhere. My work was blocked here for 2 days, finally I tried to comment out "rule process" and the CCE disappeared. This give me some idea of how this happen.
> ClassCastException at ConditionEvaluator
> ----------------------------------------
>
> Key: DROOLS-185
> URL: https://issues.jboss.org/browse/DROOLS-185
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final
> Reporter: Sergey Alaev
> Assignee: Mario Fusco
>
> Stacktrace:
> Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
> at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
> at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
> at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
> at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
> at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
> at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
> at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> Reason:
> ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
> Given following:
> interface A {
> String getString();
> }
> interface B {
> String getString();
> }
> class X implements B, A {}
> class Y implements A{}
> rule "test rule"
> when:
> A(string != null)
> then:
> end
> When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
> Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
> Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
> Quickfix: use following declaration of class X:
> class X implements A, B {}
> Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-3664) Exceptions during download of webstart libraries
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3664?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3664:
--------------------------------------
What makes you think this is related to your too many open files error? Can you provide details about what files are open (i.e. the lsof output)?
> Exceptions during download of webstart libraries
> ------------------------------------------------
>
> Key: WFLY-3664
> URL: https://issues.jboss.org/browse/WFLY-3664
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Windows 7 (64bit), Windows Server 2012 R2 (64bit)
> Reporter: Markus Schwarz
> Assignee: Stuart Douglas
> Priority: Minor
> Attachments: demo-src.zip, server.log
>
>
> I have a webstart application using the JnlpDownloadServlet. If the client cache is empty, launching the JNLP will download the libraries. The webstart application works as expected, but in the server logs there are many errors regarding download of the libraries.
> Just to mention: Not always the same libraries are listed with erros in the logs files. Sometimes I even got now exceptions.
> For my tests I used Wildfly 8.1.0.FINAL as well as a nightly build from 24. of July without any further changes of the configuration files (https://ci.jboss.org/hudson/job/WildFly-latest-master/).
> I tested it under Windows 7 and Windows Server 2012 R2. The demo contains an older JnlpDownloadServlet, but I tested it also with the one coming with JDK 7u65.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBMETA-384) jboss-web_8_0.xsd Eclipse validation errors
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBMETA-384?page=com.atlassian.jira.plugin... ]
Denis Golovin updated JBMETA-384:
---------------------------------
Description:
Eclipse validation reports error in xsd file:
1. https://github.com/jboss/metadata/blob/master/web/src/main/resources/sche...
{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}
2. https://github.com/jboss/metadata/blob/master/web/src/main/resources/sche...
{code}src-ct.2.1: Complex Type Definition Representation Error for type 'symbolic-linked-allowedType'. When
<simpleContent> is used, the base type must be a complexType whose content type is simple, or, only if
restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is
specified, a simple type. 'boolean' satisfies none of these conditions.{code}
3. It seems missing
{code}<xsd:include schemaLocation="jboss-common_6_0.xml" />{code}
for schema that defines two types and a group listed below:
{code}jboss:security-domainType
jboss:security-roleType
jboss:jndiEnvironmentRefsGroup{code}
was:
Eclipse validation reports error in xsd file:
1. https://github.com/jboss/metadata/blob/master/web/src/main/resources/sche...
{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}
2. line 299: src-ct.2.1: Complex Type Definition Representation Error for type 'symbolic-linked-allowedType'. When
<simpleContent> is used, the base type must be a complexType whose content type is simple, or, only if
restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is
specified, a simple type. 'boolean' satisfies none of these conditions.
3. It seems missing
{code}<xsd:include schemaLocation="jboss-common_6_0.xml" />{code}
for schema that defines two types and a group listed below:
{code}jboss:security-domainType
jboss:security-roleType
jboss:jndiEnvironmentRefsGroup{code}
> jboss-web_8_0.xsd Eclipse validation errors
> -------------------------------------------
>
> 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:
> 1. https://github.com/jboss/metadata/blob/master/web/src/main/resources/sche...
> {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}
> 2. https://github.com/jboss/metadata/blob/master/web/src/main/resources/sche...
> {code}src-ct.2.1: Complex Type Definition Representation Error for type 'symbolic-linked-allowedType'. When
> <simpleContent> is used, the base type must be a complexType whose content type is simple, or, only if
> restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is
> specified, a simple type. 'boolean' satisfies none of these conditions.{code}
> 3. It seems missing
> {code}<xsd:include schemaLocation="jboss-common_6_0.xml" />{code}
> for schema that defines two types and a group listed below:
> {code}jboss:security-domainType
> jboss:security-roleType
> jboss:jndiEnvironmentRefsGroup{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBMETA-384) jboss-web_8_0.xsd Eclipse validation errors
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBMETA-384?page=com.atlassian.jira.plugin... ]
Denis Golovin updated JBMETA-384:
---------------------------------
Description:
Eclipse validation reports error in xsd file:
1. https://github.com/jboss/metadata/blob/master/web/src/main/resources/sche...
{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}
2. line 299: src-ct.2.1: Complex Type Definition Representation Error for type 'symbolic-linked-allowedType'. When
<simpleContent> is used, the base type must be a complexType whose content type is simple, or, only if
restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is
specified, a simple type. 'boolean' satisfies none of these conditions.
3. It seems missing
{code}<xsd:include schemaLocation="jboss-common_6_0.xml" />{code}
for schema that defines two types and a group listed below:
{code}jboss:security-domainType
jboss:security-roleType
jboss:jndiEnvironmentRefsGroup{code}
was:
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}
> jboss-web_8_0.xsd Eclipse validation errors
> -------------------------------------------
>
> 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:
> 1. https://github.com/jboss/metadata/blob/master/web/src/main/resources/sche...
> {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}
> 2. line 299: src-ct.2.1: Complex Type Definition Representation Error for type 'symbolic-linked-allowedType'. When
> <simpleContent> is used, the base type must be a complexType whose content type is simple, or, only if
> restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is
> specified, a simple type. 'boolean' satisfies none of these conditions.
> 3. It seems missing
> {code}<xsd:include schemaLocation="jboss-common_6_0.xml" />{code}
> for schema that defines two types and a group listed below:
> {code}jboss:security-domainType
> jboss:security-roleType
> jboss:jndiEnvironmentRefsGroup{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBMETA-384) jboss-web_8_0.xsd Eclipse validation errors
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBMETA-384?page=com.atlassian.jira.plugin... ]
Denis Golovin updated JBMETA-384:
---------------------------------
Summary: jboss-web_8_0.xsd Eclipse validation errors (was: jboss-web_8_0.xsd imports web-app_3_1.xsd with wrong namespce)
> jboss-web_8_0.xsd Eclipse validation errors
> -------------------------------------------
>
> 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] (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 commented on WFLY-3384:
------------------------------------
I've submitted an alternative fix.
> 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