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

[Design of POJO Server] - Re: Deploying ValidatorFactory

by pete.muir＠jboss.org

This is how we bind the BeanManager in WB http://anonsvn.jboss.org/repos/jbossas/projects/webbeans-ri-int/trunk/dep... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249053#4249053 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249053

16 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Please don't touch hudson for a while

by clebert.suconic＠jboss.com

What I usually do is to wget the raw console: you go to Hudson, right after the log you will see the raw link, then you can do: wget http://OUR-INTERNAL-IP/hudson/view/JBM%202/job/JBM2-tests-clone/14/consol... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249047#4249047 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249047

16 years, 5 months

1
0
0 / 0

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

by adrian＠jboss.org

By the way, ScopeKey is Serializable so don't break the serialized form if you change the internal state. Although the only place I can think of where this could "leak" onto a different machine is via the Deployment jmx management see org.jboss.deployers.structure.spi.DeploymentBean View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249035#4249035 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249035

16 years, 5 months

1
0
0 / 0

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

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | You do need something like the ScopeKey being mutable until the last minute | because things like the CLASS scope may not be known until the bean instance | is constructed from a factory. Only then do you know the class. | By the way, that's another HACK (and marked as such in the code) see KernelScopeInfo and InstantiateAction. If you can think of a better way to do it then feel free to fix it. ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249034#4249034 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249034

16 years, 5 months

1
0
0 / 0

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

by clebert.suconic＠jboss.com

Yeah.. ok... I was wondering if those were because of changes you had at your workspace. I couldn't replicate that. it's not important... It's fixed anyway now :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249030#4249030 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249030

16 years, 5 months

1
0
0 / 0

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

by timfox

Well I saw a lot of queue instances which were not GC'd when I run System.gc() and Runtime.runFinalizers() several times. Those instances didn't occur after my fixes. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249026#4249026 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249026

16 years, 5 months

1
0
0 / 0

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

by adrian＠jboss.org

"smarlow(a)redhat.com" wrote : "adrian(a)jboss.org" wrote : | | The brain dead part is that it gets used at runtime in the BasicMetaDataRepository | | as the key to a map which it then freezes to avoid mutablity. | | The issue being that you still could incur contention because | | of the synchronization on the scopes within the ScopeKey traversed in equals()/hashCode(). | | | | I assume you mean in the current implementation (even with freeze, synchronization is needed). With the proposed changes, we don't need the synchronization on the scopes within the (immutable) ScopeKey. | BACKWARDS COMPATIBILITY I'm saying immutability breaks backwards compatibility (in our code and in other code which might not even have been written yet but could get written against the existing api in the released jboss5/mc binaries). That's because the ScopeKey is used as a builder. Our main use case is just to build a APPLICATION/DEPLOYMENT scope from the "Default Scope" and an INSTANCE/CLASS scope on top a DEPLOYMENT. This is done with a clone() and addScope(). So if you clone it or use some more optimized object in the MDR itself then this synchronization is not required. REASON FOR SCOPEKEY BEING MUTABLE You do need something like the ScopeKey being mutable until the last minute because things like the CLASS scope may not be known until the bean instance is constructed from a factory. Only then do you know the class. There was also an additional (unimplemented or at least unused) requirement to allow services to add extra scopes. e.g. an EJB could add a CLUSTER scope to get shared clustered metadata. Or similarly allowing a SUBSYSTEM scope for shared defaults, e.g. SUBSYSTEM=EJB So each stage of the deployment can modify the full MDR scope until it gets registered. YOUR SOLUTION VS MY SOLUTION Changing all the other api, e.g. DeploymentUnit, KernelScopeInfo, etc. to make this "mutable scope holder" some other class would be a lot more effort (besides breaking existing - or even still to be written - use cases). It would be better to just the leave the ScopeKey as the builder and optimize the runtime in one of the ways I suggested (or maybe some other way you can think of?). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249025#4249025 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249025

16 years, 5 months

1
0
0 / 0

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

by jesper.pedersen

1) Yes 2) Yes, but define a type for the override-element such that it only can have our defined values (xsd:restriction on xsd:token) We can change the XSD until we release the first version, so we'll work through the use-cases over time. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249024#4249024 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249024

16 years, 5 months

1
0
0 / 0

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

by clebert.suconic＠jboss.com

"timfox" wrote : "clebert.suconic(a)jboss.com" wrote : | | I also run without the changes, and the only leak I found was the Pinger. (which is fixed now) | | I don't think QueueImpl was leaking (as I tested it without the fixes). | | | | | | You couldn't find the leaks because I fixed them (as discussed on IRC) in revision 7704 last night ;) | I ran the profiler without your changes, and I couldn't see QueueImpl leaking. I can confirm that Pinger was leaking. And indeed I couldn't find any leaks after your changes. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249021#4249021 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249021

16 years, 5 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 : | The brain dead part is that it gets used at runtime in the BasicMetaDataRepository | as the key to a map which it then freezes to avoid mutablity. | The issue being that you still could incur contention because | of the synchronization on the scopes within the ScopeKey traversed in equals()/hashCode(). | I assume you mean in the current implementation (even with freeze, synchronization is needed). With the proposed changes, we don't need the synchronization on the scopes within the (immutable) ScopeKey. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249020#4249020 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249020

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