tunnel-web error: PermissionChecker not initialized

[Raymond Jones, geändert vor 15 Jahren.]

I generated a JAX-RPC client with NetBeans 6.1 for Liferay 5.0.1 RC UserService and wrote a simple test case utilizing it. The test fails resulting to the stack trace below.

So, am I missing some authentication issue or is this a bug in tunnel-web implementation?

public class UserServiceSoapTest extends TestCase {

    private static final long COMPANY_ID = 10108;

    private UserServiceSoap soap = null;
    
    @Before
    public void setUp() {        
        UserServiceSoapService soapService = new UserServiceSoapService_Impl();
        soap = new UserServiceSoapService_Impl().getPortal_UserService();
    }

    /**
     * Test of updateUser method, of class UserServiceSoap.
     */
    @Test
    public void testGetUserByScreenName() throws Exception {
        assertNotNull(soap.getUserByScreenName(COMPANY_ID, "test"));
    }

}

17:13:14,273 ERROR [UserServiceSoap:60] com.liferay.portal.security.auth.PrincipalException: PermissionChecker not initialized
com.liferay.portal.security.auth.PrincipalException: PermissionChecker not initialized
        at com.liferay.portal.service.impl.PrincipalBean.getPermissionChecker(PrincipalBean.java:77)
        at com.liferay.portal.service.impl.UserServiceImpl.getUserByScreenName(UserServiceImpl.java:244)
        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:597)
        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:301)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
        at $Proxy91.getUserByScreenName(Unknown Source)
        at com.liferay.portal.service.UserServiceUtil.getUserByScreenName(UserServiceUtil.java:180)
        at com.liferay.portal.service.http.UserServiceSoap.getUserByScreenName(UserServiceSoap.java:267)
        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:597)
        at org.apache.axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java:397)
        at org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:186)
        at org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:323)
        at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
        at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
        at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
        at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:454)
        at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281)
        at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:699)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
        at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
        at com.liferay.portal.servlet.AxisServlet.service(AxisServlet.java:83)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at com.liferay.portal.kernel.servlet.PortalClassLoaderServlet.service(PortalClassLoaderServlet.java:88)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
        at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:98)
        at com.liferay.portal.servlet.filters.secure.SecureFilter.doFilter(SecureFilter.java:205)
        at com.liferay.portal.kernel.servlet.PortalClassLoaderFilter.doFilter(PortalClassLoaderFilter.java:87)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
        at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
        at java.lang.Thread.run(Thread.java:619)

[Lari Tuominen, geändert vor 15 Jahren.]

Hi Raymond,

Did you find any solution for this problem?

- Lari

[Lari Tuominen, geändert vor 15 Jahren.]

OK, I had malformed URL..... it needs to be in format http://<user ID>:<password>@<server name>:<port number>/tunnel-web/secure/axis/<service> as mentioned in liferay-administration guide.

- Lari

[Carlos Ernesto Descalzi, geändert vor 15 Jahren.]

Hi all,

I have a similar problem when using Soap.
In my case it works after a while, as if it takes longer to initialize than the rest of liferay. Actually is not a blocker, but since soap interfaces are being used by a JAAS login module in another server, it becomes annoying.

I was using 5.2.1 and I've just updated to 5.2.2

Any thought about what can be the issue?.

Thanks.

[Carlos Ernesto Descalzi, geändert vor 15 Jahren.]

Digging in the code I found the problem is a thread local which is not properly initialized.
Once "something else" sets its value, seems the permission checker works, but looks like it is because the thread local that is not purged.

[Harri T., geändert vor 14 Jahren.]

I reported this issue.

[Ian Gratton, geändert vor 14 Jahren.]

Hi there, my first post on your forums - thanks for building such a great portal platform.

I've just started out on a Liferay integration project where we want to be able to interact with the portal directly using the Axis web services it provides for admin functions.

We too are getting issues with the Permission Checker in a very intermittent way.

