Indeed, OSGi can improve the performance of classloading because it reduces the search space.
Looking up service references can add a small overhead. However this is usually done very infrequently, with the result being cached until the framework notifies us of a change. Regards, Neil -- Neil Bartlett Sent from a phone On Friday, 14 March 2014 at 13:43, Dharmender Goyal wrote: > Partially yes, my code logic will be a major factor. > What I want to know is any framework overhead - perhaps related to repository > reference lookups, class loading etc. I will run a performance and soak test > cycle but can benefit from prior experience of fellow users. > > Thanks > > > On Friday, March 14, 2014 9:28 AM, Neil Bartlett <[email protected]> wrote: > All of these concerns -- performance, security, etc -- are pretty much > orthogonal to OSGi. That is, it depends entirely on the code you run inside > OSGi rather than on OSGi itself. > > Regards, > Neil > > > On Fri, Mar 14, 2014 at 12:14 PM, Dharmender Goyal <[email protected] > (mailto:[email protected])> wrote: > > Hello > > I am evaluating use of OSGI bundle based design to replace an existing high > > volume, multi-user (1000+) J2EE implementation. My prototypes are working > > but want to know of any potential issues with deadlocks, performance, > > security, scalability etc. > > Is there anyone using OSGI bundles for large scale implementations, > > possibly with JBoss, WAS or Tomcat? Any suggestions? > > > > Thanks > > > > Dharmender Goyal > > [email protected] (mailto:[email protected]) > >
