On 1/13/18 9:09 AM, Romain Manni-Bucau wrote:
Which is where it doesnt work at all because team i < 4 should not
know anything of team4 code and they cant depend on something created
after they package which is the case today.
There must be a contract on the name of the resource bundle and the name
and semantic of the keys. Such dependency already exists. I don't
understand why it's critical to avoid any dependency on the new SPI
classes and this new SPI class represents the bundle name you hardcoded
in the code that calls getBundle.
Mandy
Said otherwise: being transversal is not possible with modules which
should be fixed IMHO.
Just for my knowledge: why adding a flag is not an option?
Le 13 janv. 2018 18:05, "mandy chung" <mandy.ch...@oracle.com
<mailto:mandy.ch...@oracle.com>> a écrit :
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