Sometimes the web services work, sometimes we get the same soap fault thrown as you have already mentioned, i.e:

AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
 faultSubcode: 
 faultString: java.rmi.RemoteException: PermissionChecker not initialized
 faultActor: 
 faultNode: 
 faultDetail: 
	{http://xml.apache.org/axis/}hostname:localhost

Our issue is nothing to do with IP address restrictions via the axis.servlet.hosts.allowed property. All the hosts we want to be able to access the web services are listed. We are using proper user ids and encrypted passwords found in User_.userid and User_.password_ columns in the database. It also doesn't seem to matter if you use the web service client like this:

UserServiceSoapService svc = new UserServiceSoapServiceLocator();
UserServiceSoap userService = svc.getPortal_UserService(new URL("http://99999:xxxxXXXXxxxxXXX=@localhost:8080/tunnel-web/axis/Portal_UserService"));

or like this

UserServiceSoapService svc = new UserServiceSoapServiceLocator();
UserServiceSoap userService = svc.getPortal_UserService(new URL("http://localhost:8080/tunnel-web/axis/Portal_UserService"));
((Portal_UserServiceSoapBindingStub)userService).setUsername("99999");
((Portal_UserServiceSoapBindingStub)userService).setPassword("xxxxXXXXxxxxXXX=");	

So as you say it seems like a time-based issue at start up - the PermissionChecker does not get fired up straight way.

Has anyone found a suitable way to poke the Permission Checker into life so web service calls begin to work ? Its not ideal that the portal magically starts to to serve web service requests after some random undetermined period of time.

Have any fixes been made to address this issue that are not in trunk ? Any insight into this issue would be greatly appreciated.

Regards

Ian.

[Ian Gratton, geändert vor 14 Jahren.]

Ok,

bit more information for you here that may aid in understanding more about this problem. I'm obviously new to the forums but I am eager to get to the bottom of this problem as I suspect are others judging by some of the posts that exist surrounding Liferays web service interfaces.

The simple Axis java client I have built in eclipse (this is just to test things out) obviously forms the URL in the above code sample to access the tunnel-web context. Obviously I see the soap fault.

This is the strange thing I have found

If I run my simple java app that attempts to call the Portal_UserService.getUserById I get the soap fault.

Then if I then go to the machine that is hosting the Liferay portal and access the WSDL for this service from a browser (or something as simple as hitting it with curl or wget) i.e.

http://99999:xxxxXXXXxxxxXXX=@localhost:8080/tunnel-web/axis/Portal_UserService?wsdl

Then if I got back to the other machine and run my Java web service client the code works just fine. If I attempt to run the Java client again it works for maybe another 3 or 4 times and then fails again with the soap fault.

If I then go back to the machine running the portal and access the WSDL again and then go back to the machine with the Java client the web service call works for a random number of times. I have since found I can access the WSDL from the same machine running the java client via my browser and that has the same effect of making the web services work for a few moments.

It seems a little bizarre that somebody requesting the WSDL for a service on a completely different machine would cause my web service call to work - but obviously for a seemingly random number times. Sometimes the java service works between 1-5 time before resorting back to getting the soap fault. If I go and prod the WSDL again it starts to work - well - for a while.

This is very very strange - why would accessing the WSDL from a service down in the tunnel-web app cause some functionality inside of the portal to work for a short period of time and then begin to fail after a random period of time ?

If you think there is anything I can do to help diagnose this please let me know.

It would be pretty horrible if we have to resort to interacting directly with the portal database itself - obviously to do this you have to turn of all caching that can take place within hibernate as it will maybe miss changes that are happening to the database outside of the portal. The web services provide a nice level of abstraction from the innards of the portal - its just a real shame they don't work consistently.

It would be interesting to see if anyone else having this problem can get their web service clients to work in the same way by hitting the wsdl.

[Austin Mulvihill, geändert vor 14 Jahren.]

Ian Gratton:

http://99999:xxxxXXXXxxxxXXX=@localhost:8080/tunnel-web/axis/Portal_UserService?wsdl

You might have mistyped it but I do know that if you are going to provide a user ID and password, you should use /tunnel-web/secure/axis/

I am having this problem too. My specifics are as follows:

portal-ext.properties
axis.servlet.hosts.allowed=xx.x.x.xxx(my ip),127.0.0.1,SERVER_IP
axis.servlet.https.required=false

I don't use the secure one (at least for now, in dev)

Everything has been working for several days now, but suddenly, when I try to call

user=proxy.getUserByEmailAddress(company.getCompanyId(), email);

I get

java.rmi.RemoteException: PermissionChecker not initialized

ONLY if a user exists with that email. (If it doesn't exist it throws

com.liferay.portal.NoSuchUserException: No User exists with the key

but I plan for that)

[Ian Gratton, geändert vor 14 Jahren.]

Hi Austin,

thanks for taking the time to reply.

I will try and check later on what happens when I go via tunnel-web/secure/axis

It obviously seems to work to some extent if you don't.

Regards

Ian.

[Gloria Muñoz, geändert vor 14 Jahren.]

Any feedback on this?

Austin, right now I'm exactly at the same point of you, same test case:

portal-ext.properties
axis.servlet.hosts.allowed=xx.x.x.xxx(my ip),127.0.0.1,SERVER_IP
axis.servlet.https.required=false

Everything has been working for several days now, but suddenly, when I try to call
1user=proxy.getUserByEmailAddress(company.getCompanyId(), email);

I get
java.rmi.RemoteException: PermissionChecker not initialized
ONLY if a user exists with that email. (If it doesn't exist it throws
com.liferay.portal.NoSuchUserException: No User exists with the key
but I plan for that)

Did you find a solution??

[Ian Gratton, geändert vor 14 Jahren.]

Hi Gloria,

if I go via the URL you suggest i.e:

http://<hostname>:/tunnel-web/secure/axis/Portal_UserService</hostname>

I don't seem to get the PermissionChecker issues any more. I've tried different scenarios that would have caused problems before like invoking the services after the portal has just been started, no portal users logged, re-accessing the WSDL, some portal users logged in etc. and each one now seems fine.

The only difference with this technique is you no longer have to encode a liferay user id and encrypted password into the URL. You now have to use this technique in your java client code e.g:

((Portal_UserServiceSoapBindingStub)userService).setUsername("[e-mail]");
((Portal_UserServiceSoapBindingStub)userService).setPassword("test");

I will continue on with what I was doing now but it seems this is maybe the solution to the PermissionChecker problems people are getting. If I come across anything I think is related I will update the thread.

Thanks again for your help.

Ian

[Ian Gratton, geändert vor 14 Jahren.]

Another quick update

After the changes above things have been working for a while but every now and again I get the following error thrown back in my Java web service client

Remote Service call failed
AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
 faultSubcode: 
 faultString: java.rmi.RemoteException
 faultActor: 
 faultNode: 
 faultDetail: 
	{http://xml.apache.org/axis/}hostname:LOCALHOST

java.rmi.RemoteException
	at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222)
	at org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:129)
	at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1774)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2930)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
	at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
	at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
	at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
	at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
	at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
	at org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
	at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
	at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
	at org.apache.axis.client.Call.invoke(Call.java:2767)
	at org.apache.axis.client.Call.invoke(Call.java:2443)
	at org.apache.axis.client.Call.invoke(Call.java:2366)
	at org.apache.axis.client.Call.invoke(Call.java:1812)
	at com.liferay.portal.service.http.Portal_GroupServiceSoapBindingStub.addGroup(Portal_GroupServiceSoapBindingStub.java:637)

