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

[Design the new POJO MicroContainer] - Re: Aliases tests

by adrian＠jboss.org

The "generic" tests are in the dependency module: 1) Add an alias for a context with a "bad" ObjectName org.jboss.test.dependency.controller.test.CrossContextDependencyBadObjectName2TestCase 2) Rewrite the "iDepend" on when it is a "bad" ObjectName org.jboss.test.dependency.controller.test.CrossContextDependencyBadObjectNameTestCase These should handle all the problems (and remove the need to do this in system-jmx) but we need similar concrete tests that the "inject", "depends", etc. actually work in the POJO metadata. It should just be a case of "copying" all the basic dependency tests in org.jboss.test.kernel.dependency.test.* to make two new tests that follow the same pattern as the generic tests. i.e. 1) good dependency name depends on bad bean name 2) bad dependency name depends on good bean name All those tests could really do with some refactoring to make them more easily extendable and reusable (and remove OldAbstractDependencyTest). Besides not being easily extensible, there's also lots of repeated code in them as well. :-( But that is an optional part of the task. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034602#4034602 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034602

19 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Bean as a value to a deployment level classloader

by alesj

"adrian(a)jboss.org" wrote : | We don't want to modify the ClassLoaderMetaData set on the deployment by the user! I don't see what we are modifying in this case? Probably nothing currently? But we should add a dependency on the ClassLoaderMetaData in case actual classloader is inner bean. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034589#4034589 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034589

19 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Bean as a value to a deployment level classloader

by adrian＠jboss.org

This test is failing because there is no "rewrite" of the ClassLoaderMetaData to unwrap the embedded BeanMetaDataFactory. | java.lang.IllegalStateException: Bean not found cl at state ControllerState@120d62b{Installed} | at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.getControllerContext(MicrocontainerTestDelegate.java:152) | at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.getBean(MicrocontainerTestDelegate.java:125) | at org.jboss.test.kernel.junit.MicrocontainerTest.getBean(MicrocontainerTest.java:93) | at org.jboss.test.kernel.junit.MicrocontainerTest.getBean(MicrocontainerTest.java:80) | at org.jboss.test.kernel.deployment.test.BeanMetaDataWithClassloaderTestCase.testBeanAsValueMetaData(BeanMetaDataWithClassloaderTestCase.java:48) | i.e. replace | <classloader> | <bean name="cl" class="org.jboss.test.kernel.deployment.support.NullClassLoader" /> | </classloader> | with | <classloader> | <inject bean="cl"/> | </classloader> | | <bean name="cl" class="org.jboss.test.kernel.deployment.support.NullClassLoader" /> | This needs to get done somewhere in AbstractKernelDeployer.deployBeans() with deployBean() using any modified version. We don't want to modify the ClassLoaderMetaData set on the deployment by the user! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034576#4034576 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034576

19 years

1
0
0 / 0

[Design of JBoss Build System] - Problem with eclipse plugin and JBoss Tests "hack"

by adrian＠jboss.org

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=105740 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034566#4034566 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034566

19 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Aliases tests

by alesj

Where is the generic test mentioned in JBMICROCONT-173? - http://jira.jboss.com/jira/browse/JBMICROCONT-173 What all would you like to test? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034565#4034565 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034565

19 years

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

This is the change that makes the AccessControl test work in eclipse. | - <classpathentry kind="src" path="src/tests"/> | + <classpathentry kind="src" output="eclipse-classes-tests" path="src/tests"/> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034562#4034562 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034562

19 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Build Automation Stuff

by mark.proctor＠jboss.com

Currently we have to upload the manuals and javadocs page by page, image by image, creating long upload times. This automation should be accompanied by an enhancement to jboss.org where projects only upload zips containing the content, which jboss.org then manages the rendering of the contents of that zip. As jboss.org is moving all projects to maven the maven's site generation facilites should be templated and integrated with jboss.org. The plugin should be able to differentiate between releases (stable and unstable) and nightly snapshots, as the location of jars, zip, manuals, javadocs etc may be different. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034561#4034561 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034561

19 years

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

If I understand the code to the eclipse plugin correctly, it is not possible to have a seperate output directory for tests unless you also build eclipse classes into the same place as the normal maven build puts things: org.apache.maven.plugin.eclipse.EclipsePlugin.buildDirectoryList(...) | // If using the standard output location, don't mix the test output into it. | String testOutput = null; | boolean useStandardOutputDir = buildOutputDirectory | .equals( new File( project.getBuild().getOutputDirectory() ) ); | if ( useStandardOutputDir ) | { | testOutput = IdeUtils.toRelativeAndFixSeparator( projectBaseDir, new File( project.getBuild() | .getTestOutputDirectory() ), false ); | } | There's only one parameter that controls output so it is all or nothing. We have this configured in jboss-parent | <plugin> | <groupId>org.apache.maven.plugins</groupId> | <artifactId>maven-eclipse-plugin</artifactId> | <configuration> | <downloadSources>true</downloadSources> | <buildOutputDirectory>target/eclipse-classes</buildOutputDirectory> | </configuration> | </plugin> | What we really want is the non-existant: | <testOutputDirectory>target/eclipse-classes-tests</testOutputDirectory> | as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034552#4034552 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034552

19 years

1
0
0 / 0

[Design of JBoss Build System] - Build Automation Stuff

by pgier

Mark Proctor requested a few features to automate more of the maven build process. This thread can be used to discuss these ideas. Update the jboss maven2 repo - currently the maven deploy plugin handles several protocols for deployment (ftp, ssh, webdav, etc) but it doesn't include the ability to commit to cvs or svn the way that we are currently set up. So that is a manual step. IT has set up a snapshot respository (http://snapshots.jboss.org) which can be updated via webdav. The ability to upload to this repo will be included in version 2 of the jboss-parent pom. Copy dists to downloads.jboss.com - This can be done either with a new custom plugin, or we might be able to configure the deploy plugin as part of the release profile to upload these distributions the way we want. The deploy plugin will automatically pick up any artifacts that are attached to the build, such as custom assemblies for distribution. So we would just have to use one of the existing protocols that downloads.jboss.com has available. Update the labs.jboss.org site - depending on what information we want on the labs, this might be a combination of the maven site plugin (which creates a default web site for a project) and our own custom plugin which creates the info that we can't get though configuring the default site plugin. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034522#4034522 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034522

19 years

1
0
0 / 0

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

by adrian＠jboss.org

The AccessController test is not working properly in eclipse. This is indicitive a greater failure in that tests are being given all permissions when they should run with restricted rights. This stems from a "hack" in our test framework where we look for the phrase "tests" in the url to see whether to give the class restricted access: org.jboss.test.security.TestsPolicyPlugin | // Is this a test location? | File file = new File(url.toString()); | String name = file.getName(); | if (name.indexOf("tests") != -1 || name.indexOf("-test.jar") != -1) | { | But with the new maven build, the test classes don't live in somewhere with tests in the name, they are in the same codebase as the base classes. I assume this is an issue with the eclipse:eclipse plugin? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034519#4034519 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034519

19 years

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 April 2007