January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2732) Injected EJB not available to MDB @PreDestroy methods

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2732?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2732: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1160575|https://bugzilla.redhat.com/show_bug.cgi?id=1160575] from MODIFIED to ON_QA > Injected EJB not available to MDB @PreDestroy methods > ----------------------------------------------------- > > Key: WFLY-2732 > URL: https://issues.jboss.org/browse/WFLY-2732 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Fix For: 8.0.0.Final > > Attachments: MDBLifeCycleJAR.zip > > > MDB with method annotated with @PreDestroy and injected EJB. In this method we are calling an EJB. When the application is undeployed the PreDestroy method is called but it fails on the call to the injected EJB as it's already been undeployed. > This was fixed in an RFE for Session Beans but does not seem to work for MDB. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4253) CredentialIdentityFactory.NULL_IDENTITY does not get initialized and causes NullPointerExceptions

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4253?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski reassigned WFLY-4253: ---------------------------------------- Assignee: Bartosz Baranowski (was: Darran Lofthouse) > CredentialIdentityFactory.NULL_IDENTITY does not get initialized and causes NullPointerExceptions > ------------------------------------------------------------------------------------------------- > > Key: WFLY-4253 > URL: https://issues.jboss.org/browse/WFLY-4253 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.2.0.Final > Environment: Java 1.8.0_25 > Reporter: Rostyslav Smirnov > Assignee: Bartosz Baranowski > > org.jboss.security.identity.extensions.CredentialIdentityFactory.NULL_IDENTITY does not get initialized to an empty identity due to initialization method returning a reference to NULL_IDENTITY, which has not initialized yet, resulting in null pointer. This causes NullPointerException in org.jboss.security.SecurityContextUtil.clearIdentities() and org.jboss.security.SecurityContextUtil.getIdentities() methods. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[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 commented on DROOLS-687: ----------------------------------------- After discussion with Marco we see several ways to implement this: Proposal A) In mvel add a SourceContext object during bootstrap, so when evaluations turn bad, it can include the context in the error message. Note: you might be able to reuse ParserContext directly instead of having to add a SourceContext interface and instance. {code} interface SourceContext { String buildErrorMessagePart(); } class ReflectiveAccessorOptimizer { ... SourceContext sourceContext; public ReflectiveAccessorOptimizer(...., SourceContext sourceContext) { this.sourceContext = sourceContext; } public Object evaluateExpression(...) { ... // Old code // if (curr == null) throw new NullPointerException(); // New code if (curr == null) throw new NullPointerException("NPE happened at " + sourceContext.buildErrorMessagePart()); } {code} Pro: no performance impact! (the if's, catches etc are already there. Only when it's broken it might take a few nanoseconds longer to build the exception, but nobody cares how slow a broken app is) Con: A lot of work (need to be applied throughout mvel, including jitted constraints) Proposal B) try-catch around every mvel calls in drools and somehow figure out the context from drools. This means that the encapsulating drools code needs to know the exact line of every mvel object it uses... Con: performance impact! Try-catches during runtime code, all the time. Con: easy to forgot try-catch when writing new drools code that uses mvel (maintenance prob) Proposal C) Introduce boolean assertMode that if true does B) (so a try catch around every mvel call) and otherwise not Con: User has to be educated about this assertMode Con: 2 paths of execution that need to be kept in sync. Personally, I prefer A) - anything worth doing is worth doing well ;) > 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

1
0
0 / 0

[JBoss JIRA] (WFLY-4254) Symbolic links within web applications do not work

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4254?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski closed WFLY-4254. ------------------------------------ Resolution: Rejected Rejecting as others were rejected. Also there are workarounds - ie. mount filesys. > Symbolic links within web applications do not work > -------------------------------------------------- > > Key: WFLY-4254 > URL: https://issues.jboss.org/browse/WFLY-4254 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Reporter: Kris Iyer > Assignee: Bartosz Baranowski > > Symbolic Linking under exploded web-apps to files and/or directories outside the web-app do not work. > Here is what I tried under an exploded war: > <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" > version="8.0"> > <symbolic-linking-enabled>true</symbolic-linking-enabled> > </jboss-web> > Does not follow links and results in a 404. > HTTP/?.? 404 Not Found > Connection: keep-alive > X-Powered-By: Undertow/1 > Server: WildFly/8 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-361) CLONE - Config XML with <interface ...><any-ipv4-address /></interface> + -Djava.net.preferIPv4Stack=false produces binding to ANY address (error)

by Emmanuel Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-361?page=com.atlassian.jira.plugin... ] Emmanuel Hugonnet resolved WFCORE-361. -------------------------------------- Resolution: Out of Date > CLONE - Config XML with <interface ...><any-ipv4-address /></interface> + -Djava.net.preferIPv4Stack=false produces binding to ANY address (error) > -------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-361 > URL: https://issues.jboss.org/browse/WFCORE-361 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Pavel Janousek > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Beta1 > > > The same situation is with every shipped and supported configuration/profile. As base for my explanation I'm using standalone.xml. Standalone.xml declares xmlns as: > {code} > <server xmlns="urn:jboss:domain:1.3"> > {code} > The real XSD file which defined elements is jboss-eap-6.0/docs/schema/jboss-as-config_1_3.xsd. > The very common Linux system has implemented and enabled dualstack in these days. If we instruct AS instance to bind to +any+ IPv4 address via {code}<interface name="public"> > <any-ipv4-address /> > </interface>{code} > The real result is to bind running AS instance to +any+ IP address, not only in IPv4 address space but in IPv6 too! > With default setting (= -Djava.net.preferIPv4Stack=true), result is correct - it is bound to ANY IPv4 addresses only. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3862) Run HTTPSConnectionWithCLITestCase and VaultPasswordsInCLITestCase.java with standalone profile

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3862?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3862: ----------------------------------------------- Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1145994|https://bugzilla.redhat.com/show_bug.cgi?id=1145994] from ASSIGNED to CLOSED > Run HTTPSConnectionWithCLITestCase and VaultPasswordsInCLITestCase.java with standalone profile > ----------------------------------------------------------------------------------------------- > > Key: WFLY-3862 > URL: https://issues.jboss.org/browse/WFLY-3862 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Petr Kremensky > Assignee: Petr Kremensky > > HTTPSConnectionWithCLITestCase and VaultPasswordsInCLITestCase.java secures management interface with SSL, but they sometimes fail to unsecure it due to problem mentioned in WFLY-3778. We should use different configuration to avoid breaking whole manual-mode module due to this (other tests cannot use secured server). > Also change tests to use :*reload* command instead of *reload* operation. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4254) Symbolic links within web applications do not work

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4254?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski updated WFLY-4254: ------------------------------------- Issue Type: Bug (was: Feature Request) > Symbolic links within web applications do not work > -------------------------------------------------- > > Key: WFLY-4254 > URL: https://issues.jboss.org/browse/WFLY-4254 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Reporter: Kris Iyer > Assignee: Bartosz Baranowski > > Symbolic Linking under exploded web-apps to files and/or directories outside the web-app do not work. > Here is what I tried under an exploded war: > <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" > version="8.0"> > <symbolic-linking-enabled>true</symbolic-linking-enabled> > </jboss-web> > Does not follow links and results in a 404. > HTTP/?.? 404 Not Found > Connection: keep-alive > X-Powered-By: Undertow/1 > Server: WildFly/8 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4254) Symbolic links within web applications do not work

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4254?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski updated WFLY-4254: ------------------------------------- Issue Type: Feature Request (was: Bug) > Symbolic links within web applications do not work > -------------------------------------------------- > > Key: WFLY-4254 > URL: https://issues.jboss.org/browse/WFLY-4254 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Reporter: Kris Iyer > Assignee: Bartosz Baranowski > > Symbolic Linking under exploded web-apps to files and/or directories outside the web-app do not work. > Here is what I tried under an exploded war: > <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" > version="8.0"> > <symbolic-linking-enabled>true</symbolic-linking-enabled> > </jboss-web> > Does not follow links and results in a 404. > HTTP/?.? 404 Not Found > Connection: keep-alive > X-Powered-By: Undertow/1 > Server: WildFly/8 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4254) Symbolic links within web applications do not work

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4254?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski reassigned WFLY-4254: ---------------------------------------- Assignee: Bartosz Baranowski (was: Tomaz Cerar) > Symbolic links within web applications do not work > -------------------------------------------------- > > Key: WFLY-4254 > URL: https://issues.jboss.org/browse/WFLY-4254 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Reporter: Kris Iyer > Assignee: Bartosz Baranowski > > Symbolic Linking under exploded web-apps to files and/or directories outside the web-app do not work. > Here is what I tried under an exploded war: > <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" > version="8.0"> > <symbolic-linking-enabled>true</symbolic-linking-enabled> > </jboss-web> > Does not follow links and results in a 404. > HTTP/?.? 404 Not Found > Connection: keep-alive > X-Powered-By: Undertow/1 > Server: WildFly/8 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4250) Manually created CDI producer methods in the Extension are not injected

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/WFLY-4250?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on WFLY-4250: ------------------------------------------- There is one thing that I don't quite understand - my test class depends on {{org.infinispan.cdi}} module which exports {{org.infinispan}} classes ([code on Github|https://github.com/infinispan/infinispan/blob/master/as-modules/em...]). Moreover, other beans (which are not created this way) are available for injection (like [AdvancedCacheProducer|https://github.com/infinispan/infinispan/blob/maste...], which is shown here: [build logs|https://gist.github.com/pruivo/8d6a04c87a632568c635]). If my understanding is correct - classloader and bean visibility should allow injecting this beans even though they belong to other deployment module (infinispan module in this case). > 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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2015