NetBeans Forums

 FAQFAQ   SearchSearch   MemberlistMemberlist   RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
  

Wrapper Module - compile and provided dependencies?

 
Post new topic   Reply to topic    NetBeans Forums -> NetBeans Platform Users
View previous topic :: View next topic  
Author Message
kpenrose



Joined: 18 Jan 2012
Posts: 18

PostPosted: Thu Nov 12, 2015 2:10 pm    Post subject: Wrapper Module - compile and provided dependencies? Reply with quote

I have just started programming on the NetBeans RCP, using maven, trying to port some existing JavaFX applications into the platform. The JavaFX applications are part of a suite of apps, so I thought it would be cool to allow them all to be modules which could be loaded into the platform as needed by each group of users.
The JavaFX apps rely heavily on JMS and of course database access. Both of these led to huge problems for me on the RCP. I found that adding the necessary jar files for remote EJB lookup to be very painful, so I switched to webservices (which is very easily done by adding the @WebService annotation to the beans - no need for Remote classes, etc.) Integrating webservices into the RCP was relatively painless.
However, adding JMS has been another story - and it's still related to adding the necessary jar files to the project to allow the stand-alone application to access services housed in the glassfish 4.1 server. I've tried adding gf-client.jar and imqjmsra.jar from the org.glassfish.main branch of the repositories. I tried creating two wrapper modules, one for each, and using them in the RCP application.
In each module that uses classes from these wrappers, I added a provided dependency, based on the fact that I read that doing so keeps that wrapper module from being added to the current module. I obviously need the reference to the wrapper module in order to compile my code. After following this procedure, I get many ClassNotFound errors when trying to run the application. Adding them as compile dependencies removed the ClassNotFound errors, but then I get issues of the app trying to load a class from two different modules.
For anyone familiar with using gf-client.jar, you also need all of the module jars that are found in the $GLASSFISH_HOME/modules directory to be on the classpath. Not sure how to wrap up this mess either. I found a way around those problems by wrapping the glassfish-embedded-all.jar file, which contains everything needed, but again, compile dependencies in each module and I end up with a 400MB application. Using this method is the only way I have been able to get webservices working AND JMS.
So, my question really boils down to: how do you wrap a jar of jars (hundreds) and make them available to all requiring modules in an application? Something that seems simple on its cover is turning out to be a nightmare for me.
Thanks.
Back to top
Tim Boudreau
Posted via mailing list.





PostPosted: Thu Nov 12, 2015 10:44 pm    Post subject: Wrapper Module - compile and provided dependencies? Reply with quote

You're going to need to expose all the packages from your dependencies as public packages of your wrapper module - that will probably cure the ClassNotFound issues (you can use wildcards which can help).

The times I've had a giant pile of dependencies like that, I've used the maven assembly plugin to build one giant library containing everything and then used that - not pretty, but does the job.  Or I've written scripts to generate the dependency and classpath info, so it could be regenerated easily when some piece got upgraded.


Honestly, I'd look at something more lightweight for the back-end communication (i.e. something RESTful that doesn't try to hide the fact that wire communication is happening - you'll likely get in trouble later doing network I/O in the event thread and not knowing it until someone runs it on a screwy network), but that may not be an option for you.


-Tim








On Thu, Nov 12, 2015 at 9:10 AM, kpenrose <address-removed ([email]address-removed[/email])> wrote:
Quote:
I have just started programming on the NetBeans RCP, using maven, trying to port some existing JavaFX applications into the platform.  The JavaFX applications are part of a suite of apps, so I thought it would be cool to allow them all to be modules which could be loaded into the platform as needed by each group of users.
The JavaFX apps rely heavily on JMS and of course database access.  Both of these led to huge problems for me on the RCP.  I found that adding the necessary jar files for remote EJB lookup to be very painful, so I switched to webservices (which is very easily done by adding the @WebService annotation to the beans - no need for Remote classes, etc.)  Integrating webservices into the RCP was relatively painless.
However, adding JMS has been another story - and it's still related to adding the necessary jar files to the project to allow the stand-alone application to access services housed in the glassfish 4.1 server.  I've tried adding gf-client.jar and imqjmsra.jar from the org.glassfish.main branch of the repositories.  I tried creating two wrapper modules, one for each, and using them in the RCP application.
In each module that uses classes from these wrappers, I added a provided dependency, based on the fact that I read that doing so keeps that wrapper module from being added to the current module.  I obviously need the reference to the wrapper module in order to compile my code.  After following this procedure, I get many ClassNotFound errors when trying to run the application. Adding them as compile dependencies removed the ClassNotFound errors, but then I get issues of the app trying to load a class from two different modules.
For anyone familiar with using gf-client.jar, you also need all of the module jars that are found in the $GLASSFISH_HOME/modules directory to be on the classpath.  Not sure how to wrap up this mess either.  I found a way around those problems by wrapping the glassfish-embedded-all.jar file, which contains everything needed, but again, compile dependencies in each module  and I end up with a 400MB application.  Using this method is the only way I have been able to get webservices working AND JMS.
So, my question really boils down to: how do you wrap a jar of jars (hundreds) and make them available to all requiring modules in an application?  Something that seems simple on its cover is turning out to be a nightmare for me.
Thanks.








--
http://timboudreau.com
Back to top
kpenrose



Joined: 18 Jan 2012
Posts: 18

PostPosted: Fri Nov 13, 2015 1:41 pm    Post subject: Re: Wrapper Module - compile and provided dependencies? Reply with quote

Thanks Tim. This is kinda what I'd assumed I would have to due as far as creating a wrapper module is concerned; as I said, I'm just starting with this, so where do I declare the public packages (the manifest.mf file? or the pom?), and what is the syntax that you use for those jars in jars? Some of the files in this jar are class files, some are jars, some are dtd's and some are META-INF files. Maybe REST is the way to go...

Tim Boudreau wrote:
You're going to need to expose all the packages from your dependencies as public packages of your wrapper module - that will probably cure the ClassNotFound issues (you can use wildcards which can help).

The times I've had a giant pile of dependencies like that, I've used the maven assembly plugin to build one giant library containing everything and then used that - not pretty, but does the job.  Or I've written scripts to generate the dependency and classpath info, so it could be regenerated easily when some piece got upgraded.


Honestly, I'd look at something more lightweight for the back-end communication (i.e. something RESTful that doesn't try to hide the fact that wire communication is happening - you'll likely get in trouble later doing network I/O in the event thread and not knowing it until someone runs it on a screwy network), but that may not be an option for you.


-Tim








On Thu, Nov 12, 2015 at 9:10 AM, kpenrose <address-removed ([email]address-removed[/email])> wrote:
Quote:
I have just started programming on the NetBeans RCP, using maven, trying to port some existing JavaFX applications into the platform.  The JavaFX applications are part of a suite of apps, so I thought it would be cool to allow them all to be modules which could be loaded into the platform as needed by each group of users.
The JavaFX apps rely heavily on JMS and of course database access.  Both of these led to huge problems for me on the RCP.  I found that adding the necessary jar files for remote EJB lookup to be very painful, so I switched to webservices (which is very easily done by adding the @WebService annotation to the beans - no need for Remote classes, etc.)  Integrating webservices into the RCP was relatively painless.
However, adding JMS has been another story - and it's still related to adding the necessary jar files to the project to allow the stand-alone application to access services housed in the glassfish 4.1 server.  I've tried adding gf-client.jar and imqjmsra.jar from the org.glassfish.main branch of the repositories.  I tried creating two wrapper modules, one for each, and using them in the RCP application.
In each module that uses classes from these wrappers, I added a provided dependency, based on the fact that I read that doing so keeps that wrapper module from being added to the current module.  I obviously need the reference to the wrapper module in order to compile my code.  After following this procedure, I get many ClassNotFound errors when trying to run the application. Adding them as compile dependencies removed the ClassNotFound errors, but then I get issues of the app trying to load a class from two different modules.
For anyone familiar with using gf-client.jar, you also need all of the module jars that are found in the $GLASSFISH_HOME/modules directory to be on the classpath.  Not sure how to wrap up this mess either.  I found a way around those problems by wrapping the glassfish-embedded-all.jar file, which contains everything needed, but again, compile dependencies in each module  and I end up with a 400MB application.  Using this method is the only way I have been able to get webservices working AND JMS.
So, my question really boils down to: how do you wrap a jar of jars (hundreds) and make them available to all requiring modules in an application?  Something that seems simple on its cover is turning out to be a nightmare for me.
Thanks.








