November 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - Re: static field replication in PojoCache

by ben.wang＠jboss.com

"genman" wrote : Why are 4 and 5 even good ideas, let alone "requirements"? Yeah, sorry, just missed typing the "restriction" part. anonymous wrote : | As a user, I would want to specify where the static variable is stored and how and if it is replicated. The "registerClass" would essentially link a class to the cache. A class would have to belong to a single cache. Le'ts say we change your api naming first to "registerStaticVariableClass" to be more verbose. An additional api like that (and possibly unregisterStaticVariableClass) is certainly ok but like I mentioned it adds additional APIs to PojoCache, of which I'd like to avoid if possible, especially this won't be used often. Furthermore, there are 2 pitfalls: 1. There are some dependency on the static variable lifecycle. Consider this: | POJO.someStaticVar = 20; // setting but no replication yet. | cache = PojoCacheFactory.createCache(...); | cache.registerStaticVariableClass(Pojo.class); | // Still no POJO.someStaticVar replication yet unless we do | // POJO.someStaticVar = 30; to trigger replication. | // But now we failover to the other node and do | int val = POJO.someStaticVar; // this is not 20! | Of course this probably doesn't happen often but there is the possibility. 2. You will need to invoke this API in every cache instance in the clustering group (even the others are merely acting as passive backup) in order for it be funtion properly. E.g., cache1 and cache2 will need individually: | cache = PojoCacheFactory.createCache(...); | cache.registerStaticVariableClass(Pojo.class); | Otherwise, when you failover, the remote cache will have no knowledge of interceptiong the anonymous wrote : | 1. User needs to be able to specify which PojoCache they are replicating their object with. This is becaues it's a common use case to have multiple PojoCache instances per JVM. There are 2 difference cases for multiple PojoCache instances inside same vm: 1. Different clustering groups, e.g., one cache instance for http and another one for ejb, and furthermore the all use the same POJO static variable. a) They don't share the same POJO.statVar field and expect it to be replicated to a specific cache instance. In this case, only a specific cache instance is needed to replicate the static variable. Yes, we should support this fashion of usage. b) Both cache instances access the same POJO.someStaticVar and still expect only replicating the staticVar to a specific PojoCache instance, e.g., http one (but not the ejb one). This does not follow the regular Java semantics and IMO, I can't think of a use case for that now. 2. Same clustering groups, e.g., 1 VM has cache1 and cache2 but same jgroups channel. This is happening a lot in testing but is there other real life usage? anonymous wrote : | 2. User needs to be able to control (turn on/off) replication of the static fields. It needs to be off by default. This is because they might want to use this object in a situation where they aren't using JBossCache, e.g. on a simple client without JBoss Cache. | You are asking for fine-grained, runtime control to decide when to replicate and not. But I am thinking more of global wide cache control via POJO field annotation, @Replicatable. That is, if cache is declared properly and POJO is declared as well, then some static field replication will happen. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985196#3985196 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985196

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Test deployment failure due to ZipFile java.lang.InternalErr

by scott.stark＠jboss.org

I'm seeing this failure trying to deploy a test ear: | java.lang.InternalError: jzentry == 0, | jzfile = 147726040, | total = 6, | name = /home/svn/JBossHead/jboss-head/testsuite/output/lib/manifest-web.ear, | i = 4, | message = invalid LOC header (bad signature) | at java.util.zip.ZipFile$3.nextElement(ZipFile.java:429) | at java.util.zip.ZipFile$3.nextElement(ZipFile.java:415) | at java.util.jar.JarFile$1.nextElement(JarFile.java:221) | at java.util.jar.JarFile$1.nextElement(JarFile.java:220) | at org.jboss.virtual.plugins.context.jar.AbstractJarHandler.initJarFile(AbstractJarHandler.java:138) | at org.jboss.virtual.plugins.context.jar.JarHandler.<init>(JarHandler.java:60) | at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:180) | at org.jboss.virtual.plugins.context.file.FileSystemContext.<init>(FileSystemContext.java:150) | at org.jboss.virtual.plugins.context.file.FileSystemContext.<init>(FileSystemContext.java:124) | at org.jboss.virtual.plugins.context.file.FileSystemContext.<init>(FileSystemContext.java:113) | at org.jboss.virtual.plugins.context.file.FileSystemContextFactory.getVFS(FileSystemContextFactory.java:54) | at org.jboss.virtual.VFS.getVFS(VFS.java:106) | at org.jboss.virtual.VFS.getRoot(VFS.java:120) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:791) | at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:570) | 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:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) | 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:668) | at sun.reflect.GeneratedMethodAccessor92.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266) | at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) | at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) | at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) | at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179) | at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) | 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:668) | at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:816) | at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:417) | at sun.reflect.GeneratedMethodAccessor88.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) | at sun.rmi.transport.Transport$1.run(Transport.java:153) | at java.security.AccessController.doPrivileged(Native Method) | at sun.rmi.transport.Transport.serviceCall(Transport.java:149) | at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) | at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) | at java.lang.Thread.run(Thread.java:595) | Other ears are working so I'm not sure what the issue is. Searching for this error indicates its a problem with not closing the jar file. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985178#3985178 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985178

