April 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-64) Filesystem deployment scanner deployment failure removes unrelated deployments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-64?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFCORE-64: ----------------------------------------------- Bartek Spyrko-Smietanko <bspyrkos(a)redhat.com> changed the Status of [bug 1327093|https://bugzilla.redhat.com/show_bug.cgi?id=1327093] from NEW to POST > Filesystem deployment scanner deployment failure removes unrelated deployments > ------------------------------------------------------------------------------ > > Key: WFCORE-64 > URL: https://issues.jboss.org/browse/WFCORE-64 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha5 > Environment: WIndows and Linux platforms both exhibit the issue > Reporter: Jess Holle > Assignee: ehsavoie Hugonnet > > If one's standalone-full.xml configuration contains something like: > <deployments> > <deployment name="MyWebApp.war" runtime-name="MyWebApp.war" enabled="true"> > <fs-exploded path="../../SomeDir/MyWebApp.war" relative-to="jboss.home.dir"/> > </deployment> > </deployments> > whether manually inserted (while the server is not running) or installed via the CLI via > /deployment=ServiceCenter.war/:add(runtime-name=ServiceCenter.war,content=[{archive=false,path="../../Windchill/ServiceCenter.war",relative-to="jboss.home.dir"}]) > and a deployment scanner like: > <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0"> > <deployment-scanner name="1" path="../../../Applications" relative-to="jboss.server.base.dir" scan-interval="5000" auto-deploy-exploded="true"/> > </subsystem> > a failure by a deployment-scanner to deploy an application (exploded in my case, though I'm not sure this makes a difference) will cause the explicitly listed <deployments> to be removed from the configuration! > This occurs irrespective of the value used for auto-deploy-exploded and to <deployment> elements that had already successfully been deployed and started. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (SECURITY-941) LdapExtLoginModule does not use empty string for rolesCtxDN search correctly

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/SECURITY-941?page=com.atlassian.jira.plug... ] Peter Skopek commented on SECURITY-941: --------------------------------------- https://github.com/jbossas/redhat-picketbox/pull/14 > LdapExtLoginModule does not use empty string for rolesCtxDN search correctly > ---------------------------------------------------------------------------- > > Key: SECURITY-941 > URL: https://issues.jboss.org/browse/SECURITY-941 > Project: PicketBox > Issue Type: Bug > Reporter: Ondrej Lukas > Assignee: Peter Skopek > Priority: Critical > Fix For: 4.9.6.Final > > > Using LdapExtLoginModule rolesCtxDN with empty string causes that no role search is done, i.e. no roles are assigned to user even if LDAP contains this mapping. In correct behavior empty string should be used as base DN of ldap search. It is regression against PicketBox 4.9.3.Final. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (SECURITY-941) LdapExtLoginModule does not use empty string for rolesCtxDN search correctly

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/SECURITY-941?page=com.atlassian.jira.plug... ] Peter Skopek resolved SECURITY-941. ----------------------------------- Fix Version/s: 4.9.6.Final Resolution: Done > LdapExtLoginModule does not use empty string for rolesCtxDN search correctly > ---------------------------------------------------------------------------- > > Key: SECURITY-941 > URL: https://issues.jboss.org/browse/SECURITY-941 > Project: PicketBox > Issue Type: Bug > Reporter: Ondrej Lukas > Assignee: Peter Skopek > Priority: Critical > Fix For: 4.9.6.Final > > > Using LdapExtLoginModule rolesCtxDN with empty string causes that no role search is done, i.e. no roles are assigned to user even if LDAP contains this mapping. In correct behavior empty string should be used as base DN of ldap search. It is regression against PicketBox 4.9.3.Final. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1474) CLI version command should not use JBoss AS in its output field names

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created WFCORE-1474: ----------------------------------------- Summary: CLI version command should not use JBoss AS in its output field names Key: WFCORE-1474 URL: https://issues.jboss.org/browse/WFCORE-1474 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 2.1.0.Final Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky An example output of the current version command [standalone@localhost:9990 /] version JBoss Admin Command-line Interface JBOSS_HOME: /xxx/wildfly-core-3.0.0.Alpha1-SNAPSHOT JBoss AS release: 3.0.0.Alpha1-SNAPSHOT "Kenny" JBoss AS product: <product name> JAVA_HOME: /yyy/java java.version: 1.8.0_60 java.vm.vendor: Oracle Corporation java.vm.version: 25.60-b23 os.name: Linux os.version: 4.4.6-300.fc23.x86_64 'JBoss AS' should not appear in the field names. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (SECURITY-941) LdapExtLoginModule does not use empty string for rolesCtxDN search correctly

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/SECURITY-941?page=com.atlassian.jira.plug... ] Peter Skopek reassigned SECURITY-941: ------------------------------------- Assignee: Peter Skopek (was: Darran Lofthouse) > LdapExtLoginModule does not use empty string for rolesCtxDN search correctly > ---------------------------------------------------------------------------- > > Key: SECURITY-941 > URL: https://issues.jboss.org/browse/SECURITY-941 > Project: PicketBox > Issue Type: Bug > Reporter: Ondrej Lukas > Assignee: Peter Skopek > Priority: Critical > > Using LdapExtLoginModule rolesCtxDN with empty string causes that no role search is done, i.e. no roles are assigned to user even if LDAP contains this mapping. In correct behavior empty string should be used as base DN of ldap search. It is regression against PicketBox 4.9.3.Final. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-81) Log Tool generates class names that violate FindBugs standard rules

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-81?page=com.atlassian.jira.plugin... ] David Lloyd commented on LOGTOOL-81: ------------------------------------ Generated code often fails to comply with naming conventions (consider lambda class names and anonymous class names, at the least), which is one reason they are conventions and not hard requirements. In general analyzing generated code is not likely to be helpful since that code doesn't ever have to be maintained by humans (which is in fact the primary motivation for generating it in the first place). That said, the proposal to capitalize the first letter seems harmless and an easy workaround. > Log Tool generates class names that violate FindBugs standard rules > ------------------------------------------------------------------- > > Key: LOGTOOL-81 > URL: https://issues.jboss.org/browse/LOGTOOL-81 > Project: Log Tool > Issue Type: Bug > Environment: OS X Mavericks, Java 1.7 > Reporter: Tom Cunningham > Assignee: James Perkins > > Log Tool generates class names like : > ./api/target/generated-sources/annotations/org/switchyard/APILogger_$logger.java > ./validate/target/generated-sources/annotations/org/switchyard/validate/ValidateMessages_$bundle.java > When I run findbugs, my project isn't clean anymore because of these generated classes - findbugs complains that these classes do not start with a capital letter. It looks like this violates the NM_CLASS_NAMING_CONVENTION rule. > From Findbugs website : > Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML). > http://findbugs.sourceforge.net/bugDescriptions.html > I can probably work around this by providing FindBugs exceptions for "_$logger" and "_$bundle", but it might be good practice if the first letter were upper cased in the generated class (i.e. "_$Logger" and "_$Bundle" . -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-5979) Colocated Artemis backup does not failback

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-5979?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFLY-5979: ----------------------------------- the issue still occurs with Artemis 1.1.0.wildfly-015 > Colocated Artemis backup does not failback > ------------------------------------------ > > Key: WFLY-5979 > URL: https://issues.jboss.org/browse/WFLY-5979 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.CR5 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > Use case: > * starts 2 WildFly servers with the standalone-full-ha.xml configuration and additional ha-policy for the messaging-activemq server: > {noformat} > <replication-colocated request-backup="true"> > <master check-for-live-server="true"/> > </replication-colocated> > {noformat} > The default configuration for the colocated's slave is (allow-failback=true, restart-backup=true). > Scenario: > 1. Starts the 2 servers > 2. Kill server #1 > => server #2 must activate its backup > 3. Restart server #1 > => server #1 checks for a live server > => server #2 must failback and restart the server #1's backup > => server #1 is the live server > Currently at step (3), the activated server on #2 does not failback, the server #1 is started as live server and both uses the same nodeID. > {noformat} > * start server #1 > 14:54:12,151 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 71) AMQ221007: Server is now live > 14:54:12,151 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 71) AMQ221001: Apache ActiveMQ Artemis Message Broker version 1.1.0.wildfly-010 [nodeID=cd605092-b933-11e5-ba21-cb5e13c1ea67] > * Server #2 > 14:56:27,926 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 71) AMQ221007: Server is now live > 14:56:27,927 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 71) AMQ221001: Apache ActiveMQ Artemis Message Broker version 1.1.0.wildfly-010 [nodeID=198586c5-b933-11e5-a199-4dbe14260a82] > ... > 14:56:32,245 INFO [org.apache.activemq.artemis.core.server] (default I/O-5) AMQ221049: Activating Replica for node: cd605092-b933-11e5-ba21-cb5e13c1ea67 > * Server #1 also creates a replica for server #2 > 14:56:32,969 INFO [org.apache.activemq.artemis.core.server] (default I/O-13) AMQ221049: Activating Replica for node: 198586c5-b933-11e5-a199-4dbe14260a82 > ... > 14:56:32,738 INFO [org.apache.activemq.artemis.core.server] (Thread-7 (ActiveMQ-client-netty-threads-1157501840)) AMQ221024: Backup server ActiveMQServerImpl:: > serverUUID=cd605092-b933-11e5-ba21-cb5e13c1ea67 is synchronized with live-server. > * Kill server #1 -> colocated backup on server #2 becomes live > 14:57:21,718 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221037: ActiveMQServerImpl::serverUUID=cd605092-b933-11e5-ba21-cb5e13c1ea67 to become 'live' > * Restart server #1 > 15:12:05,755 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 71) AMQ221001: Apache ActiveMQ Artemis Message Broker version 1.1.0.wildfly-010 [nodeID=cd605092-b933-11e5-ba21-cb5e13c1ea67] > * At this stage both server #1 and #2 behave like live servers for cd605092 > 4:58:09,893 WARN [org.apache.activemq.artemis.core.client] (activemq-discovery-group-thread-dg-group1) AMQ212034: There are more than one servers on the network broadcasting the same node id. You will see this message exactly once (per node) if a node is restarted, in which case it can be safely ignored. But if it is logged continuously it means you really do have more than one node on the same network active concurrently with the same node id. This could occur if you have > a backup node active at the same time as its live node. nodeID=cd605092-b933-11e5-ba21-cb5e13c1ea67 > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-81) Log Tool generates class names that violate FindBugs standard rules

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-81?page=com.atlassian.jira.plugin... ] Tom Cunningham commented on LOGTOOL-81: --------------------------------------- This is one of the Java naming conventions though, I'm not sure whether it matters or not that the class is generated. http://www.oracle.com/technetwork/java/codeconventions-135099.html > Log Tool generates class names that violate FindBugs standard rules > ------------------------------------------------------------------- > > Key: LOGTOOL-81 > URL: https://issues.jboss.org/browse/LOGTOOL-81 > Project: Log Tool > Issue Type: Bug > Environment: OS X Mavericks, Java 1.7 > Reporter: Tom Cunningham > Assignee: James Perkins > > Log Tool generates class names like : > ./api/target/generated-sources/annotations/org/switchyard/APILogger_$logger.java > ./validate/target/generated-sources/annotations/org/switchyard/validate/ValidateMessages_$bundle.java > When I run findbugs, my project isn't clean anymore because of these generated classes - findbugs complains that these classes do not start with a capital letter. It looks like this violates the NM_CLASS_NAMING_CONVENTION rule. > From Findbugs website : > Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML). > http://findbugs.sourceforge.net/bugDescriptions.html > I can probably work around this by providing FindBugs exceptions for "_$logger" and "_$bundle", but it might be good practice if the first letter were upper cased in the generated class (i.e. "_$Logger" and "_$Bundle" . -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-81) Log Tool generates class names that violate FindBugs standard rules

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-81?page=com.atlassian.jira.plugin... ] David Lloyd commented on LOGTOOL-81: ------------------------------------ I think this is a bug in FindBugs; it should disregard classes annotated with {{@Generated}}. > Log Tool generates class names that violate FindBugs standard rules > ------------------------------------------------------------------- > > Key: LOGTOOL-81 > URL: https://issues.jboss.org/browse/LOGTOOL-81 > Project: Log Tool > Issue Type: Bug > Environment: OS X Mavericks, Java 1.7 > Reporter: Tom Cunningham > Assignee: James Perkins > > Log Tool generates class names like : > ./api/target/generated-sources/annotations/org/switchyard/APILogger_$logger.java > ./validate/target/generated-sources/annotations/org/switchyard/validate/ValidateMessages_$bundle.java > When I run findbugs, my project isn't clean anymore because of these generated classes - findbugs complains that these classes do not start with a capital letter. It looks like this violates the NM_CLASS_NAMING_CONVENTION rule. > From Findbugs website : > Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML). > http://findbugs.sourceforge.net/bugDescriptions.html > I can probably work around this by providing FindBugs exceptions for "_$logger" and "_$bundle", but it might be good practice if the first letter were upper cased in the generated class (i.e. "_$Logger" and "_$Bundle" . -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6525) Impossible to use custom FileSystemProviders embedded in an application

