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

[Design of JBossCache] - Re: Injection of MBeanServer

by kabir.khan＠jboss.com

I'm moving the discussion of the integration here: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983882#3983882 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983887#3983887 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983887

19 years, 5 months

1
0
0 / 0

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

by kabir.khan＠jboss.com

In response to http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983302#3983302, I am looking at integrating the aop-mc integration code with JBoss 5. I have more or less got this working on my machine. A few things: 1) In order for the AOPConstructorJoinpointFactory to be used, I have had to add jboss-aop-mc-int.jar to the root jboss/lib directory since the check done by the PropertyConfiguration is done when first started. Unless I move server/xxx/lib/javassist.jar server/xxx/deployers/jboss-aop-jboss5.deployer/jboss-aop-jdk50.jar server/xxx/deployers/jboss-aop-jboss5.deployer/trove.jar into jboss/lib as well I get NoClassDefFoundErrors when accessing the jboss-aop-mc-int.jar classes - probably because the classloader used for loading up the jboss/lib classes cannot see the classes loaded up from the server/xxx/lib and server/xxx/deployers directory. 2) It slows the startup time of the default configuration from about 37s to 45s on my machine. The AspectManagerService currently has an "exclude" property to set all classes starting with "org.jboss." to not be transformed/inspected, which works on the underlying AspectManager singleton. However the AspectManagerService is installed as part of the AspectDeployer, which is one of the last deployers to be deployed, meaning that inspection is done of all beans before it has been installed since the AspectManagerService has not yet been installed. This is also controllable via system properties, so the run.sh/.bat files could be modified to use that, so that this is picked up before the AspectManagerService has been installed. I think I would prefer some way for inspection of classes to be "turned off", until the AspectManagerService has been installed. Is there a way to swap out the ConstructorJoinPointFactory returned by the AOPJoinpointFactoryBuilder at runtime, so that it returns the BasicJoinpointFactory until the AspectManagerService is installed, and the AOPJoinpointFactory after the AspectManagerService has been installed? I can think of at least one hacky way to do this :-) I guess the question is, do we want the mc, and deployers installed before the AspectDeployer, to have this integration with the aspect layer or not? Do we care about the performance at this stage? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983882#3983882 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983882

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Possible optimization of CachedSetImpl

by genman

1. I actually don't know the difference ... I may have copied that from the original implementation. The tests seemed to pass. What's the sematic difference? 2. I'm not sure how this would work better? The need for offsetting the hash code is to deal with a typically rare edge condition. If the hash function is reasonably distributed, then the chances of hash code collision (and therefore the need to do the hash code+1 trick) would be at best 1 in 2^32 and likely only a few orders of magnitude worse otherwise. I think people expect hash collisions would happen more often, but that's because in ordinary hash tables, collisions happen from evaluating (hash code % some small number). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983871#3983871 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983871

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: VirtualFile metadata

by bill.burke＠jboss.com

If you want to switch to "vfsfile:" based URLs you're gonna have to cache anyways. Otherwise, performance is horrible, at least with the current implementation. Its just a thought. Maybe it doesn't matter overall. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983866#3983866 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983866

19 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Integration with different JBoss Cache releases

by bstansberry＠jboss.com

"wolfc" wrote : We need the 1.4 stuff in branch 4.2 for as long as that hasn't switched. I won't do anything on Branch_4_2 until the decision to switch is made. anonymous wrote : | For SFSB I got the pieces of the puzzle here: | http://wiki.jboss.org/wiki/attach?page=WolfC%2FEJB3Cache.png | | I think we should get a basic idea of where we're heading, so we don't run ourselves into the ground. We need different artifacts each with it's own dependencies which must never be circular. Sure. I don't think this will be a problem; it's a pretty straightforward abstraction. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983863#3983863 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983863

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Testing with FLUSH

by vblagojevic＠jboss.com

Hey guys, I running tests in o.j.c.statetransfer with FLUSH by introducing FLUSH protocol in replSync-service.xml and replAsync-service.xml but that does not give me any indication if having FLUSH in jgroups stack will work with other tests. Many other tests are using programmaticaly hand coded stack and I think that we should make an effort to have an ability to run any test with any jgroups stack if that stack is valid for a particular test. In fact I believe that moving from programmatic stack to parametrized stack is crucial because we can then ship JBC and have a hard guarantee that certain jgroups stack passes almost 2000 JBC unit tests. What a piece of mind that would be. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983862#3983862 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983862

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Partial state transfer -when target root integration is

by vblagojevic＠jboss.com

That is a good point. I think although we have designed FQN class to allow non string fqns so much JBC code relies on the fact that fqns are strings. We should be clear about the fact that only string fqns are acceptable. Manik? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983856#3983856 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983856

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Task Forms

by tom.baeyens＠jboss.com

i like the <tf:formline/>. this makes the location of the form line image configurable in one spot in the web application. but i'm not sure if the other proposals are appropriate. making the forms more loosely coupled to their runtime environment is indeed a plus. i see some potential downsides... Using EL to access variables is a good thing (maybe they already are included in the lookup). But you should take into account that users can define variable names with spaces. In that case we need another lookup mechanism. Also I not so sure if a dependency on the runtime environment is a problem if that environment is properly documented and makes use of known technologies. We should avoid that people have to learn the jBPM Form Layer apart from JSF and Facelets. At least, this was the idea when designing the forms solution. Also with the buttons, the idea was that the graphical designer will generate those. After initial generation of the form by the gpd, the users now are able to customize the boring form layout to their own wishes. By just using plain JSF/Facelets constructs, it seems much more flexible for users to start tweaking the graphical form. On the other hand, if users don't customize the forms, they can always re-generate after they made some updates that have an impact on the form. So this explains why I was not too concerned with usability of the form constructs. My main concern was lowering the learning curve. The other important thought is that mostly, users will generate the forms and will not be looking at the form code. In my current design, they only have a problem of loosing synchronization if they start customizing the form and then adding transitions, variables or other changes that have an impact on the form. Then the user is placed for the dillemma of regenerating and loosing updates or maintaining his changes manually in the form. I mainly wanted to give you the background of why i designed it this way. In summary, my advice would be to only go for the formline change. But of course, you are free to override my opinion or try to change it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983835#3983835 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983835

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: libraries in an .ear file

by andyredhead

or jee5 even! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983802#3983802 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983802

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: libraries in an .ear file

by andyredhead

I'm all in favour of small steps towards jee4 ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983798#3983798 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983798

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