I am using version 3.0.0 of STS, and whenever I open a load of projects or do a build it is giving the message:
validating element <element here> with rule '#required property rule'
or similar messages
It is taking around two or three seconds per bean, and is going through every class file in my hierarchy. This can take around 45 minutes for larger projects.
Are there any configuration settings which could help with this?
It could be a lack of memory causing the problem. I'd try bumping up your Xmx to 1024m (default is 768m). You can change this setting in your STS.ini. It is colocated with the STS executable.
Related
I am using following command to deploy code to my AEM instance "mvn clean install -Daem.host=localhost -Daem.port=1202 -Dmaven.test.skip=true
"
After deployment pages are taking too long to load at least 7 mins.
I found No errors/Exceptions in error log.
There could be couple of factors causing this slowness -
Amount of memory allocated to AEM instance, default setting is - CQ_JVM_OPTS='-server -Xmx1024m -XX:MaxPermSize=256M -Djava.awt.headless=true' which is actually not sufficient for optimal performance. I have been using double of this configurations and sometimes even more.
When you deploy your package with code, the bundles are processed and services are registered. Depending on number of services/components being registered the time can go up. Sometimes there are hooks within code that cause few system level bundles to cycle as well, if that happens it would actually cause all the other bundles dependent on system bundle to cycle and registering the services again.
your code deployment could be triggering some workflow that either consumes lot of resources or is causing delayed activation on your bundle. The first scenario could happen if your deployment has something like images which when deployed causes OOTB image workflow to trigger (there could be other based on your code). Second scenario could be that you have bundle activator either waiting for another bundle which gets deployed later (and/or stays installed and not active) or you are building some sort of caching that waits for pages to be deployed and processed. There are countless such scenarios that can cause this issue.
What you could do is check the status of the bundles in /system/console/bundles pre and post deployment you can identify bundle related issues there. Another thing you could try is to do selective deployment of the code to figure out what module is causing issue that then dive deeper in to that module.
Also look at recent request logs to identify the flow of page load to see if there are services, filters etc in picture that are causing delays.
Let me know if any of this approach helps you identify the root cause and in case you need further help, will be here to assist.
I am trying to use eclipse kepler for Java EE 7.I already installed JBoss Tools and added JBoss Wildfly successfully as a server. However my changes are not automatically deployed. Is there anyway the app can be deployed automatically just as when using glassfish?
Using Eclipse, click twice on your WildFly Server to edit the following properties:
Publishing: choose "Automatically publish after a build event". I like to change the publishing interval to 1 second too.
Application Reload Behavior: check the "Customize application reload ..." checkbox and edit the regex pattern to \.jar$|\.class$
That's it. Good luck!
Both #varantes and #Sean are essentially correct, but these answers are not full.
Unfortunately the only way in a Java server environment to have full, zero-downtime hot deployment is to use paid JRebel or free spring-loaded tool.
But for small project there are some ways to speed up work by partial hot-deployment. Essentially:
When enabled option Automatically publish when resource change
then changes inside *.html, *.xhtml files are immediately
reflected as soon as you refresh the browser.
To make hot deployment work for *.jsp files too, then you should
inside ${wildfly-home}/standalone/configuration/standalone.xml
make following change:
<jsp-config/>
replace with:
<jsp-config development="true"/>
restart the server and enjoy hot deployment of web files.
But when modifying *.java source files, then only partial hot deployment is possible. As #varantes stated in his answer, enabling Application Reload Behavior with regex pattern set to \.jar$|\.class$ is an option, but has serious downside: whole module is restarted, thus:
It takes some time (depending on how big is a module).
Whole application state is lost.
So personally, I discourage this solution. JVM supports (in debug mode) code-swapping for methods' bodies. So as long as you are modifying only bodies of existing methods, you are at home (zero downtime, changes are reflected immediately). But you have to disable automatic publishing inside server settings otherwise the application's state will still be destroyed by that republish.
But if you are heavily crafting Java code (adding classes, annotations, constructors) then unfortunately I can only recommend set publishing into Never publish automatically (or shutdown server) and when you finish your work in Java files, then restart by hand your module (or turn-on server). Up to you.
It works for small Java projects, but for bigger ones, JRebel is invaluable (or just spring-loaded), because all approaches described above are not sufficient. Also because of such problems, solutions like Rails/ Django /Play! Framework gained so huge popularity.
I am assuming you are using the latest version of Wildfly (8.0 Beta 1 as of writing).
In the standalone.xml config file, look for <jsp-config/>. Add the attribute development="true" and it should hot-deploy. The resulting config will look like this:
<jsp-config development="true"/>
Add attributes (development, check-interval, modification-test-interval, recompile-on-fail) in configuration file in xPath = //servlet-container/jsp-config/
<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
<jsp-config development="true" check-interval="1" modification-test-interval="1" recompile-on-fail="true"/>
</servlet-container>
(It works in WildFly-8.0.0.Final)
Start server in debug mode and It will track chances inside methods. Other changes It will ask to restart the server.
We use Eclipse (Indigo, with STS). Certain of our projects take inordinately long to build. Often the progress indicator sticks on, say, 87%, for 30 seconds.
I'm trying to find out what Eclipse is spending it's time on during the build cycle. I hope to be able to optimize the build or disable components that are causing it to be so slow. I'd like to see a log file saying ("compiling java code", "processing resources", etc).
I've poked around the log files in the .metadata directory. I've looked on the Eclipse site for tips. I've tried using "-debug" when starting Eclipse. I still can't find the information I'm looking for.
Is there any way to get Eclipse to spit out a log of what activities it is spending its time on when it builds a project?
What kind of projects are these? Java? Dynamic Web? Two things to look at for hints about what's going on are in the project Properties dialog; look at the Builders section and the Validation section. Try disabling the validations to see if that makes a difference in your build times.
To get some insight into what's happening at the times when the build seems to hang, try setting the -debug and -consoleLog options, as described here.
Disable your virus scanner software for your workspace and project directories. I increased the speed of my build in that way.
You can go to edit Windows->preference->general->workspace->build order to edit the default that exist according to your project need.
And check the maximum number of iteration when building with cycle.
I hope it works.
Since eclipse is a Java application, the usual debugging tools are at your disposal. In particular, you might try connecting to eclipse with JConsole and inspect the thread dump taken when the build "hangs", or run eclipse within a profiler.
You might find out things like a validator trying to download an xml schema, and waiting for the timeout since eclipse is not configured to use the corpoate proxy server - something which is very hard to find out by other means ;-)
Look into Apache Ant build scripts. Eclipse has support to auto generate them as a starting point instead of coding the whole thing by hand. The shop I worked in used tuned ANT scripts to optimize and control build order. We then piped output to log files using shell scripts.
You can try and replace with this aapt . My build for a particular project went from 3 minutes to 41 seconds....
This is an old post but thought of sharing my solution. I was using eclipse Luna and I noted that when you keep on working on a GIT branch without checking into git over the time the build becomes very slow. In my case I just deleted the folder .git and the file .gitignore and the build was very fast. Please note that this will disconnect eclipse from git, therefore use this aproach only if you know how to connect back to git branch using git commands.
I'm running GWT from within IntelliJ. (Plain GWT, IntelliJ v9). I'm able to run my application via my "GWT development mode" configuration, but when I try to run it through my "local tomcat" configuration, I get a bunch of incomprehensible error messages referring to Oracle and all sorts of weird stuff that I don't use, followed by this error which is sorted to the bottom of all the others:
Error: Out of memory; to increase the amount of memory, use the -Xmx flag at startup (java -Xmx128M ...)
I'm guessing that this error is the root cause.
According to my understanding, there is a GWT compilation step which runs in a JVM separate to both IntelliJ and tomcat, and so I'm unsure where to set the -Xmx parameter.
My question is: where do I find this -Xmx parameter? (And: am I on the right track, taking this error message at face value, or is it a symptom of deeper problems?)
You can configure the heap in the GWT facet settings:
As CrazyCoder just said you can increase the amount of memory for gwt compiler in the GWT Facet settings. The GWT Compiler running out of memory on bigger apps is very common if you don`t increase the amount of memory. Most projects should be fine with 512m, but on large projects I already needed more memory.
So this is not some out of memory error caused by some bad design on your behalf.
In my application, I set it to 1024 but it gives me out of memory after 7-9 page refresh on dev mode. And after that I tried it to optimize by doing performance hack, I separated my *.gwt.xml for every gwt module for specific browsers by setting:
MySampleModule_FF.gwt.xml
<set-property name="user.agent" value="gecko1_8"/>
And I run my dev mode with this gwt.xml for Firefox. In addition to it also separated internationalization as well.
After that my out of memory issues considerably decreased.
32 bit JDK also sometimes causes Out Of Memory error. Try using 64 bit JDK.
To those who get the same error under Eclipse, try to restore cache files (if they were removed accidentally in WAR folder ), this way I solve the same problem under my Eclipse project.
I just spent a half hour debugging some new code that's not broken because I forgot to check (again!) my logs for this dreaded message:
WARN openjpa.Enhance - Creating subclass for ...
I'm running OpenJPA 2.1.0 inside an OpenEJB 3.2 snapshot build, Java 1.6.0_25, and Eclipse Helios. My entities are enhanced using the ant PCEnhancerTask.
My META-INF/openjpa.xml contains
<property name="openjpa.RuntimeUnenhancedClasses" value="unsupported" />
<property name="openjpa.DynamicEnhancementAgent" value="false" />
Is there anyway with this EE configuration to have OpenJPA enforce the RuntimeUnenhancedClasses option as it does in an SE configuration?
I suspect my 'real' problem stems from an Eclipse svn update that sometimes touches my JPA entity source, causing a build that overwrites my enhanced classes.
It's frustrating how often I run a unit test from the IDE that fails in some weird way, and I go digging through my code looking for a problem when all I need to do is run the enhancer.
Put the <property name="openjpa.RuntimeUnenhancedClasses" value="unsupported" /> META-INF/persistence.xml.
Looks like we're logging this action on debug level (maybe it should be info level), but OpenEJB will set that property to the default as it was in OpenJPA 1.x so that apps that worked with OpenEJB 3.1.x/OpenJPA 1.x will still work without modification in 3.2.x. If the property is already set in the persistence.xml it will never be overridden, so setting it there will have the effect you want.
Open to suggestions on how to save others in the same boat some time in the future. Seems either looking in the openjpa.xml file and seeing the property set already or issuing the log message on info would do it -- or both.
It sounds like for whatever reason your properties aren't being picked up when running in the container.
I have a number of possible solutions:
Try setting your properties in META-INF/persistence.xml. I assume you have these properties in the openjpa.xml file for a reason, but it might help us figure out where the real problem is.
Set -Dopenjpa.RuntimeUnenhancedClasses=false as a JVM property. This will apply to all PUs for a given JVM.
Move to a version of OpenJPA that is >= 2.0.0. RuntimeUnenhancedClasses was turned off as the default behavior in that release.