Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Plugging the users in - extend your application with pluggable Groovy DSL

Plugging the users in - extend your application with pluggable Groovy DSL

t is often beneficial to allow users extend your software with their own logic. With the rise of dynamic languages on the JVM it is also much more easier to do than ever before. In this session we will share our experience in creating Groovy authored user plugins interface.

After a brief introduction to domain specific languages (DSLs), their relevance to user plugins and how they can be easily implemented in Groovy, we’ll look at more user-friendly, but developer-challenging type of DSLs, which support plugins written both in Groovy or Java.

Good public API design is another very important aspect - while the APIs have to be broad enough to allow interesting functionality, internals should stay close to allow changes and further development. Exposing APIs to the world come with great responsibility - once ublished they can’t be changed without a price, so it is important keep backwards compatibility in mind.

Another very important aspect is security - you let strangers into your chambers, and you better be ready. Leveraging security mechanisms is essential to establish proper sandboxing and protect your application from malicious or faulty plugins.

Finally, we will cover another very important and nontrivial aspect of user plugins exposure - the classpath isolation when your plugins require dependencies. We will compare different solutions like establishing classpath hierarchies, OSGi, JBoss modules and the long-awaited Project Jigsaw.

3d73332968c0bf62e1ece7299deb8b37?s=128

Baruch Sadogursky

September 12, 2013
Tweet

Transcript

  1. © 2013 SpringOne 2GX. All rights reserved. Do not distribute

    without permission. Plugging the users in extend your application with pluggable Groovy DSL
  2. None
  3. None
  4. None
  5. None
  6. None
  7. None
  8. None
  9. None
  10. None
  11. None
  12. None
  13. None
  14. None
  15. – scheduled tasks

  16. – scheduled tasks – Custom security realms

  17. – scheduled tasks – Custom security realms – Change resolution

    rules
  18. – scheduled tasks – Custom security realms – Change resolution

    rules – Manipulate downloaded content
  19. – scheduled tasks – Custom security realms – Change resolution

    rules – Manipulate downloaded content – Listeners on storage events
  20. – Custom security realms – Change resolution rules – Manipulate

    downloaded content – Listeners on storage events – searches
  21. – Change resolution rules – Manipulate downloaded content – Listeners

    on storage events – searches – New rest commands
  22. – Manipulate downloaded content – Listeners on storage events –

    searches – New rest commands – Custom promotions
  23. – Listeners on storage events – searches – New rest

    commands – Custom promotions – Deploy and query artifacts and metadata
  24. – Etc.

  25. None
  26. Requirements ___________

  27. Requirements –Familiar to Java users ___________

  28. Requirements –Familiar to Java users –Simple DSL ___________

  29. Requirements –Familiar to Java users –Simple DSL –Simple deployment: ___________

  30. Requirements –Familiar to Java users –Simple DSL –Simple deployment: –No

    packaging ___________
  31. Requirements –Familiar to Java users –Simple DSL –Simple deployment: –No

    packaging –No restart ___________
  32. None
  33. None
  34. Small helpers

  35. Small helpers Totally new language

  36. Small helpers Totally new language

  37. None
  38. None
  39. Small helpers Totally new language

  40. <3

  41. Parse groovy scripts Create closure objects Cast to SAM Find

    SAMs in classpath SAMs map Cast to Closure Execute
  42. Show me the code!

  43. None
  44. Public API Design _____________

  45. Public API Design –Papi is contract _____________

  46. Public API Design –Papi is contract –Maintain backwards compatibility at

    all costs _____________
  47. Public API Design –Papi is contract –Maintain backwards compatibility at

    all costs – Breaking API might crash the server! _____________
  48. Public API Design –Papi is contract –Maintain backwards compatibility at

    all costs – Breaking API might crash the server! – Start small _____________
  49. Public API Design –Maintain backwards compatibility at all costs –

    Breaking API might crash the server! – Start small – Listen to users _____________
  50. Public API Design compatibility at all costs – Breaking API

    might crash the server! – Start small – Listen to users – Fluent API is your friend _____________
  51. Public API Design – Breaking API might crash the server!

    – Start small – Listen to users – Fluent API is your friend – Strong Java Types, compatibility _____________
  52. Show me the code!

  53. None
  54. None
  55. None
  56. None
  57. None
  58. None
  59. The conflict __________

  60. The conflict – Need to access Artifactory jars (PAPI) __________

  61. The conflict – Need to access Artifactory jars (PAPI) –

    Need to be isolated from Artifactory jars (3rd party) __________
  62. None
  63. None
  64. None
  65. None
  66. We’ll do it ourselves! ________________

  67. None
  68. We’ll do it ourselves! 1. Pull up what’s common ________________

  69. We’ll do it ourselves! 1. Pull up what’s common 2.

    isolate the rest ________________
  70. We’ll do it ourselves! 1. Pull up what’s common 2.

    isolate the rest ________________
  71. None
  72. None
  73. None
  74. None
  75. None