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). * 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. 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. >
