[alesj]

The issue is not do we temp or not.
And controlling this is not hard or hacky. ;-)
e.g. simple jboss-structure.xml will do
or adding a simple ModificationTypeMatcher.

The real issue is why this worked before,
when we always temped everything.
Which is exactly what we do here - we temp - but it doesn't work.
So far I got zero useful information from JBossWeb, old WarDeployer authors, ...

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.

Where is this piece of code?
Or where does TC/JBW do a check for if the resource has changed?

That's all I need to know, and I'll dig it up from there.

[dimitris]

I suppose we need a minimal test in the AS testsuite to demonstrate/understand how this works, both in 4.2.x and 5.x, one that does not involve seam.

OTOH, which ever deployment requires special configuration to make it work (jboss-structure.xml") might be "simple" if you have written half of the deployment framework yourself but is not simple nor acceptable by our average user.

[gozilla]

AFAIK, JBoss 4 only temped packed deployments like ears, wars, sars, ... Only jars were used directly.

It used directly the files from exploded archives.

That's how I used exploded WARs to have tomcat recompile jsps or other resources

Francois

[jaikiran]

"gozilla" wrote:
AFAIK, JBoss 4 only temped packed deployments like ears, wars, sars, ...

That's correct. For exploded deployments (of WAR, EAR etc...) there were no temps in 4.x. I just did a simple test against the exploded jmx-console.war that comes in AS 4.x. There are no temps created for this app.

As for how the jsp changes are picked up in exploded deployments (on AS4.x), from what i remember - the timestamp of the jsp file is compared against the generated servlet classes (i don't exactly remember where this logic resides, but i strongly believe its somewhere within tomcat/jboss web code). I guess the same logic applies for xhtml files, not sure.

[alesj]

"jaikiran" wrote:

"gozilla" wrote:
AFAIK, JBoss 4 only temped packed deployments like ears, wars, sars, ...

That's correct. For exploded deployments (of WAR, EAR etc...) there were no temps in 4.x. I just did a simple test against the exploded jmx-console.war that comes in AS 4.x. There are no temps created for this app.

Hmmm, this then raises another question.
How did we then handle resources lookup at undeploy (when the app was deleted)?
I guess we didn't. :-)

[jaikiran]

"jaikiran" wrote:
(i don't exactly remember where this logic resides, but i strongly believe its somewhere within tomcat/jboss web code).

For those curious, when the jsp is being serviced, the call goes through org.apache.jasper.compiler.Compiler:

/**
 * Determine if a compilation is necessary by checking the time stamp of the
 * JSP page with that of the corresponding .class or .java file. If the page
 * has dependencies, the check is also extended to its dependeants, and so
 * on. This method can by overidden by a subclasses of Compiler.
 *
 * @param checkClass
 * If true, check against .class file, if false, check against
 * .java file.
 */
public boolean isOutDated(boolean checkClass)

Not sure about xhtml.

[gozilla]

If I remember well, redeploying/undeploying an exploded EAR didn't work reliably (certainly on Windows), because of locks, ...

But we preferred to live with it, because for a relative large EAR (about 80Mb, mostly from a 65M WAR), the time to unpack it was longer than the JBoss boot time on our hardware.
And you often have problems with statics anyway.

So I think "temp even for exploded" is not a good option, because it will defeat one of the purposes of using exploded deployments: speed.

Francois

[alesj]

"gozilla" wrote:

So I think "temp even for exploded" is not a good option, because it will defeat one of the purposes of using exploded deployments: speed.

Sure, but nothing is for free. ;-)
* no temp = faster, but no undeploy resources handling
* temp = slow, but you can handle resources anytime

I'm more than happy to remove this Seam 'feature',
but it still doesn't solve the problem when you really need
to have a temp, plus you wanna monitor the changes.
Having both should not be impossible ...

[jaikiran]

Looking at the JIRA which started this Seam specific change https://jira.jboss.org/jira/browse/JBSEAM-3702 , there were 3 logs attached, out of which 2 issues are being addressed separately (https://jira.jboss.org/jira/browse/JBSEAM-4012) and there's no role of VFS in those issues.

The third exception in those logs relates to:

"alesj" wrote:

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.

The exception stacktrace shows:

2008-11-14 14:14:03,874 INFO [org.jboss.seam.navigation.Pages] (http-127.0.0.1-8080-21) no pages.xml file found: /WEB-INF/pages.xml
2008-11-14 14:14:05,245 ERROR [org.apache.wicket.util.thread.Task] (ModificationWatcher Task) Unhandled exception thrown by user code in task ModificationWatcher
java.lang.RuntimeException: java.io.IOException: Child not found jboss-seam-wicket-booking.ear/jboss-seam-wicket-booking.war/WEB-INF/classes/org/jboss/seam/example/wicket/Home.html for FileHandler@6861787[...]]
 at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getLastModified(VirtualFileURLConnection.java:87)
 at org.apache.wicket.util.resource.UrlResourceStream.lastModifiedTime(UrlResourceStream.java:256)
 at org.apache.wicket.markup.MarkupResourceStream.lastModifiedTime(MarkupResourceStream.java:144)
 at org.apache.wicket.util.watch.ModificationWatcher$1.run(ModificationWatcher.java:176)
 at org.apache.wicket.util.thread.Task$1.run(Task.java:115)
 at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: Child not found jboss-seam-wicket-booking.ear/jboss-seam-wicket-booking.war/WEB-INF/classes/org/jboss/seam/example/wicket/Home.html for FileHandler@6861787[...]]
 at org.jboss.virtual.VirtualFile.findChild(VirtualFile.java:431)
 at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.resolveVirtualFile(VirtualFileURLConnection.java:106)
 at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getVirtualFile(VirtualFileURLConnection.java:118)
 at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getLastModified(VirtualFileURLConnection.java:83)
 ... 5 more
2008-11-14 14:14:06,248 ERROR [org.apache.wicket.util.thread.Task] (ModificationWatcher Task) Unhandled exception thrown by user code in task ModificationWatcher
java.lang.RuntimeException: java.io.IOException: Child not found jboss-seam-wicket-booking.ear/jboss-seam-wicket-booking.war/WEB-INF/classes/org/jboss/seam/example/wicket/Home.html for FileHandler@6861787[path= ...]]
 at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getLastModified(VirtualFileURLConnection.java:87)

So there is some ModificationWatcher Task which is polling for any changes to some file, maybe to refresh some cache? If the entire application is deleted, does the ModificationWatcher Task even have to bother about the file change? Maybe we can just log this at DEBUG level instead of ERROR?
From what i see in the logs, the ModificationWatcher does the same as HDScanner in the AS does? So how does the HDScanner handle similar (deleted) app?

[jaikiran]

"jaikiran" wrote:

From what i see in the logs, the ModificationWatcher does the same as HDScanner in the AS does? So how does the HDScanner handle similar (deleted) app?

HotDeploymentRepository (intelligently) does this :

// Check for removal
 if (root.exists() == false)
 {
 long rootLastModified = root.getLastModified();
 ModificationInfo info = new ModificationInfo(ctx, rootLastModified, ModifyStatus.REMOVED);
 modified.add(info);
 iter.remove();
 // Remove last modified cache
 cleanUpRoot(root);
 if (trace)
 log.trace(pathName + " was removed");
 }

Can't something similar be done in ModificationWatcher?

[alesj]

"jaikiran" wrote:

Can't something similar be done in ModificationWatcher?

This is Wicket code, and it does what it does. :-)
I don't think we can do anything about it.

But that's not the point.
Any other code could do something at undeploy.
And since most of the app servers do temping by default it would work ootb.

e.g. one of our first tests, for minimal config, tests exactly that =
spins off a new thread at undeploy, and tries to load some inner class

Moving Remy's email to this forum thread.

"remy" wrote:

JBW has a VFS-like abstraction too, so one could write one that monitors
an "original" folder, compare with what is in the "real" folder, and sync
them.

...

JBoss should probably have something to keep the temped stuff in sync
with the original stuff when it does temping. JBW will pick up changes
if you update the temp copy.

Both ideas sound OK.
But I guess the 2nd one is more general, not limited just to JBW.
I'll probably try to impl something on top of that. ;-)

[jaikiran]

"alesj" wrote:

This is Wicket code, and it does what it does. :-)
I don't think we can do anything about it.

Yep, that's correct. I meant the code could be changed in the wicket/seam :)

"alesj" wrote:

But that's not the point.
Any other code could do something at undeploy.
And since most of the app servers do temping by default it would work ootb.

So then the original question remains about 4.x:

How did we then handle resources lookup at undeploy (when the app was deleted)?
I guess we didn't. :-)

I decided to give this a try with a simple WAR which has a ServletContextListener which on contextDestroyed, looks up a properties file within the WAR:

public class MyServletContextListener implements ServletContextListener {

