Writing SeamTests with Seam 2.0.0. CR2 - What's...| JBoss.org Content Archive (Read Only)

30. Re: Writing SeamTests with Seam 2.0.0. CR2 - What's Changed?

pmuir Oct 31, 2007 11:23 AM (in response to bsmithjj)

"bsmithjj" wrote:
I don't believe wrong is the correct term to describe the situation, rather, from your (Seam team) perspective, you provide examples that are based on 'things' being in places in the Seam 2.0.0.CR(X) distribution. Thus, jars like "jboss-embedded-all.jar" are not truly all. I say that because I had to discover (the hard way) that I needed to add jboss-embedded-api.jar and jboss-deployers.jar to my repo and test-scoped dependencies to my pom.xml.

Yes, the "official" maven support for Seam isn't well documented. This is because it is new and needs help from the community (e.g. blog articles, patches to the docs) - by using Maven with Seam you are
pushing the boundaries.

Now, useful information rather than me just pointing out the obvious ;)

You are depending on org.jboss.embedded jboss-embedded to get embedded support? The transitive dependencies on this are

jboss-embedded
 -> hibernate-all
 -> thirdparty-all
 -> jboss-embedded-all
 -> jboss-embedded-api
 -> jboss-deployers

So that should pull all the dependencies for booting the embedded container. This should be *easier* than setting up the classpath in ant as you have a well defined set of jars/scopes.

No, this is not in the Seam 2.0.0.CR3 docs - I double checked. I'm guessing your ant scripts build up classpaths using the lib and the lib/test directories in the distro and so it's easy to miss this kind of thing. I also just discovered that I need to add hibernate-commons-annotations.jar to my test-scoped dependencies, and thus, again, hibernate-all.jar is not truly all. It would be nice if the 'all' jars were truly 'all'. ;-)

Things become truly messy with embedded if you need newer bits of hibernate than come with embedded. Yes, embedded is a source of pain, we need to improve this.

The version of hibernate in hibernate-all doesn't depend on hibernate-commons-annotations (it's an older hibernate) but Seam's compile dependencies are newer than that.

I also needed to learn the jboss embedded container layout a bit; this is so that I could put appropriate maven2 testResource instructions into my pom(s) and reproduce the bootstrap directory layout. And... I needed to figure out that I need to copy my target/classes contents to the bootstrap deploy dir (I haven't figured out how to get the bootstrap to treat target/classes as part of the classpath).

You should just be able to add all of this to the classpath when run tests - thats what we do with Ant.

31. Re: Writing SeamTests with Seam 2.0.0. CR2 - What's Changed?

pmuir Oct 31, 2007 11:25 AM (in response to bsmithjj)

You have WEB-INF/components.xml in your classpath?

32. Re: Writing SeamTests with Seam 2.0.0. CR2 - What's Changed?

bsmithjj Oct 31, 2007 1:28 PM (in response to bsmithjj)

WEB-INF/components.xml? no - I'm trying to boot the embedded jboss ONLY from an ejb module that's part of a larger ear project. This all worked nicely in Seam 1.2.1. I say that because (as you probably know quite well by now ;-)) that I am immensely frustrated at things like <core:ejb> disappearing. I can't understand why you wouldn't think about supporting that IN ADDITION TO whatever new form of the JBoss container you want people to be able to boot and test with. As it stands now, in order to migrate our development process from Seam 1.2.1 to Seam 2.0.0, I have to figure out how to get a working jboss embedded (in addition to other things). Although traditionally, the focus of a framework evolution is to fix problems in the current version of the framework and add in new features, this current 'style of evolution' I see in Seam is one in which I am forced to move all dimensions of my development work forward simultaneously.

On the subject of maven and transitive dependencies, please do not deploy the Seam 2.0 releases to your public repository with poms that contain transitive dependencies - that's already tripped me up once because Seam 2.0.0.CR3 transitively stuck el-api.jar into my war and that already existed in the server. Transitive dependencies buy you nothing when they cause unexpected problems that take longer to fix (due to the surprise nature) than simply adding the dependencies you know you need due to good documentation. Knowing version dependencies (to me) is a good thing. Hiding versions and/or dependencies is bad.

