This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'm sorry! I didn't see that your question was related to Spring DM...
Chapter 10, "Advanced concepts", deals with advanced concepts of Spring DM ;-) and shows how to adapt standard behaviours of the framework to your needs. Here is the list of these aspects:
- How to configure components through configuration fragments or with beans
- How to parameterize both standard and Web extenders of Spring DM
- How to configure embedded Web containers
- How Spring DM integrates with Java 2 security and the OSGi security model
- Description of advanced patterns (Implementation provider and chained class loader patterns)
Can you be more explicit on "existing custom classloaders"? As a matter of fact, as you probably know, OSGi has a specific class loader management...
David Newton wrote:It does, thanks. I work on some apps that have their own classloaders and was wondering if they'd conflict with how OSGi does its classloading--haven't had time to look into it at all yet.
David, there would almost certainly be some interaction. How much pain you feel would probably be proportional to how OSGi conformant you want your application to be. Obviously you can do things like put things on the bootclasspath to subvert pretty much all of OSGi's classloading behaviour and not feel any pain at all - but if you want to reap the benefits of OGSi you might need to look more carefully at how the app doe classloading.
For context we (Oracle in the CEP product that I work on) use custom classloaders for certain behaviour inside our OSGi container and it works fine.