Sorry for the delayed response. netccdfAll.jar is build in a special way, but is not pushed to our maven repo because it doesnt fit into mavens "one artifact per module" rigidity. We are moving to gradle and will fix that eventually. John > John- > > I experimented with changing the netCDF code to use a different method of > class loading, which did not make any difference. However, I tried using > your netcdfAll.jar and that corrected the problem! Thanks a lot for the > recommendation. Can I get the netcdfAll.jar from the > http://artifacts.unidata.ucar.edu/content/repositories/unidata-releases > maven repository or am I going to have to install it for maven? What would > the group and artifact ids be if I can get it from the repo? Thanks again > for all your help, I really appreciate it. > > -Todd Harrison > > > On 8/20/14, 1:53 PM, "Unidata netCDF Java Support" > <address@hidden> wrote: > > >Hi Todd: > > > >We have never tried the mule "hot load" thing. However, what we do in the > >java library is very common so there must be a workaround. > > > >What if you explicitly load the jars yourself into whatever class loader > >handles this correctly? > > > >What if you use a single jar like netcdfAll.jar? eg: > > > > ftp://ftp.unidata.ucar.edu/pub/netcdf-java/v4.5/netcdfAll-4.5.jar > > > >Id be interested in what you find out. > > > >John > > > >> As a follow up, it appears after some research that the issue may be > >> related to how you load classes at runtime. This would be specifically > >> with the use of Class.forName(). > >> > >> Please refer: > >> > >> http://blog.osgi.org/2011/05/what-you-should-know-about-class.html > >> > >> "Class.forName is Evil - Class.forName will pin classes in memory > >>forever > >> (almost, but long enough to cause problems). If you're forced to do > >> dynamic class loading use ClassLoader.loadClass instead. All variations > >> of the Class.forName suffer from the same problem. See BJ HargraveÂs > >>blog > >> about this. > >> > >> -Todd > >> > >> From: <Harrison>, Todd Harrison > >><address@hidden<mailto:address@hidden>> > >> Date: Tuesday, August 19, 2014 at 11:12 AM > >> To: > >>"address@hidden<mailto:address@hidden > >>ucar.edu>" > >><address@hidden<mailto:address@hidden > >>ucar.edu>> > >> Subject: Hot Deployment Issue > >> > >> I am attempting to use netcdf in a mule ESB flow to process GRIB1 and > >>GRIB2 files. When I undeploy the application I find that specific > >>libraries are still locked by the java execution environment: > >> > >> Â Jdom2-2.0.4.jar > >> > >> Â Joda-time-2.2..jar > >> > >> Â Jsoup-1.7.2.jar > >> > >> Â Netcdf-4.3.22.jar > >> > >> Â Protobuf-java-2.5.0.jar > >> > >> Â Quartz-2.1.1.jar > >> > >> Â Udunits-4.3.22.jar > >> These seem to be locked as a result of running the netcdf > >>functionality. Unfortunately, this prevents me from being able to hot > >>deploy the mule application because these jars cannot be deleted unless > >>the entire mule process is restarted. I have a business requirement to > >>support hot deployment. I thought that it might be related to not > >>releasing the netcdf resources, but IÂm executing netcdfFile.close(); at > >>the end of my processing. Are there any other resources that are kept as > >>static references that I need to be aware of? Thanks for your assistance. > >> > >> Todd Harrison<mailto:address@hidden> > >> Lockheed Martin IS&GS > >> (303) 932-4607 > >> > >> > > > >Ticket Details > >=================== > >Ticket ID: SVV-295336 > >Department: Support netCDF Java > >Priority: Normal > >Status: Closed > > > > Ticket Details =================== Ticket ID: SVV-295336 Department: Support netCDF Java Priority: Critical Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.