Win a copy of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds this week in the Cloud/Virtualization forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

New Article: Adding Plugins to a Java Application  RSS feed

author and iconoclast
Posts: 24220
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Our own irrascible Ulf Dittmer has written a rootin' tootin' new article entitled Adding Plugins to a Java Application in the new edition of the JavaRanch Journal. Y'all got sumpin' ter say, say it here.
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I found this article very interesting, as I use plugins very frequently. As Ulf has used some deprecated methods in the SecurityManager, I had a look to see how it could work without using deprecated methods.

My aims are slightly different to Ulf's. I started with an interface called ThirdPartyPlugin and wanted to put tight security round any class that implements this plugin, whether loaded from the classpath or via a custom loader. This prevents anyone slipping a rogue plugin onto the classpath. I also want to allow the plugin to instantiate any existing or new classes from any package - so the developer can spread his or her code across several new classes.

It turned out that I did not need a custom classloader, but it's still nice to use one to keep third-party code separate. However, my SecurityManager code is a bit clumsy without using the deprecated methods. Basically the SecurityManager has to navigate up the callstack and find out if any classes implement the ThirdPartyPlugin interface. If so, that's when it needs to throw SecurityExceptions.
One further quirk - when the third-party plugin needs to instantiate a class that is not in the standard Java packages, SecurityManager.checkRead(String file) gets called, so here the SecurityManager needs to allow the call to succeed if a ClassLoader is in the callstack before the ThirdPartyPlugin.

If there's a more elegent solution, I'd be interested to know about it.

Here's my SecurityManager code...

  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!