cancel
Showing results for 
Search instead for 
Did you mean: 

Virtualization in user sandboxes not working

mcmagi
Champ in-the-making
Champ in-the-making
In my web project, I am attempting to create content via the 'admin' user, yet when I go to preview that content before I publish it I get a tomcat 404 error.  It's not until the content gets published (via the workflow approval process) and is in the staging sandbox that it's viewable, and ONLY in the staging sandbox.  It's a bit of a toss-up whether I will be to view it in the user's sandbox after it's published.

Note this is only happening in my own web project.  When I follow the same process in the demo "alfrescowww" project, the virtualization is working fine.  Can adding and removing a web form several times cause the web project to get messed up somehow?

Out of curiosity, how does the virtualization work for user sandboxes?  In other words, how is it able to determine which user is being requested?  It looks like the virtualization server makes the determination from the hostname?

Thanks,
- Michael C. Maggio
16 REPLIES 16

jcox
Champ in-the-making
Champ in-the-making
The way the virtualization serer "knows"  that new
webapps have been created is via JMX notifications from
the Alfrseco webapp.   These notifications must be in
all the right places for everything to work as you'd expect.

The reason you're seeing the problem you've described
is that the version you're runing did not include full
integration betweeen the alfresco webapp and the
virtualization server.

You won't see this issue in the GA release *.
In short: upgrade!

Cheers,
-Jon

——
* unless you do something out of band via CIFS
    like changing web.xml.   NOTE: you **can** modify
    other assets such as JSPs, html and so on to your
    heart's content in CIFS – just the webapp-centric
    stuff such as web.xml, the jars, and webapp
    creation/desctruction really need to be done via
    the gui.  Again the issue here is proper JMX notification.

mcmagi
Champ in-the-making
Champ in-the-making
Thanks for the info Jon.  Is there a more recent version?  (I'm running the 2.0a preview)  Or do you mean I will have to wait for the final 2.0 release?

jcox
Champ in-the-making
Champ in-the-making
The webapp/virt server integration work was checked in at
2007-02-02 23:33:03 -0500   (the "-0500" means EST).

Therefore, could download source from the SVN
and build  it yourself… or just wait until the pre-built
2.0 release is published on SourceForge;  this will
happen around the 20th, I believe.

  Cheers,
  -Jon

mcmagi
Champ in-the-making
Champ in-the-making
Hi Jon,

Strangely, I was eventually able to get the virtualization server to work properly in the 2.0 preview.  When I added other users to the project, I was able to virtualize their sandbox content.  Just the admin user gave me problems.  Perhaps that means the virtualization server was down when I invited the admin user to the project, but running (and JMX-notified) when I invited the other users?

Regardless, I now have another issue with the virtualization server.  It no longer responds to requests at all.  Instead, it hangs on startup with the following exception:


Feb 16, 2007 8:47:32 AM org.alfresco.mbeans.VirtServerRegistrationThread registerVirtServer
INFO: Connected to remote Alfresco JMX Server
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)
Caused by: java.lang.NullPointerException
        at org.alfresco.catalina.host.AVMHostConfig$AVMWebappDescriptor.setParentRepo(AVMHostConfig.java:1753)
        at org.alfresco.catalina.host.AVMHostConfig.deployAVMWebappsInDependencyOrder(AVMHostConfig.java:794)
        at org.alfresco.catalina.host.AVMHostConfig.deployAllAVMwebappsInRepository(AVMHostConfig.java:373)
        at org.alfresco.catalina.host.AVMHostConfig.deployApps(AVMHostConfig.java:228)
        at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122)
        at org.alfresco.catalina.host.AVMHostConfig.start(AVMHostConfig.java:180)
        at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
        at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
        at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021)
        at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
        at org.alfresco.catalina.host.AVMHost.start(AVMHost.java:580)
        at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
        at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
        at org.apache.catalina.core.StandardService.start(StandardService.java:450)
        at org.apache.catalina.core.StandardServer.start(StandardServer.java:709)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
        … 6 more

I thought maybe my web project was causing problems (seeing that deployApps was in the stack trace) and so I deleted it, but that didn't solve the problem.

