AS 5 not reliably picking up changes in exploded EAR

[maxandersen]

Hi guys,

I'm opening this forum thread based on Ales request in https://jira.jboss.org/jira/browse/JBAS-6590

Kenneth found that when you use an exploded ear on AS 5 then:

1) Seam deployer causes a copy of resources to tmp which by sideeffect makes all changes to the exploded directory (i.e. .xhtml) invisible to the server making a quick turnaround impossible without updating the internaml tmp directory directly.

2) Even when removing the SeamModificationTypeMatcher changes were not being picked up reliably.

I have verified #1 but haven't had time yet to check #2 (trying to get a release out ;) but Kenneth attached a test project for you all to try.

So...what do we do about this ?

And is there tests in AS we can update to add tests for this so we don't loose the hotdeploy functionallity again ?

[maxandersen]

fyi:
Ales gave links to this jira
https://jira.jboss.org/jira/browse/JBSEAM-3702
and http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4203667#4203667
as the cause of the Seam behavior.

I'm quite sure the sideeffect of not picking up changes is not what we wanted here ;)

[maxandersen]

Kenneth just mailed me saying that #2 is not a problem - the reason it happend was that he in his attempt of trying to get AS to pickup changes had set facelets.REFRESH_PERIOD to 0.

So we are back to only have the problem for Seam apps!

[pmuir]

I talked to Ales about this, he said that this forcing of a tmp copy shouldn't cause changes not to be seen as the original is still watched for changes and modificationcs copied.

[maxandersen]

but apparently it is - maybe something specific for facelets ? i.e. if jboss web says it is should look at the tmp/ dir instead of the actual deployed dir and changes to .xhtml is not being copied over ?

[maxandersen]

I still don't understand why Seam needs to have a tmp for exploded deployment ?

[pmuir]

I still don't understand why Seam needs to have a tmp for exploded deployment ?

It's a workaround for another problem in JBoss 5 (which I don't quite understand)... Really, it looks to me like all realworld apps will have this problem.

[maxandersen]

well it only hits seam because that fix (for whatever it is) causes a tmp copy to be created instased of running directly of the files...

[pmuir]

No, I mean realworld apps will hit the orignal problem, not the hot-deploy problem.

[alesj]

I still don't understand why Seam needs to have a tmp for exploded deployment ?

It's a very simple problem. ;-)

Some apps, in this case it was Seam Wicket example app,
still want to do some resources lookup at undeploy.
An undeploy which was triggered by the app's dir/archive deletion from deploy/.
But since the app was deleted there is nowhere to do the lookup from.
Unless you do a temp copy. ;-)
And this is what we used to do, and what most app servers still do.

We changed this behavior due to the VFS usage which can handle nested jars in memory.
But we still provide a way to do temp - via jboss-structure.xml.
In this case Seam guys found it too verbose to have to include jboss-structure.xml
in any Seam deployment in JBoss5, hence this feature was developed
== able to recognize deployments and modify the ContextInfo info before the actual/real deployment phase kicks in.

We did temps by-default before, in 4.x, but I don't know how
Tomcat/JBossWeb handled this, since afaik WarDeployer didn't monitor all non-metadata files.

[jason.greene]

"alesj" wrote:

We did temps by-default before, in 4.x, but I don't know how
Tomcat/JBossWeb handled this, since afaik WarDeployer didn't monitor all non-metadata files.

I asked Remy, and he doesn't know this worked before. However, I can make a very good educated guess, that tomcat just calls getResource on a standard xhtml request, which is of course going to point to the tmp.

One possible solution would be for the deployer to copy *any* changed files in an exploded deployment to the tmp.

[maxandersen]

We definitely should do this if no other option exists, BUT won't *every* app in the world that is looking up resources during undeploy have this issue ? (i.e. this is not seam specific, it is also an issue for *any* decent sized app that uses its deployed files/dependencies when undeploying)

[dimitris]

Why not just enable copying to /tmp anyway? As you can see, not doing it requires hacks over hacks to overcome. JBoss 4 did it, and was faster than what we do now.

[maxandersen]

so JBoss 4 always had two copies ? If yes, then sure - I just thought the value of exploded deployment were that AS used these files *directly*.

[dimitris]

JBoss 4 copied to tmp whatever was packed, top-level or nested.