by David Brodski (JIRA)

[ https://issues.jboss.org/browse/WFLY-6525?page=com.atlassian.jira.plugin.... ] David Brodski commented on WFLY-6525: ------------------------------------- When I tried the _com.sun.nio.zipfs.ZipFileSystemProvider_, it worked, but it is integrated in the jre. If you create your own provider it is not working. > Impossible to use custom FileSystemProviders embedded in an application > ----------------------------------------------------------------------- > > Key: WFLY-6525 > URL: https://issues.jboss.org/browse/WFLY-6525 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: 9.0.2.Final, 10.0.0.Final > Reporter: Xavier Dury > Assignee: David Lloyd > > Using a custom {{FileSystemProvider}} inside an application is not possible with Wildfly: > * Using {{Paths.get(uri)}} won't work as {{FileSystemProvider}} caches previously discovered FSPs and won't see those that could be embedded in the application > * Using {{FileSystems.newFileSystem(uri, map, classLoader)}} won't work either because FSPs from {{com.sun.nio.*}} will be discovered and those classes are not visible to the application (and are not exported by sun.jdk module.xml). This will give the following error: {{java.util.ServiceConfigurationError: java.nio.file.spi.FileSystemProvider: Provider com.sun.nio.zipfs.ZipFileSystemProvider not found}}. > More info on https://developer.jboss.org/message/954528 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

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 April 2016