December 2009 - jboss-jira - Jboss List Archives

[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, 2 months

4
14
0 / 0

[JBoss JIRA] Created: (HIBERNATE-54) problems w/ column names beginning with '_' (underscore) w/ apache derby database

by bugra uytun (JIRA)

problems w/ column names beginning with '_' (underscore) w/ apache derby database --------------------------------------------------------------------------------- Key: HIBERNATE-54 URL: http://jira.jboss.com/jira/browse/HIBERNATE-54 Project: Hibernate Issue Type: Bug Environment: windows xp, java 1.5.0_09, eclispe 3.2.1, hibernate 3.2.1, derby 10.2.2.0, hibernate tools 3.2 beta8 Reporter: bugra uytun Assigned To: Steve Ebersole derby has problems with column names beginning with underscore, see also http://db.apache.org/derby/docs/10.1/ref/crefsqlj1003454.html therefore such column names should be between double quotation marks (notice that double quotation marks also sets the case sensitivity on column names.) but hibernate translates a HQL statement like this "from table1 t where t.id = '1'" to something like: select table1_.id as id4, table1_._colname1 as column27_4_ schema1.table1 table1_ where table1_.id = '1' but because of the columns that are beginning with an underscore the translation should be: select table1_."id" as id4, table1_."_colname1" as column27_4_ schema1."table1" table1_ where table1_."id" = '1' the errors i got are: DEBUG [JDBCExceptionReporter]: could not execute query [<translated sql statement>] ERROR 42X01: Syntax error: Encountered "_" at line 1, column 987. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown Source) at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:497) at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:415) at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139) at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1538) at org.hibernate.loader.Loader.doQuery(Loader.java:661) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224) at org.hibernate.loader.Loader.doList(Loader.java:2211) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2095) at org.hibernate.loader.Loader.list(Loader.java:2090) at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:388) at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338) at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121) at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79) at <mypackage>.MyHibernate.main(MyHibernate.java:13) WARN main org.hibernate.util.JDBCExceptionReporter - SQL Error: 20000, SQLState: 42X01 ERROR main org.hibernate.util.JDBCExceptionReporter - Syntax error: Encountered "_" at line 1, column 987. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1577) Require at least maven 2.0.9

by Carlo de Wolf (JIRA)

Require at least maven 2.0.9 ---------------------------- Key: EJBTHREE-1577 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1577 Project: EJB 3.0 Issue Type: Feature Request Components: build Reporter: Carlo de Wolf Assignee: Carlo de Wolf Fix For: 1.0.0-Beta7 Because a bug in Maven with the ordering of the class path, you need at least version 2.0.9. -- 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, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2385) A BestSolutionChangedEvent should be fired when a StartingSolutionInitializer generates a new best solution

by Geoffrey De Smet (JIRA)

A BestSolutionChangedEvent should be fired when a StartingSolutionInitializer generates a new best solution ----------------------------------------------------------------------------------------------------------- Key: JBRULES-2385 URL: https://jira.jboss.org/jira/browse/JBRULES-2385 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-solver Affects Versions: 5.1.0.M1 Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet try examination example with exam set 2: after initialization the score in the dialog is stale -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-541) Thread pools in transport protocols not using daemon threads

by Paul Ferraro (JIRA)

Thread pools in transport protocols not using daemon threads ------------------------------------------------------------ Key: JGRP-541 URL: http://jira.jboss.com/jira/browse/JGRP-541 Project: JGroups Issue Type: Bug Affects Versions: 2.5 Reporter: Paul Ferraro Assigned To: Bela Ban Priority: Minor The ThreadFactory used by the ThreadPoolExecutors (for both regular and OOB messages) in org.jgroups.protocols.TP does not create daemon threads. During runtime the JVM will resist exiting unless the channel is explicitly shutdown. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

4
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1744) Create an ivy resolver for maven uniquely versioned snapshots

by Carlo de Wolf (JIRA)

Create an ivy resolver for maven uniquely versioned snapshots ------------------------------------------------------------- Key: EJBTHREE-1744 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1744 Project: EJB 3.0 Issue Type: Feature Request Reporter: Carlo de Wolf Assignee: Carlo de Wolf -- 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, 2 months

1
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2372) Task - User ReceivedTime whenever Claim operation happens

by vijpan (JIRA)

