August 2009 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Seam deployments and hot deployments in AS 5.1.0

by clerum

Ales, Any update on replacement jars so that we can get Seam working with 5.1? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249297#4249297 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249297

16 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Reaper Thread Leaking...

by clebert.suconic＠jboss.com

I am now running NettyFileStorageSymmetricClusterWithBackupTest, and it seems that the ReaperThread is leaking. I am investigating it. I made this post just as a FYI, as this may be related to other failures on the testsuite. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249293#4249293 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249293

16 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: BeanAnnotationAdapter/AnnotationPlugin

by jaikiran

Similar discussion here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=153499. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249288#4249288 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249288

16 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - BeanAnnotationAdapter/AnnotationPlugin

by kabir.khan＠jboss.com

1) The BeanAnnotationAdapter currently does this for each bean class/constructor/property/parameter: | AnnotatedInfo info = class/constructor/property | MetaDataRetrieval retrieval = //MDR for class/constructor/property/parameter | List<BeanAnnotationPlugin> list = //get plugins for class/constructor/property/parameter | for (AnnotationPlugin plugin : list) | plugin.applyAnnotations(info, retrieval) | Then the plugin does the following: | public abstract class AbstractAnnotationPlugin<T extends AnnotatedInfo, C extends Annotation> extends BaseMetaDataAnnotationPlugin<T, C> implements AnnotationPlugin<T, C> | { | public final void applyAnnotation(T info, MetaData retrieval, MetaDataVisitor visitor) throws Throwable | { | Class<C> annotationClass = getAnnotation(); | C annotation = retrieval.getAnnotation(annotationClass); | if (annotation == null) | { | return; | } | //create metadata from annotation | } | } | So every class/constructor/property results in a call to MDR.getAnnotation() for each plugin regardless of if annotations exist or not. Would it not make more sense to do something like this instead, which would only hit the MDR.getAnnotation() when there actually are any annotations? | AnnotatedInfo info = class/constructor/property | MetaDataRetrieval retrieval = //MDR for class/constructor/property | Map<Annotation, AnnotationPlugin> map = //get plugins for class/constructor/property | for (Annotation annotation : info.getAnnotations()){ | AnnotationPlugin plugin = map.get(annotation); | if (plugin != null) | plugin.applyAnnotations(info, retrieval); | } | 2) For the web beans work the annotation types of the binding types are not known in advance, and so the plugins can not easily be plugged in to the framework. I would like to extend it to accommodate this better as I am currently checking the annotations myself in a custom DescribeAction. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249282#4249282 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249282

16 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Lots of largemessages

by clebert.suconic＠jboss.com

anonymous wrote : Not sure if that was the point you were trying to make. | | But if so, then yes we need to set objects to null in teardown. I didn't check / know about the order on Constructors... but yes.. the point I was trying to make is JUnit will hold one instance of the class per test method. So we must make sure we set fields to null on the test. We could maybe make some simple and generic code on UnitTestCase::tearDown, using reflection. But we would need to make sure we all called super.tearDown at the end of our tearDown methods. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249239#4249239 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249239

16 years, 7 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: JVMTI committed on Branch_2_0

by jesper.pedersen

anonymous wrote : | I will fix the dependency later tonight... | Thanks, anonymous wrote : | Regarding the style... | Yes, I know that the style is different from other JBoss projects, but that was the style of the original code submission. Checkstyle will though force it to be the same all-over. If you want the task of doing a code reformat I have settings for a JBoss code style - but I think we should the little time we have on other things. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249238#4249238 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249238

16 years, 7 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: JVMTI committed on Branch_2_0

by clebert.suconic＠jboss.com

I will fix the dependency later tonight... Regarding the style... all the other projects at JBoss use next line on brackets. I know I have used next line on 1.0, but I think we should do the same as other projects. I committed a style settings on eclipse. If you use eclipse (which I believe you do), it would format the same for everybody. We should agree on a format and change that settings, then the format fix is automatic. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249236#4249236 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249236

16 years, 7 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: proposal for JBossRA 2.0 metadata

by jesper.pedersen

anonymous wrote : | We also need an attribute to figure out which bean we use bean validation group against, like : | The groups should be used for the entire RAR archive IMHO - e.g. if people wants more advanced features they'll use the BV API. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249232#4249232 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249232

16 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Does ScopeKey need to maintain a sorted (in ScopeLevel.l

by smarlow＠redhat.com

"adrian(a)jboss.org" wrote : | 2) The other is as I mention above. Use the ScopeKey as the builder class | and retrieve a more optimizated key for internal use within the MDR. | | e.g. something like: | | | public class ScopeKey | | { | | ... | | | | Object getOptimzedKey() {} // Key for use at runtime | | } | | | | In fact (1) and (2) are just variations on the same theme, with (2) potentially | being more optimal. | I'm trying to do (2) as follows. | public class ScopeKey | { | ... | | /** | * The returned ScopeKey is immutable and optimized for use at runtime. | * @return Optimized immutable ScopeKey | */ | public ScopeKey getOptimizedKey() | { | return new UnmodifiableScopeKey(this); | } | | } | Where UnmodifiableScopeKey is similar to the code that I previously posted. There is a dependency between UnmodifiableScopeKey + ScopeKey that needs to be manually maintained but maybe I could test for that in a UnmodifiableScopeKey unit test. UnmodifiableScopeKey extends ScopeKey and overides all of the public ScopeKey methods. The (work in progress) UnmodifiableScopeKey source is here http://pastebin.com/m5d484e25 Does UnmodifiableScopeKey work for everyone? I assume this will work as the optimizedKey. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249231#4249231 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249231

16 years, 7 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: proposal for JBossRA 2.0 metadata

by jeff.zhang

for 2) yeah. I have add the restriction. please see https://jira.jboss.org/jira/browse/JBMETA-219 1) We also need an attribute to figure out which bean we use bean validation group against, like : | <bean-validation-groups bean-id="org.jboss.jca.test.deployers.spec.rars.ra16standard303jbossra.TestResourceAdapter"> | <bean-validation-group>com.mycompany.myproject.bv.Group1</bean-validation-group> | <bean-validation-group>com.mycompany.myproject.bv.Group2</bean-validation-group> | </bean-validation-groups> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249228#4249228 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249228

16 years, 7 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 August 2009