[JBoss JIRA] Created: (JBAS-5900) jars are not loaded from the lib directory of a sar in JBoss AS 5
by Matt Wringe (JIRA)
jars are not loaded from the lib directory of a sar in JBoss AS 5
-----------------------------------------------------------------
Key: JBAS-5900
URL: https://jira.jboss.org/jira/browse/JBAS-5900
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ClassLoading
Affects Versions: JBossAS-5.0.0.CR2
Reporter: Matt Wringe
Assignee: Scott M Stark
Attachments: testsar.tar.gz
In JBoss AS 5, any jars placed in the lib directory of a sar are not loaded and results in a class not found exception. The classes are loaded if the jar is placed in the root directory of the sar.
On previous versions of JBoss AS, the classes would be loaded from either location. This prevents sars that would have worked on JBoss AS 4 to fail on JBoss AS 5.
Steps to reproduce:
1) take zip attached to this report.
2) deploy test-in-lib.sar to JBoss AS 5. The sar will not deploy and will fail with a classNotFoundException
3) deploy test-in-lib.sar to JBoss AS 4, the sar will deploy without issue.
test-in-root.sar will work on both versions of JBoss. The only difference between these sars is the location of the jar.
--
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
11 years, 9 months
[JBoss JIRA] Created: (HIBERNATE-100) All versions of hibernate-tools packages are broken on eclipse-3.4
by solid Iduncare (JIRA)
All versions of hibernate-tools packages are broken on eclipse-3.4
------------------------------------------------------------------
Key: HIBERNATE-100
URL: http://jira.jboss.com/jira/browse/HIBERNATE-100
Project: Hibernate
Issue Type: Bug
Environment: Reproducable on Linux, Windows and Mac OSX
Reporter: solid Iduncare
Assigned To: Steve Ebersole
All versions of the Jboss hibernate-tools eclipse plugin fail in various ways on eclipse-3.4 (Ganymede). I have obtained various versions of the plugin via the eclipse update sites (both stable and dev) and all have various problems. I first attempted to download the latest from the stable update link (http://download.jboss.org/jbosstools/updates/stable/) . I selected the hibernate tools package for install only. It installs but is unusable. It seems to have no ill effects otherwise. When you attempt to add a hibernate configuration in the hibernate console, you get an exception similar to the followng:
java.lang.NoClassDefFoundError: org/eclipse/ui/internal/util/SWTResourceUtil
at org.hibernate.eclipse.console.workbench.xpl.AnyAdaptableLabelProvider.getImage(AnyAdaptableLabelProvider.java:166)
at org.eclipse.jface.viewers.WrappedViewerLabelProvider.getImage(WrappedViewerLabelProvider.java:117)
at org.eclipse.jface.viewers.WrappedViewerLabelProvider.update(WrappedViewerLabelProvider.java:165)
at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:145)
at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:932)
at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:102)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.runtime.Platform.run(Platform.java:880)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:1012)
at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:466)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.runtime.Platform.run(Platform.java:880)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:2041)
at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:827)
at org.eclipse.jface.viewers.AbstractTreeViewer.createAddedElements(AbstractTreeViewer.java:340)
at org.eclipse.jface.viewers.AbstractTreeViewer.internalAdd(AbstractTreeViewer.java:270)
at org.eclipse.jface.viewers.TreeViewer.internalAdd(TreeViewer.java:652)
at org.hibernate.eclipse.console.viewers.xpl.MTreeViewer.add(MTreeViewer.java:106)
at org.eclipse.ui.progress.DeferredTreeContentManager$3.runInUIThread(DeferredTreeContentManager.java:353)
at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:94)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3800)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3425)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2382)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
I googled this error and it brought me to a hibernate jira page hosted by atlasian. That Jira page recommended using the latest hibernate tools plugin from the dev update site(http://download.jboss.org/jbosside/hibernatetools/updates/development/) so I did. Now this is where all hell brakes loose. After installing the latest version from this site and restarting eclipse, the JEE perspective is completely disabled. JSP files open in a regular text editor and all attempts to update eclipse fail with this exception:
Cannot complete the request. See the details.
Cannot find a solution where both Match[requiredCompatibility:
org.eclipse.equinox.p2.iu/org.eclipse.emf.ecore.xml/[2.1.0,2.1.0]] and Match[requiredCompatability:
....
In short there is no usable version of hibernate tools for eclipse-3.4.
--
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
11 years, 10 months
[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
11 years, 11 months
[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
11 years, 11 months
[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
11 years, 11 months