BTW, Pete, I appreciate your discussions / interactions and patience with me ;-). In all my rants on the forum here, my frustrations tend to stem from no smooth transition being available for Seam 1.2.1 -> Seam 2.0.0 (on the issues I've posted about). I believe Seam could be a little kinder to its early adopters than it has been. Instead, I have several areas now where I need to 'start from scratch' (e.g. <core:ejb/> gone but actually worked fine ... hence this particular thread).

33. Re: Writing SeamTests with Seam 2.0.0. CR2 - What's Changed?

neilac333 Oct 31, 2007 3:47 PM (in response to bsmithjj)

I have studied the forum, yet I am having trouble simply getting the most basic test to work--a single TestNG unit test extending SeamTest with a single method with Assert.assertTrue(true). That's it. No FacesContext simulation or anything remotely complex. I haven't seen anything in the documentation or in the Yuan book that might help.

Can you please provide just a basic tutorial on the configuration necessary to make SeamTest work? JAR files, configuration files like components.xml and their contents and where they should be, any other kinds of special settings, etc.

It is really frustrating to be having so much trouble with something so basic.

Thanks.

Here is the stack trace of the error:

java.lang.RuntimeException: Unable to create a KernelInitializer based on the specified KernelConfig
 at org.jboss.kernel.KernelFactory.createKernelInitializer(KernelFactory.java:156)
 at org.jboss.kernel.KernelFactory.assembleNewKernel(KernelFactory.java:99)
 at org.jboss.kernel.KernelFactory.newInstance(KernelFactory.java:67)
 at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.bootstrap(AbstractBootstrap.java:120)
 at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
 at org.jboss.embedded.Bootstrap.createKernel(Bootstrap.java:131)
 at org.jboss.embedded.Bootstrap.getInstance(Bootstrap.java:76)
 at org.jboss.seam.mock.EmbeddedBootstrap.startAndDeployResources(EmbeddedBootstrap.java:10)
 at org.jboss.seam.mock.BaseSeamTest.startJbossEmbeddedIfNecessary(BaseSeamTest.java:967)
 at org.jboss.seam.mock.BaseSeamTest.init(BaseSeamTest.java:892)
 at org.jboss.seam.mock.SeamTest.init(SeamTest.java:42)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:604)
 at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:394)
 at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:142)
 at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:79)
 at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:165)
 at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:103)
 at org.testng.TestRunner.runWorkers(TestRunner.java:678)
 at org.testng.TestRunner.privateRun(TestRunner.java:624)
 at org.testng.TestRunner.run(TestRunner.java:495)
 at org.testng.SuiteRunner.runTest(SuiteRunner.java:300)
 at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:295)
 at org.testng.SuiteRunner.privateRun(SuiteRunner.java:275)
 at org.testng.SuiteRunner.run(SuiteRunner.java:190)
 at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:792)
 at org.testng.TestNG.runSuitesLocally(TestNG.java:765)
 at org.testng.TestNG.run(TestNG.java:699)
 at org.testng.TestNG.privateMain(TestNG.java:824)
 at org.testng.TestNG.main(TestNG.java:802)
Caused by: java.lang.AbstractMethodError: org.jboss.aop.microcontainer.integration.AOPJoinpointFactoryBuilder.createJoinpointFactory(Lorg/jboss/reflect/spi/ClassInfo;Lorg/jboss/repository/spi/MetaDataContext;)Lorg/jboss/joinpoint/spi/JoinpointFactory;
 at org.jboss.classadapter.plugins.BasicClassAdapter.getJoinpointFactory(BasicClassAdapter.java:85)
 at org.jboss.beans.info.plugins.AbstractBeanInfo.getJoinpointFactory(AbstractBeanInfo.java:140)
 at org.jboss.kernel.plugins.config.Configurator.findConstructor(Configurator.java:210)
 at org.jboss.kernel.plugins.config.Configurator.getConstructorJoinPoint(Configurator.java:194)
 at org.jboss.kernel.plugins.config.Configurator.instantiate(Configurator.java:92)
 at org.jboss.kernel.plugins.config.Configurator.instantiateAndConfigure(Configurator.java:68)
 at org.jboss.kernel.plugins.config.property.PropertyKernelConfig.getImplementation(PropertyKernelConfig.java:149)
 at org.jboss.kernel.plugins.config.property.PropertyKernelConfig.createKernelInitializer(PropertyKernelConfig.java:117)
 at org.jboss.kernel.KernelFactory.createKernelInitializer(KernelFactory.java:150)
 ... 32 more

34. Re: Writing SeamTests with Seam 2.0.0. CR2 - What's Changed?

bsmithjj Oct 31, 2007 4:21 PM (in response to bsmithjj)

please start a new thread with this topic "I am having trouble simply getting the most basic test to work"

Thanks

35. Re: Writing SeamTests with Seam 2.0.0. CR2 - What's Changed?

pmuir Nov 5, 2007 9:09 AM (in response to bsmithjj)

"bsmithjj" wrote:
WEB-INF/components.xml? no - I'm trying to boot the embedded jboss ONLY from an ejb module that's part of a larger ear project.

