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

[Design of JBossCache] - Re: JBCACHE-890 - idea for consolidating meta-data on a node

by bstansberry＠jboss.com

Somewhat off-topic, but I think we should think about a similar implementation approach for Option. I think we're going to start replicating those some day, and we're also likely to add new flags over time. If I'm thinking correctly, use of an EnumSet *may* help maintain serialization-compatibility between releases as long as we: 1) Don't remove enum constants from the enum we use for the flags. 2) Only add new enum constants at the end of the list; i.e. don't change order. 3) Don't replicate a new constant if we're interoperating with a previous release that doesn't understand it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995443#3995443 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995443

19 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: JTA integration

by tom.baeyens＠jboss.com

if you want to use 1 session, you can inject it into the jbpmContext with the setSession(Session) method at the jbpmContext.close, the session is not going to be flushed or closed by jbpm. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995433#3995433 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995433

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: java:comp.ejb3 versus java:comp

by scott.stark＠jboss.org

All the containers already have context maps that could be leveraged to pickup an enc key from. I just don't want to force an implementation detail like a thread local accessor onto all enc users. The main enc tests are the org.jboss.test.naming.test.ENCUnitTestCase and in the web tier, org.jboss.test.web.test.EncAnnotationsUnitTestCase,EncXmlUnitTestCase,WebIntegrationUnitTestCase. The WebIntegrationUnitTestCase is too bloated with other tests and the testENCServlet, testENCServletViaInvoker tests should just be integrated into the other tests. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995431#3995431 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995431

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: java:comp.ejb3 versus java:comp

by bill.burke＠jboss.com

Do you know of a basic subset of unit tests I can run to test ENC changes for EJB2 and WAR? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995422#3995422 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995422

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: java:comp.ejb3 versus java:comp

by bill.burke＠jboss.com

anonymous wrote : This assumes that every callback path has an interceptor model that allows this. Its not true for either the ejb2 or web containers. Callbacks like ejb timers, activation callbacks, session events, don't have the same invocation model as requests. Well, the key has to be set someplace and somewhere if your'e not using the ClassLoader as the key. EJB3 has no problem pushing/popping the ENC for EJB callbacks. Not sure why EJB2 or JBossWeb would have any problem as well. anonymous wrote : There is also the issue of being able to view encs for debugging. Having a bunch of isolated encs buried in various containers vs having a map keyed by component id just seems cleaner. Ok...so can we get implementing this? There should be no reason why we need to overengineer this and can have a simple static variable ConncurrentHashMap implementation for the id->ENC mapping. I can probably figure out all the places to add the hooks in for EJB3/EJB2. For JBossWeb I made need a hint. Bill View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995421#3995421 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995421

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: java:comp.ejb3 versus java:comp

by scott.stark＠jboss.org

This assumes that every callback path has an interceptor model that allows this. Its not true for either the ejb2 or web containers. Callbacks like ejb timers, activation callbacks, session events, don't have the same invocation model as requests. There is also the issue of being able to view encs for debugging. Having a bunch of isolated encs buried in various containers vs having a map keyed by component id just seems cleaner. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995415#3995415 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995415

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: java:comp.ejb3 versus java:comp

by bill.burke＠jboss.com

org.jboss.ejb3.ThreadLocalENCFactory org.jboss.ejb3.ThreadLocalStack (ThreadLocalStack is in ejb3 module rather than common because I did not want to have to patch common.jar in older JBoss 4.x versions) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995412#3995412 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995412

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: java:comp.ejb3 versus java:comp

by bill.burke＠jboss.com

Why do you even need to have an ID or an interceptor or even an invocation context? Just let the freakin container push/pop an instance of the ENC onto the ThreadLocal that the java:comp ObjectFactory uses. The current EJB3 ObjectFactory implementation knows nothing about AOP, just the ThreadLocal it uses to obtain the ENC. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995411#3995411 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995411

19 years, 3 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: Code Coverage in JBoss AS Test Suite

by smcgowan＠redhat.com

The lastest version of EMMA - 2.1.5320 - introduces a new command line tool called ctl which allows coverage data to be captured remotely and prior to JVM exit. This works well in J2EE environments and is intended for such. Instrumentation still needs to be done prior to running tests (referred to as off-line mode) using EMMAs tool - instr. See: http://emma.sourceforge.net/faq.html#q.runtime.appservers which documents the few easy steps. I recently used EMMA to capture coverage data in J2EE environment but found it to be more useful when obtaining coverage metrics against a standalone component (.jar) to enhance the coverage as I developed tests. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995410#3995410 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995410

19 years, 3 months

1
0
0 / 0

[Design of JBoss Build System] - Apache Ant 1.7.0 is out

by scott.stark＠jboss.org

anonymous wrote : | Hi, | | We have the pleasure to announce the release of Apache Ant 1.7.0. | | Ant 1.7 introduces a resource framework. Some of the core ant tasks such as are now able to process not only file system resources but also zip entries, tar entries, paths, ... Resource collections group resources, and can be further combined with operators such as union and intersection. This can be extended by custom resources and custom tasks using resources. | | Ant 1.7 starts outsourcing of optional tasks to Antlibs. The .NET antlib replaces the .NET optional tasks which ship in Ant. Support for the version control system Subversion is also provided as an antlib. | | Ant 1.7 fixes also a large number of bugs. | | Ant 1.7 has some initial support for Java6 features. | | The Apache Ant Team | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995409#3995409 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995409

19 years, 3 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 December 2006