[JBoss JIRA] (JBLOGGING-79) Not enough context is shown when a Logger implementation can not be found
by Carlo de Wolf (JIRA)
Carlo de Wolf created JBLOGGING-79:
--------------------------------------
Summary: Not enough context is shown when a Logger implementation can not be found
Key: JBLOGGING-79
URL: https://issues.jboss.org/browse/JBLOGGING-79
Project: JBoss Logging
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Affects Versions: 3.1.0.GA
Reporter: Carlo de Wolf
Assignee: David Lloyd
Both the class loader used and the original ClassNotFoundException should be available in the stack trace.
{noformat}
13:13:21,520 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.messaging.default: org.jboss.msc.service.StartException in service jboss.messaging.default: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
Caused by: java.lang.ExceptionInInitializerError
at org.jboss.as.messaging.HornetQService.start(HornetQService.java:92)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
... 3 more
Caused by: java.lang.IllegalArgumentException: Invalid logger interface org.jboss.as.messaging.MessagingLogger (implementation not found)
at org.jboss.logging.Logger.getMessageLogger(Logger.java:2250)
at org.jboss.logging.Logger.getMessageLogger(Logger.java:2214)
at org.jboss.as.messaging.MessagingLogger.<clinit>(MessagingLogger.java:47)
... 6 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] Created: (JBLOGGING-6) DatasourceAppender
by Luca Stancapiano (JIRA)
DatasourceAppender
------------------
Key: JBLOGGING-6
URL: https://jira.jboss.org/jira/browse/JBLOGGING-6
Project: JBoss Logging
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: jboss-logging-log4j
Affects Versions: 1.0.0.GA-slf4j-jboss-logging, 2.0.6.GA-spi
Reporter: Luca Stancapiano
Assignee: Dimitris Andreadis
Fix For: 2.0.6.GA-spi, 1.0.0.GA-slf4j-jboss-logging
hi.... what do you think about a DatasourceAppender? This is very simple. It overrides getConnection and closeConnection methods of org.apache.log4j.jdbc.JDBCAppender class and it is configurable by a *-log4j.xml file. Here there is an example of xml file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
<appender name="DATABASE" class="org.jboss.logging.appender.DatasourceAppender">
<param name="Threshold" value="INFO"/>
<param name="datasource" value="java:/PortalDS"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value=
"INSERT INTO JBP_LOGGING_SAMPLES_USERS (log_date, log_type, log_user, operation) VALUES ( '%d{yyyy-MM-dd HH:mm:ss.SSS}','%p', '%C;%L', '%C;%L')"/>
</layout>
</appender>
<category name="org.jboss.portal.core.identity.UsersActivityStatsServiceImpl">
<appender-ref ref="DATABASE"/>
</category>
</log4j:configuration>
it is the same configuration for JDBCAppender but there is a 'datasource' parameter so you can specify the datasource location. Below there is the whole class:
/*
* JBoss, Home of Professional Open Source
* Copyright 2005, JBoss Inc., and individual contributors as indicated
* by the @authors tag. See the copyright.txt in the distribution for a
* full listing of individual contributors.
*
* This is free software; you can redistribute it and/or modify it
* under the terms of the GNU Lesser General Public License as
* published by the Free Software Foundation; either version 2.1 of
* the License, or (at your option) any later version.
*
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this software; if not, write to the Free
* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
*/
package org.jboss.logging.appender;
import java.sql.Connection;
import java.sql.SQLException;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.sql.DataSource;
/**
* An extension of the default Log4j JDBCAppender which will use a datasource to
* handle datas into database.
*
* @version <tt>$Revision: 1958 $</tt>
* @author <a href="mailto:jedim@vige.it">Luca Stancapiano</a>
*/
public class DatasourceAppender extends org.apache.log4j.jdbc.JDBCAppender {
/**
* URL of the DB for default connection handling
*/
protected String datasource = "java:/DefaultDS";
protected DataSource ds;
public void setDatasource(final String datasource) {
this.datasource = datasource;
}
/**
* I override this method to get a connection from datasource.
*/
protected Connection getConnection() throws SQLException {
if (connection == null || connection.isClosed()) {
if (ds == null)
try {
InitialContext ic = new InitialContext();
ds = (DataSource) ic.lookup(datasource);
} catch (NamingException e) {
e.printStackTrace();
}
connection = ds.getConnection();
}
return connection;
}
protected void closeConnection(Connection con) {
try {
connection.close();
} catch (SQLException ex) {
ex.printStackTrace();
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] Created: (JBLOGGING-55) NPE in FileAppender$Helper
by Ondrej Zizka (JIRA)
NPE in FileAppender$Helper
--------------------------
Key: JBLOGGING-55
URL: https://issues.jboss.org/browse/JBLOGGING-55
Project: JBoss Logging
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Ondrej Zizka
Assignee: David Lloyd
When you set the file="..." to just a file, i.e. file="foobar.log",
then you get a NPE at line
if (!dir.exists()) {
probably because
dir = new File(filename.trim()).getParentFile();
returns null.
I'd expect the appender to write to a file in new File( new File(System.getProperty("user.dir")), filename.trim() ).
package org.jboss.logging.appender;
import java.io.File;
import java.net.MalformedURLException;
import java.net.URL;
import org.apache.log4j.helpers.LogLog;
public class FileAppender$Helper
{
public static void makePath(String filename)
{
File dir;
try
{
URL url = new URL(filename.trim());
dir = new File(url.getFile()).getParentFile();
}
catch (MalformedURLException e) {
dir = new File(filename.trim()).getParentFile();
}
if (!dir.exists()) {
boolean success = dir.mkdirs();
if (!success)
LogLog.error("Failed to create directory structure: " + dir);
}
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4309) EJB client API implementation is missing configuration which enables "silent auth" for cluster nodes
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4309:
-----------------------------------
Summary: EJB client API implementation is missing configuration which enables "silent auth" for cluster nodes
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.2.Final
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='node-1', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from the same machine as the server. As a result the "silent auth" mechanism as explained "Local clients" section of this doc [1] comes into picture. The EJB client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto connection to a node in the cluster is because the EJB client API implementation is missing this piece of configuration which enables "silent auth" for cluster nodes. We need to fix that to make it consistent with how we handle non-cluster node connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4185) Impossible to use "reload" MDR operation in testsuite run
by Vladimir Rastseluev (JIRA)
Vladimir Rastseluev created AS7-4185:
----------------------------------------
Summary: Impossible to use "reload" MDR operation in testsuite run
Key: AS7-4185
URL: https://issues.jboss.org/browse/AS7-4185
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.1.Final
Reporter: Vladimir Rastseluev
Fix For: 7.1.2.Final
Writing test, using Arquillian, that needs server reloading (e.g.for changing server configuration).
Test successfully pass, when runs alone.
If it runs in testsuite, it can pass or not, but tests,next to it, fail with this exception:
org.jboss.remoting3.NotOpenException: Writes closed
at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:107)
at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296)
at org.jboss.remotingjmx.protocol.v1.Common.write(Common.java:177)
at org.jboss.remotingjmx.protocol.v1.ClientConnection$TheConnection.addNotificationListener(ClientConnection.java:1298)
at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:65)
at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57)
at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] Created: (JBMESSAGING-1826) Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager
by Yong Hao Gao (JIRA)
Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager
----------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1826
URL: https://jira.jboss.org/browse/JBMESSAGING-1826
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core Persistence
Affects Versions: 1.4.7.GA, 1.4.0.SP3.CP10
Reporter: Yong Hao Gao
Assignee: Yong Hao Gao
Fix For: 1.4.0.SP3.CP11, 1.4.8.GA
In JDBCPersistenceManager, when a message is delivered and completed, the message is removed from DB. It includes two deletes in the DB - the reference in JBM_MSG_REF and the message in JBM_MSG. The two deletes are currently done in two separate local transactions as in removeReference() method:
...
new RemoveReferenceRunner().executeWithRetry();
deleteMessage(ref.getMessage().getMessageID());
...
If a server crashes between the two operations, it will leave the tables in an inconsistent state, i.e. ref removed but the message still there. This may result in message stuck, as in this case:
1. A server is crashing when a client_ack comes in, the clienk_ack will cause the message to be cleared from the server. If the client_ack processing goes as far as that the removing of reference succeeds but failed to delete the message due to the crashing, the message is left in JBM_MSG table but the corresponding entry in JBM_MSG_REF is gone.
2. Eventually the jms client will get ack failure exception. It then expects the messages to be re-delivered after server start-up. But that will never happen. When the server starts up it loads references in JBM_MSG_REF for delivery, but this message's ref is gone.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months