JUnit should not attempt to instantiate/run unit test classes defined as abstract, thoughts?
by Galder Zamarreno
Hi,
Let's say you define an abstract unit test class which is contains test
methods that are run for concrete implementations, i.e.:
class abstract MyAbstractTestCase
{
void test000(){}
void test001(){}
}
class YourConcreteTestCase extends MyAbstractTestCase
{}
class HisConcreteTestCase extends MyAbstractTestCase
{}
If you have a filter to run tests ending in *TestCase, JUnit will try to
run all 3 classes: MyAbstractTestCase, YourConcreteTestCase,
HisConcreteTestCase, i.e.
test000 for MyAbstractTestCase
test001 for MyAbstractTestCase
test000 for YourConcreteTestCase
test001 for YourConcreteTestCase
test000 for HisConcreteTestCase
test001 for HisConcreteTestCase
An abstract class is, amongst other things, a class that can't be
instantiated. Why does JUnit attempt to (doing something funky, that's
for sure) go against the Java rules and try to execute an abstract unit
test class? I'd expect YourConcreteTestCase and HisConcreteTestCase to
be executed as they're concrete implementations.
Of couse, this can easily be avoided by renaming the Abstract class to
something that does not end in *TestCase, but why should I? I defined it
as abstract, do not instantiate it :)
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
17 years, 1 month
AS testsuite regressions
by Dimitris Andreadis
As a reminder, when you make changes, do check the subsequent testsuite runs in hudson to
make sure you don't introduce regressions.
http://hudson.jboss.org/hudson/view/JBoss%20AS/
Hudson reports both the overall change in the number of failed tests (e.g. +10) and also the
"Age" of each individual failing test, so it's relatively easy to identify regressions
caused by a particular set of check-ins, especially in stable branches.
Discover early, fix early.
Thanks
/Dimitris
17 years, 1 month
Re: [jboss-dev] Apologize (was Usecase xml ...)
by Ke Jin
On Nov 20, 2007; 07:16am, Adrian wrote:
>On Mon, 2007-11-19 at 01:20 -0500, Ke Jin wrote:
>> On Thu Nov 15 12:43:18 EST 2007, Adrian wrote:
>> > I saw somebody just "discovered the idea" and called it
>> > the high sounding title "Domain Specific Modelling for IOC"
>> > http://www.pocomatic.com/docs/whitepapers/dsm/
>> >
>> > Except it uses xslt, yuck!
>> > We've being doing that with our datasources for 4 years. :-)
>>
>> Adrian, it is my article.
>>
>> Firstly, I apologize that my article wasted your precious time.
>>
>
>Not really. I've been advocating the idea (if not your solution)
>for some time now. :-)
>
>> Secondly, I never claimed this was a "just discovered idea", not even the
>word "discovered".
>> Instead, I put it very clear that this is similar to the C++ #define marco
>or Lisp defmacro expression. Both of them have been used for decades. Even
>exactly within the area of IoC frameworks, I knew JICE has already supported
>the similar thing for years. Even for ourselves, our first implementation
>supporting this model transformation on top of a third party Java IoC
>container (either Spring or JBoss Microcontainer) was released a year ago
>(PocoCapsule for Java, Sept-25 2006). If we intended to claim this as a "just
>discovered idea", we would have claimed it last year instead of waiting almost
>14 months. Therefore, in the TSS news post (most people found my article from
>thsi post), I used the term "plain-old" to describe this approach, instead of
>a "just discovered idea".
>>
>
>Yep. I've never liked preprocessors, they allow too many hacks
>and don't catch the unintentional ones (i.e. bugs).
>
>Hence my "YUCK" :-)
It seems we have some communication problem. Let me clarify it again. I have never claimed using XSLT transformation to simplify XML configuration is my "just discovered idea". Because the key concept of this idea has been around for decades. I don't mind your yuck, neither care whoever want to claim it is their idea few years ago.
[snip]
>
>> Fourthly, for using the XSLT, please read my post and article closely (pay
>attention to "higher order transformation"). The XSLT is just used as the core
>schema for model transformation, because it is standardized and ubiquitous
>(therefore, would be easy for third party support). None-XSLT transformation
>stylesheet schema can certainly be supported, and already supported by
>PocoCapsule for C++.
>>
>
>The problem for me is that the XSLT (or similar approaches)
>looses what the user actually configures.
>i.e. for programmatic deployment, error reporting
>or if they want to change the model dynamically.
>
>e.g. In our datasource that uses XSLT it is impossible to do:
>
>DataSourceModel dsm = new DataSourceModel(); // pun intended :-)
>dsm.setPoolSize(20);
>deploy(dsm);
>
>// Later - oops need to xslt, etc.
>dsm.setPoolSize(40);
>
>You pretty much have to recreate the whole thing
>because of implementation details. :-(
>
Firstly, our configuration is not in the w3c XSLT but in a XML scheam similar to spring and jboss microcontainer.
Secondly, the inconvenience of programmatic programming (I guess you meant "imperative" programming) in XSLT, is not the weakness of XSLT, but a paradigm shift for a classic OO mindset. XSLT is designed as a declarative language, delibrately avoided the concept of muteable variables which is vital for imperative (programmatic) configuration. This is just like not supporting pointers (i.e. direct memory access) in Java and not supporting record navigation (direct data access without cursors) in SQL DML had let a lot classic minds hard to accept them initially. The good frameworks nicely balances what code should be in the imperative language implemented components (beans), what code should be in the declarative XML configurations and XSLT stylesheets. Neither imperative programming style nor declarative paradigm is the silver bullet to address all issues at all levels.
Thirdly, all things in your mission impossible list are coincidentally supported in our IoC+DSM solution as handy to use features. For instance, our model transformer (even if it is based on XSLT 1.x) supports user-defined, subject specific and programmatic error reporting, our IoC container (and the core schema) supports dynamic configuration changes, and also it supports the configuration in your mission impossible increasing pool size example.
Cheers!
Ke
>> Sincerely,
>> Ke
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>--
>xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>Adrian Brock
>Chief Scientist
>JBoss, a division of Red Hat
>xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
>_______________________________________________
>jboss-development mailing list
>jboss-development(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/jboss-development
17 years, 1 month
Apologize (was Usecase xml ...)
by Ke Jin
On Thu Nov 15 12:43:18 EST 2007, Adrian wrote:
> I saw somebody just "discovered the idea" and called it
> the high sounding title "Domain Specific Modelling for IOC"
> http://www.pocomatic.com/docs/whitepapers/dsm/
>
> Except it uses xslt, yuck!
> We've being doing that with our datasources for 4 years. :-)
Adrian, it is my article.
Firstly, I apologize that my article wasted your precious time.
Secondly, I never claimed this was a "just discovered idea", not even the word "discovered". Instead, I put it very clear that this is similar to the C++ #define marco or Lisp defmacro expression. Both of them have been used for decades. Even exactly within the area of IoC frameworks, I knew JICE has already supported the similar thing for years. Even for ourselves, our first implementation supporting this model transformation on top of a third party Java IoC container (either Spring or JBoss Microcontainer) was released a year ago (PocoCapsule for Java, Sept-25 2006). If we intended to claim this as a "just discovered idea", we would have claimed it last year instead of waiting almost 14 months. Therefore, in the TSS news post (most people found my article from thsi post), I used the term "plain-old" to describe this approach, instead of a "just discovered idea".
Thirdly, for the title, it is "DSM *in* IoC", not *for* IoC. I think this title precisely points out what this scenario is really about, what vision I intend to emphasize (namely "domain-specific modeling"), what opinion I have on the "annotation vs XML" issue, and also where we go beyond our predecessors'. We do not stop at using this approach as merely a configuration simplification method (as in JICE) or migration method (as BEA's jboss descriptors to weblogic migration tool) or a code generation tools (as many CASE or DSM design tools). Please read the discussion/examples of "framework of frameworks" in my article. Certainly, I would like to hear your suggestion on what would be an appropriate title.
Fourthly, for using the XSLT, please read my post and article closely (pay attention to "higher order transformation"). The XSLT is just used as the core schema for model transformation, because it is standardized and ubiquitous (therefore, would be easy for third party support). None-XSLT transformation stylesheet schema can certainly be supported, and already supported by PocoCapsule for C++.
Sincerely,
Ke
17 years, 1 month
(no subject)
by Da Feng
Hello:
I find jboss j2se project svn:
http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_5_0_0_Beta2/j2se
failed some test.(org.jboss.test.jmx.serialization.SerializationSUITE);
one
problem is due to constructor mismatch, but the reports says there are
in total 2 error and 4 failure. some failure seems related to usage of
Method object.
Is there any hints?
DaFENG
Coder
Telecommunication && Network Industry
Pudong
Shanghai
China
____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs
17 years, 1 month
jboss 5 dependencies
by Andy Taylor
As part of the development of JBoss Messaging 2.0 we need the jbossas 5
core-libs. Is there any possibility of making a snapshot of these
available in the repository?
--
--
Andy Taylor <ataylor(a)redhat.com>
Core Developer (JBoss Messaging)
JBoss - a division of Red Hat
17 years, 1 month
EJB3 xpetstore dep libraries -> thirdparty?
by Galder Zamarreno
Hi,
Don't know whether this has come out before. EJB3's xpestore example
contains its dependency libraries within SVN:
cirrus.hibernate
com.mysql
com.opensymphony.module.webwork
com.sap
javancss
org.apache.cactus
org.apache.log4j
org.apache.struts
org.hsqldb
org.junitee
xdoclet
com.java2html
com.opensymphony.module.sitemesh
com.pointbase
de.hunsicker.jalopy
javax.j2ee
org.apache.commons
org.apache.oro
org.apache.velocity
org.jdom
org.postgresql
Shouldn't these libraries be in thirdparty rather under source control?
Having these under source control slows down svn co.
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
17 years, 1 month
Re: [jboss-dev-forums] [Design the new POJO MicroContainer] - Checking DeploymentContext for failures
by Adrian
Since jboss.org is down I'll answer here...
On Wed, 2007-11-14 at 10:48 -0500, alesj wrote:
> Regarding http://jira.jboss.com/jira/browse/JBMICROCONT-187.
>
> What's the best way to get failing ControllerContexts that belong to DeploymentContext param?
>
> This is what I came up currently:
>
> | protected final void checkComplete(
> | DeploymentContext context,
> | Map<String, Throwable> contextsInError,
> | Map<String, Set<MissingDependency>> contextsMissingDependencies,
> | Set<ControllerContext> notInstalled,
> | List<ControllerState> states)
> | {
> | Attachments attachments = context.getDeploymentUnit();
> | if (attachments != null && checkers != null)
> | {
> | for (AttachmentChecker checker : checkers)
> | {
> | ControllerContext cc = checker.getControllerContext(controller, attachments);
> | if (cc != null)
> | {
> | if (cc.getState().equals(cc.getRequiredState()) == false && notInstalled.contains(cc))
> | {
> | checkControllerContext(cc, contextsInError, contextsMissingDependencies, states);
> | }
> | }
> | }
> | }
> | List<DeploymentContext> children = context.getChildren();
> | if (children != null && children.isEmpty() == false)
> | {
> | for(DeploymentContext child : children)
> | checkComplete(child, contextsInError, contextsMissingDependencies, notInstalled, states);
> | }
> | }
> |
>
> where AttachmentChecker looks like this, e.g. Bean checker:
>
> | public abstract class AbstractAttachmentChecker<T> implements AttachmentChecker
> | {
> | private Class<T> type;
> |
> | protected AbstractAttachmentChecker(Class<T> type)
> | {
> | if (type == null)
> | throw new IllegalArgumentException("Null type.");
> | this.type = type;
> | }
> |
> | public ControllerContext getControllerContext(Controller controller, Attachments attachments)
> | {
> | T attachment = attachments.getAttachment(type);
> | if (attachment != null)
> | return getControllerContext(controller, attachment);
> |
> | return null;
> | }
> |
> | protected abstract ControllerContext getControllerContext(Controller controller, T attachment);
> | }
> |
> | public class BeanAttachmentChecker extends AbstractAttachmentChecker<BeanMetaData>
> | {
> | public BeanAttachmentChecker()
> | {
> | super(BeanMetaData.class);
> | }
> |
> | protected ControllerContext getControllerContext(Controller controller, BeanMetaData attachment)
> | {
> | return controller.getContext(attachment.getName(), null);
> | }
> | }
> |
>
> Another checker implementations would include ServiceAC (mbeans) and ControllerContextAC (OSGi deployments).
> Any others?
You don't need to do anything so complicated.
You just need the relevant deployers to record the context names in some
well defined place, e.g. the Deployment{Unit|Context}
It's probably important enough to use a special method rather than
an attachment.
e.g.
public class BeanMetaDataDeployer extends
AbstractSimpleRealDeployer<BeanMetaData>
{
/** The kernel controller */
private final KernelController controller;
/**
* Create a new BeanDeployer.
*
* @param kernel the kernel
* @throws IllegalArgumentException for a null kernel
*/
public BeanMetaDataDeployer(Kernel kernel)
{
super(BeanMetaData.class);
if (kernel == null)
throw new IllegalArgumentException("Null kernel");
controller = kernel.getController();
setComponentsOnly(true);
}
@Override
public void deploy(DeploymentUnit unit, BeanMetaData deployment)
throws DeploymentException
{
KernelControllerContext context = new
AbstractKernelControllerContext(null, deployment, null);
try
{
controller.install(context);
+ unit.addControllerContextName(deployment.getName());
}
catch (Throwable t)
{
throw DeploymentException.rethrowAsDeploymentException("Error
deploying: " + deployment.getName(), t);
}
}
@Override
public void undeploy(DeploymentUnit unit, BeanMetaData deployment)
{
+ unit.removeControllerContextName(deployment.getName());
controller.uninstall(deployment.getName());
}
}
In practice, the component deployment unit name should be the context
name.
This is at least true for the POJO and Service deployers.
So you could just add it as some kind of easy declaration in the
constructor:
public BeanMetaDataDeployer(Kernel kernel)
{
super(BeanMetaData.class);
if (kernel == null)
throw new IllegalArgumentException("Null kernel");
controller = kernel.getController();
setComponentsOnly(true);
// obviously some shorter property name ;-)
setComponentDeploymentNameIsControllerContextName(true);
}
and handle it in the abstract classes:
deploy(...); // will throw an error if not registered in the
controller
if (unit.isComponent() &&
isComponentDeploymentNameControllerContextName())
addComponentContextName(unit.getSimpleName());
>
> View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104658#4104658
>
> Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104658
> _______________________________________________
> jboss-dev-forums mailing list
> jboss-dev-forums(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-dev-forums
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 1 month