19 years, 5 months

1
0
0 / 0

[Design of JBoss Eclipse IDE (dev)] - Re: bug?! I can't run a webservice client, netbeans works...

by Smilidon

by the way, i use jboss 4.0.4ga, jbossws 1.0.3, jsr 181 server part and a jsr 109 client. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985166#3985166 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985166

19 years, 5 months

1
0
0 / 0

[Design of JBoss Eclipse IDE (dev)] - Re: bug?! I can't run a webservice client, netbeans works...

by Smilidon

First thing is, that i dont understand why i have some jars in the classpath of my client that i dont added to my eclipse project. Second, i changed the order of some jars like jbossall-client, jbossws-client and jboss-xml-binding and now i get this error: | Exception in thread "main" java.lang.NoSuchFieldError: fFeatures | at org.jboss.xb.binding.parser.xni.XniJBossXBParser$ParserConfiguration.configurePipeline(XniJBossXBParser.java:459) | at org.apache.xerces.parsers.DTDConfiguration.reset(Unknown Source) | I found some classes of this xml pharser in jboss-commons.jar of the eclipse plugin and that looks like the problem. i tried to remove that jar, but my client wont start anymore. why? why do i need for runing an application the jboss-common.jar? sorry it looks like that is something wrong there. still confused s. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985165#3985165 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985165

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Another problem with jar urls

by scott.stark＠jboss.org

Another example of why we need to drop jar urls is that one cannot obtain an InputStream from which to copy the jar: | public void testJarURLCopy() | throws Exception | { | FileOutputStream fos = new FileOutputStream("/tmp/x.jar"); | JarOutputStream jos = new JarOutputStream(fos); | JarEntry je = new JarEntry("META-INF/MANIFEST.MF"); | jos.putNextEntry(je); | jos.write("Manifest-Version: 1.0\r\n".getBytes()); | jos.write("\r\n".getBytes()); | jos.close(); | | FileInputStream fis = new FileInputStream("/tmp/x.jar"); | byte[] buffer = new byte[128]; | int read; | int count = 0; | while( (read = fis.read(buffer)) > 0 ) | { | count += read; | } | fis.close(); | System.out.println("Read "+count+" bytes from x.jar"); | | URL jarURL = new URL("jar:file:/tmp/x.jar!/"); | InputStream is = jarURL.openStream(); | int count2 = 0; | while( (read = is.read(buffer)) > 0 ) | { | count2 += read; | } | is.close(); | System.out.println("Read "+count+" bytes from x.jar"); | assert count == count2 : "expected count == count2"; | } | Running this produces: | [starksm@succubus x]$ java tstjar | Read 189 bytes from x.jar | Exception in thread "main" java.io.IOException: no entry name specified | at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:129) | at java.net.URL.openStream(URL.java:1007) | at tstjar.main(tstjar.java:31) | To work around this in the vfs level the openStream implementation of a jar needs to detect if it refers to the jar itself and unwrap the jar url to obtain a usable url connection. We do need to move to custom vfs urls and handlers to have consistent behvior. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985164#3985164 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985164

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: onDemand handling and aspects

by kabir.khan＠jboss.com

