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

[Design of POJO Server] - Re: Web: ENC References

by anil.saldhana＠jboss.com

We previously had it part of AbstractWebDeployer such that the ENC binding happened generically to all web containers integrated. Can we not retain the same pattern in AbstractWebDeployment lest we expect all integrated web deployments to remember to do this ENC binding? Or you thinking the subclass web deployments make the decision to process the ENC references? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983556#3983556 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983556

19 years, 5 months

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: Unable to passivate due to ctx lock IS GONE

by alex.loubyansky＠jboss.com

See JBAS-979 for the info. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983551#3983551 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983551

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Web: ENC References

by scott.stark＠jboss.org

It should be called by the subclass deployment, like from within TomcatDeployment.performDeployInternal. I'll look into it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983550#3983550 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983550

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Web: ENC References

by anil.saldhana＠jboss.com

I am testing the addition of the following line at the end of the deploy method of AbstractWarDeployer | //Process the ENC references | deployment.processEnc(unit.getClassLoader(), metaData); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983538#3983538 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983538

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - War deployments: establishing

by anil.saldhana＠jboss.com

In trunk, for Web deployments, have we taken care of establishing the ENC references? | From previous | AbstractWebDeployer->processEncReferences | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983527#3983527 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983527

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Are you considering an OSGi based micro kernel ?

by alesj

Sascha, we can discuss this at the JBW. I'm already planning to do http://jira.jboss.com/jira/browse/JBMICROCONT-26, so we can probably fit this in as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983522#3983522 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983522

19 years, 5 months

1
0
0 / 0

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

by scott.stark＠jboss.org

"bstansberry(a)jboss.com" wrote : | Biggest hassle to all this is the compile-time incompatibility between JBC releases. So, if we have different JBC adapters in the code base, the EJB3 build is going to need to be segmented to build each one separately. No surprise there. Also, in IDEs it will be a pain to have different sets of adapters on the build path -- would need to do something like have a separate Eclipse project per adapter. This has to be done anyway as there need to be separate artifacts for each cache spi implementation. Its not practical to have this segemented based on java packages alone in a monolithic project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983519#3983519 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983519

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Should acquired locks be released in the order they were

by bdueck

Folks; This is a bit of a stale thread, but I do now have some data that confirms the change I proposed to TransactionEntry does indeed have a positive effect on scalability. My tests show it improves overall scalability by up to 6%. Some tests show no improvement, but none show degredation. Can everyone please re-review the proposal below as well as the earlier posts in this thread? If there are no objections, I'll make the change this week. anonymous wrote : | org.jboss.cache.TransactionEntry | - changed TransactionEntry.locks from List based implementation to | ConcurrentReaderHashMap. This avoids expensive linear scannng calls | to locks.contains() in addLock() and also improves concurrency by | avoiding blocking synchroized() calls where most of the access to | locks is read-only. I'm using ConcurrentReaderHashMap here more as | a Set than a Map since there is no value to store. We're really just | interested in efficient searches in locks and highly concurrent reads. | | - I'm not sure of the impact of this change on | org.jboss.cache.interceptors.OptimisticLockingInterceptor and | org.jboss.cache.interceptors.PessimisticLockInterceptor | which might be relying on some implementation specifics of the order of | insertion of entries into what getLocks() returns. Seems to me though | that if they do have some sort of dependency on ordering that there | should be a better way to deal with this... | | - this change impacts one public method - getLocks() which previously | returned a java.util.List and now returns a java.util.Set. Only one test | is affected by this (org.jboss.cache.cache.optimistic.OpLockingInterceptorTest) | which depends on List.get(int) method that isn't available in Set. | Thanks, Brian. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983518#3983518 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983518

19 years, 5 months

1
0
0 / 0

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

by scott.stark＠jboss.org

I believe we have to focus on getting jboss5 to the api levels we need, and then worry about introducing abstractions to allow dependencies to be decoupled for reuse in legacy profiles. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983517#3983517 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983517

19 years, 5 months

1
0
0 / 0

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

by bstansberry＠jboss.com

My next question is where/how to do this work. I'm my workspace copy of trunk, I've got JBC 2.0 compatible stuff written in the existing org.jboss.ebj3.cache.tree and org.jboss.ejb3.entity packages. I'm going to need to get that checked in at some point this week or early next week. But once I do that, the old 1.4.x compatible stuff is gone until we get the EJB3 project set up for different adapters. Is there a problem with converting EJB3 trunk to 2.0 compatibility, and then adding the 1.4.x adapters later? Or do you guys need 1.4 compatibility in trunk for some other purpose? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983510#3983510 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983510

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