--
http://timboudreau.com
Back to top
Boris Heithecker
Posted via mailing list.





PostPosted: Fri Nov 13, 2015 6:41 pm    Post subject: Wrapper Module - compile and provided dependencies? Reply with quote

Hello,yes, it's possible to use jms and remote ejb calls in a NetBeans RCP, an application has been running in a production environment for over a year now. 
In my experience, the only viable solution is adding glassfish-embedded-all as a library jar plus some adaption to the netbeans platform. The all-in-one distribution (glassfish-embedded-all-4.1.jar) is only one jar and 87MB, not 400, and you'll hardly get a smaller solution if you assemble a working jms message queue from scratch. 
Other solutions could be 1. launching an external glassfish installation in embedded mode - not possible because of netbeans classloader issues, 2. lauching an external gf installation as an osgi bundle from within nb - not possible because apache felix doesn't comply with the nb classloader system here, too. 
I've added glassfish-embedded-all-4.1.jar to a regular module as an additional wrapped jar (Project Properties -> Libraries -> Wrapped JARs tab) and exported only the official java ee API packages (Project Properties -> API Versioning). This leverages part of the Java EE APi to NB. On platform startup, a tiny glassfish domain (domain directory plus domain.xml with all unnecessary services removed) contained in the module sources under ModuleProjectDir/release is launched - using a custom adapted glassfish runtime builder for configuration of the running gf instance. 
To use jms, you have to add jms resources to the domain.xml, but it works even in rather poor network conditions. 
It's impossible to go into more detail at this place, because, after all, using java ee apis on top of the platform is an accumulation of many small solutions which can't be given here at full length. But our approach is definitely a viable solution, it's even possible to secure ejb remote calls and jms connections. 
For part of my remote database communication, secured webservices are used as well, but I've found out that these are definitely slower and could become a serious performance issue if you need quick responses to user activity. 
Hope this could help you,
Boris




2015-11-12 15:10 GMT+01:00 kpenrose <address-removed ([email]address-removed[/email])>:
Quote:
I have just started programming on the NetBeans RCP, using maven, trying to port some existing JavaFX applications into the platform.  The JavaFX applications are part of a suite of apps, so I thought it would be cool to allow them all to be modules which could be loaded into the platform as needed by each group of users.
The JavaFX apps rely heavily on JMS and of course database access.  Both of these led to huge problems for me on the RCP.  I found that adding the necessary jar files for remote EJB lookup to be very painful, so I switched to webservices (which is very easily done by adding the @WebService annotation to the beans - no need for Remote classes, etc.)  Integrating webservices into the RCP was relatively painless.
However, adding JMS has been another story - and it's still related to adding the necessary jar files to the project to allow the stand-alone application to access services housed in the glassfish 4.1 server.  I've tried adding gf-client.jar and imqjmsra.jar from the org.glassfish.main branch of the repositories.  I tried creating two wrapper modules, one for each, and using them in the RCP application.
In each module that uses classes from these wrappers, I added a provided dependency, based on the fact that I read that doing so keeps that wrapper module from being added to the current module.  I obviously need the reference to the wrapper module in order to compile my code.  After following this procedure, I get many ClassNotFound errors when trying to run the application. Adding them as compile dependencies removed the ClassNotFound errors, but then I get issues of the app trying to load a class from two different modules.
For anyone familiar with using gf-client.jar, you also need all of the module jars that are found in the $GLASSFISH_HOME/modules directory to be on the classpath.  Not sure how to wrap up this mess either.  I found a way around those problems by wrapping the glassfish-embedded-all.jar file, which contains everything needed, but again, compile dependencies in each module  and I end up with a 400MB application.  Using this method is the only way I have been able to get webservices working AND JMS.
So, my question really boils down to: how do you wrap a jar of jars (hundreds) and make them available to all requiring modules in an application?  Something that seems simple on its cover is turning out to be a nightmare for me.
Thanks.




