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

[Design of EJB 3.0] - Re: Status of annotation based configuration

by adrian＠jboss.org

"ALRubinger" wrote : | OK, but if we externalize the defaults into a "constants" class/interface, it'll have to go into ext-api for @Pool to get at it. I don't think this is too implementation-specific to be a problem, but worth noting. | | S, | ALR If you don't like the default being in ext-api, make the defaultPool "##Default" or "*Default" then bind that to a real runtime default in your PoolFactoryRegistry config. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106435#4106435 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4106435

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Status of annotation based configuration

by ALRubinger

"adrian(a)jboss.org" wrote : Why do they have to specify a default pool implementation? Most likely all they want to do is change the pool size? A much better point. "adrian(a)jboss.org" wrote : We should define defaults somewhere and reference them from the three places that use. OK, but if we externalize the defaults into a "constants" class/interface, it'll have to go into ext-api for @Pool to get at it. I don't think this is too implementation-specific to be a problem, but worth noting. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106430#4106430 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4106430

18 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Presentation Framework update

by chris.laprun＠jboss.com

Yeah, I would also prefer a change like that to occur after 2.6.3 is released... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106428#4106428 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4106428

18 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MC deadlock

by adrian＠jboss.org

This issue was raised before. It needs somebody who can reproduce it to get a TRACE log. It shouldn't have to wait to get a lock on something it is unlocking. ;-) Or more accurately it shouldn't have to wait forever since the other thread should give up the lock when it spots it doesn't own it. LIke I said before, my guess is it is in the "ThreadTask.releaseInNextTask" logic, since I just copied that from the old classloader code without really understanding how it works. i.e. It is probably releasing the lock twice or something similar to that? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106426#4106426 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4106426

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re:

by ALRubinger

"bstansberry(a)jboss.com" wrote : What's your thinking behind making the @CacheConfig.name attribute type a Class? At least for the current usage in the clustered case a String is fine. Compile-time constraints for the bean provider. Course, we're using Strings elsewhere (@Cache, @Pool) so maybe that'd make more sense for consistency. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106422#4106422 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4106422

18 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Presentation Framework update

by thomas.heute＠jboss.com

That would be preferred :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106417#4106417 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4106417

18 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Work on 187, 188, 218, .bsh, StructureDeployer

by alesj

I'm almost done with tests for this work. Just two more tests that I have in mind currently and would need some help on how to make them work. :-) For the single deployment api in MainDeployerImpl, I added a ReentrantReadWrite lock for the following purpose. All methods that modify existing deployments (all, topLevel, error) have a read lock, except for shutdown, which has a write lock. Meaning you can 'safely' use first methods, since it's up to the user to explicitly remove deployment, where shutdown undeploys them all - regarding how they were added: single deploy or via add/process. A RRW lock can take multiple read locks and exclusive write lock, so this looks exactly the behavior we're looking for. What I would like to do, is to test that a single deploy|undeploy and (add|remove)+process don't corrupt each other in multithread requests. Another test would include a shutdown thread, from where on all other non-shutdown (deploy|undeploy) threads should fail. The question is how to gather required information, meaning that a thread was legally allowed to go (or not go) past the locks that we've put? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106415#4106415 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4106415

18 years, 4 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: Using xinclude in config files

by adrian＠jboss.org

"snacker" wrote : It's not working... | | I couldn't find any command/env properties to set, so I created a dummy DocumentBuilderFactory class which sets namespaceaware and xincludeaware to true then proxies all calls to org.apache.xerces.jaxp.DocumentBuilderFactoryImpl. | I've got no idea why it's not working. Ask the Apache Xerces project. There is likely some nuance they can explain. THIS IS NOT A JBOSS ISSUE, so there's little point trying to guess here. I even tried hacking the configuration properties but that doesn't work either: | package test; | | public class MyXmlParserConfig extends org.apache.xerces.parsers.XIncludeAwareParserConfiguration | { | public MyXmlParserConfig() | { | setFeature(NAMESPACES, true); | setFeature(XINCLUDE_FEATURE, true); | } | | // OR Even more belt and braces: | | public boolean getFeature(String featureId) throws org.apache.xerces.xni.parser.XMLConfigurationException | { | | if (featureId.equals(NAMESPACES) || featureId.equals(XINCLUDE_FEATURE)) | return true; | return super.getFeature(featureId); | } | } | Neither works. There's not point testing jboss5-Beta2. The SARDeployer where you report your stacktrace uses a plain SAXParser not JBossXB. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106413#4106413 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4106413

18 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Annotation to metadata status

by anil.saldhana＠jboss.com

"wolfc" wrote : I think I already spotted some bugs. ;-) | I'll do some test cases. | | Anil's case is invalid, because BusinessBean does not implement an interface. An empty @Remote is however valid (EJB 3 4.6.6 bullet 5.1). Oh! no. I wrote a BusinessInterface interface and forgot BusinessBean to extend BI. :( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106411#4106411 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4106411

18 years, 4 months

1
0
0 / 0

[Design of JBoss Build System] - Re: bootstraping a local repository

by pgier

Yes, I created this wiki page to show some stuff you should put into settings.xml. http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenSettings I recommend creating a setttings.xml file under the .m2 directory in your home directory (~/.m2/settings.xml), instead of editing the global maven settings file. That way you can use those settings with multiple maven installations if you want. If you want to use only the jboss repository (and ignore the maven central repo), I just added some info to the wiki page on how to do this . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106402#4106402 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4106402

18 years, 4 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 November 2007