As part of http://www.jboss.com/index.html?module=bb&op=viewtopic&t=94575 I extended the AspectBeanMetaDataFactory so that instead of | <bean name="JMXIntroduction" class="org.jboss.aop.microcontainer.beans.IntroductionBinding"> | <property name="classes">@org.jboss.aop.microcontainer.aspects.jmx.JMX</property> | <property name="interfaces"> | <list elementClass="java.lang.String"> | <value>org.jboss.kernel.spi.dependency.KernelControllerContextAware</value> | </list> | </property> | <property name="manager"><inject bean="AspectManager" property="aspectManager"/></property> | </bean> | <beanfactory name="JMXAdvice" class="org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction"> | <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property> | </beanfactory> | | <bean name="JMXAspect" class="org.jboss.aop.microcontainer.beans.Aspect"> | <property name="advice"><inject bean="JMXAdvice"/></property> | <property name="manager"><inject bean="AspectManager" property="aspectManager"/></property> | </bean> | | <bean name="JMXBinding" class="org.jboss.aop.microcontainer.beans.AspectBinding"> | <property name="pointcut">execution(* @org.jboss.aop.microcontainer.aspects.jmx.JMX->$implements{org.jboss.kernel.spi.dependency.KernelControllerContextAware}(..))</property> | <property name="aspect"><inject bean="JMXAspect" property="definition"/></property> | <property name="manager"><inject bean="AspectManager" property="aspectManager"/></property> | </bean> | we can use | <aop:lifecycle xmlns:aop="urn:jboss:aop-beans:1.0" | name="JMXAdvice" | class="org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction" | classes="@org.jboss.aop.microcontainer.aspects.jmx.JMX" | manager-bean="AspectManager" | manager-property="aspectManager" | pointcut="execution(* @org.jboss.aop.microcontainer.aspects.jmx.JMX->$implements{org.jboss.kernel.spi.dependency.KernelControllerContextAware}(..))"> | <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property> | </aop:lifecycle> | It is definitely easier and less verbose, but I did this before I saw Adrian's reply, which I have yet to digest :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985149#3985149 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985149

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - JBAOP-271 Hardcoded aspect manager

by kabir.khan＠jboss.com

For http://jira.jboss.com/jira/browse/JBAOP-271 I have made the AspectBeanMetaDataFactory not instantiate the AspectManager itself yet, but rather rely in it being installed as a bean. By default it will look for a bean called "AspectManager", but this can be overridden, using the manager-bean and manager-property attributes of aop:aspect, e.g: | <aop:aspect xmlns:aop="urn:jboss:aop-beans:1.0" | name="JMXAdvice" | class="org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction" | manager-bean="AspectManager" | manager-property="aspectManager" | pointcut="execution(* @org.jboss.aop.microcontainer.aspects.jmx.JMX->$implements{org.jboss.kernel.spi.dependency.KernelControllerContextAware}(..))"> | <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property> | </aop:aspect> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985148#3985148 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985148

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: @JMX aspect and aop/mc integration

by kabir.khan＠jboss.com

| <beanfactory name="JMXAdvice" class="org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction"> | <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property> | </beanfactory> | | <bean name="JMXAspect" class="org.jboss.aop.microcontainer.beans.Aspect"> | <property name="advice"><inject bean="JMXAdvice"/></property> | <property name="manager"><inject bean="AspectManager" property="aspectManager"/></property> | </bean> | | <bean name="JMXBinding" class="org.jboss.aop.microcontainer.beans.AspectBinding"> | <property name="pointcut">execution(* @org.jboss.aop.microcontainer.aspects.jmx.JMX->$implements{org.jboss.kernel.spi.dependency.KernelControllerContextAware}(..))</property> | <property name="aspect"><inject bean="JMXAspect" property="definition"/></property> | <property name="manager"><inject bean="AspectManager" property="aspectManager"/></property> | </bean> | now becomes | <aop:aspect xmlns:aop="urn:jboss:aop-beans:1.0" | name="JMXAdvice" | class="org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction" | manager-bean="AspectManager" | manager-property="aspectManager" | pointcut="execution(* @org.jboss.aop.microcontainer.aspects.jmx.JMX->$implements{org.jboss.kernel.spi.dependency.KernelControllerContextAware}(..))"> | <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property> | </aop:aspect> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985146#3985146 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985146

19 years, 5 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: JDK1.6 retro compiler

by adrian＠jboss.org

If the actions that JBossRetro performs was made properly configurable (see the todos in the code) rather being hardwired in a few classes this would be a none-issue. e.g. you can imagine being able to add to the transformations on the ant task | <retro ...> | <transformation-classes>...ClassRedirector, JDK16ClassRedirector</> | | | | | with defaults for when this is not specified. | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985145#3985145 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985145

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: onDemand handling and aspects

by adrian＠jboss.org

The issue is more to do with the current KernelAware interface not being rich enough because it only deals with the instance. The callbacks are done on whether the instance (which could implement it via an interceptor) has to be constructed. What we really want is for all controller contexts to be acted upon regardless of whether the real instance exists. Such an api exists, it is the [Instance]ClassAdapter which was originally designed to represent the instance regardless of whether it exists. But the current code does not use the ClassAdapter exclusively so there is no consistency. This was a deliberate decision in the AOP integration to "get something working" without modifying AOP too much. P.S. An alternative approach would be treat the JMX registration as a new deployer that acts after the bean metadata. But this has no integration with the real AOP. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985144#3985144 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985144

19 years, 5 months

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-dev-forums November 2006