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

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

by bela＠jboss.com

Absolutely, +1. This is in line with the rest of our semantics View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985716#3985716 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985716

19 years, 4 months

1
0
0 / 0

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

by ben.wang＠jboss.com

BTW, the corresponding Jira is: [url] http://jira.jboss.com/jira/browse/JBCACHE-726 [/url] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985709#3985709 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985709

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Update on metadata progress

by anil.saldhana＠jboss.com

I will make the changes to the ejb metadata class when I start with the cts tomorrow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985708#3985708 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985708

19 years, 5 months

1
0
0 / 0

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

by ben.wang＠jboss.com

OK, let me try to propose from step 1 again on a newer approach after collecting these feedback. Let's first list the example POJO though: | public class POJO | { | public static int someStaticVar; | | @Transient | private static int anotherStaticVar; | | ... | } | 1. static field replication is on by *default*. If a user wants to turn it off, he can annotate it with @Transient tag as in the above code snippet. 2. There will be no new API introduced. Instead, we will rely on the usual POJO attach/detach to trigger static field replication. E.g., | ... | // First attach will trigger static field replication as well. | cache.attach("id", pojo); | ... | cache.someStaticVar = 20; // This will get replicated. | | // last attach will remove the static field. | cache.detach("id"); | 2a. Again we will store the static variable under a special area, /__JBoss_Static__/. 2b. We will do reference counting to keep track of how many POJO there are associating it (such that we know when to remove the replicated static field). I think this is much cleaner approach. What do you think? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985706#3985706 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985706

19 years, 5 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Version Question

by balellu

Thanks for the update. Unfortunately i cannot upgrade to 1.4.x. This means that i've to find some other tool. Can you suggest any other profiling tool that will help me to create heap dumps and identify the cause behind the OOM that i am facing. Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985701#3985701 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985701

19 years, 5 months

1
0
0 / 0

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

by bstansberry＠jboss.com

Tweaking JMXIntroduction so it just directly registered my beans worked just fine. The problem is there is no way to cleanly express that that's what I want done: 1) JMXIntroduction could just try to register context.getTarget(), catch NotCompliantMBeanException, and then create and register the StandardMBean. Problem is this approach ignores the @JMX.exposedInterface value -- what if the bean is Foo implements FooMBean, Bar, and @JMX.exposedInterface=Bar.class? Kind of an edge case, but not clean. 2) JMXIntroduction could try to register context.getTarget() only if @JMX.exposedInterface=null. This would be a clean solution. Problem is null is not a valid value for an annotation attribute, and the attribute type is Class, so you can't use the "" means null trick. (Hacky idea -- make it "Class exposedInterface() default void.class". The compiler accepts that.) 3) I tried adding another attribute "boolean registerDirectly() default false;" to @JMX. But the deployment of any beans where it didn't specify the attribute failed in SimpleAnnotationValidator, which makes no attempt to read default values. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985698#3985698 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985698

19 years, 5 months

1
0
0 / 0

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

by bstansberry＠jboss.com

I was playing with the StandardMBean thing and rebuilt the aop-mc-int-dep.jar from source. After that the DistributedReplicantManager NPE went away. Is the microcontainer snapshot on repository.jboss.com up to date? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985696#3985696 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985696

19 years, 5 months

1
0
0 / 0

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

by scott.stark＠jboss.org

That is correct. We really should validate whether the target already implements a particular jmx interface, or just add an attribute to the annotation to indicate if the target should not be wrapped before registration. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985692#3985692 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985692

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ExpiryDestination support

by scott.stark＠jboss.org

I added dummy noop implementations of this attribute in the current messaging module implementation to allow such legacy mbeans to deploy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985691#3985691 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985691

19 years, 5 months

1
0
0 / 0

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

by bstansberry＠jboss.com

Another problem I'm seeing is that many beans implement MBeanRegistration, but those callbacks aren't getting invoked. I think this is because the object registered with the MBeanServer is not the bean itself but rather a StandardMBean created in JMXIntroduction. That object doesn't implement MBeanRegistration. With the beans I'm working with, it's actually not necessary to wrap them in a StandardMBean object before registering them. They are all already compliant standard mbeans of the X implements XMBean variety. I'm going to play a bit and see if there's any issue with registering the beans directly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985690#3985690 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985690

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