You say you've tried auto binding, but have you tried explicitly setting
the id? Like so:
public static void bind(ServiceBinder binder)
{
binder.bind(AssetFinder.class,
AssetFinderImpl.class).withId("AssetFinderWithExplicitId");
}
Auto binding assigns the class name as the service id, which is logical.
However if you have colliding names then you need to specify unique ids.
The fact that you're seeing this problem in deployment but not
production smells a bit off though. Does there happen to be two copies
of your war lying around? It sounds like that builder method is being
called more than once (very odd), or that another part of the app is
contributing a service with the same name - but if that were the case
you'd probably know it.
Steve Eynon wrote:
Hello,
I have a number of T5 web apps that all use a common component module.
In the component's module class (as defined by the
Tapestry-Module-Classes property in its jar's MANIFEST.MF) there is a
simlpe build method:
public static AssetFinder buildAssetFinder(@InjectService AssetSource
assetSource) {
return new AssetFinder(assetSource);
}
All is well whilst developing in Eclipse using the Jetty Launcher but
when I try to deploy in a standalone Jetty instance by copying the war
into its webapps folder I get the following exception:
java.lang.RuntimeException:
Service id 'AssetFinder' has already been defined by
com.alienfactory.websitetags.WebsiteTagsModule.buildAssetFinder(AssetSource)
(at WebsiteTagsModule.java:28)
and may not be redefined by
com.alienfactory.websitetags.WebsiteTagsModule.buildAssetFinder(AssetSource)
(at WebsiteTagsModule.java:28).
You should rename one of the service builder methods.
It's as if the MANIFEST.MF and hence my module class is being parsed
more than once. I've checked the .war and that module class does only
exist the once.
I've also tried autobuilding with the "public static void
bind(ServiceBinder binder)" method and receive a similar message.
I've done the usual searches (tapestry website, google, mailing lists)
and not found any mention of anyone having deployment problems outside
of Tomcat. Are there any known gotchas with respect to deploying
component modules?
Regards,
Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
