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

[Design the new POJO MicroContainer] - Re: Tests don't work in eclipse

by adrian＠jboss.org

We already use the standard maven names in the common project. It would make sense to be consistent. But let us know when you do it, otherwise you're going to break our WIP. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034076#4034076 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034076

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Tests don't work in eclipse

by pgier

Since the resources folders are being moved, is it ok to move them into the standard maven directory layout? src/main/resources src/test/resources That way we wouldn't need to have the resources configuration in the pom at all. What we have now for spring-int is similar, but a little different. /src/resources/main /src/resources/tests We could also move the java source files into the standard layout: /src/main/java /src/test/java View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034075#4034075 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034075

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Remove eclipse files from SVN?

by adrian＠jboss.org

"pgier" wrote : Is this plugin (m2eclipse) not an option? | Does that work with eclipse project sets? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034072#4034072 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034072

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Remove eclipse files from SVN?

by Kevin.Conner＠jboss.com

"pgier" wrote : Is this plugin (m2eclipse) not an option? I must admit that I have never tried it. I am a big fan of maven/subversion/eclipse but I do tend to keep them separate :-) Must give it a try though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034068#4034068 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034068

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Internal AbstractController State

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | The reason I say it is dangerous is because there is more to updating a context's | state than allContexts. There are other "indexes" where the context could exist. | I'm actually currently changing it so you can have a name->context in the allContexts which doesn't exist anywhere else. These will be aliases. So that will be even more work do in the scoped kernel, i.e. move the aliases as well as the main name/context. This says to me that we need a well defined api for these operations (register/unregisterControllerContext) where this, future enhancements and subclasses can plugin their new knowledge. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034067#4034067 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034067

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Internal AbstractController State

by adrian＠jboss.org

I can see having the abstract controller state protected is a bit dangerous given the recent changes for the Scoped Kernels. So I've changed all the state to private with documented protected methods for subclasses to use. The reason I say it is dangerous is because there is more to updating a context's state than allContexts. There are other "indexes" where the context could exist. Besides this new api looks wrong to me anyway, I documented it in a TODO | // TODO This api looks broken and unsafe | // 1) It should not be public | // 2) There should be parameter checking for public methods | // 3) There should be locking when updating state | // 4) Error handling? | public void addControllerContext(ControllerContext context) | The way to make more dangerous operations available to subclasses would be through some helper class that is only protected accesible. e.g. | | private UnsafeInterface unsafe = new UnsafeImplementation(); | | protected UnsafeInterface getUnsafe() | { | return unsafe; | } | | protected interface UnsafeInterface | { | // Methods intended for subclasses that know what they are doing here | // Properly documented to explain requirements, e.g. locking | } | | private class UnsafeImplementation implements UnsafeInterface | { | // Implementation of potentially unsafe methods, but still does some checking | // like null parameters or reasonable error handling so we don't end up | // with a subclass breaking the whole system. | } | There is a similar trick that is the reverse where you define a wrapper interface that only exposes safe methods and make the real implementation unreachable (you always hand out the wrapper externally). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034065#4034065 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034065

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Tests don't work in eclipse

by Kevin.Conner＠jboss.com

Okay, I'll leave them alone then. BTW AbstractKernelConfigTest is also doing the same via XMLUtil. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034062#4034062 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034062

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Remove eclipse files from SVN?

by pgier

Is this plugin (m2eclipse) not an option? If I do a clean checkout of microcontainer, then delete the .project and .classpath files. Then create a project in eclipse and right click (maven-> enable). Eclipse sets up the project and classpath settings for me. This way we could remove the .project and .classpath files from the command line, and not have to use eclipse:eclipse from the command line. Assuming that this plugin is installed in eclipse, the steps could just be: 1. Check out the project from svn using subclipse. 2. Right click on the project and enable maven. 3. (Optional) Change local preferences as needed. Am I missing something that is required in the setup of the project? It didn't work for me when I tried to set up the individual modules of microcontainer as eclipse projects, so I guess this part might still require eclipse:eclipse. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034061#4034061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034061

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Remove eclipse files from SVN?

by adrian＠jboss.org

"Kevin.Conner(a)jboss.com" wrote : "adrian(a)jboss.org" wrote : I hate scripts. I always preferred make (declaritive) to ant (scripts). | Well, I was thinking more along the lines of having maven generate it :-) | But I don't want any extra steps that are unnecessary. Shelling out to the command line defaults the whole point of using an IDE. anonymous wrote : | "adrian(a)jboss.org" wrote : I want to download things and have it work, not waste time | | baby sitting eclipse builds (like I do now :-( ) | | or remembering what order of magic incantations I need to get to a working build | | (besides rm -rf * and start again :-) | Sounds as if you need to use emacs + mvn command line :-) | I was probably more productive when I used wordpad and cygwin, but then I broke the build a lot when I forgot to commit stuff. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034055#4034055 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034055

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Tests don't work in eclipse

by adrian＠jboss.org

The xml-test resources should be combined with the normal resources. However, currently the tests add xml-test to the resource name to retrieve. org.jboss.test.kernel.dependency.test.OldAbstractKernelDependencyTest | protected void deploy(int number) throws Throwable | { | String packageName = Classes.getPackageName(getClass()); | packageName = packageName.replace('.', '/'); | String name = "/xml-test/" + packageName + '/' + getName() + number + ".xml"; | getLog().debug("Using " + name); | URL url = getResource(name); | if (url == null) | throw new RuntimeException("Resource not found: " + name); | getLog().debug("url=" + url); | util.deploy(url); | } | In fact, as the name suggests, the tests need updating to the "new" abstract test case. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034054#4034054 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034054

18 years, 8 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