This is quite a big step forward. Before this, you had to publish html pages and copy them to your target webserver.
EPF build in is a lucene search. If you stick to tomcat you never will run into any problems with this construct. If you try to use the Oracle Weblogic to deploy your process.war file, you get into trouble.
The root of all evil is the spec. The org.eclipse.epf.web.servlet.SearchServlet uses
ServletConfig.getServletContext().getRealPath(index) to determine the lucene index location. If you look at the Servlet Specification you read this:
The real path returned will be in a form appropriate to the computer and
operating system on which the servlet container is running, including the
proper path separators. This method returns null if the servlet container
cannot translate the virtual path to a real path for any reason (such as
when the content is being made available from a .war archive).
Tomcat for example returns the path of the actual exploded deployment. Weblogic simply returns null here.
LD> _indexPath: null
LD> _currentSearchString: test
LD> unicodes: test
LD> analyzerName: null
LD> _hits: null
java.lang.NullPointerException
at org.eclipse.epf.web.servlet.SearchServlet.runQuery(SearchServlet.java
:206)
at org.eclipse.epf.web.servlet.SearchServlet.runSearch(SearchServlet.jav
a:174)
at org.eclipse.epf.web.servlet.SearchServlet.doGet(SearchServlet.java:12
9)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:821)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run
(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecuri
tyHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.jav
a:292)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.jav
a:176)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio
n.run(WebAppServletContext.java:3498)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Authenticate
dSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppS
ervletContext.java:2180)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletC
ontext.java:2086)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.j
ava:1406)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Ok. What to do to get this working on Oracle Weblogic Server? You have different options.
1) you can simply deploy the process.war exploded. No NullPointerException, everything works fine. If this is no option for you, you need to digg deeper
2) you can change the org.eclipse.epf.web.servlet.SearchServlet a bit to refer to absolute paths. Look at lines 64/65 and change them to:
_indexPath = config.getInitParameter("searchIndex");
_xslURL = config.getInitParameter("xslFile");
This means, you have to move the index directory out of the war to a separate location on your disc. After this you should also change the web.xml:
<init-param>
<param-name>searchIndex</param-name>
<param-value>Drive:/your/path/to/the/index</param-value>
</init-param>
This mean, you always have to distribute the search index as a separate directory. I Should mention here, that I realy did not try this out at all. You may come across some more issues with the org.eclipse.epf.web.search.IndexSearch after this.
3) you can do some heavier modifications on the codebase. Its an option to change the lucene directory driver. A good beginning for further research on this could be this thread in the lucene java-users mailinglist. I will possibly get the change to a more deeper look at the 3rd way in the future ...