And inside the Tomcat instance which is hosting liferay we see.

17:17:42,717 ERROR [GroupServiceSoap:95] com.liferay.portal.security.auth.PrincipalException
com.liferay.portal.security.auth.PrincipalException
        at com.liferay.portal.service.base.PrincipalBean.getUserId(PrincipalBean.java:91)
        at com.liferay.portal.service.impl.GroupServiceImpl.addGroup(GroupServiceImpl.java:60)
        at sun.reflect.GeneratedMethodAccessor753.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
        at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
        at $Proxy23.addGroup(Unknown Source)
        at com.liferay.portal.service.GroupServiceUtil.addGroup(GroupServiceUtil.java:54)
        at com.liferay.portal.service.http.GroupServiceSoap.addGroup(GroupServiceSoap.java:89)
        at sun.reflect.GeneratedMethodAccessor752.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.apache.axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java:397)
        at org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:186)
        at org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:323)
        at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
        at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
        at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
        at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:454)
        at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281)
        at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:699)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
        at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
        at com.liferay.portal.servlet.AxisServlet.service(AxisServlet.java:79)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at com.liferay.portal.kernel.servlet.PortalClassLoaderServlet.service(PortalClassLoaderServlet.java:108)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:154)
        at com.liferay.portal.servlet.filters.secure.SecureFilter.processFilter(SecureFilter.java:282)
        at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:91)
        at com.liferay.portal.kernel.servlet.PortalClassLoaderFilter.doFilter(PortalClassLoaderFilter.java:78)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Unknown Source)

