• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Tim Cooke
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Frank Carver
  • Henry Wong
  • Ron McLeod
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Himai Minh

New Article: Adding Plugins to a Java Application

 
author and iconoclast
Posts: 24204
44
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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...

 
No, tomorrow we rule the world! With this tiny ad:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic