October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7328) Undertow subsystem is misleading about listener capabilities

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-7328: ------------------------------------ Summary: Undertow subsystem is misleading about listener capabilities Key: WFLY-7328 URL: https://issues.jboss.org/browse/WFLY-7328 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.0.0.Final Reporter: Brian Stansberry Assignee: Stuart Douglas ListenerResourceDefinition registers the LISTENER_CAPABILITY regardless of the value of the 'enabled' attribute. But the contract provided by that capability is only fulfilled if the attribute is 'true'. Even worse, the attribute supports expressions, which can only be reliably resolved in Stage.RUNTIME, which is too late for recording a capability. Fortunately, it's vault resolution that makes it necessary to resolve in RUNTIME and reality is people are highly unlikely to use the vault for this expression, so we can try and resolve and hope for the best. This enabled stuff is just the worst. DON'T USE THIS CONCEPT IN YOUR MODEL! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7327) Improve wording in logging message for key WFLYWELD0013

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-7327: ------------------------------------ Summary: Improve wording in logging message for key WFLYWELD0013 Key: WFLY-7327 URL: https://issues.jboss.org/browse/WFLY-7327 Project: WildFly Issue Type: Bug Components: CDI / Weld Reporter: Gunnar Morling Assignee: Stuart Douglas Priority: Minor I'm seeing this message: {quote} WFLYWELD0013: Deployment deployment "demo.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) {quote} Apart from the repeated "deployment", the double negation makes it confusing, I reckon it should say something like that: {quote} WFLYWELD0013: Deployment "demo.war" contains CDI annotations but is not a bean archive (Found no beans.xml nor a class with bean defining annotations) {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-124) Change switch statements to if/else blocks when translating levels

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-124?page=com.atlassian.jira.plu... ] James Perkins updated JBLOGGING-124: ------------------------------------ Git Pull Request: https://github.com/jboss-logging/jboss-logging/pull/22, https://github.com/jboss-logging/jboss-logging/pull/23 (was: https://github.com/jboss-logging/jboss-logging/pull/22) > Change switch statements to if/else blocks when translating levels > ------------------------------------------------------------------ > > Key: JBLOGGING-124 > URL: https://issues.jboss.org/browse/JBLOGGING-124 > Project: JBoss Logging > Issue Type: Enhancement > Reporter: James Perkins > Assignee: James Perkins > Fix For: 3.3.1.Final > > > Currently a switch statement is used when levels are translated from a JBoss Logging level to the back end log level. This will likely perform better as an if/else block with the mostly likely used level at the top of the comparison. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7319) Processing of variables doesn't work in servlet mapping

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7319?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-7319. ---------------------------------- Resolution: Rejected You need to change: <spec-descriptor-property-replacement>false</spec-descriptor-property-replacement> to <spec-descriptor-property-replacement>true</spec-descriptor-property-replacement> in the ee subsystem. > Processing of variables doesn't work in servlet mapping > ------------------------------------------------------- > > Key: WFLY-7319 > URL: https://issues.jboss.org/browse/WFLY-7319 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: John Ament > Assignee: Stuart Douglas > > I have the following servlet mapping: > {code} > <servlet> > <servlet-name>TogglzConsoleServlet</servlet-name> > <servlet-class>org.togglz.console.TogglzConsoleServlet</servlet-class> > </servlet> > <servlet-mapping> > <servlet-name>TogglzConsoleServlet</servlet-name> > <url-pattern>${togglz.uri}</url-pattern> > </servlet-mapping> > {code} > Regardless of system property, the value is not processed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5213) Injecting external context to Artemis fails

by Bartosz Andrzejewski (JIRA)

[ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.... ] Bartosz Andrzejewski commented on WFLY-5213: -------------------------------------------- I'm trying to connect to remote Artemis standalone server and be able to use MDB's. I thought it can be configured in massaging-activemq module - since it has dependency to org.apache.activemq.artemis, but apparently it can not. Should I add *org.apache.activemq.artemis* extension to the configuration (since it is not listed in standalone-full configuration by deafult), and define remote-connector + pooled-connection-factory in this module (instead of defining it massaging-activemq module)? > Injecting external context to Artemis fails > ------------------------------------------- > > Key: WFLY-5213 > URL: https://issues.jboss.org/browse/WFLY-5213 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Beta2 > Reporter: Ondřej Kalman > Assignee: Jeff Mesnil > Fix For: 10.0.0.CR1 > > > When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object. > Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1871) AbstractDeploymentChainStep should fail if executed post-boot

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1871: ---------------------------------------- Summary: AbstractDeploymentChainStep should fail if executed post-boot Key: WFCORE-1871 URL: https://issues.jboss.org/browse/WFCORE-1871 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry AbstractDeploymentChainStep is intended to be called from AbstractBoottimeAddStepHandler or a functional equivalent that only calls it during boot. But WFLY-7300 and https://github.com/wildfly/wildfly/pull/9264 show that usage pattern is not being followed. So we should enforce it and fail if called post-boot. As a nice-to-have, instead of always failing the impl could check the OperationDefinition for the currently executing operation and if it reports that reload is required, then AbstractDeploymentChainStep can do the reload-required stuff currently done by AbstractBoottimeAddStepHandler. If the definition doesn't report reload-required, then the definition is wrong and the usage is wrong, so we should fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1870) :add operations implemented using AbstractBoottimeAddStepHandler should report that reload is required in the read-operation-description output

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1870?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1870: ------------------------------------- Description: As discussed on https://github.com/wildfly/wildfly/pull/9264 CRITICAL POINT: Solving this generically can have the effect of changing the management API of many, many subsystems. It doesn't actually change their behavior though. was:As discussed on https://github.com/wildfly/wildfly/pull/9264 > :add operations implemented using AbstractBoottimeAddStepHandler should report that reload is required in the read-operation-description output > ----------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1870 > URL: https://issues.jboss.org/browse/WFCORE-1870 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Kabir Khan > Assignee: Brian Stansberry > > As discussed on https://github.com/wildfly/wildfly/pull/9264 > CRITICAL POINT: Solving this generically can have the effect of changing the management API of many, many subsystems. It doesn't actually change their behavior though. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1870) :add operations implemented using AbstractBoottimeAddStepHandler should report that reload is required in the read-operation-description output

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1870?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-7326 to WFCORE-1870: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1870 (was: WFLY-7326) Component/s: Domain Management (was: Domain Management) Fix Version/s: (was: 11.0.0.Alpha1) > :add operations implemented using AbstractBoottimeAddStepHandler should report that reload is required in the read-operation-description output > ----------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1870 > URL: https://issues.jboss.org/browse/WFCORE-1870 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Kabir Khan > Assignee: Brian Stansberry > > As discussed on https://github.com/wildfly/wildfly/pull/9264 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7326) :add operations implemented using AbstractBoottimeAddStepHandler should report that reload is required in the read-operation-description output

by Kabir Khan (JIRA)

Kabir Khan created WFLY-7326: -------------------------------- Summary: :add operations implemented using AbstractBoottimeAddStepHandler should report that reload is required in the read-operation-description output Key: WFLY-7326 URL: https://issues.jboss.org/browse/WFLY-7326 Project: WildFly Issue Type: Bug Components: Domain Management Reporter: Kabir Khan Assignee: Brian Stansberry Fix For: 11.0.0.Alpha1 As discussed on https://github.com/wildfly/wildfly/pull/9264 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7322) LDAP referrals does not work in Elytron ldap-realm

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.... ] Jan Kalina updated WFLY-7322: ----------------------------- Comment: was deleted (was: Problem in FOLLOW mode: NamingEnumeration.hasMore create new LdapReferralContext and socket, which is not covered by DelegatingDirContext yet. {code:text} java.lang.RuntimeException: ELY01084: Error while consuming results from search. SearchDn [dc=users,dc=elytron,dc=wildfly,dc=org], Filter [(|(objectclass=referral)(uid={0}))], Filter Args [[refUser]]. Caused by: javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: localhost:11391 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting]] at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:237) at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMore(AbstractLdapNamingEnumeration.java:189) at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:938) ... 39 more Caused by: javax.naming.CommunicationException: localhost:11391 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting] at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:95) at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150) at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreReferrals(AbstractLdapNamingEnumeration.java:325) at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:227) ... 41 more Caused by: java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting at org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory.getDefault(ThreadLocalSSLSocketFactory.java:46) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jndi.ldap.Connection.createSocket(Connection.java:284) at com.sun.jndi.ldap.Connection.<init>(Connection.java:203) at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137) at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1614) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746) at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:151) at com.sun.jndi.url.ldap.ldapURLContextFactory.getObjectInstance(ldapURLContextFactory.java:52) at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601) at javax.naming.spi.NamingManager.processURL(NamingManager.java:381) at javax.naming.spi.NamingManager.processURLAddrs(NamingManager.java:361) at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:333) at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:114) ... 44 more {code} ) > LDAP referrals does not work in Elytron ldap-realm > -------------------------------------------------- > > Key: WFLY-7322 > URL: https://issues.jboss.org/browse/WFLY-7322 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all: > * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object) > * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals > Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 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 October 2016