May 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBASMP-52) jboss-as:deploy deploys ear but doesn't deploy contained ejb module

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/JBASMP-52?page=com.atlassian.jira.plugin.... ] James Perkins closed JBASMP-52. ------------------------------- Resolution: Rejected This should be working, please re-open if this is still an issue. > jboss-as:deploy deploys ear but doesn't deploy contained ejb module > ------------------------------------------------------------------- > > Key: JBASMP-52 > URL: https://issues.jboss.org/browse/JBASMP-52 > Project: JBoss AS Maven Plugins > Issue Type: Bug > Components: deploy > Affects Versions: 7.4.Final > Environment: Linux hostname 3.7.10-gentoo #1 SMP Fri Aug 30 17:01:59 ART 2013 x86_64 Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz GenuineIntel GNU/Linux > Reporter: Matías Blasi > Assignee: James Perkins > > I have a simple ear application (build with maven-ear-plugin). > This application contains just a persistence-unit definition (persistence.xml) and a ejb-module. > The ejb module is another maven build, containing some ejb3, handled with maven-ejb-plugin. > The ear file is correctly built: > myapp.ear > | > + META-INF/application.xml > + lib/allmylibs.jar > + myejb.jar > When trying to deploy the ear with the jboss-as:deploy, the application is deployed (the persistence unit deployment logs in server.log), but no ejb is registered, anyway, no errors in log, and BUILD SUCCESFUL after mvn command. > Finally, an ear file is present under $JBOSS_HOME/standalone/data/content > The strange thing is that if I get that generated ear file, I can succesfully deploy it through the management console, or by copying it to a folder scanned by a deployment-scanner (in both cases the ejbs are correctly deployed) > Nothing found in google! :( > I tried with all the plugin version from 7.1.1 to 7.4. > Also a lot of tries with different maven-ear-plugin and maven-jboss-as-plugin configuration options.... no lucky after two days of work. > Regards, > Matías. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1037) Add log4j2 support for WildFly

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-1037?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-1037: -------------------------------- Summary: Add log4j2 support for WildFly (was: JBoss AS7 and Log4j2) > Add log4j2 support for WildFly > ------------------------------ > > Key: WFLY-1037 > URL: https://issues.jboss.org/browse/WFLY-1037 > Project: WildFly > Issue Type: Clarification > Security Level: Public(Everyone can see) > Components: Logging > Environment: Spring 3, Hibernate, Wicket, JBoss AS7 > Reporter: Amarkanth Ranganamayna > Assignee: James Perkins > Priority: Optional > > I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2. > Looks like Jboss AS7 by default use log4j 1.x > Are you guys already working on using log4j2 ? > If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging. > Thanks, > Amar -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1037) JBoss AS7 and Log4j2

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-1037?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-1037: -------------------------------- Priority: Optional (was: Major) > JBoss AS7 and Log4j2 > -------------------- > > Key: WFLY-1037 > URL: https://issues.jboss.org/browse/WFLY-1037 > Project: WildFly > Issue Type: Clarification > Security Level: Public(Everyone can see) > Components: Logging > Environment: Spring 3, Hibernate, Wicket, JBoss AS7 > Reporter: Amarkanth Ranganamayna > Assignee: James Perkins > Priority: Optional > > I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2. > Looks like Jboss AS7 by default use log4j 1.x > Are you guys already working on using log4j2 ? > If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging. > Thanks, > Amar -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3038) BridgeLogger implementation of Logger does not support Level.OFF or null as parameter values for setLevel method

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-3038?page=com.atlassian.jira.plugin.... ] James Perkins closed WFLY-3038. ------------------------------- Resolution: Out of Date The {{BridgeLogger}} is no longer use. If this is still an issue please reopen. > BridgeLogger implementation of Logger does not support Level.OFF or null as parameter values for setLevel method > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3038 > URL: https://issues.jboss.org/browse/WFLY-3038 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: Antonio Montanana > Assignee: James Perkins > Labels: jboss > > Deploying our application on the JBoss 6.0.0 application server we encounter the following NullPointerException (NPE) also logged in the > log\server.log file: > 2011-03-17 12:52:18,269 ERROR > [filenet_error.engine.com.filenet.engine.tasks.TaskManager] > (TaskManager$RootTask_RootTask_ScheduledPoolExecutor_9) > TaskManager$RootTask:RootTask running with error , with message null: > java.lang.NullPointerException > at org.jboss.logmanager.log4j.LevelMapping.getLevelFor(LevelMapping.java:65) [:6.0.0.Final] > at org.jboss.logmanager.log4j.BridgeLogger.setPriority(BridgeLogger.java:199) [:6.0.0.Final] > at org.jboss.logmanager.log4j.BridgeLogger.setLevel(BridgeLogger.java:194) [:6.0.0.Final] > at com.filenet.engine.util.Logger.removeTraceLoggerLevel(Logger.java:377) > ... > The com.filenet.engine.util.Logger.removeTraceLoggerLevel method executes the following two lines of code: > org.apache.log4j.Logger traceLogger = getLog4JTraceLogger(subsystem, traceFlag); > traceLogger.setLevel(null); > Note the setLevel method is passing in a null parameter value (supported by org.apache.log4j.Logger.setLevel) to remove the specified logging level. We've verified that the JBoss LevelMapping.getLevelFor method throws the NPE as a result of the null parameter value passed into setLevel (changing the parameter value to another level (e.g. Level.DEBUG) eliminates the exception). The setLevel(null) code executed with no exceptions in JBoss 5.1.0 and earlier versions of the server and is supported by org.apache.log4j.Logger.setLevel. > It appears that the logging mechanism has changed significantly in JBoss 6.0, there is now a BridgeLogger class that extends the > org.apache.log4j.Logger class providing the implementation of the setLevel method. That implementation appears to have omitted > support for "null" as a parameter value and causes the NPE. Further testing indicates that the Level.OFF value is also not supported either - leaving no way to remove the logging level. > We would like to see support for "null" and Level.OFF added to the BridgeLogger extension of Logger. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3031) Management audit logging logs parallel boot ops in separate records

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3031?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3031: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1092220|https://bugzilla.redhat.com/show_bug.cgi?id=1092220] from POST to MODIFIED > Management audit logging logs parallel boot ops in separate records > ------------------------------------------------------------------- > > Key: WFLY-3031 > URL: https://issues.jboss.org/browse/WFLY-3031 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.1.0.CR1 > > > The parallel boot ops (i.e. the subsystem stuff) are logged in separate log records from the other stuff. > This is questionable because they are actually all part of the same execution. The main execution blocks for the parallel ops. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2997) AccessAuditContext domainUUID is not set when the domain-uuid header is set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2997?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2997: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1092213|https://bugzilla.redhat.com/show_bug.cgi?id=1092213] from POST to MODIFIED > AccessAuditContext domainUUID is not set when the domain-uuid header is set > --------------------------------------------------------------------------- > > Key: WFLY-2997 > URL: https://issues.jboss.org/browse/WFLY-2997 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.1.0.CR1 > > > org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler creates a UUID and sets "operations-headers" => "domain-uuid" on the op, but it does not pass the same UUID to AccessAuditContext. The result is the log record has null in the domainUUID field but the operation headers part of the "ops" field shows the uuid. Confusing. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2891) Not authorised write operation does not get audit logged if log-read-only="false"

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2891?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2891: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1092203|https://bugzilla.redhat.com/show_bug.cgi?id=1092203] from POST to MODIFIED > Not authorised write operation does not get audit logged if log-read-only="false" > --------------------------------------------------------------------------------- > > Key: WFLY-2891 > URL: https://issues.jboss.org/browse/WFLY-2891 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.CR1 > Reporter: Kabir Khan > Assignee: Brian Stansberry > Fix For: 8.1.0.CR1 > > > This is because audit logging uses the controller lock to find out if the model was a write operation. If rbac is enabled and an operation is not authorised, the error happens before the controller lock is taken. So if audit log log-read-only="false" the failed operation does not get logged. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3017) OperationContextImpl.readResourceForUpdate assumes all resources represent persistent config

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3017?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3017: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1092206|https://bugzilla.redhat.com/show_bug.cgi?id=1092206] from POST to MODIFIED > OperationContextImpl.readResourceForUpdate assumes all resources represent persistent config > -------------------------------------------------------------------------------------------- > > Key: WFLY-3017 > URL: https://issues.jboss.org/browse/WFLY-3017 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.1.0.CR1 > > > The readResourceForUpdate impl makes a few assumptions regarding the fact that a given Resource represents persistent config (i.e. Resource.isRuntime() == true): > 1) It calls rejectUserDomainServerUpdates() which means an OSH running on a server could not call this. > 2) It calls authorize(false, READ_WRITE_CONFIG) which means an OSH for an op available to the RBAC Operator role could not call this. > Places this impacts include LogStoreProbeHandler and LogStoreTransactionDeleteHandler which should be calling readResourceForUpdate but aren't -- and can't because of this bug. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3020) LogStoreProbeHandler overwrites the LogStoreResource root model

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3020?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3020: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1092198|https://bugzilla.redhat.com/show_bug.cgi?id=1092198] from POST to MODIFIED > LogStoreProbeHandler overwrites the LogStoreResource root model > --------------------------------------------------------------- > > Key: WFLY-3020 > URL: https://issues.jboss.org/browse/WFLY-3020 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.1.0.CR1 > > > LogStoreProbeHandler replaces the 'delegate' held by LogStoreResource. Doing this removes any data from the existing delegate's 'model' field, i.e. the "type" attribute. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3283) Upgrade Generic JMS RA to 1.0.5.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3283?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3283: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1090961|https://bugzilla.redhat.com/show_bug.cgi?id=1090961] from MODIFIED to ON_QA > Upgrade Generic JMS RA to 1.0.5.Final > ------------------------------------- > > Key: WFLY-3283 > URL: https://issues.jboss.org/browse/WFLY-3283 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: JMS > Affects Versions: 8.1.0.CR1 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2014