Back to top
Boris Heithecker
Posted via mailing list.





PostPosted: Sun Nov 15, 2015 11:00 am    Post subject: Wrapper Module - compile and provided dependencies? Reply with quote

Forgot to say that: if, after all, you want to use a http-only solution, an alternative to jms could be a web sockets/async http framework. I've made good experience with atmosphere in a web application, but havn't so far tried to install it's java se client (wasycn?) in netbeans. It has a lot of dependecies, too, but maybe one could get it to work. Boris


2015-11-12 15:10 GMT+01:00 kpenrose <address-removed ([email]address-removed[/email])>:
Quote:
I have just started programming on the NetBeans RCP, using maven, trying to port some existing JavaFX applications into the platform.  The JavaFX applications are part of a suite of apps, so I thought it would be cool to allow them all to be modules which could be loaded into the platform as needed by each group of users.
The JavaFX apps rely heavily on JMS and of course database access.  Both of these led to huge problems for me on the RCP.  I found that adding the necessary jar files for remote EJB lookup to be very painful, so I switched to webservices (which is very easily done by adding the @WebService annotation to the beans - no need for Remote classes, etc.)  Integrating webservices into the RCP was relatively painless.
However, adding JMS has been another story - and it's still related to adding the necessary jar files to the project to allow the stand-alone application to access services housed in the glassfish 4.1 server.  I've tried adding gf-client.jar and imqjmsra.jar from the org.glassfish.main branch of the repositories.  I tried creating two wrapper modules, one for each, and using them in the RCP application.
In each module that uses classes from these wrappers, I added a provided dependency, based on the fact that I read that doing so keeps that wrapper module from being added to the current module.  I obviously need the reference to the wrapper module in order to compile my code.  After following this procedure, I get many ClassNotFound errors when trying to run the application. Adding them as compile dependencies removed the ClassNotFound errors, but then I get issues of the app trying to load a class from two different modules.
For anyone familiar with using gf-client.jar, you also need all of the module jars that are found in the $GLASSFISH_HOME/modules directory to be on the classpath.  Not sure how to wrap up this mess either.  I found a way around those problems by wrapping the glassfish-embedded-all.jar file, which contains everything needed, but again, compile dependencies in each module  and I end up with a 400MB application.  Using this method is the only way I have been able to get webservices working AND JMS.
So, my question really boils down to: how do you wrap a jar of jars (hundreds) and make them available to all requiring modules in an application?  Something that seems simple on its cover is turning out to be a nightmare for me.
Thanks.




Back to top
Tim Boudreau
Posted via mailing list.





PostPosted: Mon Nov 16, 2015 4:08 am    Post subject: Wrapper Module - compile and provided dependencies? Reply with quote

FWIW, if you're looking for an async http client, I wrote one:

https://github.com/timboudreau/netty-http-client



-Tim


