November 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5913) RAR (inbound adapter) inside EAR does not see JAR files in EAR/lib

by Juan José Olmedilla Arregui (JIRA)

Juan José Olmedilla Arregui created AS7-5913: ------------------------------------------------ Summary: RAR (inbound adapter) inside EAR does not see JAR files in EAR/lib Key: AS7-5913 URL: https://issues.jboss.org/browse/AS7-5913 Project: Application Server 7 Issue Type: Bug Environment: JBoss 7.1.2 on Windows 7 and Windos Vista Reporter: Juan José Olmedilla Arregui -I have a RAR file and EJB JAR inside my EAR. The RAR includes several JAR libraries only used by it which are packed within it. - The EJB JAR includes an MDB that receives the inbound messages from the Resource Adapter and therefore needs to have access to the same MessageListener interface which is in the common JAR file library included in EAR/lib. - The RAR has a dependency on the common MessageListener interface included in the JAR file sitting in EAR/lib - The project is a maven multi-module project using maven jar (for the commong library where the interface is), ejb, ear and rar plugins - Things I have tried: 1. Including "compile" dependency to the common jar in both, the EJB JAR and RAR. It does not work because it includes two copies of the jar, one in the EAR/lib and one inside the RAR, it deploys but later it fails when a message is received because there are two different bytecodes for the same class. 2. Including a Dependency in the MANIFEST of the RAR pointing to deployment.EARNAME.ear.MYLIBNAME.jar. It does not find that dependency 3. Including a Dependency in the MANIFEST of the RAR pointing to deployment.EARNAME.ear.lib.MYLIBNAME.jar. It does not find that deployment 4. Including the dependency as "provided" in the EJB project as in the RAR, including in both MANIFEST's a dependency on "deployment.MYLIBNAME.jar" and deploying separately the MYLIBNAME.jar and EARNAME.ear. This works but I want a solution that allows me to pack everything in one single EAR file -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
8
0 / 0

[JBoss JIRA] (AS7-4613) hibernate.hbm2ddl.auto=create-drop fails arquillian tests, but value=create works fine

by Craig Schwarzwald (JIRA)

Craig Schwarzwald created AS7-4613: -------------------------------------- Summary: hibernate.hbm2ddl.auto=create-drop fails arquillian tests, but value=create works fine Key: AS7-4613 URL: https://issues.jboss.org/browse/AS7-4613 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.1.1.Final Reporter: Craig Schwarzwald Priority: Critical You can find my project with the tests here: https://github.com/CavemanCraig/IssueWithTestsUsingCreateDrop/tags I created 2 tags, a v0.9 which has persistence.xml specifying value=create which you can use to prove the tests work correctly, and v1.0 which specifies value=create-drop which should work just as well, but doesn't. The main error that seems to be getting returned is: Caused by: org.h2.jdbc.JdbcSQLException: Sequence "HIBERNATE_SEQUENCE" not found; SQL statement: call next value for hibernate_sequence [90036-161] This same code was working about a week ago even with specifying "create-drop". -- 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

13 years, 1 month

2
4
0 / 0

[JBoss JIRA] (JBRULES-3697) git-clone-others.sh script should work on Mac too

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created JBRULES-3697: ----------------------------------------- Summary: git-clone-others.sh script should work on Mac too Key: JBRULES-3697 URL: https://issues.jboss.org/browse/JBRULES-3697 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: All Reporter: Geoffrey De Smet Assignee: Toni Rikkola Basically, on this script https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/scri... these 3 requirements need to be met: * Works with all 3 git URL types (used to clone droolsjbpm-build-bootstrap) ** HTTP: https://github.com/droolsjbpm/droolsjbpm-build-bootstrap.git ** SSH: git@github.com:droolsjbpm/droolsjbpm-build-bootstrap.git ** Git Read-Only: git://github.com/droolsjbpm/droolsjbpm-build-bootstrap.git * Works on forks too ** Blessed: git@github.com:droolsjbpm/droolsjbpm-build-bootstrap.git ** ge0ffrey: git@github.com:ge0ffrey/droolsjbpm-build-bootstrap.git ** Rikkola: git@github.com:Rikkola/droolsjbpm-build-bootstrap.git * Works on Mac -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
1
0 / 0