Now obviously every time I set up a call to a web service (be it accessing Portal_UserService, Portal_GroupService, or Portal_LayoutService) I am always passing through the username and password.

e.g.

((Portal_UserServiceSoapBindingStub)userService).setUsername(LIFERAY_USERNAME);
((Portal_UserServiceSoapBindingStub)userService).setPassword(LIFERAY_PASSWORD);

or

((Portal_GroupServiceSoapBindingStub)groupService).setUsername(LIFERAY_USERNAME);
((Portal_GroupServiceSoapBindingStub)groupService).setPassword(LIFERAY_PASSWORD);

or

((Portal_LayoutServiceSoapBindingStub)layoutService).setUsername(LIFERAY_USERNAME);
((Portal_LayoutServiceSoapBindingStub)layoutService).setPassword(LIFERAY_PASSWORD);

Providing I always call Portal_UserService.getUserById(<value>) first - all the other web service calls work. If I try and interact with Portal_GroupService.addGroup() it can sometimes result in the com.liferay.portal.security.auth.PrincipalException that you can see above.

This seems very very strange. For now I can obviously ensure I try and access Portal_UserService.getUserById(<some-known-value>) prior to accessing any other web services but it is not ideal as I'm obviously having to make an additional call each time I interact with the Portal via the web services.

Do you think this is just the issue with the PermissionChecker that I'm seeing in a slightly different context ? Any Ideas ?

[Austin Mulvihill, geändert vor 14 Jahren.]

Good news:

At this moment, I am running my test program off my local box trying to access our dev liferay in the datacenter and it is failing, throwing the PrincipalException.
However, I am testing code in a .war that I deployed to liferay's tomcat/webapps directory and it is not having issues.

I am using the user id/password with /tunnel-web/secure/axis in both environments.

This is good enough for me, at least it works when I go to deploy it, if I have to do all my testing on the server, that is a little inconvenient but okay.

UPDATE: So it is only working in our dev environment, but not in our QA environment

[Dan Posey, geändert vor 14 Jahren.]

In addition to the PermissionChecker error, it also appears that the lucene information does not get updated when a

addPage(nodeId, "pagetitle", "== Content ==", "\"", false, "creole", "FrontPage", "\"", context);

is called.

So when doing a search on the page that is added (when it does work) the search does not return the page.

I have found that the addPage function works only once when the Social Office application is restarted and only after the initial user login.

This happens with the WikiPageServiceSoap service = locater.getPortlet_Wiki_WikiPageService();