On Sun, Nov 15, 2015 at 4:46 AM, Boris Heithecker <address-removed ([email]address-removed[/email])> wrote:
Quote:
Forgot to say that: if, after all, you want to use a http-only solution, an alternative to jms could be a web sockets/async http framework. I've made good experience with atmosphere in a web application, but havn't so far tried to install it's java se client (wasycn?) in netbeans. It has a lot of dependecies, too, but maybe one could get it to work. Boris


2015-11-12 15:10 GMT+01:00 kpenrose <address-removed ([email]address-removed[/email])>:
Quote:
I have just started programming on the NetBeans RCP, using maven, trying to port some existing JavaFX applications into the platform.  The JavaFX applications are part of a suite of apps, so I thought it would be cool to allow them all to be modules which could be loaded into the platform as needed by each group of users.
The JavaFX apps rely heavily on JMS and of course database access.  Both of these led to huge problems for me on the RCP.  I found that adding the necessary jar files for remote EJB lookup to be very painful, so I switched to webservices (which is very easily done by adding the @WebService annotation to the beans - no need for Remote classes, etc.)  Integrating webservices into the RCP was relatively painless.
However, adding JMS has been another story - and it's still related to adding the necessary jar files to the project to allow the stand-alone application to access services housed in the glassfish 4.1 server.  I've tried adding gf-client.jar and imqjmsra.jar from the org.glassfish.main branch of the repositories.  I tried creating two wrapper modules, one for each, and using them in the RCP application.
In each module that uses classes from these wrappers, I added a provided dependency, based on the fact that I read that doing so keeps that wrapper module from being added to the current module.  I obviously need the reference to the wrapper module in order to compile my code.  After following this procedure, I get many ClassNotFound errors when trying to run the application. Adding them as compile dependencies removed the ClassNotFound errors, but then I get issues of the app trying to load a class from two different modules.
For anyone familiar with using gf-client.jar, you also need all of the module jars that are found in the $GLASSFISH_HOME/modules directory to be on the classpath.  Not sure how to wrap up this mess either.  I found a way around those problems by wrapping the glassfish-embedded-all.jar file, which contains everything needed, but again, compile dependencies in each module  and I end up with a 400MB application.  Using this method is the only way I have been able to get webservices working AND JMS.
So, my question really boils down to: how do you wrap a jar of jars (hundreds) and make them available to all requiring modules in an application?  Something that seems simple on its cover is turning out to be a nightmare for me.
Thanks.













--
http://timboudreau.com
Back to top
kpenrose



Joined: 18 Jan 2012
Posts: 18

PostPosted: Fri May 12, 2017 2:12 pm    Post subject: Re: Wrapper Module - compile and provided dependencies? Reply with quote

Boris,
It's been a while since I started this project, and I had switched to using webservices because they were so easy to implement and they worked rather well with the NetBeans RCP application. However, as I'm sure you know, there are some limitations to what you can do with webservices, and I have started to try to replace them with EJBs. As I'm sure you're also aware, calling remote EJBs from Netbeans platform apps is a real pain, and I notice that you have done just that.
I've built and deployed the ejb's on my glassfish server (4.1), and I can access them and retrieve data from stand-alone, command line apps with no problem. I've become very proficient at bundling the correct libraries and putting it all together in a netbeans platform application. I have no problem getting an initial context, and querying the context for all of the available jndi entries. However, when I try to do a look-up on any of those jndi entries, I get a naming exception, even though I got the jndi name directly from the server. I have tried with both portable and non-portable names created by the glassfish server. Nothing works. I have the glassfish libraries and the ejb libraries all packaged into one netbeans module. When I attempt the lookup, there are no errors on the server side, and only the naming exception in the netbeans client.
There are many stories on the web from people who have exactly the same problem, but there doesn't seem to be a solution other than switching to JBoss or WebSphere or some other costly solution. I have even tried the Payara (Glassfish) server to no avail.
If you do indeed, have this puzzle figured out, I would love to hear what you do did to accomplish this herculean feat! Please do share. I'll provide any information you need as to what I've done to get to this point, and hopefully you can provide the missing piece to get me to the promised land.

