January 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2672) Additional debug logging for LDAP based group loading.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2672?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2672: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1044772|https://bugzilla.redhat.com/show_bug.cgi?id=1044772] from POST to MODIFIED > Additional debug logging for LDAP based group loading. > ------------------------------------------------------ > > Key: WFLY-2672 > URL: https://issues.jboss.org/browse/WFLY-2672 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2739) BeanDeploymentArchive for external (WFLY) modules added twice

by Pëtr Andreev (JIRA)

[ https://issues.jboss.org/browse/WFLY-2739?page=com.atlassian.jira.plugin.... ] Pëtr Andreev commented on WFLY-2739: ------------------------------------ Pull Request: https://github.com/wildfly/wildfly/pull/5828 > BeanDeploymentArchive for external (WFLY) modules added twice > ------------------------------------------------------------- > > Key: WFLY-2739 > URL: https://issues.jboss.org/browse/WFLY-2739 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.CR1 > Environment: Win7,CentOS6 > Reporter: Pëtr Andreev > Assignee: Jozef Hartinger > Fix For: 8.0.0.Final > > > The Weld-WFLY integration adds a dependency on WFLY module twice if the application deployment unit is an EAR containg libs, ejbs, war, etc. It prevents an application having dependencies on a new Picketlink (PL) extension to be deployed since PL contains a portable extension which has to be injected within PL module. The Weld-validation of the second time injection fails. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-388) Inconsistent behavior of "contains" operator

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-388?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-388. -------------------------------- Fix Version/s: 6.1.0.Beta1 Resolution: Done > Inconsistent behavior of "contains" operator > -------------------------------------------- > > Key: DROOLS-388 > URL: https://issues.jboss.org/browse/DROOLS-388 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.1.Final, 6.0.0.Final > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Minor > Fix For: 6.1.0.Beta1 > > > The compiler accepts constraints such as > {code} > Person( fullName contains 'Jr' ) // should be fullName.contains('Jr') > {code} > Interestingly, MVEL evaluates it as the string operation "contains", but > once the constraint is jitted it is again evaluated as a collection operator. > That is, a rule such as: > {code} > when > $s : String( this contains "foo" ) > then > {code} > with inputs "foo1" .. "fooN" effectively fires an unpredictable number of times before starting to fail silently -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-388) Inconsistent behavior of "contains" operator

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-388?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-388: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1060033|https://bugzilla.redhat.com/show_bug.cgi?id=1060033] from NEW to ASSIGNED > Inconsistent behavior of "contains" operator > -------------------------------------------- > > Key: DROOLS-388 > URL: https://issues.jboss.org/browse/DROOLS-388 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.1.Final, 6.0.0.Final > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Minor > > The compiler accepts constraints such as > {code} > Person( fullName contains 'Jr' ) // should be fullName.contains('Jr') > {code} > Interestingly, MVEL evaluates it as the string operation "contains", but > once the constraint is jitted it is again evaluated as a collection operator. > That is, a rule such as: > {code} > when > $s : String( this contains "foo" ) > then > {code} > with inputs "foo1" .. "fooN" effectively fires an unpredictable number of times before starting to fail silently -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-388) Inconsistent behavior of "contains" operator

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-388?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-388: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1060033 > Inconsistent behavior of "contains" operator > -------------------------------------------- > > Key: DROOLS-388 > URL: https://issues.jboss.org/browse/DROOLS-388 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.1.Final, 6.0.0.Final > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Minor > > The compiler accepts constraints such as > {code} > Person( fullName contains 'Jr' ) // should be fullName.contains('Jr') > {code} > Interestingly, MVEL evaluates it as the string operation "contains", but > once the constraint is jitted it is again evaluated as a collection operator. > That is, a rule such as: > {code} > when > $s : String( this contains "foo" ) > then > {code} > with inputs "foo1" .. "fooN" effectively fires an unpredictable number of times before starting to fail silently -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2785) master reload on windows using bind IP without a reverse DNS entry (or a wrong one)

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.... ] Emanuel Muckenhuber reassigned WFLY-2785: ----------------------------------------- Assignee: Aleksandar Kostadinov (was: Emanuel Muckenhuber) Once your PR is merged, you can resolve this issue. Thanks > master reload on windows using bind IP without a reverse DNS entry (or a wrong one) > ----------------------------------------------------------------------------------- > > Key: WFLY-2785 > URL: https://issues.jboss.org/browse/WFLY-2785 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.0.0.CR1 > Environment: windows > Reporter: Aleksandar Kostadinov > Assignee: Aleksandar Kostadinov > Labels: addressing, domain, socket > Attachments: server_logs.zip > > > When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try). > Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established. > Here is how to reproduce: > # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15) > # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15 > # issue this cli command: reload --restart-servers=false --host=master > # see logs for messages from server-one and server-two (I'll attach an archive with such logs) > The fix I found for the issue is:{CODE} > diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java > index 308df0e..c6a88e8 100644 > --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java > +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java > @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER; > > import java.io.IOException; > import java.io.OutputStream; > -import java.net.InetAddress; > import java.net.InetSocketAddress; > import java.util.Collections; > import java.util.LinkedHashMap; > @@ -769,7 +768,7 @@ class ManagedServer { > public boolean execute(ManagedServer server) throws Exception { > assert Thread.holdsLock(ManagedServer.this); // Call under lock > // Reconnect > - final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName(); > + final String hostName = managementSocket.getHostString(); > final int port = managementSocket.getPort(); > processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey); > return true; > {CODE} > I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a05...] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something? > Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs. > IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2805) Fix the classpath resolution in jconsole.sh (and .bat)

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-2805?page=com.atlassian.jira.plugin.... ] Emanuel Muckenhuber resolved WFLY-2805. --------------------------------------- Resolution: Done This got merged already. > Fix the classpath resolution in jconsole.sh (and .bat) > ------------------------------------------------------ > > Key: WFLY-2805 > URL: https://issues.jboss.org/browse/WFLY-2805 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Scripts > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.Final > > > The jconsole scripts use a some hardcoded module names and the module path to resolve the classpath. This however might not work with a patched instance, since modules get invalidated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2850) AJP connector with external authentication

