Ofbiz hot-deploy not firing - deployment

I added an ofbiz component in the hot-deploy folder.
This is a working component (fired it in the browser and all works just fine). However, after inspecting the documentation I would expect the ofbiz run-time environment to identify the new changes in java files and fire a hot deploy for the newly changed component.
I also added in ofbiz_home/framework/base/config/ofbiz-containers.xml the following property:
<property name="apps-context-reloadable" value="false"/>
Despite all this, the hot-deploy is not fired and I have to stop and restart the whole ofbiz application in order to see the changes made in the java files.
What am I missing? Thank you!

Hot-deploy means it doesn't require you adding the component to a component-load.xml as in applications and framework folders. If you change java files, you still have build the component and restart OFBiz. It will pick up xml and ftl files though, you might have to clean the cache, that's all.

Related

JavaEE Servlet won't hot deploying

I started working with javaEE and currently doing some basic servlet stuff. So I'm using Eclipse neon and GlassFish server. Created a dynamic web project and everything works fine.
The problem are servlet file changes. If there is a change in the java file nothing happens - no hot deploying/ republish. I have to complete remove the application from server and re add it to see the changes.
Changing .html files works (doesn't effect servlets changes)
Rebuild does nothing
Server "clean" does nothing
Server restart does nothing
"Automatically publish when resources change" is of course on, hence the html changes
The problem might be, that it does not observe the correct files for triggering the redeployment.
I haven't tried it for GlassFish, but could see the same behavior for WildFly as you described with the default server settings.
Try to add \.class$ to section Application Reload Behavior in server settings. (This will be the case for exploded deployment.)
Credits to varantes answer in this question

Make per-context JNDI variable available to Tomcat in Eclipse

I'm using Tomcat 8.5.6 inside Eclipse 4.6.1. I have my web-app project/context foo, which has a JAX-RS (using RESTEasy 3.1.0.CR3) endpoint of bar, so I can fire up Tomcat inside Eclipse and access:
http://localhost:8080/foo/bar
I have a variable named foobar which I want to access inside my JAX-RS implementation using JNDI:
final String foobar = (String) new InitialContext().lookup("java:comp/env/foobar");
I plan on deploying the produced WAR in production using Tomcat autodeploy. I want to configure the foobar variable for Tomcat externally to the WAR. How can I do that so that I can test it in Eclipse?
After a lot of reading, I found what I thought to be the $CATALINA_HOME of Eclipse: …\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\. So I created a context file for foo at …\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\conf\Catalina\localhost\foo.xml to correspond to my project/context, and put the following inside it:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<Environment name="foobar" type="java.lang.String" value="123"/>
</Context>
Yes, I know that Eclipse erases this directory whenever I rebuild. But after building, I saved to file at least want to see if it works. It doesn't. I get an error:
javax.naming.NameNotFoundException: Name [foobar] is not bound in this Context. Unable to find [foobar].
I want to at least get it working so I can know how to do this in production, and worry later about the context file deletion thing in Eclipse. So what did I do wrong? Why can't Tomcat in Eclipse find this JNDI variable?
Note: I am not using a web.xml file and have no desire to do so; besides, this variable should be defined outside the WAR in the production deployment.
Update: The good news is that (on Windows 10 Professional Anniversary Edition 64-bit) using the same Tomcat but in standalone mode, I put the same foobar.xml file inside the standalone Tomcat's conf\Catalina\localhost\foo.xml, and my JAX-RS application picked it up just fine. So how can I define a JNDI variable in Tomcat inside Eclipse for testing?
It appears that in order to get Eclipse+Tomcat to recognize the per-module context files, you have to go into the server configuration (double-click on the server) and turn on the Publish module contexts to separate XML files. This way Tomcat will use the specific context XML file you created. Otherwise it apparently puts them in conf/server.xml and ignores the context-specific file you created.
There is still the problem that Eclipse regenerates this file each time you do a rebuild, destroying whatever JNDI variables you placed there. I'm trying to get the workaround in https://stackoverflow.com/a/22380248/421049 to work, but not yet succeeding. Anyone have any better ideas?
At least I'm able to reproduce a production environment now --- albeit temporarily, until the next rebuild.
Your link to Markus' answer on https://stackoverflow.com/a/22380248/1794485 allowed me to get this working, or at least as described in his workaround. But the remaining problem to solve was ordering.
As he said, you can workaround this by having a local copy of the META-INF/context.xml somewhere else, and adding this folder to the Deployment Assembly in the project properties of the Eclipse project.
This didn't pick up for me initially though. It looks like that while the Deployment Assembly in the properties shows as sorted by name, in fact it has an order like any other path. When I then removed the src/main/webapp entry (so the one containing the normal META-INF/context.xml) and added it back in, this effectively moved it down the pecking order. The next Tomcat deploy and startup in Eclipse finally put my preferred copy of META-INF/context.xml in .metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\myapp\META-INF
If in doubt about the true sequence of that Deployment Assembly path, have a look under your Eclipse project on the file system - at .settings\org.eclipse.wst.common.component.

Is there any way of configuring Oracle ATG to load java class changes dynamically?

I am interested in setting up a development environment for ATG in which changes on class will take effect immediately after the build is done, without restarting server and building again the ear file.
I have searched in the product documentation but the only thing I saw you can configure to load dynamically would be the configuration files section.
Is there any other way of configuring the environment for better productivity?
Use JRebel. That will do dynamic re-loading for java classes, property files and other deployable assets. Great for productivity.
If your purpose is to debug and most of time is getting wasted packing and unpacking the ear, you can always use remote debugging with JBoss and Eclipse, but for major changes like adding a method wont be working in that case. One solution to this is use Java DCEVM which will dynamically update code in the JVM. Its a simple jdk just point your Java_home to this jdk and in debug mode you can add code to you class see changes. Use the below link for more information about DCEVM
https://github.com/dcevm/dcevm

Getting Eclipse to automatically reload the JSP pages in my Java web application

I was given a template of a Struts project to work on, and I noticed that when I run the web project on integrated Tomcat in Eclipse and make changes to the .jsp viewpages, they don't automatically reload after a few seconds - which does happen in other projects I made myself.
So I figured this was a configuration issue and I did some research, I had a look at my Tomcat server settings:
(x) Automatically publish when resources change (1 second interval)
But because my own projects reload and I use the same server for them, I figured it must be an application specific issue.
So I looked at context.xml to see if there was anything to change here
<Context
...
reloadable="true"
...
>
Which I can only assume tells the server to indeed reload the application on changes.
So I really can't figure it out. It seems to me like everything is in order here. What am I missing?
From Apache Tomcat documentation about the Context attributes:
reloadable
Set to true if you want Catalina to monitor classes in
/WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically
reload the web application if a change is detected. This feature is
very useful during application development, but it requires
significant runtime overhead and is not recommended for use on
deployed production applications. That's why the default setting for
this attribute is false. You can use the Manager web application,
however, to trigger reloads of deployed applications on demand.
Also maybe this will be interesting for you: Using Tomcat Reload Features To Speed Up Development
I ran into the same problem, with a Java/Spring project that I imported via its Maven .pom files into Eclipse.
I found that I had to run the project with "Debug" instead of "Run" - only then, changes to my .jsp files were noticed, so that a reload of the web page would show the changes almost instantly.

Can I update the HTML files using Wicket and Eclipse without recompiling the classes?

I'm using Eclipse and Maven-2 and I'd like to be able to edit my HTML files without "it" (not sure if it's Eclipse or Maven) recompiling my application. I understand that usually Eclipse tries to do a hot replace of new compiled Java classes with Eclipse and Tomcat.
Can I use something like this?
getResourceSettings().setResourcePollFrequency(null);
I know I can turn auto update off for Tomcat in Eclipse but I'd like the HTML file to update and the classes not to update if possible.
BTW, my primary concern is that Tomcat tends to get Perm gen errors after I (hot) reload too many java classes.
You're sort of correct, you're supposed to use setResourcePollFrequency(Duration.ONE_SECOND); or similar. This link has more detailed information. However what I've found is that due to Wicket's caching internal cache containers like to get really messed up after any hotswapping so you may just have to learn the hotkey for restarting Tomcat or start doing Wicket development with the integrated Jetty and WicketTester.
You may want to consider increasing the permgen space when you run eclipse. There is a command line argument:
eclipse [normal arguments] -vmargs -XX:PermSize=64M -XX:MaxPermSize=128M
(copied from:)
http://wiki.eclipse.org/FAQ_How_do_I_increase_the_permgen_size_available_to_Eclipse%3F
I am not sure offhand how to prevent wicket from reloading HTML files but I will see if I can find it.
Edit:
If setting the poll frequency to null doesn't work, try using Duration.MAXIMUM. Also, you can uncheck "Build Automatically" in the eclipse Project menu, though this is more of a hassle then it's worth, IMHO.
According to the wicket FAQ, wicket only reloads changed markup files when you explicitly set the resource poll frequency:
http://www.wicketframework.org/faqs.html
I am not sure how to prevent eclipse from copying altered files to the output aside from disabling build automatically.
If Build Automatically is enabled (it is by default: Project->Build Automatically) then any modification to the project files will trigger the build, regardless of whether they are in source folders or not.
I always work with Build Automatically disabled as I find it too intrusive (for reasons like this), and just hit ctrl-B when I want the project to build, or alt-P N to launch the clean dialog if needed.
I understand you're using (and might want to keep using) Tomcat, but during Wicket development you can run the supplied Jetty server onder /src/test/java/com/your/package/Start.java in debug mode to get this behaviour.. Set Wicket to development mode to use this feature.
HTML files or jsp files?
Are you using tomcat? If you are editing only html files, go ahead and change them as you wish. As long as you don't deploy them somewhere else for tomcat to fetch them, you'll see the update(s).
If it's jsp, save your new file, delete the files under the old work folder. This will make tomcat think it's the first time the file is requested and it will re-compile the jsp on the fly.