mcmagi
Champ in-the-making
Champ in-the-making
Some additional info that may (hopefully) shed some light on this mystery…

This whole problem came about when I attempted to reconfigure alfresco to use a different hostname for the virtualization server.  That is, I wanted the links in the CMS to resolve to the actual IP of the machine rather than the loopback address.  This way, I do not have to run a browser on the same machine where the application is hosted.  I first followed this tutoral from the WIKI, but found that it wasn't doing the trick.  The links in the CMS still reported the alfrescodemo.net hostname with the loopback address.  It wasn't until I changed the property 'alfresco.virtserver.domain' in virtual-tomcat/conf/alfresco-virtserver.properties that I was able to get the links to work properly.

It was then that I found the virtualization server was not working properly and I found the exception above in the catalina.log.  Even when I reverted the config, I was not able to fix the problem.

jcox
Champ in-the-making
Champ in-the-making
Be sure the IP address in your virtualization domain is hypen-encoded within
$VIRTUAL_TOMCAT_HOME/conf/alfresco-virtserver.properties

For example, it should look something like this:
alfresco.virtserver.domain=192-168-1-5.ip.alfrescodemo.net

If it looks like the folowing value, it won't work (note the dots):
alfresco.virtserver.domain=192.168.1.5.ip.alfrescodemo.net

As for the wiki info being stale, my apologies; I just updated it today:

http://wiki.alfresco.com/wiki/Configuring_the_Virtualization_Server

   Cheers,
   - Jon

mcmagi
Champ in-the-making
Champ in-the-making
Hi John.  The address is encoded correctly.  I receive the above exception when I startup the virtual-tomcat, not when I click on a link.  When I click on a link, the browser appears to connect but waits forever for a response.

jcox
Champ in-the-making
Champ in-the-making
When you upgrade from the preview release,
make sure you do all of the following:

  o  delete the old backing store (alf_data)
  o  drop the 'alfresco' database, and then re-create it
  o  rm -rf  $VIRTUAL_TOMECAT_HOME/work/*
  o  rm -rf  $TOMCAT_HOME/work/*

Also, double-check your conf files.
Your  $VIRTUAL_TOMCAT_HOME/conf
dir should contain all of (and only) the
following files:

alfresco-jmxrmi.access
alfresco-jmxrmi.password
alfresco-shared.properties
alfresco-virtserver-context.xml
alfresco-virtserver.properties
Catalina
catalina.policy
catalina.properties
context.xml
logging.properties
server-minimal.xml
server.xml
tomcat-users.xml
web.xml

Finally,  if you change your admin password in the webapp,
you must make the corresponding change inside of
$VIRTUAL_TOMCAT_HOME/conf/alfresco-virtserver.properties 

For example, if you changed the admin password in the webapp
to  "moo" then the last lines of alfresco-virtserver.properties
should look like this:


# Admin level user and password to connect to login to Alfresco server.
#
alfresco.server.user=admin
alfresco.server.password=moo




———–
Aside: 

This has nothing to do with your problem at all,
but a much better demo name than "alfrescowww"
would have been something like  'mysite'.

That way, your URL to staging would look like this:
http://mysite.www--sandbox.

Your "author" area URLs would look like this:
http://alice.mysite.www--sandbox.
http://bob.mysite.www--sandbox.

Your "preview" URLs would look like this:
http://preview.alice.mysite.www--sandbox.
http://preview.bob.mysite.www--sandbox.

Personally, I think that's a lot nicer.

sacco
Champ in-the-making
Champ in-the-making
Finally, if you change your admin password in the webapp,
you must make the corresponding change inside of
$VIRTUAL_TOMCAT_HOME/conf/alfresco-virtserver.properties

For example, if you changed the admin password in the webapp
to "moo" then the last lines of alfresco-virtserver.properties
should look like this:


# Admin level user and password to connect to login to Alfresco server.
#
alfresco.server.user=admin
alfresco.server.password=moo

That's really quite an important piece of information which I don't think I've seen elsewhere.  It also might be something of an issue for prduction environments…