Thanks!

Boris Heithecker wrote:
Hello,yes, it's possible to use jms and remote ejb calls in a NetBeans RCP, an application has been running in a production environment for over a year now. 
In my experience, the only viable solution is adding glassfish-embedded-all as a library jar plus some adaption to the netbeans platform. The all-in-one distribution (glassfish-embedded-all-4.1.jar) is only one jar and 87MB, not 400, and you'll hardly get a smaller solution if you assemble a working jms message queue from scratch. 
Other solutions could be 1. launching an external glassfish installation in embedded mode - not possible because of netbeans classloader issues, 2. lauching an external gf installation as an osgi bundle from within nb - not possible because apache felix doesn't comply with the nb classloader system here, too. 
I've added glassfish-embedded-all-4.1.jar to a regular module as an additional wrapped jar (Project Properties -> Libraries -> Wrapped JARs tab) and exported only the official java ee API packages (Project Properties -> API Versioning). This leverages part of the Java EE APi to NB. On platform startup, a tiny glassfish domain (domain directory plus domain.xml with all unnecessary services removed) contained in the module sources under ModuleProjectDir/release is launched - using a custom adapted glassfish runtime builder for configuration of the running gf instance. 
To use jms, you have to add jms resources to the domain.xml, but it works even in rather poor network conditions. 
It's impossible to go into more detail at this place, because, after all, using java ee apis on top of the platform is an accumulation of many small solutions which can't be given here at full length. But our approach is definitely a viable solution, it's even possible to secure ejb remote calls and jms connections. 
For part of my remote database communication, secured webservices are used as well, but I've found out that these are definitely slower and could become a serious performance issue if you need quick responses to user activity. 
Hope this could help you,
Boris




2015-11-12 15:10 GMT+01:00 kpenrose <address-removed ([email]address-removed[/email])>:
Quote:
I have just started programming on the NetBeans RCP, using maven, trying to port some existing JavaFX applications into the platform.  The JavaFX applications are part of a suite of apps, so I thought it would be cool to allow them all to be modules which could be loaded into the platform as needed by each group of users.
The JavaFX apps rely heavily on JMS and of course database access.  Both of these led to huge problems for me on the RCP.  I found that adding the necessary jar files for remote EJB lookup to be very painful, so I switched to webservices (which is very easily done by adding the @WebService annotation to the beans - no need for Remote classes, etc.)  Integrating webservices into the RCP was relatively painless.
However, adding JMS has been another story - and it's still related to adding the necessary jar files to the project to allow the stand-alone application to access services housed in the glassfish 4.1 server.  I've tried adding gf-client.jar and imqjmsra.jar from the org.glassfish.main branch of the repositories.  I tried creating two wrapper modules, one for each, and using them in the RCP application.
In each module that uses classes from these wrappers, I added a provided dependency, based on the fact that I read that doing so keeps that wrapper module from being added to the current module.  I obviously need the reference to the wrapper module in order to compile my code.  After following this procedure, I get many ClassNotFound errors when trying to run the application. Adding them as compile dependencies removed the ClassNotFound errors, but then I get issues of the app trying to load a class from two different modules.
For anyone familiar with using gf-client.jar, you also need all of the module jars that are found in the $GLASSFISH_HOME/modules directory to be on the classpath.  Not sure how to wrap up this mess either.  I found a way around those problems by wrapping the glassfish-embedded-all.jar file, which contains everything needed, but again, compile dependencies in each module  and I end up with a 400MB application.  Using this method is the only way I have been able to get webservices working AND JMS.
So, my question really boils down to: how do you wrap a jar of jars (hundreds) and make them available to all requiring modules in an application?  Something that seems simple on its cover is turning out to be a nightmare for me.
Thanks.




Back to top
Display posts from previous:   
Post new topic   Reply to topic    NetBeans Forums -> NetBeans Platform Users All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo