[JBoss JIRA] (DROOLS-687) Helpful error message for MvelConstraint
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-687?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet reassigned DROOLS-687:
---------------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> Helpful error message for MvelConstraint
> ----------------------------------------
>
> Key: DROOLS-687
> URL: https://issues.jboss.org/browse/DROOLS-687
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.CR4
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
>
> When you hit NullPointerException with LHS constraint during runtime, the error message is not very helpful for users to detect the root cause.
> For example,
> {noformat}
> rule 'hello person'
> when
> Person( address.street == 'abbey' )
> then
> end
> {noformat}
> If Person.address is null, the error message is:
> {noformat}
> [Error: null pointer: address.street]
> [Near : {... address.street == "abbey" ....}]
> ^
> [Line: 1, Column: 1]
> at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:427)
> at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
> at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
> at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
> at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:117)
> at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
> at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113)
> at org.mvel2.MVEL.executeExpression(MVEL.java:930)
> at org.drools.core.util.MVELSafeHelper$RawMVELEvaluator.executeExpression(MVELSafeHelper.java:481)
> at org.drools.core.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:77)
> at org.drools.core.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:62)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:226)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:183)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:138)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60)
> at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:290)
> at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:253)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:281)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:241)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1481)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1436)
> at org.drools.compiler.integrationtests.Misc2Test.testMvelConstraintErrorMessage(Misc2Test.java:7086)
> ...
> Caused by: java.lang.NullPointerException
> at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:393)
> ... 46 more
> {noformat}
> Users cannot identify which rule is associated with the constraint when they have many similar rules. Also users cannot identify which fact (Person) caused the issue when they insert many facts.
> I'm not sure if it's really possible to provide a better message in this case. But I filed this as an enhancement request.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (DROOLS-687) Helpful error message for MvelConstraint
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-687?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-687:
------------------------------------
Priority: Critical (was: Major)
> Helpful error message for MvelConstraint
> ----------------------------------------
>
> Key: DROOLS-687
> URL: https://issues.jboss.org/browse/DROOLS-687
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.CR4
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Priority: Critical
>
> When you hit NullPointerException with LHS constraint during runtime, the error message is not very helpful for users to detect the root cause.
> For example,
> {noformat}
> rule 'hello person'
> when
> Person( address.street == 'abbey' )
> then
> end
> {noformat}
> If Person.address is null, the error message is:
> {noformat}
> [Error: null pointer: address.street]
> [Near : {... address.street == "abbey" ....}]
> ^
> [Line: 1, Column: 1]
> at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:427)
> at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
> at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
> at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
> at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:117)
> at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
> at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113)
> at org.mvel2.MVEL.executeExpression(MVEL.java:930)
> at org.drools.core.util.MVELSafeHelper$RawMVELEvaluator.executeExpression(MVELSafeHelper.java:481)
> at org.drools.core.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:77)
> at org.drools.core.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:62)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:226)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:183)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:138)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60)
> at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:290)
> at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:253)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:281)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:241)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1481)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1436)
> at org.drools.compiler.integrationtests.Misc2Test.testMvelConstraintErrorMessage(Misc2Test.java:7086)
> ...
> Caused by: java.lang.NullPointerException
> at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:393)
> ... 46 more
> {noformat}
> Users cannot identify which rule is associated with the constraint when they have many similar rules. Also users cannot identify which fact (Person) caused the issue when they insert many facts.
> I'm not sure if it's really possible to provide a better message in this case. But I filed this as an enhancement request.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4250) Manually created CDI producer methods in the Extension are not injected
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-4250?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger commented on WFLY-4250:
---------------------------------------
Stuart's analysis is correct. Bean visibility follows classloader visibility. In the past we did not check this properly but that is now fixed.
> Manually created CDI producer methods in the Extension are not injected
> -----------------------------------------------------------------------
>
> Key: WFLY-4250
> URL: https://issues.jboss.org/browse/WFLY-4250
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Environment: Happened on Linux environment
> Reporter: Sebastian Łaskawiec
> Assignee: Jozef Hartinger
>
> h2. Issue description:
> During migration from Wildfly 8.1 to 8.2 (Weld 2.1.2.Final -> 2.2.6.Final) in Infinispan we discovered a problem with injecting beans created programmatically in Infinispan-cdi integration module. The problem appeared in {{GreetingServiceIT}} and {{GreetingCacheManagerIT}} test. Both those tests use the following modules integrated into Wildfly:
> * org.infinispan.cdi (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" export="true")
> * org.infinispan.jcache (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" and "org.infinispan.cdi" slot="ispn-7.1" services="import")
> [Infinispan's CDI Extension|https://github.com/infinispan/infinispan/blob/master/cdi/src/ma...] invokes [{{embeddedExtension.registerCacheBeans(event, beanManager)}}|https://github.com/infinispan/infinispan/blob/master/cdi/s...], which registers custom {{Cache}} and {{AdvancedCache}} producer beans. Those beans are being successfully added to {{BeanManager}} but are never chosen for injection. All tests fail because of unsatisfied dependencies for {{Cache<CacheKey, String>}} with qualifiers {{@GreetingCache}}.
> h2. Steps to reproduce:
> * Download and unzip [https://github.com/slaskawi/infinispan/archive/upgrade_to_wf_8_2_failed_t...]
> * Run {{./build.sh clean install -pl cdi,as-modules/embedded,integrationtests/as-integration-embedded -am -DskipTests}}
> * Modify Arquillian xml if breakpoint is needed {{./integrationtests/as-integration-embedded/src/test/resources/arquillian.xml}}
> * Run test (using IDE or Maven: {{./build.sh test -pl integrationtests/as-integration-embedded -Dtest=GreetingServiceIT}})
> h2. Finding during debugging:
> At first I would suggest creating conditional breakpoints:
> * {{org.jboss.weld.bootstrap.Validator}} line 370 (WF 8.2) or 366 (WF 8.1), condition {{"[BackedAnnotatedField] @Inject @GreetingCache private org.infinispan.test.integration.as.cdi.GreetingServiceIT.greetingCache".equals(ij.toString())}} - this will stop debugger when validating injection points for {{{GreetingCache}}.
> * {{org.jboss.weld.resolution.TypeSafeResolver.ResolvableToBeanCollection}} line 51, condition {{from.toString().startsWith("Types: [org.infinispan.Cache<javax.cache.annotation.CacheKey, java.lang.String>]") || from.toString().contains("org.infinispan.Cache")}} - this stops debugger on loading {{Cache}} producer methods (created in Infinispan CDI Extension) to {{resolved}} Loading Cache in Wildfly 8.1.
> During debugging session we discovered that the beans from Infinispan's CDI Extension are created but never used for injection. This is because {{beanManager.getBeans(ij)}} in {{Validator.java}} always return empty list. In Wildfly 8.1 beans are properly resolved using {{ResolvableToBeanCollection#load}} method, but for some reason it never happens in Wildfly 8.2, because those beans are already preset in {{resolved}} Loading Cache with empty collection value. Unfortunately we couldn't find answer why.
> h2. Workaround:
> In order to fix CDI Producer Beans accessibility we need to add a new dependency to our test: {{META-INF/MANIFEST.MF: Dependencies: org.infinispan:ispn-7.1}}.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4250) Manually created CDI producer methods in the Extension are not injected
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4250?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4250:
--------------------------------------
Basically the root cause appears to be that when the beans are added weld calls org.jboss.as.weld.deployment.WeldDeployment#loadBeanDeploymentArchive() to determine the Bean deployment archive that the beans belong to. This just looks at the class type, and as it appears that they bean class type comes from the infinispan module it creates a bean deployment archive that corresponds to this module.
As the deployment itself does not have a dependency on the infinispan module it can't inject the beans, once you add this dependency it starts working as expected.
I'm not 100% sure if this is the desired behaviour, I am assigning this to Jozef as he should be able to shed more light on it.
> Manually created CDI producer methods in the Extension are not injected
> -----------------------------------------------------------------------
>
> Key: WFLY-4250
> URL: https://issues.jboss.org/browse/WFLY-4250
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Environment: Happened on Linux environment
> Reporter: Sebastian Łaskawiec
> Assignee: Stuart Douglas
>
> h2. Issue description:
> During migration from Wildfly 8.1 to 8.2 (Weld 2.1.2.Final -> 2.2.6.Final) in Infinispan we discovered a problem with injecting beans created programmatically in Infinispan-cdi integration module. The problem appeared in {{GreetingServiceIT}} and {{GreetingCacheManagerIT}} test. Both those tests use the following modules integrated into Wildfly:
> * org.infinispan.cdi (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" export="true")
> * org.infinispan.jcache (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" and "org.infinispan.cdi" slot="ispn-7.1" services="import")
> [Infinispan's CDI Extension|https://github.com/infinispan/infinispan/blob/master/cdi/src/ma...] invokes [{{embeddedExtension.registerCacheBeans(event, beanManager)}}|https://github.com/infinispan/infinispan/blob/master/cdi/s...], which registers custom {{Cache}} and {{AdvancedCache}} producer beans. Those beans are being successfully added to {{BeanManager}} but are never chosen for injection. All tests fail because of unsatisfied dependencies for {{Cache<CacheKey, String>}} with qualifiers {{@GreetingCache}}.
> h2. Steps to reproduce:
> * Download and unzip [https://github.com/slaskawi/infinispan/archive/upgrade_to_wf_8_2_failed_t...]
> * Run {{./build.sh clean install -pl cdi,as-modules/embedded,integrationtests/as-integration-embedded -am -DskipTests}}
> * Modify Arquillian xml if breakpoint is needed {{./integrationtests/as-integration-embedded/src/test/resources/arquillian.xml}}
> * Run test (using IDE or Maven: {{./build.sh test -pl integrationtests/as-integration-embedded -Dtest=GreetingServiceIT}})
> h2. Finding during debugging:
> At first I would suggest creating conditional breakpoints:
> * {{org.jboss.weld.bootstrap.Validator}} line 370 (WF 8.2) or 366 (WF 8.1), condition {{"[BackedAnnotatedField] @Inject @GreetingCache private org.infinispan.test.integration.as.cdi.GreetingServiceIT.greetingCache".equals(ij.toString())}} - this will stop debugger when validating injection points for {{{GreetingCache}}.
> * {{org.jboss.weld.resolution.TypeSafeResolver.ResolvableToBeanCollection}} line 51, condition {{from.toString().startsWith("Types: [org.infinispan.Cache<javax.cache.annotation.CacheKey, java.lang.String>]") || from.toString().contains("org.infinispan.Cache")}} - this stops debugger on loading {{Cache}} producer methods (created in Infinispan CDI Extension) to {{resolved}} Loading Cache in Wildfly 8.1.
> During debugging session we discovered that the beans from Infinispan's CDI Extension are created but never used for injection. This is because {{beanManager.getBeans(ij)}} in {{Validator.java}} always return empty list. In Wildfly 8.1 beans are properly resolved using {{ResolvableToBeanCollection#load}} method, but for some reason it never happens in Wildfly 8.2, because those beans are already preset in {{resolved}} Loading Cache with empty collection value. Unfortunately we couldn't find answer why.
> h2. Workaround:
> In order to fix CDI Producer Beans accessibility we need to add a new dependency to our test: {{META-INF/MANIFEST.MF: Dependencies: org.infinispan:ispn-7.1}}.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4250) Manually created CDI producer methods in the Extension are not injected
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4250?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-4250:
------------------------------------
Assignee: Jozef Hartinger (was: Stuart Douglas)
> Manually created CDI producer methods in the Extension are not injected
> -----------------------------------------------------------------------
>
> Key: WFLY-4250
> URL: https://issues.jboss.org/browse/WFLY-4250
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Environment: Happened on Linux environment
> Reporter: Sebastian Łaskawiec
> Assignee: Jozef Hartinger
>
> h2. Issue description:
> During migration from Wildfly 8.1 to 8.2 (Weld 2.1.2.Final -> 2.2.6.Final) in Infinispan we discovered a problem with injecting beans created programmatically in Infinispan-cdi integration module. The problem appeared in {{GreetingServiceIT}} and {{GreetingCacheManagerIT}} test. Both those tests use the following modules integrated into Wildfly:
> * org.infinispan.cdi (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" export="true")
> * org.infinispan.jcache (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" and "org.infinispan.cdi" slot="ispn-7.1" services="import")
> [Infinispan's CDI Extension|https://github.com/infinispan/infinispan/blob/master/cdi/src/ma...] invokes [{{embeddedExtension.registerCacheBeans(event, beanManager)}}|https://github.com/infinispan/infinispan/blob/master/cdi/s...], which registers custom {{Cache}} and {{AdvancedCache}} producer beans. Those beans are being successfully added to {{BeanManager}} but are never chosen for injection. All tests fail because of unsatisfied dependencies for {{Cache<CacheKey, String>}} with qualifiers {{@GreetingCache}}.
> h2. Steps to reproduce:
> * Download and unzip [https://github.com/slaskawi/infinispan/archive/upgrade_to_wf_8_2_failed_t...]
> * Run {{./build.sh clean install -pl cdi,as-modules/embedded,integrationtests/as-integration-embedded -am -DskipTests}}
> * Modify Arquillian xml if breakpoint is needed {{./integrationtests/as-integration-embedded/src/test/resources/arquillian.xml}}
> * Run test (using IDE or Maven: {{./build.sh test -pl integrationtests/as-integration-embedded -Dtest=GreetingServiceIT}})
> h2. Finding during debugging:
> At first I would suggest creating conditional breakpoints:
> * {{org.jboss.weld.bootstrap.Validator}} line 370 (WF 8.2) or 366 (WF 8.1), condition {{"[BackedAnnotatedField] @Inject @GreetingCache private org.infinispan.test.integration.as.cdi.GreetingServiceIT.greetingCache".equals(ij.toString())}} - this will stop debugger when validating injection points for {{{GreetingCache}}.
> * {{org.jboss.weld.resolution.TypeSafeResolver.ResolvableToBeanCollection}} line 51, condition {{from.toString().startsWith("Types: [org.infinispan.Cache<javax.cache.annotation.CacheKey, java.lang.String>]") || from.toString().contains("org.infinispan.Cache")}} - this stops debugger on loading {{Cache}} producer methods (created in Infinispan CDI Extension) to {{resolved}} Loading Cache in Wildfly 8.1.
> During debugging session we discovered that the beans from Infinispan's CDI Extension are created but never used for injection. This is because {{beanManager.getBeans(ij)}} in {{Validator.java}} always return empty list. In Wildfly 8.1 beans are properly resolved using {{ResolvableToBeanCollection#load}} method, but for some reason it never happens in Wildfly 8.2, because those beans are already preset in {{resolved}} Loading Cache with empty collection value. Unfortunately we couldn't find answer why.
> h2. Workaround:
> In order to fix CDI Producer Beans accessibility we need to add a new dependency to our test: {{META-INF/MANIFEST.MF: Dependencies: org.infinispan:ispn-7.1}}.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4205) Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
by Nick . (JIRA)
[ https://issues.jboss.org/browse/WFLY-4205?page=com.atlassian.jira.plugin.... ]
Nick . commented on WFLY-4205:
------------------------------
Any updates please?
> Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
> --------------------------------------------------------------------------------
>
> Key: WFLY-4205
> URL: https://issues.jboss.org/browse/WFLY-4205
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.2.0 Final, EAR Deployment, Spring MVC, Ubuntu 14.04
> Reporter: Nick .
> Assignee: Stuart Douglas
> Labels: EAR, servlet3.0, spring-mvc
>
> Hi,
> I have spring mvc enabled web apps (20+ web apps) packaged as an EAR deployment. All my spring mvc related jar's are in my EAR/lib, i'm using SpringServletContainerInitializer (implementation of ServletContainerInitializer ) code as follows
> {code}
> @HandlesTypes(WebApplicationInitializer.class)
> public class SpringServletContainerInitializer implements ServletContainerInitializer {
> @Override
> public void onStartup(Set<Class<?>> webAppInitializerClasses, ServletContext servletContext)
> throws ServletException {
> List<WebApplicationInitializer> initializers = new LinkedList<WebApplicationInitializer>();
> if (webAppInitializerClasses != null) {
> for (Class<?> waiClass : webAppInitializerClasses) {
> // Be defensive: Some servlet containers provide us with invalid classes,
> // no matter what @HandlesTypes says...
> if (!waiClass.isInterface() && !Modifier.isAbstract(waiClass.getModifiers()) &&
> WebApplicationInitializer.class.isAssignableFrom(waiClass)) {
> try {
> initializers.add((WebApplicationInitializer) waiClass.newInstance());
> }
> catch (Throwable ex) {
> throw new ServletException("Failed to instantiate WebApplicationInitializer class", ex);
> }
> }
> }
> }
> if (initializers.isEmpty()) {
> servletContext.log("No Spring WebApplicationInitializer types detected on classpath");
> return;
> }
> AnnotationAwareOrderComparator.sort(initializers);
> servletContext.log("Spring WebApplicationInitializers detected on classpath: " + initializers);
> for (WebApplicationInitializer initializer : initializers) {
> initializer.onStartup(servletContext);
> }
> }
> }
> {code}
> But the @HandlesTypes(WebApplicationInitializer.class) are not getting detected from the EAR/lib
> Even i have tried adding the extracted the SPI from spring-web jar and added inside my war's WEB-INF/lib as a jar
> WEB-INF/lib/web-init-spi.jar which contains
> META-INF/services/javax.servlet.ServletContainerIntializer file with org.springframework.web.SpringServletContainerInitializer as an entry. This time its detecting SpringServletContainerInitializer but not detecting what defined in @HandlesTypes
> Its only working If i package all those spring mvc jars inside WEB-INF/lib then everything started working.
> I have no idea this is how the servlet specification works or its a wildfly issue but i see it as a problem for those who depends on Wildfly or similar EE Servers with an EAR deployment structure.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (DROOLS-689) Dependent Enumerations not working in Test Scenario, EXPECT section
by Rares Vernica (JIRA)
Rares Vernica created DROOLS-689:
------------------------------------
Summary: Dependent Enumerations not working in Test Scenario, EXPECT section
Key: DROOLS-689
URL: https://issues.jboss.org/browse/DROOLS-689
Project: Drools
Issue Type: Bug
Affects Versions: 6.1.0.Final
Reporter: Rares Vernica
Assignee: Mark Proctor
In Drools Workbench, I defined a dependent enumeration like:
'fact.f1' : ['a','b']
'fact.f2[f1=a]' : ['a1', 'a2']
'fact.f2[f1=b]' : ['b1', 'b2']
The enumeration is detected properly and the drop-down box is displayed for Guided Rules and Test Scenario GIVEN section.
The dependent filed is not detected properly for the Test Scenario EXPECT section and instead of the drop-down box a simple text box is displayed.
If I populate the text box with a correct value from the enumeration, the scenario reports success, so the rule and the scenario is correct.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JASSIST-241) VerifyError: Expecting a stackmap frame - Switch case statement Java 7
by Patson Luk (JIRA)
[ https://issues.jboss.org/browse/JASSIST-241?page=com.atlassian.jira.plugi... ]
Patson Luk commented on JASSIST-241:
------------------------------------
Dig a bit deeper into the code, it appears that below is the cause of the exception : (excuse me if any of below reasoning is incorrect as I am not too familiar with the libray)
# "insertAfter" on method replaces return statement with "goto" that jumps to the injected code
# In order to replace the RETURN op with GOTO, it needs to allocate a bigger block as GOTO take more byte, it attempts to insert gap of size 2 (not a wide goto) (CtBehavior.insertGoto)
# During the gap insertion, CodeIterator checks the byte alignment of the method, if there's TABLESWITCH (my case) or LOOKUPSWITCH, it will throws AlignmentException as the require the gapLength to be multiple of 4
# To insert a gap of multiple of 4, The end result will be a GOTO followed with 2 NOOP
# Now in the class MapMaker, it attempts to build the stackmap
# It builds a list of BasicBlock, the sequence would be (at the entrance of MapMaker.toStackMap)
#* The IfNotNull (branch instruction block)
#* The GOTO block (if o is null, used to be a return but now replaced by GOTO because of code injection)
#* The 2 NOOPS block (dead code - inserted by the GAP ) with incoming=1 (after the fixDeadcode)
#* The target "branch-to" block of ifNotNull with incoming = 1 (as IfNotNull jumps to this)
# Now in MapMaker.isTarget logic, it checks whether the block is a "branch target". To my understanding if incoming > 1, that means it should be a branch target (makes sense), if it's zero then it should NOT be a branch trarget (also makes sense), if it's 1, then it checks if the previous block has stop == true (ends with an unconditional jump), this logic makes sense MOST of the case as if the previous block is unconditional jump and this block still has incoming == 1, that means someone else branches to this block (*Just my assumption/understanding, could be wrong!*) This however, creates problem if a branch target is preceded by a piece of dead code which has stop == false
So my thought is that can we flag if a block is a dead code? It seems like javassist already has the logic to find out dead code block (fixDeadCode) and BasicBlock.makeBlocks. And in the logic of MapMaker.isTarget, if the previous block is dead code and if the "incoming" of current block == 1, that means this current block is a valid branch target as dead code does not increment the following block.
Hopefully i capture the problem correctly, apologize if i have made any false assumptions!
> VerifyError: Expecting a stackmap frame - Switch case statement Java 7
> ----------------------------------------------------------------------
>
> Key: JASSIST-241
> URL: https://issues.jboss.org/browse/JASSIST-241
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.19.0-GA
> Environment: jdk7
> Reporter: Patson Luk
> Assignee: Shigeru Chiba
>
> This could be a duplicate of issue 215 and 205.
> Tested it on the master (3.19.0-GA) with java 7. Running the below class
> {code}
> import java.util.Random;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtMethod;
> public class TestDriver {
> public static void main(String[] args) throws Exception {
> ClassPool pool = ClassPool.getDefault();
> CtClass cc = pool.get("TestClass");
>
> CtMethod testMethod = cc.getMethod("test", "(Ljava/lang/Object;)V");
> testMethod.insertAfter("System.out.println(\"inserted!\");");
> cc.toClass();
> //invoke it
> TestClass.test(new Object());
> }
> }
> class TestClass {
> public static void test(Object o) {
> //part 1
> if (o == null) {
> return;
> }
> //part 2
> int oper = new Random().nextInt();
> switch (oper) {
> case 1:
> break;
> }
> }
> }
> {code}
>
> Triggers error message as below:
> {quote}
> Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9 in method TestClass.test(Ljava/lang/Object;)V at offset 1
> at TestDriver.main(TestDriver.java:19)
> {quote}
> *Please take note that:*
> # This is observed on Java 7. When the same code is run on Java 6, it is fine
> # Both the "part 1" - return statement (commented in the code above) and "part 2" - switch/case statement have to be there to trigger the error. If either of those are commented out, then the code runs fine
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-1077) JDK ORB Subsystem
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-1077?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-1077:
-----------------------------------
You're right, this is a three-fold bug:
* Package.toString doesn't return the package name, that's getName()
* Classes are not guaranteed to have a Package object, in general
* Loggers should not use the package name to define their category, though logger category names may often share a parent hierarchy with the package hierarchy
But this should be filed as a separate bug.
> JDK ORB Subsystem
> -----------------
>
> Key: WFLY-1077
> URL: https://issues.jboss.org/browse/WFLY-1077
> Project: WildFly
> Issue Type: Feature Request
> Components: IIOP
> Reporter: Dimitris Andreadis
> Assignee: Tomasz Adamski
>
> Implement a JDK ORB subsystem that can act as a replacement for the JacORB subsystem.
> AFAIK, most/all JDK ORBs are based on the Sun ORB.
> Ideally the 2 ORBs (JDK & JacORB) would be both supported in case we need to go through a transition period, or we need to support a particular interop scenario for which interop communication has issues.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months