Is the current differentiation used to identify wink pieces that are part of the spec versus things that are "proprietary" to Wink ? Other then that, I don't think we are doing any kind of enforcement on the usage of those internal methods (e.g. OSGI visibility or something), and I have used plenty of those when doing the deep integration with Tuscany.
But it should be ok to have a better extensibility mechanism, but then we might have to identify what is "specification" versus "wink specific". On Wed, Aug 14, 2013 at 2:39 PM, Gerhard Petracek < [email protected]> wrote: > hi luciano, > > e.g. WinkConfiguration, DeploymentConfiguration, LifecycleManager and many > others are in *.internal.* packages. > technically it's possible to extend/re-use them, but they would violate a > clean spi (interface/s in a spi package would import internal class/es). > > a first step would be e.g. to support custom LifecycleManager/s which can > be implemented without internal classes. > > regards, > gerhard > > > > 2013/8/14 Luciano Resende <[email protected]> > > > On Wed, Aug 14, 2013 at 12:51 PM, Gerhard Petracek < > > [email protected]> wrote: > > > > > hi @ all, > > > > > > i was going to start with WINK-397. > > > however, just adding new interfaces and using them via > > > java.util.ServiceLoader isn't enough. > > > a lot of central classes (as well as interfaces) are in one of the > > > *.internal.* packages. > > > -> to get a clean spi, we have to move some parts. > > > if there are no objections, i'll create a first draft based on the > wink2 > > > branch. > > > > > > regards, > > > gerhard > > > > > > > > > Could you clarify a little more about what issues you are seeing and what > > changes you are planning ? > > > > -- > > Luciano Resende > > http://people.apache.org/~lresende > > http://twitter.com/lresende1975 > > http://lresende.blogspot.com/ > > > -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