Task - User ReceivedTime whenever Claim operation happens --------------------------------------------------------- Key: JBRULES-2372 URL: https://jira.jboss.org/jira/browse/JBRULES-2372 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-process-task Affects Versions: 5.1.0.M1 Reporter: vijpan Assignee: Mark Proctor Hi, Is there a way possible where "Received Time" can be stored at Task level. This datetime value should get updated with the current timestamp whenever "Claim" operation happens on the Task. The use case is that most of the time if its a 1 potential owner of the task - the task goes through "created/ready/reserved" status whenever a new Task gets created, in this case creation time would be same as received time --- but whenever the task is assigned to group or multiple potential owner or even when it is in reserved status it can be forwarded/delegated to other user/group - then in that case whenever user receives as task or in WSHT tem claim operation happens can we store the timestamp at the task level. Currently at task level we have creation time/activation time/expiration time ---- may be activation time can be used but i guess its use is very specific as detailed in WSHT/BPEL4People spec. In real world scenario it becomes quite important that when the user actually claimed the task or was assigned the task. Vijay -- 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, 2 months

5
4
0 / 0

[JBoss JIRA] Created: (JBASPECT-29) Aspects Security Unit Tests

by Anil Saldhana (JIRA)

Aspects Security Unit Tests --------------------------- Key: JBASPECT-29 URL: https://jira.jboss.org/jira/browse/JBASPECT-29 Project: JBoss Aspects Issue Type: Task Components: security Reporter: Anil Saldhana Assignee: Anil Saldhana Since aspects security has been given to me based on merit, I am jittery ever since we moved it out as an external project. The unit tests are in the AS test suite. There is a need to have some unit tests for aspects security such that a change happens in aspects security, other projects (ejb3, profile services etc) do not get affected, due to regression. -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1500) Discrepancies between removing a bean in cache vs bean passivated

by Galder Zamarreno (JIRA)

Discrepancies between removing a bean in cache vs bean passivated ----------------------------------------------------------------- Key: EJBTHREE-1500 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1500 Project: EJB 3.0 Issue Type: Sub-task Affects Versions: AS 4.2.3.GA, AS 5.0.0.CR1 Reporter: Galder Zamarreno Assignee: Galder Zamarreno There's a discrepancy between removing a bean from the cache after a timeout when bean is in cache compared to when bean is passivated: Example, when bean is in cache and has to be removed, this is called: if (now - centry.lastUsed >= removalTimeout * 1000) { synchronized (centry) { it.remove(); } } Now, when bean is passivated, this is called: if (now - centry.lastUsed >= removalTimeout * 1000) { get(centry.getId(), false); remove(centry.getId()); } And remove() method calls: if(log.isTraceEnabled()) { log.trace("Removing context " + key); } StatefulBeanContext ctx = null; synchronized (cacheMap) { ctx = (StatefulBeanContext) cacheMap.get(key); } if(ctx == null) throw new NoSuchEJBException("Could not find Stateful bean: " + key); if (!ctx.isRemoved()) container.destroy(ctx); ++removeCount; if (ctx.getCanRemoveFromCache()) { synchronized (cacheMap) { cacheMap.remove(key); } } What this means is that when a bean in cache is removed: 1.- removeCount is not updated 2.- container.destroy(ctx); is not executed and hence the @Remove method is not executed either. -- 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, 3 months

4
7
0 / 0

[JBoss JIRA] Created: (JGRP-855) java.lang.IllegalStateException: Could not flush the cluster and proceed with state retri eaval

by Clebert Suconic (JIRA)

java.lang.IllegalStateException: Could not flush the cluster and proceed with state retri eaval ------------------------------------------------------------------------------------------------ Key: JGRP-855 URL: https://jira.jboss.org/jira/browse/JGRP-855 Project: JGroups Issue Type: Bug Affects Versions: 2.6.5 Reporter: Clebert Suconic Assignee: Vladimir Blagojevic When getState is called right after the connect even with flush, eventually (intermitently) you will get this exception: SomeException: ... Caused by: java.lang.IllegalStateException: Could not flush the cluster and proceed with state retri eaval at org.jgroups.JChannel.getState(JChannel.java:1041) at org.jgroups.JChannel.getState(JChannel.java:973) at org.jgroups.JChannel.getState(JChannel.java:927) at org.jboss.messaging.core.impl.postoffice.GroupMember.start(GroupMember.java:152) ... Notice that this only started to happen only after this change: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/messaging/branches/Branch_1_4/... -- 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, 3 months

5
11
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 December 2009