The inside scoop on what's happening with Tapestry ... from the creator of the Apache Tapestry framework. Plus all the normal, random thoughts on coding and technology.
James Carman pointed out that I had mis-packaged the hivemodule.xml inside WEB-INF, not META-INF. This is what happens when you switch contexts 5,000 times per day. I've fixed this and updated the 0.1.1 distro in the repository. Also, I probably should be appending "-snapshot" to the version number (I have to see if that operates the same in the Maven 2 world as in the Maven 1 world).
Please note that this is not a support forum for Tapestry. Requests for help will be deleted. Please subscribe to the Tapestry user mailing list if you are in need of support, or contact me directly for professional (for pay) support.
Spammers: Don't bother. I delete your comments and it's a waste of time for both of us. 垃圾邮件发送者：不要打扰。我删除您的评论和它的时间对我们双方的浪费
Does this release allow you to easily set multiple Spring context files?
ReplyDeleteI've been successfully using multiple context files by implementing a mechanism of ResourceContribution (thanks to HiveMind's feature to design your own schemas).
ReplyDeleteI ended up with something like this in my hivemodule.xml:
<schema id="ResourceContributions">
...
</schema>
<configuration-point id="ApplicationContextResources" schema-id="ResourceContributions"/>
<contribution configuration-id="ApplicationContextResources">
<resource path="../serviceContext.xml"/>
<resource path="../persistenceContext.xml"/>
<resource path="../applicationContext.xml"/>
</contribution>
<service-point id="ApplicationContextBuilder" interface="org.apache.hivemind.ServiceImplementationFactory"/>
...
</service-point>
the ApplicationContextBuilder would take the ApplicationContextResouces contribution to build an appropriate ApplicationContext.
I'm just curious about why did you decide to provide creation and destruction of Spring's ApplicationContext as part of Tapestry-Spring lifecycle?
ReplyDeleteWouldn't it be easier and more flexibile if you only took care of fetching Spring's beans from ApplicationContext (which resides inside ServletContext), and leave to developers to use default ContextLoaderListener way, or whatever way they want, now and forever?
Less is more ;)
Then again, maybe I'm missing something here ...
My original thought was that you shouldn't even have to do configuration in web.xml to make it work. However, that's proving problematic, so the next "release" will require the normal Spring configuration, and will just "expose" that context to HiveMind.
ReplyDelete