NB7, GF3.1, JSF2/Primefaces2 catastrophe

[zzion]

There are several issues with NB7 and Glassfish 3.1 (on Win7/32, 3.5GB, DualCore).

It's my first experience with both progs, only used J2SE and Eclipse before - which also has it's flaws but was much more usable compared to what I experienced with NB in the last months.

So I don't know if it's normal, but a project with only some dozen classes takes about 10 to 20 seconds to deploy to an already running local glassfish. I would expect it to be faster.

Very often I get an "java.io.IOException: error while creating temp folder for data transfer" (translated from german) at the end of deployment. I can ignore it without any issues but it's still an error.

At least once per day, an out of memory for the PermGen appears while deploying. When that happens, GF can only be terminated by shutting it down via the OS.

Sometimes some project files are gone or don't work:
- this part from build-impl.xml may crash and work only after several redeploys:
[target if="netbeans.home" name="-run-deploy-nb"]
[nbdeploy clientUrlPart="${client.urlPart}" debugmode="false" forceRedeploy="${forceRedeploy}"/]
[/target]
- About once per week the granted.policy can't be generated anymore, an empty file with that name needs to be put in the correct GF folder.

The error messages when programming with JSF sometimes are just like "somewhere there's a nullpointer". I don't know if it's really impossible to locate them but that doesn't speed up developing.

Some NB only issues:
I'm using JSF2 and one cool thing about NB is the code completion for the xhtml part. Unfortunately this doesn't work when using 'ui:include'. No Java stuff is found/shown anymore in those xhtml files.

The SVN client in NB is a joke:
- Moving or refactoring classes/packages can destroy a project.
- As soon as there are local modifications in a file, the client doesn't show remote changes for this file.
- Merging is a nightmare. Very often the client even marks the whole file as different, so no merging possible.
I strongly recommend looking at subclipse which is centuries ahead in everything.

The general speed of the IDE is noticeable slower than Eclipse. For instance when there is a compile error and I correct it, it can take seconds until the IDE notices the correction. Not every time, though. (My PC isn't the fastest, but I can compare Eclipse vs. NB )

I wonder why there's still no 'systr(ace)' like in Eclipse. That's a matter of seconds to implement but ignored since 2008 and longer. (http://netbeans.org/bugzilla/show_bug.cgi?id=148947). That would speed up debugging a lot, when output is preferred over step by step debugging.

[jyeary]

I have sooooo many problems on Windows 7 that I use my mac, or even more disturbing... I use Virtual Box on my Windows 7 machine with SolarisExpress and NB with GlassFish. I have no problems with NB, GF, or Primefaces on either Mac or SolarisExpress. It says something about Windows...

On Fri, Jul 29, 2011 at 11:00 AM, zzion <address-removed ([email]address-removed[/email])> wrote:

[mdeggers]

In general, I find developing on Windows to be painful. I tend to stick with
Linux while developing (running Fedora 15 at the moment).

On your PermGen problem, it sounds like you have an application issue.

Read the following and use something like VisualVM to investigate your application.

http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java

On not being able to shut down Glassfish without an OS reboot, this
sounds like a Windows issue plus jar locking plus the possibility of a user
thread you're not cleaning up.

In Tomcat you can add an antiJarLocking attribute in a file called
context.xml. This will help with Windows and potential jar locking. I don't
know what the equivalent is for Glassfish.

If you're using locally generated threads in your application make sure
to clean them up and kill them off properly when your application exits.
User threads not properly taken care of can prevent the JVM from exiting.
Tomcat (since 6.0.18 I think) kills these threads for you and provides an
error message in the logs. Again, I don't know how Glassfish handles
thread issues.

I also find using Glassfish to be a bit cumbersome. I only use it when
developing EJB code. Otherwise I happily use Tomcat 7 installed separately.

I'm not sure what the status of Jetty is with JSF 2, but it's also worth a
look. One of the nice things about Jetty is its integration with Maven.
Maven plus Jetty plus NetBeans makes for an almost seamless continuous
development environment.

Read the following for pointers, although it's a bit dated and framework
specific.

http://www.troymaxventures.com/2009/05/rad-w-tapestry-5-netbeans-67-maven-and.html

I also find the NetBeans svn client to be not intuitive. On Windows I'll
end up using TortiseSVN. On Linux I prefer the command line or KDE's
ksvn.

I have found that NetBeans 7 is subjectively a bit slower than NetBeans
6.9.1 for many of the things I do. This is true even though I have more
plugins loaded in 6.9.1 than I do in 7. Unfortunately, I cannot develop
for Tomcat 7 and servlet 3.0 in NetBeans 6.9.1. Also unfortunately I cannot
develop portlets conveniently in NetBeans 7.0. I end up running both.

Hopefully NetBeans 7.0.1 will improve performance.

I periodically try Eclipse, and usually quickly return to NetBeans. I find
managing plugins in Eclipse to be really unpleasant when compared to
NetBeans. I also find Eclipse's project layout to be not as intuitive as
NetBeans. I guess that's because I come from an Ant (roll your own) and
Maven background. I can coerce Eclipse to do the right thing, but I would
rather not.

Your mileage may (and sounds like it does) vary. I suggest that you take
a look at your application for the permgen and failure to stop Glassfish
issues.

You might also try programming on Linux (or as another poster
suggested a Macintosh). I find that I get a subjective 20% improvement
in performance on the same hardware when moving from Windows to
Linux.

. . . . just my two cents.
/mde/

[zzion]

Thx for the long reply!

[mdeggers]

Did you read the link I put in my previous post? Out of permgen space
(especially due to multiple application reloads) is almost always an
application coding issue.

If you've written an application that registers an object with a class loaded
in a different class loader, none of the classes referencing that object
can be garbage collected. Sooner or later you'll run out of permgen
space, depending on how much you started with, how big your objects
are, etc.

To illustrate this, I followed the example given in the reference I posted
and wrote a little leaking application. While this was written for Tomcat, it
will happily run (and leak) on Glassfish 3.1. You'll have to change the log
location in logging.properties.

To see the leak, do the following.

1. Build the application (it's a Maven project, so this may take you a bit)
2. Start up Glassfish
3. Use visualvm (or another tool) and take a heap dump
4. Deploy the war file
5. Run the application - it does nothing but log messages
6. Take another heap dump
7. Undeploy the application
8. Take another heap dump

In step 3, you will obviously see no classes related to the application.
In step 6, you will obviously see classes (org.mdeggers.leakcl)
In step 8, you shouldn't see classes (but you will!)

This will illustrate the leak. If you do a similar set of steps with your
application and see classes from your application in step 8, you have a
permgen leak. You will have to fix your application.

The Maven project attached works on NetBeans 6.9.1. I see no reason
why it won't run on NetBeans 7.

. . . . just my two cents.
/mde/