Spock with tapestry-hibernate 5.3

176 views
Skip to first unread message

Tony Nelson

unread,
Dec 1, 2011, 11:35:39 AM12/1/11
to spockfr...@googlegroups.com
I'm trying to add some simple tests to a very small app that uses tapestry-hibernate.

If I just add AppModule to the SubModules I get this exception:

java.lang.IllegalArgumentException: Contribution com.starpoint.helpdesk.services.AppModule.contributeHibernateEntityPackageManager(Configuration) (at AppModule.java:62) is for service 'HibernateEntityPackageManager', which does not exist.

So I add in the 2 Hibernate modules:

@SubModule([HibernateCoreModule, HibernateModule, AppModule])

Now I get:

java.lang.IllegalArgumentException: Contribution com.starpoint.helpdesk.services.AppModule.contributeTranslatorSource(MappedConfiguration) (at AppModule.java:163) is for service 'TranslatorSource', which does not exist.

So I add in TapestryModule:

@SubModule([HibernateCoreModule, HibernateModule, TapestryModule, AppModule])

At which point I get I a dependency error that I can't figure out:

java.lang.RuntimeException: Exception constructing service 'RegistryStartup': Error invoking service contribution method org.apache.tapestry5.hibernate.HibernateCoreModule.contributeRegistryStartup(OrderedConfiguration, boolean, HibernateSessionSource): Exception constructing service 'FactoryDefaults': Error invoking service contribution method org.apache.tapestry5.ioc.services.TapestryIOCModule.setupDefaultSymbols(MappedConfiguration): Exception constructing service 'TypeCoercer': Error invoking service contribution method org.apache.tapestry5.services.TapestryModule.contributeTypeCoercer(Configuration, TypeCoercer, ThreadLocale, AssetSource, ComponentClassCache, DynamicTemplateParser): Error building service proxy for service 'ThreadLocale' (at org.apache.tapestry5.ioc.internal.services.ThreadLocaleImpl() (at ThreadLocaleImpl.java:24) via org.apache.tapestry5.ioc.services.TapestryIOCModule.bind(ServiceBinder) (at TapestryIOCModule.java:49)): Exception constructing service 'ServiceLifecycleSource': Error invoking service contribution method org.spockframework.tapestry.ExtensionModule.contributeServiceLifecycleSource(MappedConfiguration): Exception constructing service 'ServiceOverride': Error invoking service contribution method org.apache.tapestry5.services.TapestryModule.productionModeOverrides(MappedConfiguration, boolean): Exception constructing service 'TypeCoercer': Construction of service 'TypeCoercer' has failed due to recursion: the service depends on itself in some way. Please check org.apache.tapestry5.ioc.internal.services.TypeCoercerImpl(Collection) (at TypeCoercerImpl.java:129) via org.apache.tapestry5.ioc.services.TapestryIOCModule.bind(ServiceBinder) (at TapestryIOCModule.java:49) for references to another service that is itself dependent on service 'TypeCoercer'.

Has anyone gotten tapestry-hibernate testing to work?

Thanks in advance
Tony Nelson


Ray Nicholus

unread,
Dec 2, 2011, 7:07:43 AM12/2/11
to spockfr...@googlegroups.com

I ran into similar problems, and I have yet to find a solution.

--
You received this message because you are subscribed to the Google Groups "Spock Framework - User" group.
To view this discussion on the web visit https://groups.google.com/d/msg/spockframework/-/Dls8O2KpsREJ.
To post to this group, send email to spockfr...@googlegroups.com.
To unsubscribe from this group, send email to spockframewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/spockframework?hl=en.

Peter Niederwieser

unread,
Dec 2, 2011, 7:26:33 AM12/2/11
to spockfr...@googlegroups.com
Have you asked on the Tapestry list? The Tapestry folks may be in a better position to help and are familiar with Spock and its Tapestry support. Also make sure that you don't have any Tapestry 5.2 Jars on the class path (the spock-tapestry POM still references those).

Cheers,
Peter

Howard Lewis Ship

unread,
Dec 22, 2011, 2:50:16 PM12/22/11
to spockfr...@googlegroups.com
The Spock/Tapestry integration is borked; partly due to subtle changes
to 5.3 injection, and partly due to use of internals of 5.2 that
changed in 5.3.

http://tapestryjava.blogspot.com/2011/12/dissecting-tapestry-operation-trace.html

I'll be working on a fork/patch after lunch.

--
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

Peter Niederwieser

unread,
Dec 22, 2011, 2:57:51 PM12/22/11
to spockfr...@googlegroups.com
Yes, I noticed this already. I tried to add support for 5.3 but didn't see an easy way to make org.spockframework.tapestry.PerIterationManager work across Tapestry versions (because, as you said, it uses Tapestry internals that have changed). One option would be to remove that class, as I'm not sure it's used a lot. However, that would be an incompatible change.