 public void contextDestroyed(ServletContextEvent event) {
 System.out.println("Destroying " + event.getServletContext());
 ServletContext servletCtx = event.getServletContext();
 InputStream inputStream = servletCtx.getResourceAsStream("test.properties");
 System.out.println("Got stream while destroying " + inputStream);
 Properties props = new Properties();
 try {
 props.load(inputStream);
 System.out.println("Loaded props");
 } catch (Exception e)
 {
 System.out.println("Error loading props");
 e.printStackTrace();
 }

 }

Here are the results on AS-4.2.3 GA:

When the WAR is deployed in archived format, and i delete it from the deploy folder when the server is up, i see that the ServletContextListener is able to still lookup the test.properties file (since the archived deployments are temp'd):

19:48:57,038 INFO [STDOUT] Destroying org.apache.catalina.core.ApplicationContextFacade@6e056e
19:48:57,038 INFO [STDOUT] Got stream while destroying java.io.ByteArrayInputStream@a3bb2e
19:48:57,038 INFO [STDOUT] Loaded props

When the WAR is deployed in exploded format and i delete it from the deploy folder, the ServletContextListener is not able to lookup that test.properties file (since the exploded deployment are not temp'd and original file is gone):

19:47:26,638 INFO [STDOUT] Destroying org.apache.catalina.core.ApplicationContextFacade@b2771
19:47:26,639 INFO [STDOUT] Got stream while destroying null
19:47:26,639 INFO [STDOUT] Error loading props
19:47:26,639 ERROR [STDERR] java.lang.NullPointerException
19:47:26,641 ERROR [STDERR] at java.util.Properties$LineReader.readLine(Properties.java:365)
19:47:26,641 ERROR [STDERR] at java.util.Properties.load(Properties.java:293)
19:47:26,641 ERROR [STDERR] at org.myapp.servlet.MyServletContextListener.contextDestroyed(MyServletContextListener.java:26)
19:47:26,641 ERROR [STDERR] at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3895)
19:47:26,641 ERROR [STDERR] at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4527)
19:47:26,641 ERROR [STDERR] at org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1163)
19:47:26,642 ERROR [STDERR] at org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4617)
19:47:26,642 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
19:47:26,642 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
19:47:26,642 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
19:47:26,642 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
19:47:26,642 ERROR [STDERR] at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:296)
19:47:26,643 ERROR [STDERR] at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
19:47:26,643 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
19:47:26,643 ERROR [STDERR] at org.jboss.web.tomcat.service.TomcatDeployer.performUndeployInternal(TomcatDeployer.java:461)
19:47:26,643 ERROR [STDERR] at org.jboss.web.tomcat.service.TomcatDeployer.performUndeploy(TomcatDeployer.java:432)
19:47:26,643 ERROR [STDERR] at org.jboss.web.AbstractWebDeployer.stop(AbstractWebDeployer.java:422)
19:47:26,643 ERROR [STDERR] at org.jboss.web.WebModule.stopModule(WebModule.java:100)
19:47:26,643 ERROR [STDERR] at org.jboss.web.WebModule.stopService(WebModule.java:66)
19:47:26,644 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315)
19:47:26,644 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247)
19:47:26,644 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
19:47:26,644 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
19:47:26,644 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
19:47:26,644 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
19:47:26,645 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
19:47:26,645 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
19:47:26,645 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
19:47:26,645 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
19:47:26,645 ERROR [STDERR] at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
19:47:26,645 ERROR [STDERR] at $Proxy0.stop(Unknown Source)
19:47:26,645 ERROR [STDERR] at org.jboss.system.ServiceController.stop(ServiceController.java:508)
19:47:26,646 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
19:47:26,646 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
19:47:26,646 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
19:47:26,646 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
19:47:26,646 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
19:47:26,646 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
19:47:26,647 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
19:47:26,647 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
19:47:26,647 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
19:47:26,647 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
19:47:26,647 ERROR [STDERR] at $Proxy44.stop(Unknown Source)
19:47:26,647 ERROR [STDERR] at org.jboss.web.AbstractWebContainer.stop(AbstractWebContainer.java:498)
19:47:26,647 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
19:47:26,648 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
19:47:26,648 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
19:47:26,648 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
19:47:26,648 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
19:47:26,648 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
19:47:26,648 ERROR [STDERR] at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
19:47:26,649 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
19:47:26,649 ERROR [STDERR] at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
19:47:26,649 ERROR [STDERR] at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
19:47:26,649 ERROR [STDERR] at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
19:47:26,649 ERROR [STDERR] at org.jboss.wsf.container.jboss42.DeployerInterceptor.stop(DeployerInterceptor.java:98)
19:47:26,649 ERROR [STDERR] at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.stop(SubDeployerInterceptorSupport.java:196)
19:47:26,649 ERROR [STDERR] at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:99)
19:47:26,650 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
19:47:26,650 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
19:47:26,650 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
19:47:26,650 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
19:47:26,650 ERROR [STDERR] at $Proxy45.stop(Unknown Source)
19:47:26,650 ERROR [STDERR] at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:667)
19:47:26,650 ERROR [STDERR] at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:638)
19:47:26,651 ERROR [STDERR] at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:632)
19:47:26,651 ERROR [STDERR] at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:615)
19:47:26,651 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
19:47:26,651 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
19:47:26,651 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
19:47:26,651 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
19:47:26,652 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
19:47:26,652 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
19:47:26,652 ERROR [STDERR] at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
19:47:26,652 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
19:47:26,652 ERROR [STDERR] at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
19:47:26,652 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
19:47:26,652 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
19:47:26,653 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
19:47:26,653 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
19:47:26,653 ERROR [STDERR] at $Proxy9.undeploy(Unknown Source)
19:47:26,653 ERROR [STDERR] at org.jboss.deployment.scanner.URLDeploymentScanner.undeploy(URLDeploymentScanner.java:450)
19:47:26,653 ERROR [STDERR] at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:570)
19:47:26,653 ERROR [STDERR] at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
19:47:26,653 ERROR [STDERR] at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
19:47:26,654 ERROR [STDERR] at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)

So that answers the question - we did not support this even in 4.x with exploded deployments.

[dimitris]

Thanks jaikiran :)