by Geert Coelmont (JIRA)

Geert Coelmont created WFLY-2850: ------------------------------------ Summary: AJP connector with external authentication Key: WFLY-2850 URL: https://issues.jboss.org/browse/WFLY-2850 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Web (Undertow) Affects Versions: 8.0.0.CR1 Reporter: Geert Coelmont Assignee: Stuart Douglas Priority: Critical Tomcat allows to set the tomcatAuthentication attribute of the AJP connector to false to allow external web servers (e.g. apache httpd) to handle the authentication and pass that along. A similar option was added recently to JBossWeb as well (see WFLY-254), but JBossWeb has been replaced by Undertow. With Undertow this option isn't available as far as I can see. For me this is a critical problem as there is currently no way I can do negotiated (SPNEGO) authentication from within WildFly+Undertow. (See also WFLY-2404). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-89) LogContext's root logger is not created with a strong child hash map when strong=true

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-89?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on LOGMGR-89: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1031221|https://bugzilla.redhat.com/show_bug.cgi?id=1031221] from ON_QA to VERIFIED > LogContext's root logger is not created with a strong child hash map when strong=true > ------------------------------------------------------------------------------------- > > Key: LOGMGR-89 > URL: https://issues.jboss.org/browse/LOGMGR-89 > Project: JBoss Log Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: This issue happens on 32-bit JVMs, and I can reproduce it on JDK 6 (64-bit) > Reporter: Kyle Lape > Assignee: David Lloyd > Fix For: 1.2.3.GA, 1.3.3.Final, 1.4.4.Final, 1.5.2.Final, 2.0.0.Beta1 > > > When deploying an application in EAP 6 that has a log4j.xml that is deployed by the logging subsystem, it seems that the LogContext is somehow losing a reference to a custom logger, causing all configuration for that logger to be lost. > Given this configuration > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> > <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="true"> > <appender name="SAMPLE_APP" class="org.apache.log4j.RollingFileAppender"> > <param name="File" value="${jboss.server.log.dir}/SampleApp.log"/> > <param name="MaxFileSize" value="2MB"/> > <param name="MaxBackupIndex" value="5"/> > <param name="Append" value="true"/> > <layout class="org.apache.log4j.PatternLayout"> > <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/> > </layout> > </appender> > <appender name="SAMPLE_APP_MDB" class="org.apache.log4j.RollingFileAppender"> > <param name="File" value="${jboss.server.log.dir}/SampleApp-MDB.log"/> > <param name="MaxFileSize" value="2MB"/> > <param name="MaxBackupIndex" value="5"/> > <param name="Append" value="true"/> > <layout class="org.apache.log4j.PatternLayout"> > <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/> > </layout> > </appender> > <logger name="com.redhat" additivity="false"> > <level value="TRACE"/> > <appender-ref ref="SAMPLE_APP_MDB"/> > </logger> > <root> > <priority value="TRACE"/> > <appender-ref ref="SAMPLE_APP"/> > </root> > </log4j:configuration> > {code} > Every log message ends up in {{SAMPLE_APP}}, regardless of which logger was used. One message like this is also printed to the log: > {noformat} > 11:33:00,110 INFO [stdout] (Finalizer) log4j: Finalizing appender named [SAMPLE_APP_MDB]. > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-420) Incorrect resolution of global symbols in LHS rule constraint (Java dialect)

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-420?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-420. -------------------------------- Fix Version/s: 6.1.0.Beta1 Resolution: Done > Incorrect resolution of global symbols in LHS rule constraint (Java dialect) > ---------------------------------------------------------------------------- > > Key: DROOLS-420 > URL: https://issues.jboss.org/browse/DROOLS-420 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mike Rodriguez > Assignee: Mario Fusco > Priority: Minor > Fix For: 6.1.0.Beta1 > > > As described @ [http://drools.46999.n3.nabble.com/Incorrect-resolution-of-global-symbols-...]. > I upgraded from 5.5.0.Final of Drools (rule engine) to 5.6.0.Final and I am now seeing errors with globals. > We have rule constraints that access globals in a DRL; like this: > {code}some.classpath.package2.MyType ( global_instance.invoke(this) == true ) {code} > I have {code}some.classpath.package.SomeType global_instance;{code} declared at the top of the DRL, but it doesn't seem to be interpreting it as a global in the rule's restriction. > So, putting this into context within, I have a DRL such as: > package my.package.example; > global some.classpath.package.SomeType global_instance; > {code} > rule "Example rule" > when > some.classpath.package2.MyType ( global_instance.invoke(this) == true ) > then > // do something > end > {code} > I am getting an error from the package builder originating from the "Example rule" specifying something like: > "can't find method MyType.global_instance()" > Once, again this did work in 5.5.0.Final, but in 5.6.0.Final I am getting a failure trying to build the knowledge package. > It looks to me like the {{global_instance}} symbol is not being recognized as a global in the DRL and is trying to be > resolved as a method of the MyType class. > So I guess it would be trying to do a "MyType.global_instance().invoke(this)" or something. > The intent is that {{global_instance}} will be set for a session with an immutable function-type of class > (invoke is an instance method though; not static). The rule restriction uses this function/predicate to determine if some > complex criteria is true for `this` MyType instance. > I would appreciate any insight into what the issue might be. I haven't been able to find any threads out there on a similar issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 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 2014