Actually regarding to redeploying, you run into a typical Windows
problem here.
Redeploying and Windows still is an issue. The reason for this is
Windows does pessimistic filelocking which Unixoid systems generally do
not do.
Tomcat bypasses the problem to some extent by mirroring and starting the
installation from a temp dir in its local directory instead of using
the official webapp dir. (So every redeploy gets its own shadow directory)
Seems like the WTP has disabled this for whatever reason (I assume, a
bug) and adding the parameter has enabled it again.
As you said the whole redeploying is less flakey on OSX, due to the fact
that OSX as every Unix system (After all OSX is a NextStep derivate,
which is a Mach-BSD Kernel Hybrid with OO libraries on top of it) does
not lock files at all but instead relies on an optimistic locking
mechanism via .lock files.
Hence redeployment directly happens on your webapp directory instead of
copying and running it from a shadow directory, due to the fact that
the files are not locked on OS level.
It is as simple and as complicated as that. My personal experience is
that 90% of all problems especially in the Eclipse area in Windows are
caused by the pessimistic file locking.
Werner
Am 19.04.10 22:37, schrieb Johan Borchers:
Hello Werner and Rudy,
Thanks for the answers!
I did also some work to find a good solution for working with ExtVal.
For me it is working now. I did find out that problems do appear on my Windows
XP machine.
On the Mac with Snow Leopard 10.6.3 things are working better. So let me
explain what I did.
I'm working with Eclipse Galileo 3.5.2 JEE with JBoss VE plugin for RichFaces
on both the Mac and Windows XP.
Both systems are running Java 1.6.0_17. Also on both systems I have Tomcat
6.0.20.
For deployment only I use an Ubuntu 9.10 machine with Tomcat 6.0.20 and OpenJDK
6.
For development I do start or debug Tomcat in Eclipse.
I do build the war file with Ant and deploy it to the webapps directory of
Tomcat.
Tomcat redeploys (and unpacks) the webpapp after adding the war file to the
webapps directory.
Now I only have the MySQL driver software in the lib directory of Tomcat.
The rest of the libraries I now do have in the WEB-INF/lib directory of the
webapp.
The following is a list of my files in the WEB-INF/lib directory:
asm-3.2.jar
cglib-2.2.jar
commons-beanutils-1.8.0.jar
commons-collections-3.2.1.jar
commons-digester-1.8.jar
commons-lang-2.4.jar
commons-logging-1.1.1.jar
extval-annotation-based-bypass-validation-1.2.3.jar
ibatis-2.3.4.726.jar
jsf-api-mojarra-1.2_14-b01.jar
jsf-facelets-1.1.15.B1.jar
jsf-impl-mojarra-1.2_14-b01.jar
jstl-1.2.jar
myfaces-extval-core-1.2.3.jar
myfaces-extval-generic-support-1.2.3.jar
myfaces-extval-property-validation-1.2.3.jar
richfaces-api-3.3.3.Final.jar
richfaces-impl-3.3.3.Final.jar
richfaces-ui-3.3.3.Final.jar
Now on Windows with Tomcat 6.0.20 redeploying the webapp hangs on Undeploying.
At least that's the last message on the console.
The same configuration on the Mac works perfectly fine. No problem with
redeploying the webapp to a running Tomcat engine.
It just onloads the old webapp and reloads the new webapp.
I downloaded the Tomcat 6.0.26 32 bit version for Windows, configured it the
same as 6.0.20 and redeploying works also fine on Windows.
But only if I start Tomcat from the command line via catalina.bat.
Starting Tomcat from Eclipse did still hang on redeploying also for Tomcat
6.0.26.
Then I searched for the difference between starting Tomcat from the command
line and starting Tomcat in Eclipse.
Eclipse is just using the Bootstrap.jar and passing parameters where the
catalina.bat defines a lot more defaults.
I added the 2 vm parameters for configuring Tomcat JULI logging from the
catalina.bat to the startup parameters where Eclipse starts Tomcat.
Because Tomcat was not logging anything when started from Eclipse.
And guess what, redeploying the webapp to Tomcat 6.0.26 running in Eclipse
works also fine.
Redeploying on on the Mac looks more robust than on Windows. On the Mac it also
works for Tomcat 6.0.20.
I still don't know the real reason why the webapp won't unload on Windows with
Tomcat 6.0.20 but I have a workaround.
I'm able to go all the way with ExtVal because until now I did not add any JSF
validation to the webapp.
With the bypass annotation I'm able to build behavior of our desktop
applications in the webapp.
I also like the @Pattern annotation.
Q3
I now have my translated messages in the file Messages_nl_NL.properties. Extval is
showing the Dutch messages. But for the Pattern annotation it gives an English message
like "Invalid format". Where can I translate these messages and do they also
use the label of the UI object?
Regards,
Johan
On Apr 19, 2010, at 4:45 PM, Werner Punz wrote:
Ok I did some initial testing, Ext-Val + MyFaces Ext-Scripting works
but the dynamic reloading only works for constraints,
Validation group reloading does not work yet, due to caching
on Ext-Vals side as it seems.
I will work with Gerhard on this issue to resolve
it in the near future, but if you can live with what is there
either use JSF2s bean validation support or do the occasional restart if you
need to alter the Validation group settings.
Werner
Am 16.04.10 13:38, schrieb Werner Punz:
Am 16.04.10 13:16, schrieb Gerhard Petracek:
hi johan,
some additions:
as mentioned by rudy: the "required"-attribute is quite special in
combination with component initialization. i'll add some information
about
it in our new wiki. concerning your concrete issues: it would be nice
if you
can provide a link to a small demo app which illustrates the issue (to
ensure that we are talking about the same details).
Where to place the Extval libraries?
you could customize it via a custom message resolver.
as alternative you could use myfaces-core + ext-scripting - so you don't
have to restart tomcat...
Well I have not tested the combo yet, I wanted to do it this week but
haven´t found enough time, but feel free to try ext-scripting in that
combination, but I cannot gurantee that it works, not before next week
before the final testing round before 1.0, as long as you stay on the
JSF side it can help you to save a lot of restarts.
Alternatively you can use jRebel to avoid restarts.
Here is the info regarding ext-scripting (no official site yet)
http://people.apache.org/~werpu/ext-script-site/ I highly recommend
to make a checkout and build, the last beta had some serious bugs which
I fixed in between.
Have in mind Ext-Scripting currently only works on MyFaces not on
Mojarra, Mojarra support will be added but is not on the TODO list
for 1.0, also additional framework support is in the works but will
not be in 1.0.
Here is the info regarding jRebel:
http://www.zeroturnaround.com/
Werner
