January 2008 - jboss-dev-forums - Jboss List Archives

[Design of EJB 3.0] - Re: EJB3 Mavenization / Build System Cleanup

by ALRubinger

"wolfc" wrote : I'm thinking of changing the svn directory structure from trunk/... to .../trunk. So we can have independent release cycles for each component. The only con I see is that we don't have the facility in Jira for version per component. We could still have independent release cycles, but the component releases would be aside one another in branches/.. and tags/.. We *could* configure JIRA to view each "component" (project in SVN) as its own JIRA Project; though that could be overkill and administrative nightmare (instead of EJB3 Project with X Components, we'd have X Projects to watch over). "wolfc" wrote : The versions of components we depend upon are dictated by the AS component matrix. We can't deviate from that, but we can put a wrapper component in between. Link to the AS Component Matrix? Or is this simply represented by the componentrefs in build-thirdparty? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116588#4116588 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116588

18 years

1
0
0 / 0

[Design of JBossCache] - Problem with after loading Huge data

by sanatmastan

Hi, I am new to Jboss cache, so i gone through some examples and try to use them to my requirements. here is my requirement. my aim is to store and retrieve frequency of a particular key (String), so i have written a wrapper methods to add, remove, and get frequency for a key. the tricky part here is to take the advantage of tree structure of Jboss cache to implement TRIES data structure, which means the input key will be splitted into chars and inserted in the tree as nodes and the leaf node contains the frequency. If the same key is inserted twice the frequency at the leaf will increase to 2 and so on. This structure helps me to save some space by sharing some of the roots nodes for the different leaf nodes. I didnt implement any replication or persistence mechanism. The problem here is when i insert 3mil (50mb) entries i am able to get the frequency in the way i am expected and if i try to insert 10mil entries (of size 105mb) all are getting inserted (ofcouse by increasing vm heap size) with out any error, but if i try to verify the existence of a key, i am getting not exist, can anyone comment on this behaviour? I have few questions. 1) I would like to know whether Jboss cache framework will suite to my requirement where it contain less depth (20 to 30 levels) and huge breath size (in thousands)? 2) Is there any limitations on Jboss cache memory size? Please clarify... Thanks in advance Sanat. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116585#4116585 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116585

18 years

1
0
0 / 0

[Design of EJB 3.0] - Re: New Project to Validate External API

by ALRubinger

That'd be simpler, wouldn't it. http://jira.jboss.com/jira/browse/EJBTHREE-1170 S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116584#4116584 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116584

18 years

1
0
0 / 0

[Design of POJO Server] - Release Embedded JBoss Beta3

by pete.muir＠jboss.org

I've got Embeddded JBoss from the JBoss_5_0_0_Beta3 tag correctly running the Seam testsuite. The only known problem is with JMS: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=125194 but no one from messaging has been able to help. The branch is here https://svn.jboss.org/repos/jbossas/branches/EMBEDDED_JBOSS_BETA3/ I would therefore like to do a beta3 release of Embedded JBoss in a couple of days. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116557#4116557 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116557

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by manik.surtani＠jboss.com

"jason.greene(a)jboss.com" wrote : "bstansberry(a)jboss.com" wrote : Twist on this I just remembered. With entity caching, user types can be part of the FQN as well. Primary key of the entity is the last element of the FQN. A user type in an FQN is of course generally possible; entity caching is just a particular example where I've had to handle it with region-based marshalling. (The region portion of the FQN is only strings). | | IMO we should start requiring that FQNs are only composed of serializable types that are on the cache classpath. POJO Cache does a very similar thing to entity caching, and it should also be changed not to do this. We should instead compute a value based off of the hash code. In my case, which should be possible with an entity cache, I can actually allow collisions, by simply using the key object as an attribute (key) on the node, instead of the last element of an fqn. The value of the key would point to an internal fqn, containing the data of the object. Alternatively, a sub fqn structure could be created using a unique value. In this alternative case, you would have to iterate all children, performing a comparison. | | -Jason | | +100. Hugely limiting in the way we have to support custom objects in Fqns right now. I understand why people don't want just Strings as Fqn elements, but we should restrict this to Strings + boxed primitives or something like that. Again, though, not something we can do now (2.1.0). Perhaps 3.0.0? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116529#4116529 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116529

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by jason.greene＠jboss.com