[JBoss JIRA] (AS7-6040) Remove the arquillian/service code as it is dead code

by Navin Surtani (JIRA)

Navin Surtani created AS7-6040: ---------------------------------- Summary: Remove the arquillian/service code as it is dead code Key: AS7-6040 URL: https://issues.jboss.org/browse/AS7-6040 Project: Application Server 7 Issue Type: Task Affects Versions: 7.2.0.CR1 Reporter: Navin Surtani Assignee: Navin Surtani Fix For: 7.2.0.Alpha1 The code in the arquillian/service has been moved to the jmx protocol module. As a result, it should be removed from the AS 7 code base. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
5
0 / 0

[JBoss JIRA] (JBAS-2473) Remote side ClassCastExceptions as a result of WrapperDataSourceService using "getInterfaces()" to create Proxies.

by Leonardo Mendoza (JIRA)

[ https://issues.jboss.org/browse/JBAS-2473?page=com.atlassian.jira.plugin.... ] Leonardo Mendoza commented on JBAS-2473: ---------------------------------------- I would like to re-open this issue. In my testing of JBoss 4.0.4.GA, 5.1.0.GA, and 6.1.0.Final I've always encountered ClassCastExceptions when DatabaseMetaData methods that return ResultSets are called. According to this post on the ~StackOverflow website: [Java.lang.reflect.Proxy returning another proxy from invocation results in ClassCastException on assignment | http://stackoverflow.com/questions/2642700/java-lang-reflect-proxy-return...], the method that retrieves all interfaces implemented by the provided class needs to use a transitive closure to properly get the interfaces. The {{org.jboss.util.Classes.getAllInterfaces(Class)}} needs to change so that it properly retrieves all implemented interfaces: {code:title=org.jboss.util.Classes - current implementation} /** * Populates a list with all the interfaces implemented by the argument * class c and all its superclasses. * * @param allIfaces - the list to populate with the interfaces * @param c - the class to start scanning for interfaces */ public static void getAllInterfaces(List allIfaces, Class c) { while (c != null) { Class[] ifaces = c.getInterfaces(); for (int n = 0; n < ifaces.length; n ++) { allIfaces.add(ifaces[n]); } c = c.getSuperclass(); } } {code} {code:title=org.jboss.util.Classes - FIXED implementation} /** * Populates a list with all the interfaces implemented by the argument * class c and all its superclasses. * * @param allIfaces - the list to populate with the interfaces * @param c - the class to start scanning for interfaces */ public static void getAllInterfaces(List allIfaces, Class c) { allIfaces.addAll(getInterfaces(c)); } /** * Correctly gets all interfaces implemented by the given class. * {@code Class.getInterfaces()} returns only the interfaces DIRECTLY * implemented by the class. You need a transitive closure to obtain all the * interfaces. * Solution taken from http://stackoverflow.com/questions/2642700/java-lang-reflect-proxy-return... * @param clazz the class to get all the interfaces from. * @return all interfaces implemented by {@code clazz} and its superclasses. */ private static List<Class<?>> getInterfaces(Class<?> clazz) { List<Class<?>> interfaces = new ArrayList<Class<?>>(); if (clazz.isInterface()) { interfaces.add(clazz); } else { do { addInterfaces(clazz, interfaces); clazz = clazz.getSuperclass(); } while (clazz != null); } for (int i = 0; i < interfaces.size(); ++i) { addInterfaces(interfaces.get(i), interfaces); } return interfaces; } /** * Helper method used by {@code getInterfaces(...)} for getting all the * interfaces implemented by {@code clazz} and its superclasses. * @param clazz the class to get all the interfaces from. * @param interfaces the {@code List} of interfaces implemented by * {@code clazz} and its parent classes. */ private static void addInterfaces(Class<?> clazz, List<Class<?>> interfaces) { for (Class<?> intf : clazz.getInterfaces()) { if (!interfaces.contains(intf)) { interfaces.add(intf); } } } {code} I have tested this code on 5.1.0.GA and it works without issue. > Remote side ClassCastExceptions as a result of WrapperDataSourceService using "getInterfaces()" to create Proxies. > ------------------------------------------------------------------------------------------------------------------ > > Key: JBAS-2473 > URL: https://issues.jboss.org/browse/JBAS-2473 > Project: Application Server 3 4 5 and 6 > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remoting > Affects Versions: JBossAS-4.0.3 SP1 > Environment: Windows XP, jdk1.5.0_05 > Reporter: J Barkanic > Fix For: JBossAS-4.0.4.CR2, JBossAS-5.0.0.Beta1 > > > The methods, createStatementProxy and createResultSetProxy in WrapperDataSourceService use Object.getClass().getInterfaces() to gather interface information in order to create proxies to the database driver Statement and ResultSet objects. However, if the underlying driver implementation objects inherit their interfaces from a superclass, "getInterfaces()" will not return those interfaces. (Derby Embedded driver does this for ResultSet) This causes a ClassCastException on the remote side. > Other methods like createDatabaseMetaData just set the java.sql interface explicitly when creating the proxy. (I don't know if there was a reason not to do this in these two methods). > public interface MyInterface{ > public void interfaceMethod(); > } > public abstract class MyObjectA implements MyInterface{ > public void interfaceMethod(){ > //Implement interface > } > } > public class MyObjectB extends MyObjectA{ > public void interfaceMethod(){ > //Overridden implementation > } > } > public class Tester{ > public static void main(String[] args){ > MyObjectB b = new MyObjectB(); > Class[] ifaces = b.getClass().getInterfaces(); //<----------- This will not contain MyInterface > } > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-5792) Deadlock detection for Entity beans

by Christian Inzko (JIRA)

Christian Inzko created AS7-5792: ------------------------------------ Summary: Deadlock detection for Entity beans Key: AS7-5792 URL: https://issues.jboss.org/browse/AS7-5792 Project: Application Server 7 Issue Type: Feature Request Components: EJB Affects Versions: 7.1.1.Final Environment: Windows 7 64 bit, Java 1.7.0 64 bit Reporter: Christian Inzko Assignee: jaikiran pai Deadlock detection with EJB 2.1 entity beans and pessimistic locking does not work. We are migrating our application from Jboss 4.05 where we used entity beans. This jboss version was able to detect deadlock situations and throw a org.jboss.util.deadlock.ApplicationDeadlockException. This mechanism does no longer work - instead of that both transactions just hang until a transaction timeout is reached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
2
0 / 0

[JBoss JIRA] (AS7-4707) Preventing reconnect attempt of remote ejb client

by Serkan Yıldırım (JIRA)

Serkan Yıldırım created AS7-4707: ------------------------------------ Summary: Preventing reconnect attempt of remote ejb client Key: AS7-4707 URL: https://issues.jboss.org/browse/AS7-4707 Project: Application Server 7 Issue Type: Bug Components: Remoting, Server Affects Versions: 7.1.1.Final Reporter: Serkan Yıldırım Assignee: David Lloyd Priority: Blocker Hi, I have a remote ejb client and a custom login module. I am testing my login module, i enter an invalid password in remote client. My login module runs correctly and send an exception. However, remote client attempts to recall login module again to login user. But i do not want this. Because when there is an exception in my custom login module, i update some values in my database. Therefore the same code in login module runs twice and my db has inconsistent values. So how can i prevent this reconnect attemp of remote ejb client? I use JBOSS 7.1.2 Final SNAPSHOT version in server and jboss 7.1.1 client maven dependencies. Thanks. My Client code is like below: Properties pr = new Properties(); pr.put("endpoint.name", "client-endpoint"); pr.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false"); pr.put("remote.connections", "default"); pr.put("remote.connection.default.port", "4447"); pr.put("remote.connection.default.host", "localhost"); pr.put("remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS", "JBOSS-LOCAL-USER"); pr.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false"); pr.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false"); pr.put("remote.connection.default.username", "user1"); pr.put("remote.connection.default.password", "Test12345"); EJBClientConfiguration cc = new PropertiesBasedEJBClientConfiguration(pr); ContextSelector < EJBClientContext > selector = new ConfigBasedEJBClientContextSelector(cc); EJBClientContext.setSelector(selector); Properties props = new Properties(); props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); props.put("jboss.naming.client.ejb.context", true); try { Context c = new InitialContext(props); kullaniciEJB = (KullaniciEJBRemote) c.lookup("ejb:merveys-kayit-tckkys/merveys-kayit-ejb-tckkys//KullaniciEJB!tr.gov.tubitak.bilgem.uekae.deys.tckk.merveys.common.controller.ejb.kullanici.KullaniciEJBRemote"); } catch (NamingException e) { e.printStackTrace(); } int count = kullaniciEJB.countKartIslemList(1L, null, null); -- 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

13 years, 1 month

2
6
0 / 0

[JBoss JIRA] (AS7-5307) Dropped connection to EJB Server from Resin Web app

by Graeme Wallace (JIRA)

Graeme Wallace created AS7-5307: ----------------------------------- Summary: Dropped connection to EJB Server from Resin Web app Key: AS7-5307 URL: https://issues.jboss.org/browse/AS7-5307 Project: Application Server 7 Issue Type: Bug Components: EJB Affects Versions: 7.1.2.Final (EAP) Reporter: Graeme Wallace Assignee: jaikiran pai >From a resin web application, after opening a connection to a JBoss 7 server for EJB calls, the connection is randomly closed. A full worked up example is included in the forum post. -- 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

13 years, 1 month

3
3
0 / 0

[JBoss JIRA] (LOGMGR-54) org.jboss.logmanager.handlers.AsyncHandler.AsyncTask should call flush when queue runs empty

by Rico Neubauer (JIRA)

Rico Neubauer created LOGMGR-54: ----------------------------------- Summary: org.jboss.logmanager.handlers.AsyncHandler.AsyncTask should call flush when queue runs empty Key: LOGMGR-54 URL: https://issues.jboss.org/browse/LOGMGR-54 Project: JBoss Log Manager Issue Type: Enhancement Security Level: Public (Everyone can see) Components: core Affects Versions: 1.3.2.Final, 1.4.0.Beta1 Reporter: Rico Neubauer Assignee: David Lloyd When using the org.jboss.logmanager.handlers.AsyncHandler in combination with handlers that use autoFlush=false it happens that output stalls when queue runs empty. A workaround is to set autoflush=true, however this introduces a flush always, even if there are more records in the queue, which render the flush useless. An optimization is to invoke flush() on the handlers if the AsyncTask's queue ran empty - since then there is nothing else to do anyhow. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
6
0 / 0

[JBoss JIRA] (AS7-6056) Implement a consistent integration plugin API

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-6056?page=com.atlassian.jira.plugin.s... ] Thomas Diesler moved JBOSGI-621 to AS7-6056: -------------------------------------------- Project: Application Server 7 (was: JBoss OSGi) Key: AS7-6056 (was: JBOSGI-621) Workflow: GIT Pull Request workflow (was: jira) Component/s: OSGi (was: Core Framework) Security: (was: Public) Fix Version/s: 7.2.0.Alpha1 (was: JBossOSGi 1.2.0) > Implement a consistent integration plugin API > --------------------------------------------- > > Key: AS7-6056 > URL: https://issues.jboss.org/browse/AS7-6056 > Project: Application Server 7 > Issue Type: Task > Components: OSGi > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: 7.2.0.Alpha1 > > > Currently there are a number of different approaches for OSGi Framework/AS7 integration. These should be consolidated and all integration should be done through the SPI. Changes to the SPI can then be properly reflected on the (semantic) version of the framework -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

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 November 2012