November 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JASSIST-42) Proxy serialization looses inner data objects

by Damien Lecan (JIRA)

Proxy serialization looses inner data objects --------------------------------------------- Key: JASSIST-42 URL: http://jira.jboss.com/jira/browse/JASSIST-42 Project: Javassist Issue Type: Bug Reporter: Damien Lecan Assigned To: Shigeru Chiba Priority: Blocker I working with proxies build with ProxyFactory method. When I want to serialize/deserialize it, everything seems to be ok except that only proxy instance is serialized, not inner objects. Eg. Object "A" contains an instance of "B" After serialization/deserialization of a proxy of A, instance of "B" in "A" is null When I look at this code : public static SerializedProxy makeSerializedProxy(Object proxy) throws java.io.InvalidClassException { Class clazz = proxy.getClass(); return new SerializedProxy(clazz, ProxyFactory.getFilter(clazz), ProxyFactory.getHandler(clazz)); } I don't understand how serialization can keep inner objects ... -- 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, 9 months

3
11
0 / 0

[JBoss JIRA] Created: (JBRULES-535) allow for plugeable query result handlers

by Mark Proctor (JIRA)

allow for plugeable query result handlers ------------------------------------------- Key: JBRULES-535 URL: http://jira.jboss.com/jira/browse/JBRULES-535 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 Queries should be able to specify how the results are processed once they reach the terminal node. -- 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, 9 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-4344) Problematic casting to String in org.jboss.jmx.connector.invoker.AuthenticationInterceptor

by David Dossot (JIRA)

Problematic casting to String in org.jboss.jmx.connector.invoker.AuthenticationInterceptor ------------------------------------------------------------------------------------------ Key: JBAS-4344 URL: http://jira.jboss.com/jira/browse/JBAS-4344 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: JBossAS-4.0.4.GA Environment: Mac Os X, RedHat Reporter: David Dossot Assigned To: Dimitris Andreadis There is a problematic cast in org.jboss.jmx.connector.invoker.AuthenticationInterceptor.invoke(Invocation invocation) on line 110: String opname = (String) obj[1]; When Twiddling to get a particular attribute, the following code is used in org.jboss.console.twiddle.command.GetCommand.execute(String[] args) on line 165: attributeNames.toArray(names); (...) AttributeList attrList = server.getAttributes(objectName, names); So obj[1] ends up holding a String[] of attribute names (even if there is only one) and the cast fails: 14:14:44,760 ERROR [Twiddle] Exec failed java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to java.lang.String at org.jboss.jmx.connector.invoker.AuthorizationInterceptor.invoke(AuthorizationInterceptor.java:107) at org.jboss.jmx.connector.invoker.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:108) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179) 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:589) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420) 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:589) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:679) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:704) at java.lang.Thread.run(Thread.java:637) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142) at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133) at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:331) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:194) at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70) at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100) at $Proxy0.getAttributes(Unknown Source) at org.jboss.console.twiddle.command.GetCommand.execute(GetCommand.java:168) at org.jboss.console.twiddle.Twiddle.main(Twiddle.java:305) -- 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, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1804) Logical insertion lingers after the rule that inserted it no longer supports it (with testcase patch)

by Geoffrey De Smet (JIRA)

Logical insertion lingers after the rule that inserted it no longer supports it (with testcase patch) ----------------------------------------------------------------------------------------------------- Key: JBRULES-1804 URL: https://jira.jboss.org/jira/browse/JBRULES-1804 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.0.0.M2 Reporter: Geoffrey De Smet Assignee: Edson Tirelli Priority: Critical Fix For: 5.0.0.M3 This one got me headscratching for a while, untill I realized what the problem is. Tim reported on the mailing list he ran into it to. I've commmited a testcase in subversion, in TruthMaintenanceTest, called disabled_testLogicalInsertionsModifySameRuleGivesDifferentLogicalInsertion Remove the "disabled_" to enable it and try it out. Here's what happens in the testcase: 3 sensors with tempature 100, 200 and 200 are inserted. There's a rule which logically inserts all encountered tempatures, so 100 and 200. Then the first sensor modifies to a tempature of 150. As it turns out, the encoutered tempatures should be 150 and 200 now, but instead it's 100, 150 and 200. Even though there is no sensor that has a tempature of 100. -- 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, 9 months

4
17
0 / 0

[JBoss JIRA] Created: (JBAS-4383) Allow a different JSF implementation to be packaged in the WAR

by Stan Silvert (JIRA)

Allow a different JSF implementation to be packaged in the WAR -------------------------------------------------------------- Key: JBAS-4383 URL: http://jira.jboss.com/jira/browse/JBAS-4383 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JavaServerFaces Affects Versions: JBossAS-4.2.0.CR2, JBossAS-5.0.0.Beta2 Reporter: Stan Silvert Assigned To: Stan Silvert Fix For: JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta3, JBossAS-5.0.0.GA Prior to JEE5, most developers would bundle a JSF implementation such as MyFaces with the WAR. With AS 4.2 and 5.0, you should instead rely on the JSF implementation that ships with the container. However, for these legacy applications that rely on a particular implementation, we can disable the built-in JSF implementation as long as you stick with the default classloader settings. To disable the built-in JSF, you will add this to your web.xml: <context-param> <param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name> <param-value>true</param-value> </context-param> -- 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, 9 months

4
9
0 / 0

[JBoss JIRA] Created: (JBRULES-1260) Include eclipse JDT library in drools-eclipse IDE plugin

