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

[Design of POJO Server] - Re: Looking at deployment structure - JBAS-5823

by alesj

"alesj" wrote : | 2) deployment needs to go over DeploymentManager, which copies whole deployment, not what we've done before -> deployed directly from testsuite/output/lib | This way we cannot handle unpacked deployments, e.g. unpacked-ear1.ear in PartUnpackedEARDeploymentUnitTestCase. URL is pointing to a directory, and using its InputStream to copy contents doesn't do anything, or at least its not copying contents (which is probably expected for directory). | [StreamingDeploymentTarget] URL connection: sun.net.www.protocol.file.FileURLConnection:file:/C:/projects/jboss5/trunk/testsuite/output/lib/unpacked-ear1.ear/ | [StreamingDeploymentTarget] InputStream: java.io.ByteArrayInputStream@e99681 The javadocs for sun.net.www.protocol.file.FileURLConnection are useless. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170569#4170569 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170569

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MDR doesn't work on annotated privates

by wolfc

The trouble starts in: AbstractMutableComponentMetaDataLoader.addAnnotation(Member member, T annotation) The sub component signature becomes MethodSignature instead of DeclaredMethodSignature. For the moment I'll try to work around this with addAnnotation(Signature signature, T annotation). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170563#4170563 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170563

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: @JMX on a bootstrap service

by adrian＠jboss.org

I've fixed this and also removed the potential memory leak by adding a CachingAnnotationMetaData interface. It's not as optimal as I would like because of the property annotations. In that case the annotation gets added to both the getter and setter, so when we remove the annoation for the getter we loose track of the annotation when we want to remove the setter, so we have to reconstruct it. If this was a way to optimize that case, the code in KernelScopeInfo could be | Annotation annotationInstance = null; | if (annotation instanceof CachingAnnotationMetaData) | annotationInstance = ((CachingAnnotationMetaData) annotation).removeAnnotation(); | - if (annotationInstance == null) | + else | annotationInstance = annotation.getAnnotationInstance(classloader); | // Null means we never constructed it in the first place | if (annotationInstance != null) | mutable.removeAnnotation(annotationInstance.annotationType()); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170555#4170555 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170555

17 years, 7 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: [JBAS-5095] Race condition between connection.close() an

by jesper.pedersen

Ok. I'll skip that check then in my test case for TxConnectionManager. Thanks, Adrian ! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170554#4170554 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170554

17 years, 7 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: [JBAS-5095] Race condition between connection.close() an

by adrian＠jboss.org

It's ok if there's no transaction associated with the thread. The MC just won't be enlisted (yet? - lazy enlist). But it's wrong if there is a transaction and its not ACTIVE. This check is only an attempt to "fail early" anyway, it could always race with a tx rollback. The real definitive check is done later during tx.enlist(XAResource); View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170553#4170553 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170553

17 years, 7 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: [JBAS-5095] Race condition between connection.close() an

by jesper.pedersen

I'm looking at TxConnectionManager::getManagedConnection(). Shouldn't there always be a check against if an active transaction exists ? Currently we have: | Transaction tx = tm.getTransaction(); | if (tx != null && TxUtils.isActive(tx) == false) | throw new ResourceException("..."); | But in case of a transaction hasn't been started tm.getTransaction() will return null. So code should read: | Transaction tx = tm.getTransaction(); | if (tx == null || TxUtils.isActive(tx) == false) | throw new ResourceException("..."); | The transaction will only be passed to BaseConnectionManager2 if track-by-tx is enabled in any case. TxConnectionManager::checkTransactionActive() also doesn't check for a null value - the JavaDoc states that a RollbackException should be thrown if the transaction is not active. Or am I overlooking something ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170548#4170548 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170548

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: @JMX on a bootstrap service

by adrian＠jboss.org

It's a bug: https://jira.jboss.org/jira/browse/JBMICROCONT-339 actually there's more than one in there. :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170524#4170524 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170524

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: Looking at deployment structure - JBAS-5823

by alesj

"alesj" wrote : | 3) this API is asynchronous, so testing deployments requires some hacks (Thread sleep + multiple tries) | It's asynch if you forget to add name to DeploymentManager::start :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170513#4170513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170513

17 years, 7 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - jars in Lib directory within a .EAR is copied to every .WAR

by michaelchan

Hi, I have a .EAR with about 15 wars. When the .EAR is deployed, I found out from server.log, any jars in the webapp.ear/lib are copied "number of .war" times by the jboss main deployer. Say for example, I have jdom.jar in webapp.ear/lib, and the jdom.jar is copied to the lib directory of every single .WAR during deployment. Is this a bug? Or am I missing something? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170505#4170505 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170505

17 years, 7 months

1
0
0 / 0

[Design of JBossCache] - Re: Eviction redesign

by manik.surtani＠jboss.com

"mircea.markus" wrote : anonymous wrote : Perhaps a different name for "EvictionPolicy", maybe "EvictionActionPolicy" or something. Using the same term for a different thing will be confusing. | I think that the Policy and Algorithm are a not very meaningful terms for describing the responsibility of these classes; also the terms overlap. What about some other names? | anonymous wrote : EvictionAlgorithm - how are nodes selected for eviction | EvictionOrderingPolicy | anonymous wrote : EvictionPolicy - what happens when nodes are evicted | +1 for EvictionActionPolicy I agree that EvictionPolicy is too abstract/too much of a catch-all to be meaningful, but I think EvictionAlgorithm is pretty clear and makes sense. EvictionOrderingPolicy isn't quite right either since the algo doesn't exactly order stuff, but selects stuff for eviction. Perhaps EvictionSelectionAlgorithm if you think EvictionAlgorithm is too general. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170494#4170494 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170494

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