Well the error you posted is because your jndiPattern isn't getting set I think. Normally you set this in components.xml/components.properties

IN ADDITION TO whatever new form of the JBoss container you want people to be able to boot and test with.

I understand your frustration, and I'm not trying to shift the blame, but perhaps it helps to know the whole story. Originally the EJB3 team produced an Embedded EJB3 container which Seam then used for testing/tomcat. The EJB3 team then stopped work on this, and started up Embedded JBoss; we then decided to change over Seam's support to the Embedded JBoss project as the last Embedded EJB3 release was using very old (and often early beta) versions of hibernate, EJB3, microcontainer etc. This is all further compounded by the fact that Embedded JBoss needs a maintainer. Please, take your frustrations over to the Embedded JBoss forum as well as that is the place to rant to get the right people's attention.

On the subject of maven and transitive dependencies, please do not deploy the Seam 2.0 releases to your public repository with poms that contain transitive dependencies - that's already tripped me up once because Seam 2.0.0.CR3 transitively stuck el-api.jar into my war and that already existed in the server. Transitive dependencies buy you nothing when they cause unexpected problems that take longer to fix (due to the surprise nature) than simply adding the dependencies you know you need due to good documentation.

A large part of the point of moving to Maven was to gain transitive dependency management. Some projects have very poor transitive dependencies (hopefully we can get Seam to the point where this isn't true for Seam!) but I think in general they are a good thing. Please report issues in JIRA for problems you see with Seam's dependencies so we can fix them. For example, your el-api.jar problem is clearly a bug, but I see no bug report from you for it.

Knowing version dependencies (to me) is a good thing. Hiding versions and/or dependencies is bad.

Of course, and we are a huge step forward from Seam 1 here (where about half our dependencies were hidden in -all.jar files, for which to reconstruct version information for the component parts you had to look at the tag in CVS and inspect buildmagic scripts). Its a simple job to make Maven print out a nice dependency tree with version information in it to an XML file, someone just needs to do it (I will do it for 2.0.1). You can already print this information to the console if you use a snapshot version of the dependency plugin.

BTW, Pete, I appreciate your discussions / interactions and patience with me ;-). In all my rants on the forum here, my frustrations tend to stem from no smooth transition being available for Seam 1.2.1 -> Seam 2.0.0 (on the issues I've posted about). I believe Seam could be a little kinder to its early adopters than it has been. Instead, I have several areas now where I need to 'start from scratch' (e.g. <core:ejb/> gone but actually worked fine ... hence this particular thread).

I think we've addressed this in other places, and we understand your, and others, frustrations. This is why we bumped the version number to 2.0 rather than 1.3.

36. Re: Writing SeamTests with Seam 2.0.0. CR2 - What's Changed?

bsmithjj Nov 12, 2007 4:25 PM (in response to bsmithjj)

Well the error you posted is because your jndiPattern isn't getting set I think.

That's what it looks like, but I've set the jndiPattern, even wrote code to query the JNDI tree and list all the bound objects - I'm using the right pattern and seam is not finding it (in my setup). I believe there is a classloader issue here; possibly another components.xml being read (but I haven't looked into this in about a week and a half now....)

This is all further compounded by the fact that Embedded JBoss needs a maintainer. Please, take your frustrations over to the Embedded JBoss forum as well as that is the place to rant to get the right people's attention.

er.... I wouldn't even use JSF if I hadn't got started with Seam - I don't particularly like JSF. I might have been happy sticking with Hibernate + Spring for entities, DAOs, biz-objects, etc., however, Seam made the case for EJB3. Because I elected to try Seam, I needed to take a look at JSF, Facelets, 1-or-more JSF tag libraries, and EJB3. One of the perils of using Seam, at least for me, is how Seam forces me to track several dimensions (frameworks, API's, configurations, etc.) simultaneously. My point here is that I wouldn't be using the Jboss Embedded if I hadn't followed the seam recommendation to use EJB3 (this was before Seam IOC existed...). I don't think it's responsible for the framework to promote a usage pattern and break that pattern. I think the frustration is well-placed here.

I've already mentioned (either here in the forum or to Gavin) that I would have been quite happy to follow Seam 1.2.1 to 1.3.X but, hey, 1.3. is Dead On Arrival. I was looking for fixes in the 1.2.1 -to- 1.3.X codebase. My only forward path with Seam is 1.2.1 to 2.0.0 and thus, I have to resolve solved problems, and thus here we are discussing this stuff....

Anyway, I'm going to have to waste some more time to get that jboss embedded working via maven 2 - I'm close, but not quite done....

http://www.nytimes.com/2007/11/06/science/06tier.html