team1 has a dependency com.company.resources.spi.Team1Provider which can
be in a separate module (say com.company.resources module) and the
provider implementation will be in team4. i.e. team1 and team4 both
requires com.company.resources module.
Mandy
On 1/12/18 11:14 PM, Romain Manni-Bucau wrote:
Hi Mandy,
3 is the blocker because it creates a dependency to team4 which
shouldnt be visible. It is provided as a container service if you want
and other teams have no dependency on it. This means if we need to
upgrade team4 code then the operation team does it and team1, 2, 3 are
not affected at all.
In terms of costs it must stay the same. I can imagine a light SPI but
it already breaks this "container service" rule, plus it requires to
define hundreds of new classes.
Using a custom classloader with no named module can be a short term
workaround but is broken if modules use module-info only to define a
SPI for instance.
Le 13 janv. 2018 00:21, "mandy chung" <mandy.ch...@oracle.com
<mailto:mandy.ch...@oracle.com>> a écrit :
Let me try to see if I understand your situation correctly.
On 1/12/18 12:59 PM, Romain Manni-Bucau wrote:
All are com.company.*
Assuming service packages use a resource bundle.
team1, team2, team3 all uses a resource bundle. Let's say
com.company.team1.service calls
ResourceBundle.getBundle("com.company.resources.Team1").
Now translations are in http://i18n.company.com/translations
<http://i18n.company.com/translations> and the team
providing the key/values is team4 with no access to team1,
team2 and team3 sources normally.
team4 provides the key/values of "com.company.resources.Team1".
team4 and team1 will agree on the content of this resource bundle
e.g. key names and the value if any text format.
I assume your ResourceBundleControlProvider implementation returns
a Control instance that implements newBundle method to return a
ResourceBundle for
"com.company.resources.Team1".
One migration solution is to use ResourceBundleProvider. The
steps it takes are
(1) define a SPI for each bundle named
com.company.resources.spi.Team1Provider
(2) reuse your existing Control.newBundle implementation to implement
ResourceBundleProvider::getBundle to return the requested
ResourceBundle. This assumes in team4 module
(3) when migrating team1.jar to a named module, the module
definition declares uses com.company.resources.spi.Team1Provider
team4 module can have one single provider implementation for more
than one resource bundle.
Does this help? I can see it takes some amount of work. How many
resource bundles do your application have? It'd be good if you
give a try and send us feedback.
Mandy
