Ben, you nailed it. Surprisingly, the import of TapestryModule in our
own application module solved the issue.
Honestly, we should consider this as a bug, because a Tapestry
application without having TapestryModule loaded won't work at all and
this behaviour differes from the past, what you think?
Or at least let as add a hint on the "getting started" or "release
notes" page?
Again, thanks for helping, this one kept us busy for days :-)
Jens
Am 01.08.23 um 08:02 schrieb Ben Weidig:
Hi Jens,
There was thread with a similar problem in April, and it turned out that
the new Module organization could lead to missing one if you don't use the
TapestryFilter directly, like via web.xml:
https://lists.apache.org/thread/ocy882q8tgdyq6j3mjs50mjx4y7l7yod
You could try to import the TapestryModule in your AppModule explicitly.
Cheers
Ben
On Mon, Jul 31, 2023 at 7:26 PM Jens Breitenstein <jb//
j-b-s...@toc-mailserver.de> wrote:
Hi!
we are currently trying to upgrade our webapp from T5.4 to T5.8.3
The migrator did his job, entire applications builds and starts, well,
partly.
It looks like our migration is incomplete because we use two external
libs "federated-accounts" and "json-bindinding". We made a fork of both,
fixed all compile errors against T5.8.3 and we are able to start the
Quickstart application linked with these modules.
Unfortunately in our migrated T5.4 application startup fails with:
31-Jul-2023 14:20:15.889 SEVERE [RMI TCP Connection(2)-127.0.0.1]
org.apache.catalina.core.StandardContext.filterStart Exception starting
filter [Application]
java.lang.IllegalArgumentException: Contribution
org.tynamo.security.federatedaccounts.services.FederatedAccountsModule.contributeComponentClassResolver(Configuration)
(at FederatedAccountsModule.java:31) is for service
'ComponentClassResolver', which does not exist.
at
org.apache.tapestry5.ioc.internal.RegistryImpl.validateContributeDefs(RegistryImpl.java:298)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.<init>(RegistryImpl.java:242)
The method causing the error:
public static void
contributeComponentClassResolver(Configuration<LibraryMapping>
configuration) { configuration.add(new LibraryMapping(PATH_PREFIX,
"org.tynamo.security.federatedaccounts")); }
So nothing surprising.
When debugging "RegistryImpl" indeed "ComponentClassResolver" is missing
as ServiceId in the map serviceIdToModule...
if (!cd3.isOptional()) { if (cd3.getServiceId() != null) { if
(!this.serviceIdToModule.containsKey(serviceId)) { throw new
IllegalArgumentException(IOCMessages.contributionForNonexistentService(cd));
} } else if (!this.isContributionForExistentService(module, cd3)) {
...throwing the exception above.
Any idea why the core class "ComponentClassResolver" misses? Maybe an
initialization / ordering issue concerning module loading?
I forgot: all sources build with JAVA 11 without any problems.
Thanks in advance
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