"jason.greene(a)jboss.com" wrote : "bstansberry(a)jboss.com" wrote : Twist n this alternative case, you would have to iterate all children, performing a comparison. | | | | By iterating all children, I mean all children of the same hash code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116522#4116522 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116522

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by jason.greene＠jboss.com

"bstansberry(a)jboss.com" wrote : Twist on this I just remembered. With entity caching, user types can be part of the FQN as well. Primary key of the entity is the last element of the FQN. A user type in an FQN is of course generally possible; entity caching is just a particular example where I've had to handle it with region-based marshalling. (The region portion of the FQN is only strings). IMO we should start requiring that FQNs are only composed of serializable types that are on the cache classpath. POJO Cache does a very similar thing to entity caching, and it should also be changed not to do this. We should instead compute a value based off of the hash code. In my case, which should be possible with an entity cache, I can actually allow collisions, by simply using the key object as an attribute (key) on the node, instead of the last element of an fqn. The value of the key would point to an internal fqn, containing the data of the object. Alternatively, a sub fqn structure could be created using a unique value. In this alternative case, you would have to iterate all children, performing a comparison. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116521#4116521 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116521

18 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Deadlock scenarios

by flavia.rainone＠jboss.com

In the given example, deciding that interceptors shouldn't be instrumented would be the same as creating a new restriction. However, how many people intercepts an interceptor? Probably not a very common use case, nor a good practice to be followed, IMHO. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116506#4116506 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116506

18 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Deadlock scenarios

by flavia.rainone＠jboss.com

During rebuildingchain test execution, we are seeing a couple of deadlock scenarios... those are related to classload time weaving and dynamic AOP operations. I have created a bug issue: http://jira.jboss.com/jira/browse/JBAOP-499 With two subtasks: http://jira.jboss.com/jira/browse/JBAOP-500 http://jira.jboss.com/jira/browse/JBAOP-501 The first scenario (JBAOP-500) started happening after bug fix JBAOP-480. It can be stopped if JBoss AOP starts avoiding to transform the generated joinpoint classes (on class AOPTransformer). For that, simply adding an aop suffix to the generated class name would work. However, in the second scenario, JBAOP-501, the deadlock can happen when one of the threads executes an AspectManager synchronized operation that needs to load an advisable class, while the other thread starts loading an advisable class. So, the first thread has AspectManager lock but needs the class loader lock, while the second thread has the class loader lock but needs the AspectManager one to try to transform the advisable class. I have a suggestion to fix this, but I'm not sure it can be applied on the possible scenarios (this info is something we would need to gather). My idea will work only if we can state that all the advisable instances that JBoss AOP creates during AspectManager synchronized method executions won't be instrumented. If this is true, we can start considering those instances as non-advisable instead of advisable. In this case, we would need to check if the class is advisable at method AspectManager.transform (which is non-synchronized), before calling translate (which is synchronized). This would halt the transformation process on the given deadlock scenarios before acquiring AspectManager lock, avoiding the deadlock. Using the thread dump scenario provided by Stale as an example (described on task JBAOP-501), the deadlock happens when JBoss AOP loads an Interceptor class to create. In this case can we say that Interceptors shouldn't be instrumented? If we can, we can go for the approach above for this scenario. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116505#4116505 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116505

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: When will W3CEndpointReference instance construction be

by jhalliday

Thomas I was under the impression this was scheduled for the Jan 1st release, but it's still unassigned in JIRA. WTF? Thanks Jonathan. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116485#4116485 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116485

18 years

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 January 2008