Problem previewing binary content

[jukka]

Hi,

I've just starting to evaluate Alfresco WCM as a management and deployment platform for our webapps. I ran into a small problem with previewing binary content:

I followed the pdf tutorial for evaluating WCM and created the alfrescowww -project and imported the sample war file. With this project I can preview all html and jsp files just fine but all images are "broken" in the preview. They look just fine when browsing files such as:

http://<alfresco-server>/alfresco/d/d/avm/alfrescowww/-1;www;avm_webapps;ROOT;document.gif/document.gif

but through preview in virtual tomcat:

http://alfrescowww.www--sandbox.

the browser fails to display the image.  I've tried both Firefox and IE but the result is the same. It's like something has "touched" or filtered the binary file when viewed through virtualization?

I also created another project and imported my own .war file with some images. This time when viewed through the virtualization I get an error message:

java.lang.IllegalStateException: getWriter() has already been called for this response
        at org.apache.catalina.connector.Response.getOutputStream(Response.java:568)
        at org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:180)
        at javax.servlet.ServletResponseWrapper.getOutputStream(ServletResponseWrapper.java:101)
        at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:786)
        at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:354)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.alfresco.filter.CacheControlFilter.doFilter(CacheControlFilter.java:184)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
        at org.alfresco.catalina.valve.AVMUrlValve.invoke(AVMUrlValve.java:375)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at org.alfresco.catalina.valve.AVMUrlValve.invoke(AVMUrlValve.java:718)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
        at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
        at java.lang.Thread.run(Thread.java:595)
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Otherwise it looks like a very interesting and promising product. Just takes a while to see the big picture.

Our environment:

Alfresco Server: alfresco-community-tomcat-2.1.0dev on Linux Fedora Core 6
Alfresco WCM: alfresco-community-wcm-2.1.0dev
JDK:  1.5.0_11-b03

Thanks,
Jukka

[sacco]

Sacco,

I don't want to assume anything at all at this point,
so if I ask stupid/obvious-sounding questions please
don't take it the wrong way.

No, of course not .

The line-ending theory would be really weird because I'm doing
most of my testing on a Debian Linux distribution myself, and this
issue has never arisen on that box (or my NT or XP box).

Yes, that's what I thought, but I just thought I'd mention that I'd tested it and it has no effect.

However, just to rule it out  completely, when you edit this file,
how are you doing the edit?  Are you winding up with a file that
has mixed line endings?

No, never.  Usually I either set emacs to preserve whatever it finds and hide the ^Ms from my view, or else (as I'm always running on UNIX or Linux) I just convert everything at the beginning with 
dos2unix –keepdate

I edit my file using VIM which is
able to conform to either UNIX or DOS endings.   The resultant
file is of a uniform ending convention (DOS).    Personally, I hate
the DOS convention, but for now we're stuck with it.   Some editors
(most notably emacs) can actually *hide* the fact that line endings
are of a mixed type, so you'll never even see the ^M chars
(depending on your .emacs file's settings).

Yes, that's pretty much what I do.

Therefore, what I'd like you to do is use a pristine never-edited-by-you
version of alfresco-virtserver-context.xml and verify that its
md5sum is in fact:

   9f6387f740577649f914bbb2ccf19b19
‍‍‍

Yes, I've done that.

Also, I'd like you to verify for me that your virtualization server
is actually Tomcat 5.5.23.   Between minor versions, Tomcat's
semantics for filters changed a bit, so if you're not on *exactly*
Tomcat 5.5.23,  please correct that now.

Yes it is.  Until I get Alfresco completely settled, I'm actually working from the alfresco-community-tomcat  bundle, so I'm using exactly what comes in the tin.

As for the tests you ran:

[1] 
What do you mean when you say "every included context has failed"?
Is there a log entry?  Do you debugging turned on?   Again, don't
de-install the filter, or touch  alfresco-virtserver-context.xml  in any way
after it has been installed.  This is only complicating the task of
trouble-shooting what is wrong on your machine.

The log entry is the one above (from catalina.out)

INFO: XML validation disabled
20-Jul-2007 01:35:48 org.apache.catalina.core.StandardContext start
SEVERE: Error filterStart
20-Jul-2007 01:35:48 org.apache.catalina.core.StandardContext start
SEVERE: Context [/manager] startup failed due to previous errors
20-Jul-2007 01:35:50 org.apache.catalina.core.StandardContext start
SEVERE: Error filterStart
20-Jul-2007 01:35:50 org.apache.catalina.core.StandardContext start
SEVERE: Context [/host-manager] startup failed due to previous errors
20-Jul-2007 01:35:50 org.apache.catalina.core.StandardContext start
SEVERE: Error filterStart
20-Jul-2007 01:35:50 org.apache.catalina.core.StandardContext start
SEVERE: Context [] startup failed due to previous errors
20-Jul-2007 01:35:51 org.springframework.core.CollectionFactory <clinit>
INFO: JDK 1.4+ collections available
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I can still get the Virtualisation server started, and I've checked some previews and the filter is acting on them, so I'm not even sure these contexts are important (they're pretty much just the ones in a standard tomcat installation).

The stack trace that appears in the log file for e.g. manager.2007-08-03.log is just the java.lang.NullPointerException one reported above.

[2]
The typo in the config file is harmless.
Incidentally, on 2007-07-23 the typo was fixed on V2.1E
This typo never had any effect on any release because the
cut/pasted typo was identical in the section than named the filter
and in the section that referred to the filter.   For all Tomcat cares the
filter could have been called "moo" in both places.  It doesn't matter,
as long as the name is the same.

Yes, I thought as much.  Again, I just thought I'd check in case something else was looking for the filter by name.

[3]
The expiration time is copied directly from your config file
into the relevant header.  If you do an ethereal trace use
a tool such as netcat you can see the header values returned
by the filter are correct.   If you're seeing a "one minuite off"
error between 5-6 min, but correct results at 10 min, you've
either discovered a bug in your browser, or you've got clock
jitter, or are noticing some sort of quantization effect in the
way your browser rounds max-age.   One other possibility
is that you're not modifying the max-age value that you think
you are.   Note that the max-age value can be set independently
for the main working layer of a sandbox, the preview layer, and
staging.

Yes.  My guess is something like quantisation in the browser (and the browser in question was on a Windows box).  I don't think this is really a problem as I'm getting pretty much what I expected: I just thought I ought to mention it.

Another thing I'd like you to verify is that within
$VIRTUAL_TOMCAT_HOME/conf/alfresco-virtserver.properties
you have well-defined values for all of the areas (i.e.: none missing!).
By default you should have all of the following set:

alfresco.virtserver.cache-control.max-age.preview=4
alfresco.virtserver.cache-control.max-age.workarea=1800
alfresco.virtserver.cache-control.max-age.staging=1800
alfresco.virtserver.cache-control.max-age.default=1800
‍‍‍‍‍

Check.

To rule out an installer problem, one thing you could do is this:

cd $VIRTUAL_TOMCAT_HOME
find .  | grep spring
‍‍‍‍

The only result you should get back is:

  ./server/lib/spring-2.0.2.jar
‍‍‍

Check.  But to me this seems like it might be part of the problem: spring is available only to the server, but the filter is defined in web.xml, so applies to all contexts.

Gotta dash.  Have a good weekend.