Any help is of course appreciated.

Cheers,
Peter

Howard Lewis Ship

unread,
Dec 22, 2011, 6:28:19 PM12/22/11
to spockfr...@googlegroups.com
I've just rewritten stuff; the implemenatation for PerThreadManager
isn't actually a good fit for PerIterationManager since the point of
PIM is to allow for multiple theoretical threads to work within the
context of a single specification (at least, that's what I think its
for). I've broken those dependencies on Tapestry entirely using a
minimal amount of cut-and-paste.

I'm about to verify the changes ... once its ready, where would you
like the patch?

Peter Niederwieser

unread,
Dec 22, 2011, 6:37:54 PM12/22/11
to spockfr...@googlegroups.com
> the point of PIM is to allow for multiple theoretical threads to work within the context of a single specification (at least, that's what I think its for).

The idea behind PIM was to have a way to get a fresh service instance for each test method (each iteration thereof in case of a data-driven test).

> I'm about to verify the changes ... once its ready, where would you like the patch?

My preference would be a GitHub pull request. Otherwise an attachment to an issue created at http://issues.spockframework.org or an email attachment would do as well.

Thanks!
Peter

Howard Lewis Ship

unread,
Dec 22, 2011, 7:16:04 PM12/22/11
to spockfr...@googlegroups.com
You guys moved up to GitHub? I pulled from SVN. I have a patch, but I
should be able to fork and send a pull.

Peter Niederwieser

unread,
Dec 22, 2011, 7:18:07 PM12/22/11
to spockfr...@googlegroups.com
We moved quite a while ago, but it's entirely possible that no changes
were made to spock-tapestry since.

https://github.com/spockframework/spock

Tony Nelson

unread,
Jan 12, 2012, 3:32:54 PM1/12/12
to spockfr...@googlegroups.com
Is there anything I can do, perhaps a bug I can vote up or similar to get the pull request (https://github.com/spockframework/spock/pull/3) for this fix pulled into a snapshot build?

Tony

Peter Niederwieser

unread,
Jan 12, 2012, 10:06:22 PM1/12/12
to spockfr...@googlegroups.com
Tony,

I've just merged the pull request. Unfortunately it doesn't seem to be
compatible with Tapestry 5.2.

All the changes that were made are related to the per-iteration scope, a
fairly esoteric feature of spock-tapestry. As I can't see a way to make
this feature work across Tapestry versions, I'm inclined to just throw
it out. I'd be surprised if anyone used it; do you? If you are unsure,
look for usages of class spock.tapestry.ScopeConstants and do a
full-text search for @Scope("perIteration"). Thanks for any feedback.

Cheers,
Peter

> --
> You received this message because you are subscribed to the Google
> Groups "Spock Framework - User" group.

> To view this discussion on the web visit

> https://groups.google.com/d/msg/spockframework/-/b_xiRcuk4XsJ.

Tony Nelson

unread,
Jan 13, 2012, 10:46:23 AM1/13/12
to spockfr...@googlegroups.com
I don't use that specific feature, however, none of my test cases work without the fix that Howard posted. I have made several posts about it in various forums trying to determine if it's something that I did wrong or not.  I even created a sample project to show the failure.  You can get it from:


Short version of the problem, I have existing code that I am migrating from Tap4 to Tap5.  All of my domain classes are in a domain package, not entities as the hibernate-tapestry module expects.  I simply contribute an override and tapestry-hibernate finds all my domain models just fine.


The problem is that creates some type of dependency loop (I honestly don't know if it's Tapestry or Spock), and when:

@SubModule([ TapestryModule, HibernateCoreModule, AppModule ])

gets evaluated you end up with an exception, and none of the test run.  If you leave out HibernateCoreModule the test run, but then I can't run the test I need, so I'm stuck.

I don't know what the correct solution to the problem is from a detailed standpoint.  I just would really like to be able to use Spock (and Geb) for my testing, and without some sort of a fix, I can't.

Peter Niederwieser

unread,
Jan 13, 2012, 10:55:17 AM1/13/12
to spockfr...@googlegroups.com
Please try the latest snapshot.

Cheers,
Peter

> --
> You received this message because you are subscribed to the Google
> Groups "Spock Framework - User" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/spockframework/-/E-d8KzGohG8J.

Tony Nelson

unread,
Jan 13, 2012, 11:24:15 AM1/13/12
to spockfr...@googlegroups.com
The latest snapshot appears to work.  To ensure I had the latest snapshot I completely removed ~/.gradle and ~/.m2 then ran a clean test.

Did you find a simpler work around?  Just curious.

Peter Niederwieser

unread,
Jan 13, 2012, 12:42:39 PM1/13/12
to spockfr...@googlegroups.com
I just removed the offending feature whose implementation made use of
Tapestry internals. Also there is still a tiny change in there from
Howard's pull request (one annotation basically). Maybe it makes a
difference.

Cheers,
Peter

> --
> You received this message because you are subscribed to the Google
> Groups "Spock Framework - User" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/spockframework/-/E7Oa1nY5BLMJ.

Tony Nelson

unread,
Jan 13, 2012, 1:20:52 PM1/13/12
to spockfr...@googlegroups.com
I did find one thing that's not quite right but it took me a while to isolate exactly what was going on. 

I created a simple test like this:

    def "just a test"() {
        expect:
        1==1
    }


Yes, dumb.

When I ran it, it of course succeeded but I noticed that there was some text captured in stdout.  Looking at it I found:

[WARN] cfg.AnnotationBinder Package not found or wo package-info.java: com.starpoint.instihire.domain
[ERROR] ioc.Registry Method org.apache.tapestry5.ioc.internal.RegistryImpl.getObject(RegistryImpl.java:850) may no longer be invoked.
[ERROR] ioc.Registry Operations trace:
[ERROR] ioc.Registry [ 1] Instantiating service HibernateSessionManager implementation via org.apache.tapestry5.hibernate.HibernateCoreModule.buildHibernateSessionManager(HibernateSessionSource, PerthreadManager) (at HibernateCoreModule.java:96)
[ERROR] ioc.Registry [ 2] Constructing service implementation via org.apache.tapestry5.hibernate.HibernateCoreModule.buildHibernateSessionManager(HibernateSessionSource, PerthreadManager) (at HibernateCoreModule.java:96)
[ERROR] ioc.Registry [ 3] Realizing service HibernateSessionSource
[ERROR] ioc.Registry [ 4] Instantiating service HibernateSessionSource implementation via org.apache.tapestry5.internal.hibernate.HibernateSessionSourceImpl(Logger, List) (at HibernateSessionSourceImpl.java:36) via org.apache.tapestry5.hibernate.HibernateCoreModule.bind(ServiceBinder) (at HibernateCoreModule.java:45)
[ERROR] ioc.Registry [ 5] Invoking constructor org.apache.tapestry5.internal.hibernate.HibernateSessionSourceImpl(Logger, List) (at HibernateSessionSourceImpl.java:36) via org.apache.tapestry5.hibernate.HibernateCoreModule.bind(ServiceBinder) (at HibernateCoreModule.java:45) (for service 'HibernateSessionSource')
[ERROR] ioc.Registry [ 6] Realizing service ClassNameLocator
[ERROR] ioc.Registry [ 7] Instantiating service ClassNameLocator implementation via org.apache.tapestry5.ioc.internal.services.ClassNameLocatorImpl(ClasspathURLConverter) (at ClassNameLocatorImpl.java:62) via org.apache.tapestry5.ioc.services.TapestryIOCModule.bind(ServiceBinder) (at TapestryIOCModule.java:49)
[ERROR] ioc.Registry [ 8] Creating plan to instantiate org.apache.tapestry5.ioc.internal.services.ClassNameLocatorImpl via public org.apache.tapestry5.ioc.internal.services.ClassNameLocatorImpl(org.apache.tapestry5.ioc.services.ClasspathURLConverter)
[ERROR] ioc.Registry [ 9] Determining injection value for parameter #1 (org.apache.tapestry5.ioc.services.ClasspathURLConverter)
[ERROR] TapestryIOCModule.ClassNameLocator Construction of service ClassNameLocator failed: Method org.apache.tapestry5.ioc.internal.RegistryImpl.getObject(RegistryImpl.java:850) may no longer be invoked.
org.apache.tapestry5.ioc.internal.OperationException: Method org.apache.tapestry5.ioc.internal.RegistryImpl.getObject(RegistryImpl.java:850) may no longer be invoked.
	at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:121)
	at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:88)
	at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87)
	at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1121)
	at org.apache.tapestry5.ioc.internal.util.InternalUtils.calculateParameters(InternalUtils.java:293)
	at org.apache.tapestry5.ioc.internal.util.InternalUtils$23.invoke(InternalUtils.java:1488)

and much more.

After some digging I figured out that the test was just too short.  Tapestry never finished starting the registry and it was already being torn down.

To prove this to myself I added:

    def setupSpec() {
        sleep(5000)
    }

And yes, there was still (a lot) of output to stdout (which must mean I need to provide a better log4j.properties) but it was all normal output including hibernate validating my test database and all my services starting and shutting down.

My solution isn't ideal of course, but it works for now.
Reply all
Reply to author
Forward
0 new messages