April 2007 - jboss-dev-forums - Jboss List Archives

[Design of the JBoss EJB Container] - Re: JBAS-4304 - Jboss calls ejbStore inside ejbPostCreate on

by adrian＠jboss.org

There are two ways to fix this problem that I can see. 1) Delay the registration of the context with the GlobalTxEntityMap until ejbPostCreate() returns. The disadvantage is that this will require retesting of the locking and caching to make sure we have caught all the cases where delaying the registration of the synchronization with the transaction does not get an automatic tidyup. e.g. tx timeout during ejbPostCreate() will not invoke the synchronization anymore 2) Does some fixup to the state of the EntityEnterpriseContext such that the GlobalTxEntityMap knows not to flush the entity until after the ejbPostCreate has returned. e.g. We could in EntitySynchronizationInterceptor do instance.setTxAssociation(SYNCHRONIZED) in the invokeHome() and reset it to the default NONE after ejbPostCreate() This second option would tell the GlobalTxEntityMap that the data is already synchronized and doesn't need to be flushed, but this might not interplay very well with the "insertAfterEjbPostCreate" feature of CMP? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4035014#4035014 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4035014

17 years, 9 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: Updating the server task to detect OutOfMemoryErrors

by mvecera＠redhat.com

There are several problems about the JUnitMemCheckTestRunner. It works now perfetcly, but it was needed to take the whole junit ant task, copy it under org.jboss.... package and change several classes to use the new extended JUnitTestRunner (JUnitMemCheckTestRunner). I would call this solution a bit weird. But I don't have any idea, how to make it better. Do you have any idea or do you consider this solution good? For the JUnitMemCheckTestRunner you also have to change a configuration file inside ant.jar (please see file atteched to JBAS-4211). Now I would like to ask you about adding it to jboss-test project: 1) Where should the new target be? build-test.xml or examples/build.xml? 2) What server configurations should be used? Could it be 'all'? 3) What test cases should be run on the servers for the JUnitMemCheckTestRunner to check the memory? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034981#4034981 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034981

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Target directory is not correct for tests in new Maven b

by Kevin.Conner＠jboss.com

"adrian(a)jboss.org" wrote : Those are the reasons why we use target/eclipse-classes[-tests] instead of the default location. This should be solvable using profiles. I'll give it a go once I have finished my current TS work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034980#4034980 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034980

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Target directory is not correct for tests in new Maven b

by adrian＠jboss.org

That will work but introduces two other problems. 1) Whenever you do a maven clean, it will blow away the classes which completely confuses eclipse's incremental compiler. 2) When I do a release, I don't want it to have classes compiled with eclipse's compiler. I want to use the JDK compiler. Those are the reasons why we use target/eclipse-classes[-tests] instead of the default location. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034923#4034923 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034923

17 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: How do I do a jbossxb 2.0.0.CR4

by scott.stark＠jboss.org

