if my above observation is correct

It depends. You may as well include everything in distribution and only configure each installation to use what it needs. Possible reasons for going with plugins are:

1. You charge your plugins separately and don’t want to give away features for free
2. Your plugins are “heavy” in some way, e.g. there are lots of them or they have a significant size.

If those reasons do not apply to your case, you may think of a simpler solution.

how to have above kind of plugin structure with Java/Java EE?

If you’re OK with rolling your own simplest solution, here is the general scheme:

1. In app’s configuration (which can be *.properties file or a record in DB, whichever works better for your users, because they should be able to change it), add a property which contains a path to plugins directory
2. Define and expose plugin API – a set of interfaces which a plugin must implement to allow application to invoke this plugin
3. Write custom ClassLoader which uses the property from #1 and maybe checks if each plugin properly implements your API
4. Load your plugins’ classes and resources using this class loader
5. Invoke plugins’ functions via interfaces of plugin API or, if plugin consists of resources only, include those as needed

are there any frameworks in Java that supports above kind of thing?

Yes. Googling for “java plugin framework” reveals some.

Other questions on the topic:

• Best way to build a Plugin system with Java
• Java plugin framework choice
• How to create a pluginable Java program?
• Java Web application “plugin” architecture

Update:

To load JSP files (or any files), use classloader as described above: see getResource and getResourceAsStream methods.

Update 2:

After meditating some more, I see you just need to conditionally include a JSP into another JSP. This is not “pluggable UI components” or anything like that, it’s just conditional inclusion. There are no frameworks for that since it’s just about 4-6 lines of code. It seems like you think it’s more complex than it actually is.

I think this will do:

• have a property in a file (or in DB) which tells which plugin should be used
• assign a value of this property to a variable, say String plugin = ...
• pass it to your JSP: request.setAttribute("plugin", plugin); or something similar
• use it like <jsp:include page="${plugin}" flush="true" />

Could be wrong in syntax, but the point should be clear. Hope it helps.

Here is one possible solution. There are others, but this seems like quite a simple way of doing it to me. I assume your site will be built using an MVC architecture, and that plugins provide three kinds of content: Java classes to implement controllers, JSP views, and static resource files that must be served.

• Deploy your application as an expanded directory structure rather than a WAR file. This means users will be able to drop plugins as JAR files in the WEB-INF/lib directory. The server will automatically add any JAR file deployed in this directory to the classpath.
• Use the Spring MVC framework, and enable its options to scan the classpath for components.
• Each plugin can have one or more classes with the Spring annotation @Component, which will cause Spring to automatically create an instances of them. They may use @PostConstruct on a method to cause that method to execute at startup, which can be used for any initialisation you require.
• Integration with the rest of the site can be achieved by exporting services as objects of known type and using @Autowire annotations on fields of that type to cause Spring to provide references to them.
• Use the technique described at http://imwill.com/spring-mvc-4-add-static-resources-by-annotation/#.VE2HPfl_vTo to configure a resource handler that maps a directory name on the server to a directory in the classpath and store your static resources in your jar file at that location
• Precompile your JSP files to Java classes and include them in your jar file (instructions here: http://docs.oracle.com/cd/E19146-01/821-0790/abxcc/index.html)

You should then be able to bundle up features of your web site into JAR files that can be deployed simply by copying the JAR file into the WEB-INF/lib directory of your web app.

Whether you can use the file structure to configure enabled or not depends on how you deploy your web application.

Will the web app be deployed on the customers server? Then you can use the file structure.
Will you deploy the web app on your own server? Then you won’t be able to use file structure.

In any case it’s probably less complicated to include all views (e.g. JSP or JSF pages) and then have a configuration table in your database for each customer that tells you which plugins are enabled. Then in your view (JSP or JSF) you use conditional rendering based on those config values.

In other words in JavaEE you dynamically generate html, so you for each payment method you can check in your database whether it’s enabled and then only render the enabled ones to your final html output.

Update:
One way to have different builds where you include/exclude the code might be to use maven and set up different profiles for the different payment options. This solution would only work if you deploy your webapp on your customers servers. I still think that the cleanest solution would be to use configuration.