by Joshua Jackson (JIRA)

Include eclipse JDT library in drools-eclipse IDE plugin -------------------------------------------------------- Key: JBRULES-1260 URL: http://jira.jboss.com/jira/browse/JBRULES-1260 Project: JBoss Drools Issue Type: Task Security Level: Public (Everyone can see) Components: Eclipse IDE Affects Versions: 4.0.1 Reporter: Joshua Jackson Assigned To: Mark Proctor Fix For: 4.0.2 Include the core-3.2.3.v_686_R32x.jar inside the drools-eclipse IDE plugin otherwise rules can not be run from eclipse and throw this exception: org.drools.RuntimeDroolsException: Unable to load dialect 'org.drools.rule.builder.dialect.java.JavaDialectConfiguration:java' at org.drools.compiler.PackageBuilderConfiguration.buildDialectRegistry(PackageBuilderConfiguration.java:134) at org.drools.compiler.PackageBuilderConfiguration.init(PackageBuilderConfiguration.java:110) at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:83) at org.drools.compiler.PackageBuilder.<init>(PackageBuilder.java:120) at org.drools.compiler.PackageBuilder.<init>(PackageBuilder.java:86) at com.sample.DroolsTest.readRule(DroolsTest.java:50) at com.sample.DroolsTest.main(DroolsTest.java:21) Caused by: java.lang.RuntimeException: The Eclipse JDT Core jar is not in the classpath at org.drools.rule.builder.dialect.java.JavaDialectConfiguration.setCompiler(JavaDialectConfiguration.java:98) at org.drools.rule.builder.dialect.java.JavaDialectConfiguration.init(JavaDialectConfiguration.java:56) at org.drools.compiler.PackageBuilderConfiguration.buildDialectRegistry(PackageBuilderConfiguration.java:130) ... 6 more -- 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, 9 months

10
18
0 / 0

[JBoss JIRA] Created: (JBREFLECT-16) Fix the serialization for the javassist based ClassInfo implementation

by Adrian Brock (JIRA)

Fix the serialization for the javassist based ClassInfo implementation ---------------------------------------------------------------------- Key: JBREFLECT-16 URL: http://jira.jboss.com/jira/browse/JBREFLECT-16 Project: JBoss Reflection Issue Type: Task Components: Javassist Affects Versions: JBossReflection.2.2.0.Beta1 Reporter: Adrian Brock Make and test the javassist ClassInfo implementation Serializable -- 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, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAOP-577) Optimize adding aspect bindings to instance advisors

by Kabir Khan (JIRA)

Optimize adding aspect bindings to instance advisors ---------------------------------------------------- Key: JBAOP-577 URL: http://jira.jboss.com/jira/browse/JBAOP-577 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.1.0.GA With the changes from JBAOP-575, it seems that the chains are still fully calculated when woven with GeneratedAdvisorInstrumentor if added for an instance. Run org.jboss.test.aop.dynamicgenadvisor.DynamicTester.testSimpleInstanceUsingDomainForMethod() and testInstanceUsingDomainForMethod() in a debugger to see what I mean -- 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, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-5570) URLDeploymentScanner: relies on FileInputStream finalizer - causes too many open files too easily

by Toomas Rￃﾃￂﾶmer (JIRA)

URLDeploymentScanner: relies on FileInputStream finalizer - causes too many open files too easily ------------------------------------------------------------------------------------------------- Key: JBAS-5570 URL: http://jira.jboss.com/jira/browse/JBAS-5570 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Deployers Affects Versions: JBossAS-4.2.2.GA Environment: Running on Debian unstable with JDK 1.6_06 Reporter: Toomas Rￃﾃￂﾶmer Assigned To: Ales Justin I'm a JavaRebel developer from ZeroTurnaround and have been debugging an issue with "Too many open files" with JBoss that we got reported against JavaRebel. The problem: Users are getting "Too many open files" exceptions when starting and then using JBoss. The reason: *) JBoss by default has configured a mbean org.jboss.deployment.scanner.URLDeploymentScanner which scans every 5 seconds for changes in the deployment descriptors *) The implementation does a connection = URL.openConnection() and then connection.getLastModified() to check for changes. *) The underlying implementation for regular files is java.io.FileInputStream *) The resource is not explicitly closed as FileInputStream will doit it by itself in the finalizer() *) Handles are freed when GC happens (finalizer logic) I came to this conclusion by getting the number of filehandles (lsof -p <jboss-pid>). Stepping through URLDeploymentScanner and seeing the handles grow by one after every connection.getLastModified(). In all tests the handles grow by one after this call. I also let the handles grow to a few thousand and then attached a debugger and after hitting a breakpoint called System.gc() on the JVM and the number of filehandles nicely went down to ~380 with my deployment folder. Possible solution: Check for the file modification date with explicit closing. -- 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, 9 months

8
9
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-156) Look at options for reducing vfs memory usage

by Scott M Stark (JIRA)

Look at options for reducing vfs memory usage --------------------------------------------- Key: JBMICROCONT-156 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-156 Project: JBoss MicroContainer Issue Type: Task Components: VFS Affects Versions: JBossMC_2_0_0 Beta3 Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossMC_2_0_0_CR1 The vfs is eagerly creating URLs for every jar entry touched. This is resulting in a large amount of memory just for Strings. We need to look into reusing the existing name in combination with the root url handler rather than creating new urls to reduce the memory usage. -- 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, 9 months

4
13
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2008