[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
11 years, 6 months
[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
11 years, 6 months
[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
11 years, 6 months
[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
11 years, 6 months
[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
11 years, 6 months
[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
11 years, 6 months
[JBoss JIRA] (AS7-6054) OSGi Bundle Resolution Exception not being revealed
by Ed Roberts (JIRA)
Ed Roberts created AS7-6054:
-------------------------------
Summary: OSGi Bundle Resolution Exception not being revealed
Key: AS7-6054
URL: https://issues.jboss.org/browse/AS7-6054
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP2
Oracle JDK 1.6.0_32
Reporter: Ed Roberts
Assignee: Thomas Diesler
I am able to recreate a bundle resolution problem that gives very little help in where the cause lies.
We deploy a set of Spring 3.1.1.RELEASE bundles in the bundles directory structure, exposed through the standalone.xml capabilities. Separately, a set of bundles are located in the deployments folder, and they include/use some Spring 3.0.7.RELEASE; e.g. beans and core. The reason for the duplication is because a particular LDAP bundle does not work with the later spring bundles. When I deploy the spring-security-ldap-3.1.1.RELEASE.jar in the deployments folder, I get the following WARNING in the console/log file
{code}
2012-11-27 16:24:13,808 WARN [org.jboss.as.osgi](MSC service thread 1-5) JBAS011910: Cannot resolve requirements: []
{code}
The cause of the issue was located during a debug session, to be
{code}
Chain 1:
org.springframework.security.ldap [HostBundleRevision[org.springframework.security.ldap:3.1.1.RELEASE]]
import: null
|
export: osgi.wiring.package=org.springframework.beans
org.springframework.beans [HostBundleRevision[org.springframework.beans:3.0.7.RELEASE]]
Chain 2:
org.springframework.security.ldap [HostBundleRevision[org.springframework.security.ldap:3.1.1.RELEASE]]
import: null
|
export: osgi.wiring.package=org.springframework.context.support; uses:=org.springframework.beans
org.springframework.context [HostBundleRevision[org.springframework.context:3.1.1.RELEASE]]
import: null
|
export: osgi.wiring.package=org.springframework.beans
org.springframework.beans [HostBundleRevision[org.springframework.beans:3.1.1.RELEASE]]
{code}
It seems that when there are multiple providers of a requirement, the requiring bundle is deemed invalid. That doesn't seem correct. Should it not just choose the first valid provider ? Either way, when the Unresolved Bundles are empty in BundleResolveProcessor, the details of the multiple providers should at least be logged as an ERROR as it prevents the bundle from being successfully resolved.
--
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
11 years, 6 months
[JBoss JIRA] (AS7-6046) Logging indicates "missing dependency" not the cause of the error.
by Paul Hinds (JIRA)
Paul Hinds created AS7-6046:
-------------------------------
Summary: Logging indicates "missing dependency" not the cause of the error.
Key: AS7-6046
URL: https://issues.jboss.org/browse/AS7-6046
Project: Application Server 7
Issue Type: Feature Request
Components: Logging
Affects Versions: 7.1.3.Final (EAP)
Reporter: Paul Hinds
Assignee: James Perkins
Priority: Minor
If the Data sources config is incorrect so that the <driver> element does not match an existing driver, the error message is cryptic.
JBAS014775: New missing/unsatisfied dependencies:
service jboss.jdbc-driver.db2xa (missing) dependents: [service jboss.data-source.java:jboss/datasources/myDS]
I would expect a log message at ERROR level, there is no error message while other data sources are loaded.
Missing dependencies is printed on a line with no error level and the text of the message does not relate to the XML.
I would expect the error message to indicate something about where to fix the error.
e.g an XPath
subsystem[xmlns="urn:jboss:domain:datasources:1.0"]/datasources/datasource/driver.
or some text that indicates the <driver> element is the problem.
--
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
11 years, 6 months