Closed SentryMan closed 3 months ago
uncommon to provide HTTP routes to other modules.
It is common but that does not require autoProvides in order to use routes across modules. This change breaks http apps by requiring the controllers to be public which they are not required to be (the routes are public but NEITHER controllers nor routes need autoProvides because other modules do not have a compile time tight dependency to either controller or route.
When the route is registered via the common public interface that is how all the routes are found and registered with the http server and that does NOT require autoProvides.
If there was a problem there is was unrelated to autoProvides.
do not have a compile time tight dependency to either controller or route.
They may not need the route class itself, but they do need the AvajeJavalinPlugin
or HttpFeature
to be in the list of autoprovided classes.
When the route is registered via the common public interface that is how all the routes are found and registered with the http server and that does NOT require autoProvides.
Not sure I follow, say I have module A
which has the generated routes. How does module B
know that A
has any generated routes without putting a @InjectModule(requires=HttpFeature.class)
on B
?
How does module B know that A has any generated routes without putting a @InjectModule(requires=HttpFeature.class) on B?
Does module B
have routes? I think this is the issue ... If B
has routes then if does not matter, if B
has no routes but wants to wire/register them then yes it will need something like @InjectModule(requires=HttpFeature.class)
or for the routes to have autoProvides.
let's do this then, I'll change the PR such that it will auto-provide only the HTTP common interfaces and not the route classes themselves
Replaced by https://github.com/avaje/avaje-inject/pull/590
From what I've seen from doing support, it's not uncommon to provide HTTP routes to other modules.