Is there a way to use a java svn impl? Its not working on my box because the rhel4 svn client is out of date with respect to the eclipse version. | [starksm@succubus jbossxb]$ mvn release:prepare -DdryRun=true | [INFO] Scanning for projects... | [INFO] Searching repository for plugin with prefix: 'release'. | [INFO] ---------------------------------------------------------------------------- | [INFO] Building JBoss XML Binding | [INFO] task-segment: [release:prepare] (aggregator-style) | [INFO] ---------------------------------------------------------------------------- | [INFO] [release:prepare] | [INFO] Verifying that there are no local modifications... | [INFO] Executing: svn --non-interactive status | [INFO] Working directory: /home/svn/Common/trunks/jbossxb | [INFO] ------------------------------------------------------------------------[ERROR] BUILD FAILURE | [INFO] ------------------------------------------------------------------------[INFO] Unable to check for local modifications | Provider message: | The svn command failed. | Command output: | svn: This client is too old to work with working copy ''; please get a newer Subversion client | | [INFO] ------------------------------------------------------------------------[INFO] For more information, run Maven with the -e switch | [INFO] ------------------------------------------------------------------------[INFO] Total time: 1 second | [INFO] Finished at: Wed Apr 04 18:55:07 PDT 2007 | [INFO] Final Memory: 11M/169M | [INFO] ------------------------------------------------------------------------[starksm@succubus View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034841#4034841 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034841

17 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: How do I do a jbossxb 2.0.0.CR4

by pgier

You don't need to set the version in the pom. If you run "mvn release:prepare -DdryRun=true" Then it will prompt you for the release version (2.0.0.CR4) and the new trunk version (2.0.0-SNAPSHOT). See this also: http://maven.apache.org/plugins/maven-release-plugin/howto.html Using the dryRun property, it won't actually commit anything. Next, run "mvn release:clean" This will clean up the stuff that the dryRun option created. I think it's a bug in the release plugin because the version and svn URL get messed up if you do a dry run and then a prepare without clean. The steps to actually do the release are: mvn release:prepare mvn release:perform Prepare does the tag, and perform does the build from the tag. Last step is you have to commit to cvs in the maven and buildmagic repositories. I keep meaning to create a wiki entry describing these steps, I just haven't gotten around to it yet. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034840#4034840 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034840

17 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - How do I do a jbossxb 2.0.0.CR4

by scott.stark＠jboss.org

If I set the jbossxb pom.xml to a new version and test the prepare step, it fails with this error: | [starksm@succubus jbossxb]$ mvn -Dtestmode=true release:prepare | ... | way too much crap pulled from external repos | ... | [INFO] [release:prepare] | [INFO] ------------------------------------------------------------------------[ERROR] BUILD FAILURE | [INFO] ------------------------------------------------------------------------[INFO] The project jboss:jbossxb isn't a snapshot (2.0.0.CR4). | [INFO] ------------------------------------------------------------------------[INFO] For more information, run Maven with the -e switch | [INFO] ------------------------------------------------------------------------[INFO] Total time: 23 seconds | [INFO] Finished at: Wed Apr 04 17:38:00 PDT 2007 | [INFO] Final Memory: 9M/107M | [INFO] ------------------------------------------------------------------------[starksm@succubus jbossxb]$ | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034834#4034834 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034834

17 years, 9 months

1
0
0 / 0

[Design of JBossXB] - Re: JBXB-101, disabling validation

by scott.stark＠jboss.org

After digging into the xerces code, both the VALIDATION and DYNAMIC_VALIDATION features need to be false to avoid validation of docs with DOCTYPEs. The UnmarshallerImpl.setValidation(boolean) was therefore updated to: | public void setValidation(boolean validation) throws JBossXBException | { | parser.setFeature(VALIDATION, validation); | parser.setFeature(DYNAMIC_VALIDATION, false); | } | With this change the test passes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034823#4034823 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034823

17 years, 9 months

1
0
0 / 0

[Design of JBossXB] - JBXB-101, disabling validation

by scott.stark＠jboss.org

I cannot disable validation against a document dtd currently for use with the ObjectModelFactory/Unmarshaller apis. The Unmarshaller.setValidation(boolean) call has no affect. The problem would seem to be this static initialization of the parser factory and setting the validating flag to true: | public class SaxJBossXBParser | implements JBossXBParser | { | private static final Logger log = Logger.getLogger(SaxJBossXBParser.class); | | private static final SAXParserFactory saxFactory = SAXParserFactory.newInstance(); | static | { | saxFactory.setValidating(true); | saxFactory.setNamespaceAware(true); | enableXInclude(); | } | The Unmarshaller.setValidation(boolean) call maps to setting a feature of the parser. I'm not sure why this is not getting picked up on the resulting parser. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034771#4034771 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034771

17 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: HASingleton and partition merges

by bstansberry＠jboss.com

BTW, this is all documented at http://wiki.jboss.org/wiki/Wiki.jsp?page=HASingletonAndClusterMerges. For 4.0.x ended up going the StandardMBean route. Using the 'mbean interface="xxx"' approach would have required changing deploy-hasingleton-service.xml in the CP releases and I didn't want to change a config file in a CP as it could cause problems installing the CP. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034737#4034737 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034737

17 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2007