Hi Kishanthan, 3rd option is also use static weaving isn't it? Is it ok to persist the modified SPI bundles?
Thanks. On Fri, Mar 4, 2016 at 1:58 PM, Kishanthan Thangarajah <[email protected]> wrote: > Hi Miraj, > > On Fri, Mar 4, 2016 at 10:25 AM, Miraj Abeysekara <[email protected]> wrote: > >> >> ---------- Forwarded message ---------- >> From: David Bosschaert <[email protected]> >> Date: Mon, Feb 15, 2016 at 3:04 PM >> Subject: Re: SPI-Fly Mediator Service for Bundle Ordering >> To: [email protected] >> >> >> Hi Miraj, >> >> It's an interesting idea, however I'm not sure it will always work. The >> problem is that you need to have your weaving hook registered before the >> class to be woven is *loaded*, and I'm wondering whether this will provide >> enough guarantees to know that the class is not yet loaded. I mean there >> could be another bundle that loads the class that needs to be woven for >> whatever reason and suddenly this approach will stop working... >> >> The possibilities as they are right now are: >> * Use start levels. Run the dynamic weaving bundle on a very low start >> level (like 1) and run your other bundles on a higher start level (e.g. 2 >> or 4 or 50). >> > > We tried start level based solutions before too but the issue we faced was > wedid not have control over this as people will try to use this for all the > scenarios, which then became complex. Start level should be brought in as a > platform wide solution and we need to properly design and use it. So for > the moment, let's not go with this approach. > > >> * Use static weaving [1]. This will do the weaving on a bundle at build >> time and replace the to-be-woven classfiles with woven ones in the .jar. >> This approach does not have any ordering constraints at runtime. >> ** You could even run the static weaving tool as part of your OSGi >> framework provisioning phase, so statically weave bundles on-the-fly before >> you are installing them. >> > > IMO, let's go with the 3rd option mentioned above, rather than statically > weaving the bundles before starting the server. > > >> I'm just wondering, is there any reason why one of these two approaches >> doesn't work for you? >> >> Cheers, >> >> David >> >> [1] See 'Use with Static Weaving' in >> http://aries.apache.org/modules/spi-fly.html >> >> On 15 February 2016 at 08:45, Miraj Abeysekara <[email protected]> wrote: >> >>> Hi, >>> >>> We are currently developing a caching API which provides caching service >>> for the consumers. Currently the SPI-Fly dynamic weaving bundle should >>> started first in order to weave the consumer bundles otherwise the >>> consumers does not weave and can not see the class-loader of the service >>> provider bundle. >>> >>> We came up with an idea to solve this issue by exposing a OSGi service >>> from the mediator after it was started. So the consumers can use >>> declarative service to delay the startup until the mediator service >>> available. >>> >>> Is it possible to add this feature to the SPI-Fly? >>> >>> Thanks. >>> >>> Best regards, >>> Miraj Abeysekara. >>> >> >> >> >> >> -- >> Miraj Abeysekara >> Intern (Software Engineering) >> Mobile: +94775690822 >> Twitter: https://twitter.com/MiRAGECreator >> GooglePlus: https://plus.google.com/u/0/+MirageAbeysekara >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > *Kishanthan Thangarajah* > Associate Technical Lead, > Platform Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* > Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* > -- Miraj Abeysekara Intern (Software Engineering) Mobile: +94775690822 Twitter: https://twitter.com/MiRAGECreator GooglePlus: https://plus.google.com/u/0/+MirageAbeysekara
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
