[xwiki-devs] [VOTE] Upgrade officeimporter to use JODConverter 3.0-beta-2 release and add support for auto-starting oo server
Hi Devs, Jodconverter 3.0-beta-2 version has been released: http://groups.google.com/group/jodconverter/browse_thread/thread/8b73b26b701... One of the most important fix for us is the first point mentioned there: "OOo is now started with -nofirststartwizard by default. This avoids the frequent problem of OOo refusing to work on a new machine because it's expecting somebody to accept its license dialogue even in -headless mode" Without this fix currently we have to copy an already initialized ooprofile directory to the destination server and point to it from xwiki.properties file. This is a pain. Also there are several other enhancements: http://code.google.com/p/jodconverter/issues/list?can=1&q=label%3ATarget-3.0... Unfortunately some of the public APIs of jodconverter has been changed from beta-1 release to beta-2 release. But still, upgrading our officeimporter module to use this new jodconverter release will not require that much of code changes. Note: jodconverter is not available in any public maven repository AFAIK. So we need to release it to our externals repository as we did with the beta-1 version. The other feature is a frequently requested one (auto-strart) and admins are having a hard time without this feature :) Here is my +1 for both features. Thanks. - Asiri
Asiri Rathnayake wrote:
Hi Devs,
Jodconverter 3.0-beta-2 version has been released: http://groups.google.com/group/jodconverter/browse_thread/thread/8b73b26b701...
One of the most important fix for us is the first point mentioned there:
"OOo is now started with -nofirststartwizard by default. This avoids the frequent problem of OOo refusing to work on a new machine because it's expecting somebody to accept its license dialogue even in -headless mode"
Without this fix currently we have to copy an already initialized ooprofile directory to the destination server and point to it from xwiki.properties file. This is a pain.
Also there are several other enhancements: http://code.google.com/p/jodconverter/issues/list?can=1&q=label%3ATarget-3.0...
Unfortunately some of the public APIs of jodconverter has been changed from beta-1 release to beta-2 release. But still, upgrading our officeimporter module to use this new jodconverter release will not require that much of code changes.
Note: jodconverter is not available in any public maven repository AFAIK. So we need to release it to our externals repository as we did with the beta-1 version.
The other feature is a frequently requested one (auto-strart) and admins are having a hard time without this feature :)
Here is my +1 for both features.
+1 -- Sergiu Dumitriu http://purl.org/net/sergiu/
+1 Thanks -Vincent On Apr 27, 2009, at 7:03 PM, Asiri Rathnayake wrote:
Hi Devs,
Jodconverter 3.0-beta-2 version has been released: http://groups.google.com/group/jodconverter/browse_thread/thread/8b73b26b701...
One of the most important fix for us is the first point mentioned there:
"OOo is now started with -nofirststartwizard by default. This avoids the frequent problem of OOo refusing to work on a new machine because it's expecting somebody to accept its license dialogue even in -headless mode"
Without this fix currently we have to copy an already initialized ooprofile directory to the destination server and point to it from xwiki.properties file. This is a pain.
Also there are several other enhancements: http://code.google.com/p/jodconverter/issues/list?can=1&q=label%3ATarget-3.0...
Unfortunately some of the public APIs of jodconverter has been changed from beta-1 release to beta-2 release. But still, upgrading our officeimporter module to use this new jodconverter release will not require that much of code changes.
Note: jodconverter is not available in any public maven repository AFAIK. So we need to release it to our externals repository as we did with the beta-1 version.
The other feature is a frequently requested one (auto-strart) and admins are having a hard time without this feature :)
Here is my +1 for both features.
Thanks.
- Asiri
+1 On Mon, Apr 27, 2009 at 7:41 PM, Vincent Massol <[email protected]> wrote:
+1
Thanks -Vincent
On Apr 27, 2009, at 7:03 PM, Asiri Rathnayake wrote:
Hi Devs,
Jodconverter 3.0-beta-2 version has been released:
http://groups.google.com/group/jodconverter/browse_thread/thread/8b73b26b701...
One of the most important fix for us is the first point mentioned there:
"OOo is now started with -nofirststartwizard by default. This avoids the frequent problem of OOo refusing to work on a new machine because it's expecting somebody to accept its license dialogue even in -headless mode"
Without this fix currently we have to copy an already initialized ooprofile directory to the destination server and point to it from xwiki.properties file. This is a pain.
Also there are several other enhancements:
http://code.google.com/p/jodconverter/issues/list?can=1&q=label%3ATarget-3.0...
Unfortunately some of the public APIs of jodconverter has been changed from beta-1 release to beta-2 release. But still, upgrading our officeimporter module to use this new jodconverter release will not require that much of code changes.
Note: jodconverter is not available in any public maven repository AFAIK. So we need to release it to our externals repository as we did with the beta-1 version.
The other feature is a frequently requested one (auto-strart) and admins are having a hard time without this feature :)
Here is my +1 for both features.
Thanks.
- Asiri
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/
+0 Asiri Rathnayake wrote:
Hi Devs,
Jodconverter 3.0-beta-2 version has been released: http://groups.google.com/group/jodconverter/browse_thread/thread/8b73b26b701...
One of the most important fix for us is the first point mentioned there:
"OOo is now started with -nofirststartwizard by default. This avoids the frequent problem of OOo refusing to work on a new machine because it's expecting somebody to accept its license dialogue even in -headless mode"
Without this fix currently we have to copy an already initialized ooprofile directory to the destination server and point to it from xwiki.properties file. This is a pain.
Also there are several other enhancements: http://code.google.com/p/jodconverter/issues/list?can=1&q=label%3ATarget-3.0...
Unfortunately some of the public APIs of jodconverter has been changed from beta-1 release to beta-2 release. But still, upgrading our officeimporter module to use this new jodconverter release will not require that much of code changes.
Note: jodconverter is not available in any public maven repository AFAIK. So we need to release it to our externals repository as we did with the beta-1 version.
The other feature is a frequently requested one (auto-strart) and admins are having a hard time without this feature :)
Here is my +1 for both features.
Thanks.
- Asiri _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Apr 27, 2009 at 10:03 AM, Asiri Rathnayake < [email protected]> wrote:
Hi Devs,
Jodconverter 3.0-beta-2 version has been released:
http://groups.google.com/group/jodconverter/browse_thread/thread/8b73b26b701...
One of the most important fix for us is the first point mentioned there:
"OOo is now started with -nofirststartwizard by default. This avoids the frequent problem of OOo refusing to work on a new machine because it's expecting somebody to accept its license dialogue even in -headless mode"
Without this fix currently we have to copy an already initialized ooprofile directory to the destination server and point to it from xwiki.properties file. This is a pain.
+1, However, I'd also like to express a wish for the ability to launch the openoffice server the "old fashioned tedious way" for those with security concerns and a desire for standards of service administration on web servers. Does this new release re-enable that capability that was removed from 1.8M2? IMHO, many security-conscious administrators will prefer to have control over this service via traditional and accepted mechanisms like chkconfig(8) and /etc/init.d/ scripts. They may be surprised or made uncomfortable by the notion of an externally accessible Internet application running in a java web server that launches a rather extensive "untrusted system" (openoffice running as a server) and runs it with the same exact privileges as your "trusted" web server and "trusted' java and Servlet spec, thereby potentially "tainting" all, as well as exposing unexpected privilege-escalation exploits <http://en.wikipedia.org/wiki/Privilege_escalation>.
From a security standpoint, it would be nice to have "separation of concerns<http://en.wikipedia.org/wiki/Separation_of_concerns>" and "separation of privilege<http://en.wikipedia.org/wiki/Privilege_separation>" : run the Openoffice server as a different "user" on the system that can only write its own home directory and /tmp but not have the same access capabilities given to the java web server (and vice-versa). The 1.8M1/M2 releases where this advice still applied, required that both OpenOffice server and the java web server be run as the same user (tomcat). This does not have to be a fundamental limitation of the "named pipe" and unix-domain ipc used -- it's a limitation of the OpenOffice server or its configuration.
Below is a section I wrote for http://code.xwiki.org/xwiki/bin/view/Applications/OfficeImporterApplicationt... deal with this issue.
Installation notes for Fedora 10
Strange bugs can occur if the incorrect or incomplete openoffice install is selected, or if this particular build of openoffice is run with a different Java JVM than the GNU GCJ which "yum" loads as a dependency of OpenOffice. After numerous troubles with the OpenOffice server using the default Sun JDK used to run Tomcat and Xwiki, I set the JVM used by OpenOffice back to "GCJ" and things began working reliably and quickly. Therefore these instructions assume you've done "yum groupinstall 'Office/Productivity'" and "yum install openoffice.org-headless" and have the entailed Java dependencies installed: 'java-1.5.0-gcj' , 'sinjdoc', 'java_cup', 'lucene', 'saxon', 'jdom', 'xalan-j2', … See here<http://jira.xwiki.org/jira/browse/XAOFFICE-5?focusedCommentId=35043&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_35043>for details.
The OpenOffice server currently must run as same user running the Java Web Container. For example, if user 'tomcat' runs the Tomcat server, then the same user must be used to start the OpenOffice server. However since 'tomcat' is not a login account, the OpenOffice server setup requires a first interactive run of the application via the "console" or remote X server. This allows it to write configuration files used when it is launched as a server.
First, we create a new account 'OOo' to run the Open Office server interactively for its first run:
ROOT-MYHOST-105-~> useradd --user-group --password MYPASSWORD OOo ROOT-MYHOST-106-~> cp -rp .ssh ~OOo ## optional copy existing user's SSH credentials, for remote login
ROOT-MYHOST-107-~> chown -R OOo ~OOo/.ssh ## optional change ownership so SSH works
Log in to this account "OOo/MYPASSWORD" via console or via "ssh -Y OOO@MYHOST". Run OpenOffice launch program 'ooffice' once either from the SSH session or from a console menu or terminal. From the menu-bar, select "Tools->Options..." and from the "Options" dialog, open the "Openoffice.org" hierarchy and select "Java." In "Java options" be sure "Use a java runtime environment" checkbox is selected, and that the "Free Software Foundation 1.5.0" (/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre) java is selected. Then click Ok to submit the "Options" dialog. Finally, select "File->Exit" from menu-bar and openoffice should save this configuration for future use by the OpenOffice server.
Now that OpenOffice is setup for interactive use, we now need to change it over to a "server" setup. This is done by changing permissions on the ~OOo home-directory so that 'tomcat' can write the directory. Since we're no longer going to login on the "OOo" account, first thing we do is disable it:
chsh -s /sbin/nologin OOo ## you may also want to !! away the associated password in /etc/shadow
Openoffice uses two directories to persist "user" files in ~OOo; 'ooserver-start' also writes log files into ~OOo. Therefore we set permissions for the affected directories:
ROOT-MYHOST-112-~> chown -R tomcat.tomcat ~OOo/.openoffice.org ROOT-MYHOST-113-~> chown -R tomcat.tomcat ~OOo/.fontconfig ROOT-MYHOST-125-~> chown tomcat.tomcat ~OOo
The server invocation is:
sudo -u tomcat /usr/local/bin/ooserver-start
Sudo <http://fedorasolved.org/post-install-solutions/sudo> is used to run the script /usr/local/bin/ooserver-start as user 'tomcat':
#!/bin/bash export OO_SERVER="/usr/bin/ooffice" export OO_FLAGS="-nofirststartwizard" export OO_ACCEPT="socket,host=127.0.0.1,port=8100;urp;"
export OO_LOG="OOSERV.log" export USER="OOo" export LOGNAME="$USER" export HOME="/home/$USER"
unset DISPLAY #### Prevent OO from running interactive; force failure on missing openoffice.org-headless echo DISPLAY="$DISPLAY" #### for details, see http://www.artofsolving.com/node/12
echo Cleaning up in $HOME cd $HOME killall soffice.bin killall soffice.bin ### second kill's error message means the first one succeeded rm -f .openoffice.org/3/.lock ### Lockfile left from previous ^C'd invocation
rm -f OOSERV-LOG.bak mv -f $OO_LOG OOSERV-LOG.bak ### Backup previous logfile echo Starting $OO_SERVER -- see $OO_LOG for details exec $OO_SERVER -headless -accept="$OO_ACCEPT" $OO_FLAGS < /dev/null > $OO_LOG 2>&1 &
The running Openoffice server leaves a socket for communications in /tmp by default (perhaps this is the reason why the OpenOffice server must be the same user as the java webserver??):
srwxr-xr-x 1 tomcat tomcat 0 2009-01-27 17:57 /tmp/OSL_PIPE_91_SingleOfficeIPC_cabcdef0123456789abcd=
To automate startup of the OpenOffice server on boot, consider using the SysV init runlevel system<http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-boot-init-shutdown-sysv.html>and a script like /etc/init.d/openoffice<http://little.bluethings.net/2008/05/30/automating-document-conversion-in-linux-using-jodconverterooo/> .
... nmayer | 2009/01/22 02:14
IMHO, it would be a significant improvement if the OpenOffice server could run as a different user than the one which runs the web-container, such as 'tomcat' on fedora 10. The entire reason you want to run tomcat as a lower-privilege user is specifically to give it a "container" to run in, in which it has less chance of accidentally overwriting some other part of the system configuration, such as the port-80 webserver's configuration. By the "principle of least privilege" we want Java/Web-Container stuff running as a low-priv user (100<499) that can only bind nonprivileged ports. That's why tomcat runs on port 8080 or 8000 and you use Apache httpd and mod_jk etc to provide a "secure" front for Java that sysadmins have approved for use on privileged ports like port 80.
Also, by the principle of least priviledge and reduction of overlapping concerns, low privilege users such as 'tomcat' should only be able to write to a very specific part of the filesystem. Likewise a different user, e.g. 'ooserv' in the example above, should be the only user able to write in /home/ooserv and be the user running the OpenOffice server. If someone "hacks" via the OpenOffice server importer, at best they'll be able to get it to write some data into /home/ooserv, but it will not be able to change which web-apps are deployed on your server. The latter could potentially happen, in theory, because the OpenOffice server is running as same user as the Java web conainer.
There's no reason for this either. The openoffice server should be able to accept connections from any other process on the system given that it is listening on localhost, per the "socket,host=127.0.0.1,port=8100;urp;" setting.
-- Niels http://nielsmayer.com
Hi Neils, +1, However, I'd also like to express a wish for the ability to launch the
openoffice server the "old fashioned tedious way" for those with security concerns and a desire for standards of service administration on web servers. Does this new release re-enable that capability that was removed from 1.8M2?
Currently we are evaluating the possibility of sharing an OpenOffice.org server instance between multiple wikis. Jodconverter at the moment does not support this feature: http://groups.google.com/group/jodconverter/browse_thread/thread/f4505c24545... we believe that some hacking into jodconverter will allow us to implement this feature. Putting everything together (if we succeed with hacking jodconverter), OfficeImporter admin interface will allow admins to either specify an external OOo server to connect to or let XE start it's own OOo server process. This would be the ideal outcome, lets's see if we can get there :) Thanks. - Asiri
Hi Guys, The class for external processes is already available http://code.google.com/p/jodconverter/source/browse/tags/3.0-beta-2/jodconve... Which basically means you just need to modify this code to call a different ProcessOfficeManager /** * Initializes the internal {@link OfficeManager}. */ private void initializeOfficeManager() throws OpenOfficeServerManagerException { File officeHome = new File(getOfficeHome()); File officeProfile = new File(getOfficeProfile()); try { ManagedProcessOfficeManager managedProcessOfficeManager = new ManagedProcessOfficeManager(officeHome, officeProfile); managedProcessOfficeManager.setMaxTasksPerProcess(configuration.getMaxTasksPerProcess()); managedProcessOfficeManager.setTaskExecutionTimeout(configuration.getTaskExecutionTimeout()); this.officeManager = managedProcessOfficeManager; this.documentConverter = new OfficeDocumentConverter(officeManager); setOfficeManagerInitialized(true); } catch (IllegalArgumentException ex) { currentState = ServerState.CONF_ERROR; throw new OpenOfficeServerManagerException("Error while initializing OpenOffice server.", ex); } } Ludovic Asiri Rathnayake a écrit :
Hi Neils,
+1, However, I'd also like to express a wish for the ability to launch the
openoffice server the "old fashioned tedious way" for those with security concerns and a desire for standards of service administration on web servers. Does this new release re-enable that capability that was removed from 1.8M2?
Currently we are evaluating the possibility of sharing an OpenOffice.org server instance between multiple wikis. Jodconverter at the moment does not support this feature: http://groups.google.com/group/jodconverter/browse_thread/thread/f4505c24545... we believe that some hacking into jodconverter will allow us to implement this feature.
Putting everything together (if we succeed with hacking jodconverter), OfficeImporter admin interface will allow admins to either specify an external OOo server to connect to or let XE start it's own OOo server process. This would be the ideal outcome, lets's see if we can get there :)
Thanks.
- Asiri _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Hi, On Tue, Apr 28, 2009 at 12:27 PM, Ludovic Dubost <[email protected]> wrote:
Hi Guys,
The class for external processes is already available
http://code.google.com/p/jodconverter/source/browse/tags/3.0-beta-2/jodconve...
Which basically means you just need to modify this code to call a different ProcessOfficeManager
Yes, but this is for a "external but local" openoffice process (OOo process running inside the local computer). It seems like a small hack into this class: http://code.google.com/p/jodconverter/source/browse/tags/3.0-beta-2/jodconve... would allow us to connect to a remote OOo server (changing accept string). But I highly doubt that is enough, otherwise mirko would have already implemented it. I will update all of you once I get a chance to look at the code more closely. Thanks. - Asiri
It looks like we can even override the class OfficeConnectionMode ourselves and pass it as a parameter to the ExternalProcessOfficeManager constructor. That's the easiest way without needed a special build of officeimport. I don't think that the fact that it was not done necessarly means it is difficult. The need might just not have been there. Ludovic Asiri Rathnayake a écrit :
Hi,
On Tue, Apr 28, 2009 at 12:27 PM, Ludovic Dubost <[email protected]> wrote:
Hi Guys,
The class for external processes is already available
http://code.google.com/p/jodconverter/source/browse/tags/3.0-beta-2/jodconve...
Which basically means you just need to modify this code to call a different ProcessOfficeManager
Yes, but this is for a "external but local" openoffice process (OOo process running inside the local computer).
It seems like a small hack into this class:
http://code.google.com/p/jodconverter/source/browse/tags/3.0-beta-2/jodconve...
would allow us to connect to a remote OOo server (changing accept string). But I highly doubt that is enough, otherwise mirko would have already implemented it.
I will update all of you once I get a chance to look at the code more closely.
Thanks.
- Asiri _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Tue, Apr 28, 2009 at 12:38 AM, Asiri Rathnayake < [email protected]> wrote:
Yes, but this is for a "external but local" openoffice process (OOo process running inside the local computer).
It seems like a small hack into this class:
http://code.google.com/p/jodconverter/source/browse/tags/3.0-beta-2/jodconve...
The existing OOo IPC uses named-pipes/unix domain sockets via OfficeConnectionMode#pipe(). This means the OOo process must be running on the same box as xwiki. To allow remote service,TCP/IP needs to be used instead via analogous calls to OfficeConnectionMode#socket() to set up the connection via a TCP/IP socket. -- Niels http://nielsmayer.com
On Mon, Apr 27, 2009 at 8:35 PM, Niels Mayer <[email protected]> wrote:
Likewise a different user, e.g. 'ooserv' in the example above, should be
the only user able to write in /home/ooserv and be the user running the OpenOffice server. If someone "hacks" via the OpenOffice server importer, at best they'll be able to get it to write some data into /home/ooserv, but it will not be able to change which web-apps are deployed on your server. The latter could potentially happen, in theory, because the OpenOffice server is running as same user as the Java web container.
Speaking of the above, can anybody think of any scenarios that would get the openoffice converter to output some embedded velocity that would then get called on every page view of the imported document?
The last time I used the OOo converter, the resulting document presented with an empty creation- or modify- user field(bug?) and not the user that imported the document (e.g. "Creation by on Jan 27, 2009 17:58:17 GMT-08:00" in http://morgellonswiki.info/xwiki/bin/view/Sandbox/GLN_Int-J-Med-98#Informati...) If the document written with such an unexpected user field causes accidental invocation of $doc.saveWithProgrammingRights(), there would be an escalation of privilege issue that would allow destructive access to the database. Even with the document's creation/modify set correctly, a further potential scenario exists: ``Innocent-sounding user asks admin for help fixing imported document, admin "fixes" problem, but saves the document with programming rights (since he's admin). Now the previously disabled velocity hidden in the document starts working....'' In other words, it might be a good idea to take extraordinary "defensive programming <http://en.wikipedia.org/wiki/Defensive_programming>" measures to make sure $doc.saveWithProgrammingRights() can never be called on an imported document. Or generalizing further, that it shouldn't be called when an admin saves any document that wasn't previously saved with programming rights without a special notification indicating which other user's modifications you'd be trusting.... (¿Comments?) -- Niels http://nielsmayer.com
Hi Devs,
The other feature is a frequently requested one (auto-strart) and admins are having a hard time without this feature :)
There is a slight change of approach towards implementing this feature. Due to some technical limitations it seems like we cannot start the openoffice server when XE is started. But there is a better solution, we start the openoffice server when officeimporter component is loaded into the memory first time - this is done only if the autostart configuration option is set. Everything else remains the same. I hope this is ok with you, any comments are welcome. Thanks. - Asiri
On May 4, 2009, at 12:35 PM, Asiri Rathnayake wrote:
Hi Devs,
The other feature is a frequently requested one (auto-strart) and admins are having a hard time without this feature :)
There is a slight change of approach towards implementing this feature. Due to some technical limitations it seems like we cannot start the openoffice server when XE is started. But there is a better solution, we start the openoffice server when officeimporter component is loaded into the memory first time - this is done only if the autostart configuration option is set.
Everything else remains the same.
I hope this is ok with you, any comments are welcome.
hmmm as a general comment I don't like it too much since it means the user will have to wait more when doing the first import. I consider this a hack and not a better solution. It should pretty easy to add a clean notion of container initialization using components (in xwiki-containers). Right now there's already the notion of Request init and Execution context init. Note also that in XWiki.java there's already the notion of initialization (the variable "initdone" is put in the XWiki Context). Thanks -Vincent
Hi On Mon, May 4, 2009 at 4:38 PM, Vincent Massol <[email protected]> wrote:
On May 4, 2009, at 12:35 PM, Asiri Rathnayake wrote:
Hi Devs,
The other feature is a frequently requested one (auto-strart) and admins are having a hard time without this feature :)
There is a slight change of approach towards implementing this feature. Due to some technical limitations it seems like we cannot start the openoffice server when XE is started. But there is a better solution, we start the openoffice server when officeimporter component is loaded into the memory first time - this is done only if the autostart configuration option is set.
Everything else remains the same.
I hope this is ok with you, any comments are welcome.
hmmm as a general comment I don't like it too much since it means the user will have to wait more when doing the first import.
Actually it's not the first import that will start the openoffice server but the first time the wiki is opened on browser. It seems like plexus loads all the components when the user visits the wiki for the first time on browser. I consider this a hack and not a better solution.
It should pretty easy to add a clean notion of container initialization using components (in xwiki-containers). Right now there's already the notion of Request init and Execution context init.
Note also that in XWiki.java there's already the notion of initialization (the variable "initdone" is put in the XWiki Context).
Well, I could directly load openoffice server manager component upon container initialization (DefaultServletContainerInitializer) and start the openoffice server. But we don't want openoffice server manipulation code inside DefaultServletContainerInitializer, that's why we wanted to go with ObservationManager. But then came the problem of loading openoffice server manager at startup (otherwise it will not receive startup notifications). I can't think of a working acceptable solution that will allow me to load the openoffice server manager component at startup.. Thanks. - Asiri
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On May 4, 2009, at 1:35 PM, Asiri Rathnayake wrote:
Hi
On Mon, May 4, 2009 at 4:38 PM, Vincent Massol <[email protected]> wrote:
On May 4, 2009, at 12:35 PM, Asiri Rathnayake wrote:
Hi Devs,
The other feature is a frequently requested one (auto-strart) and admins are having a hard time without this feature :)
There is a slight change of approach towards implementing this feature. Due to some technical limitations it seems like we cannot start the openoffice server when XE is started. But there is a better solution, we start the openoffice server when officeimporter component is loaded into the memory first time - this is done only if the autostart configuration option is set.
Everything else remains the same.
I hope this is ok with you, any comments are welcome.
hmmm as a general comment I don't like it too much since it means the user will have to wait more when doing the first import.
Actually it's not the first import that will start the openoffice server but the first time the wiki is opened on browser. It seems like plexus loads all the components when the user visits the wiki for the first time on browser.
No this is not the case. Components are loaded on the first lookup.
I consider this a hack and not a better solution.
It should pretty easy to add a clean notion of container initialization using components (in xwiki-containers). Right now there's already the notion of Request init and Execution context init.
Note also that in XWiki.java there's already the notion of initialization (the variable "initdone" is put in the XWiki Context).
Well, I could directly load openoffice server manager component upon container initialization (DefaultServletContainerInitializer) and start the openoffice server. But we don't want openoffice server manipulation code inside DefaultServletContainerInitializer,
I didn't say that! Of course we don't want to tie in any dependency. Asiri you should read about Request initialization and Execution Context initialization. It doesn't tie any user of it in the xwiki- containers module. -Vincent
that's why we wanted to go with ObservationManager. But then came the problem of loading openoffice server manager at startup (otherwise it will not receive startup notifications). I can't think of a working acceptable solution that will allow me to load the openoffice server manager component at startup..
Thanks.
- Asiri
Hi, No this is not the case. Components are loaded on the first lookup.
Hmmm, it is what I experienced... :-?
I didn't say that! Of course we don't want to tie in any dependency. Asiri you should read about Request initialization and Execution Context initialization. It doesn't tie any user of it in the xwiki- containers module.
Ok. I will digg around and see. Thanks. - Asiri
participants (7)
-
Asiri Rathnayake -
Guillaume Lerouge -
Ludovic Dubost -
Marius Dumitru Florea -
Niels Mayer -
Sergiu Dumitriu -
Vincent Massol