Anonymous_User Absent Member.
Absent Member.
816 views

Problems starting workflow from policy after upgrade


Hello,
I recently migrated a site that was using a very old version UserApp
(3.6) all the way up to IdM 4.0.2. Everything has actually gone
surprisingly well and all the PRDs seem to work with only minor glitches
so far. So I'm quite pleased. However, I have one problem. Several of
the drivers had policy to start workflows. Those have broken now.
Whenever it tries to start a workflow from IdM policy, I see this
error:

java.rmi.RemoteException: unknown exception at server no serializer
found for "java.lang.IllegalStateException"; nested exception is:
com.novell.soa.ws.portable.ApplicationException


Since I do have the latest IdM patches on, I thought maybe it was
afadmin.jar and wssdk.jar. So I made sure and updated those in the
dirxml/classes dir on the IdM server and restarted edir, but it made no
difference (I think the error did change a bit, but I don't have the
original error handy).

So I'm at a loss on this. Any ideas why I can't do a start-workflow
from policy now? Thanks.


Matt


--
matt
------------------------------------------------------------------------
matt's Profile: https://forums.netiq.com/member.php?userid=183
View this thread: https://forums.netiq.com/showthread.php?t=48241

Labels (1)
0 Likes
15 Replies
Knowledge Partner
Knowledge Partner

Re: Problems starting workflow from policy after upgrade

On 7/19/2013 6:54 PM, matt wrote:
>
> Hello,
> I recently migrated a site that was using a very old version UserApp
> (3.6) all the way up to IdM 4.0.2. Everything has actually gone
> surprisingly well and all the PRDs seem to work with only minor glitches
> so far. So I'm quite pleased. However, I have one problem. Several of
> the drivers had policy to start workflows. Those have broken now.
> Whenever it tries to start a workflow from IdM policy, I see this
> error:
>
> java.rmi.RemoteException: unknown exception at server no serializer
> found for "java.lang.IllegalStateException"; nested exception is:
> com.novell.soa.ws.portable.ApplicationException
>
>
> Since I do have the latest IdM patches on, I thought maybe it was
> afadmin.jar and wssdk.jar. So I made sure and updated those in the
> dirxml/classes dir on the IdM server and restarted edir, but it made no
> difference (I think the error did change a bit, but I don't have the
> original error handy).


I thin kyou are on the correct track. I think there is an
nrfSomething.jar as well. If you install 4.02, make sure to apply Patch
C which includes new copies of these as well, I believe.


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Problems starting workflow from policy after upgrade


I already have 4.0.2 Patch C applied and I made sure and copied:

nrfdriver.jar
afadmin.jar
srvprvUAD.jar
wssdk.jar

From Patch C to /opt/novell/eDirectory/lib/dirxml/classes and this
problem is happening.

I ran diff's on them to make sure they were the same.

I checked that repeatedly before posting. I have an SR open too on it,
but so far nothing. I thought for sure it was the JARs which is why
I've checked repeatedly because that is the symptom, but that doesn't
appear to be it.

Matt


--
matt
------------------------------------------------------------------------
matt's Profile: https://forums.netiq.com/member.php?userid=183
View this thread: https://forums.netiq.com/showthread.php?t=48241

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Problems starting workflow from policy after upgrade

On 07/19/2013 11:24 PM, matt wrote:
>
> I already have 4.0.2 Patch C applied and I made sure and copied:
>
> nrfdriver.jar
> afadmin.jar
> srvprvUAD.jar
> wssdk.jar
>
> From Patch C to /opt/novell/eDirectory/lib/dirxml/classes and this
> problem is happening.
>
> I ran diff's on them to make sure they were the same.
>
> I checked that repeatedly before posting. I have an SR open too on it,
> but so far nothing. I thought for sure it was the JARs which is why
> I've checked repeatedly because that is the symptom, but that doesn't
> appear to be it.
>
> Matt
>
>

Greetings Matt,
In your policy, are you trying to start the workflows as the
Provisioning Admin or another user.

--

Sincerely,
Steven Williams
Lead Software Engineer
NetIQ
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Problems starting workflow from policy after upgrade

On 07/20/2013 01:30 PM, Steven Williams wrote:
> On 07/19/2013 11:24 PM, matt wrote:
>>
>> I already have 4.0.2 Patch C applied and I made sure and copied:
>>
>> nrfdriver.jar
>> afadmin.jar
>> srvprvUAD.jar
>> wssdk.jar
>>
>> From Patch C to /opt/novell/eDirectory/lib/dirxml/classes and this
>> problem is happening.
>>
>> I ran diff's on them to make sure they were the same.
>>
>> I checked that repeatedly before posting. I have an SR open too on it,
>> but so far nothing. I thought for sure it was the JARs which is why
>> I've checked repeatedly because that is the symptom, but that doesn't
>> appear to be it.
>>
>> Matt
>>
>>

> Greetings Matt,
> In your policy, are you trying to start the workflows as the
> Provisioning Admin or another user.
>

Greetings Matt,
I would tend to believe that you are not using "THE" Provisioning
Admin for the soap call. In soapUI when you use a "normal" user for the
connection (one that can login and see the WF to start it) you will get
back:

<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>no serializer found for
"java.lang.IllegalStateException"</faultstring>
<detail>
<ns1:stackTrace xsi:type="ns1:stackTrace"
xmlns:ns1="http://www.novell.com/wssdk">
<ns1:dump
xsi:type="xsd:string">com.novell.soa.ws.binding.MarshalerNotFoundException:
no serializer found for "java.lang.IllegalStateException"
......


You will need to open the endpoints as outlined in the Administration
Guide. Remember that any changes that were done within the WAR file
will be lost when you upgrade. You have to do them all over again.


I would also strongly suggest that you test with soapUI whenever having
a problem with a SOAP endpoint.



--

Sincerely,
Steven Williams
Lead Software Engineer
NetIQ
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Problems starting workflow from policy after upgrade


Steven Williams;231787 Wrote:
> On 07/20/2013 01:30 PM, Steven Williams wrote:
> > On 07/19/2013 11:24 PM, matt wrote:
> >>
> >> I already have 4.0.2 Patch C applied and I made sure and copied:
> >>
> >> nrfdriver.jar
> >> afadmin.jar
> >> srvprvUAD.jar
> >> wssdk.jar
> >>
> >> From Patch C to /opt/novell/eDirectory/lib/dirxml/classes and this
> >> problem is happening.
> >>
> >> I ran diff's on them to make sure they were the same.
> >>
> >> I checked that repeatedly before posting. I have an SR open too on

> it,
> >> but so far nothing. I thought for sure it was the JARs which is why
> >> I've checked repeatedly because that is the symptom, but that

> doesn't
> >> appear to be it.
> >>
> >> Matt
> >>
> >>

> > Greetings Matt,
> > In your policy, are you trying to start the workflows as the
> > Provisioning Admin or another user.
> >

> Greetings Matt,
> I would tend to believe that you are not using "THE" Provisioning
> Admin for the soap call. In soapUI when you use a "normal" user for
> the
> connection (one that can login and see the WF to start it) you will get
> back:
>
> <SOAP-ENV:Envelope
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
> <SOAP-ENV:Header/>
> <SOAP-ENV:Body>
> <SOAP-ENV:Fault>
> <faultcode>SOAP-ENV:Server</faultcode>
> <faultstring>no serializer found for
> "java.lang.IllegalStateException"</faultstring>
> <detail>
> <ns1:stackTrace xsi:type="ns1:stackTrace"
> xmlns:ns1="http://www.novell.com/wssdk">
> <ns1:dump
> xsi:type="xsd:string">com.novell.soa.ws.binding.MarshalerNotFoundException:
> no serializer found for "java.lang.IllegalStateException"
> ......
>
>
> You will need to open the endpoints as outlined in the Administration
> Guide. Remember that any changes that were done within the WAR file
> will be lost when you upgrade. You have to do them all over again.
>
>
> I would also strongly suggest that you test with soapUI whenever having
> a problem with a SOAP endpoint.
>
>
>
> --
>
> Sincerely,
> Steven Williams
> Lead Software Engineer
> NetIQ



There were no customizations done to the WAR file.
I'm not sure what is meant by open the endpoints, but I'll try and find
that in the docs. Are there instructions on how to test with SoapUI as
well? Thanks.

Matt


--
matt
------------------------------------------------------------------------
matt's Profile: https://forums.netiq.com/member.php?userid=183
View this thread: https://forums.netiq.com/showthread.php?t=48241

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Problems starting workflow from policy after upgrade


No, I'm not using the Provisioning Admin. But did try granting the user
rights to the Provisioning Domain with the Initiate PRD right. That
made no difference. I then tried assigning the user as a Provisioning
Administrator and that made no difference either, same error in both
cases. Is there some other right? What's also odd is that I never see
any activity in the server.log on the JBoss server when the driver tries
to start a workflow and I have to logs all in Debug. So it almost seems
like more of a software problem on the IdM server.

Matt


--
matt
------------------------------------------------------------------------
matt's Profile: https://forums.netiq.com/member.php?userid=183
View this thread: https://forums.netiq.com/showthread.php?t=48241

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Problems starting workflow from policy after upgrade

On 07/20/2013 03:24 PM, matt wrote:
>
> No, I'm not using the Provisioning Admin. But did try granting the user
> rights to the Provisioning Domain with the Initiate PRD right. That
> made no difference. I then tried assigning the user as a Provisioning
> Administrator and that made no difference either, same error in both
> cases. Is there some other right? What's also odd is that I never see
> any activity in the server.log on the JBoss server when the driver tries
> to start a workflow and I have to logs all in Debug. So it almost seems
> like more of a software problem on the IdM server.
>
> Matt
>
>

Greetings Matt,
You should only see that the user ID being pass was able to
successfully login (or not).

To open the endpoints for a Non-Prov admin to use any of the SOAP
endpoints you need to follow the steps as outlined in the Administration
Guide:

https://www.netiq.com/documentation/idm402/agpro/data/b94nzjz.html

"Removing Administrator Credential Restrictions" (section 18.1.2)


--

Sincerely,
Steven Williams
Lead Software Engineer
NetIQ
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Problems starting workflow from policy after upgrade


Steven Williams;231793 Wrote:
> On 07/20/2013 03:24 PM, matt wrote:
> >
> > No, I'm not using the Provisioning Admin. But did try granting the

> user
> > rights to the Provisioning Domain with the Initiate PRD right. That
> > made no difference. I then tried assigning the user as a

> Provisioning
> > Administrator and that made no difference either, same error in both
> > cases. Is there some other right? What's also odd is that I never

> see
> > any activity in the server.log on the JBoss server when the driver

> tries
> > to start a workflow and I have to logs all in Debug. So it almost

> seems
> > like more of a software problem on the IdM server.
> >
> > Matt
> >
> >

> Greetings Matt,
> You should only see that the user ID being pass was able to
> successfully login (or not).
>
> To open the endpoints for a Non-Prov admin to use any of the SOAP
> endpoints you need to follow the steps as outlined in the
> Administration
> Guide:
>
> https://www.netiq.com/documentation/idm402/agpro/data/b94nzjz.html
>
> "Removing Administrator Credential Restrictions" (section 18.1.2)
>
>
> --
>
> Sincerely,
> Steven Williams
> Lead Software Engineer
> NetIQ



That's the thing, I never see the user login and I have the server logs
in debug. That's why I doubt it is a rights problem. I also gave the
user Provisioning Administrator rights and I have absolutely no problem
granting those rights. I'd rather do that then modifying the WAR if I
can help it. I still believe the problem is code related since I
never even see a login attempt. I guess I can try getting some traces
to see if it is even attempting a call. Is there anywhere to see a
full Java stack trace of the error?

Matt


--
matt
------------------------------------------------------------------------
matt's Profile: https://forums.netiq.com/member.php?userid=183
View this thread: https://forums.netiq.com/showthread.php?t=48241

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Problems starting workflow from policy after upgrade


So it turns out the problem was rights.

I was making the user a Provisioning Administrator, but I was NOT
granting ALL Permissions. I was only granting Initiate PRD and View
Running PRD rights. Once I replaced that with ALL PERMISSIONS, it all
started working.

So my first question is, why did I have to grant All Permissions? And
my second is, why doesn't it throw a more descriptive error, like no
rights?

Matt


--
matt
------------------------------------------------------------------------
matt's Profile: https://forums.netiq.com/member.php?userid=183
View this thread: https://forums.netiq.com/showthread.php?t=48241

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Problems starting workflow from policy after upgrade

On 07/29/2013 09:44 PM, matt wrote:
>
> So it turns out the problem was rights.
>
> I was making the user a Provisioning Administrator, but I was NOT
> granting ALL Permissions. I was only granting Initiate PRD and View
> Running PRD rights. Once I replaced that with ALL PERMISSIONS, it all
> started working.
>
> So my first question is, why did I have to grant All Permissions? And
> my second is, why doesn't it throw a more descriptive error, like no
> rights?
>
> Matt
>
>

Greetings,
For Security reasons we can not provide the full error back to the
"SOAP" client. Generally speaking in the server.log will be the actual
error.
As stated earlier, to be able to utilize the Provisioning SOAP
endpoints, the user must be a Provisioning Admin (which means all rights).

--

Sincerely,
Steven Williams
Lead Software Engineer
NetIQ
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Problems starting workflow from policy after upgrade


Steven Williams;232090 Wrote:
> On 07/29/2013 09:44 PM, matt wrote:
> >
> > So it turns out the problem was rights.
> >
> > I was making the user a Provisioning Administrator, but I was NOT
> > granting ALL Permissions. I was only granting Initiate PRD and View
> > Running PRD rights. Once I replaced that with ALL PERMISSIONS, it

> all
> > started working.
> >
> > So my first question is, why did I have to grant All Permissions?

> And
> > my second is, why doesn't it throw a more descriptive error, like no
> > rights?
> >
> > Matt
> >
> >

> Greetings,
> For Security reasons we can not provide the full error back to the
> "SOAP" client. Generally speaking in the server.log will be the actual
> error.
> As stated earlier, to be able to utilize the Provisioning SOAP
> endpoints, the user must be a Provisioning Admin (which means all
> rights).
>
> --
>
> Sincerely,
> Steven Williams
> Lead Software Engineer
> NetIQ



I guess I'm still a little confused, when you make someone a
Provisioning Administrator, there is a check box for All Permissions.
If you don't check it, you have to go back and assign individual
permissions. So I don't see how a Prov. Admin automatically means all
rights? Or am I missing something?

Hmm, I had the server log at trace, maybe I just did not see it. Would
it really be that big a security issue to just say something like
"insufficient rights"?

Anyway, thanks for the help Steven.

Matt


--
matt
------------------------------------------------------------------------
matt's Profile: https://forums.netiq.com/member.php?userid=183
View this thread: https://forums.netiq.com/showthread.php?t=48241

0 Likes
Knowledge Partner
Knowledge Partner

Re: Problems starting workflow from policy after upgrade

On 7/30/2013 7:14 PM, matt wrote:
>
> Steven Williams;232090 Wrote:
>> On 07/29/2013 09:44 PM, matt wrote:
>>>
>>> So it turns out the problem was rights.
>>>
>>> I was making the user a Provisioning Administrator, but I was NOT
>>> granting ALL Permissions. I was only granting Initiate PRD and View
>>> Running PRD rights. Once I replaced that with ALL PERMISSIONS, it

>> all
>>> started working.
>>>
>>> So my first question is, why did I have to grant All Permissions?

>> And
>>> my second is, why doesn't it throw a more descriptive error, like no
>>> rights?
>>>
>>> Matt
>>>
>>>

>> Greetings,
>> For Security reasons we can not provide the full error back to the
>> "SOAP" client. Generally speaking in the server.log will be the actual
>> error.
>> As stated earlier, to be able to utilize the Provisioning SOAP
>> endpoints, the user must be a Provisioning Admin (which means all
>> rights).
>>
>> --
>>
>> Sincerely,
>> Steven Williams
>> Lead Software Engineer
>> NetIQ

>
>
> I guess I'm still a little confused, when you make someone a
> Provisioning Administrator, there is a check box for All Permissions.
> If you don't check it, you have to go back and assign individual
> permissions. So I don't see how a Prov. Admin automatically means all
> rights? Or am I missing something?
>
> Hmm, I had the server log at trace, maybe I just did not see it. Would
> it really be that big a security issue to just say something like
> "insufficient rights"?
>
> Anyway, thanks for the help Steven.


It is the same reason LDAP 49 errors stopped offering 601 (object does
not exist) errors or anything other than 669, bad password.

Because telling an unathenticated user info about users is a dangerous
place to go.

Insufficient rights would tell you, you had guessed a correct DN. I
concede this is a lower probability case than the LDAP 49 error case,
but I think Steve has a pretty good point here (Even if your way would
be easier for us...)



0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Problems starting workflow from policy after upgrade


Hmm, I guess I see the point but I think it could be a bit more
descriptive then this (from LAN trace):


Code:
--------------------

<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header/><SOAP-ENV:Body><SOAP-ENV:Fault><faultcode>SOAP-ENV:Server</faultcode><faultstring>no serializer found for "java.lang.IllegalStateException"</faultstring><detail><ns1:stackTrace xmlns:ns1="http://www.novell.com/wssdk" xsi:type="ns1:stackTrace"><ns1:dump xsi:type="xsd:string">com.novell.soa.ws.binding.MarshalerNotFoundException: no serializer found for "java.lang.IllegalStateException"
at com.novell.soa.ws.impl.soap.LiteralEncodingStyle.writeObject(LiteralEncodingStyle.java:414)
at com.novell.soa.ws.impl.xml.OutputStreamImpl.writeObject(OutputStreamImpl.java:122)
at com.novell.soa.ws.impl.soap.ServerResponseImpl.writeException(ServerResponseImpl.java:81)
at com.novell.soa.af.impl.soap.Provisioning_ServiceSkeleton._invoke(Provisioning_ServiceSkeleton.java:2659)
at com.novell.soa.ws.server.ServletSkeleton.invokeEndPoint(ServletSkeleton.java:208)
at com.novell.soa.ws.impl.soap.MessageHandlerInvoker.invokeServerMessageHandlers(MessageHandlerInvoker.java:348)
at com.novell.soa.ws.impl.soap.SOAPHandler.handleServerRequest(SOAPHandler.java:84)
at com.novell.soa.ws.impl.rpc.ServerDelegateImpl.handleServerRequest(ServerDelegateImpl.java:92)
at com.novell.soa.ws.server.ServletSkeleton.handleRequest(ServletSkeleton.java:107)
at com.novell.soa.ws.server.ServletSkeleton.doPost(ServletSkeleton.java:317)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
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.novell.common.auth.JAASFilter.doFilter(JAASFilter.java:104)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.novell.common.auth.saml.AuthTokenGeneratorFilter.doFilter(AuthTokenGeneratorFilter.java:88)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.novell.common.auth.sso.SSOFilter.doFilter(SSOFilter.java:87)
at com.novell.common.auth.sso.SAPFilter.doFilter(SAPFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.novell.soa.common.i18n.BestLocaleServletFilter.doFilter(BestLocaleServletFilter.java:242)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.novell.soa.common.i18n.URILoggerServletFilter.doFilter(URILoggerServletFilter.java:63)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
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:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:724)
</ns1:dump></ns1:stackTrace></detail></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>

--------------------


Couldn't it? Even in your LDAP example, a 669 is far more descriptive
then what looks like a missing class or JAR file (or other code) problem
to me. Or even better, have a debug switch to turn on and off
descriptive error messages (kinda like PWM has!). That would be the
best of both worlds. Descriptive while testing, and then a production
mode to obsfucate the errors.

Matt


--
matt
------------------------------------------------------------------------
matt's Profile: https://forums.netiq.com/member.php?userid=183
View this thread: https://forums.netiq.com/showthread.php?t=48241

0 Likes
Knowledge Partner
Knowledge Partner

Re: Problems starting workflow from policy after upgrade

On 7/30/2013 10:04 PM, matt wrote:
>
> Hmm, I guess I see the point but I think it could be a bit more
> descriptive then this (from LAN trace):
>
>
> Code:
> --------------------
>
> <SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header/><SOAP-ENV:Body><SOAP-ENV:Fault><faultcode>SOAP-ENV:Server</faultcode><faultstring>no serializer found for "java.lang.IllegalStateException"</faultstring><detail><ns1:stackTrace xmlns:ns1="http://www.novell.com/wssdk" xsi:type="ns1:stackTrace"><ns1:dump xsi:type="xsd:string">com.novell.soa.ws.binding.MarshalerNotFoundException: no serializer found for "java.lang.IllegalStateException"
> at com.novell.soa.ws.impl.soap.LiteralEncodingStyle.writeObject(LiteralEncodingStyle.java:414)
> at com.novell.soa.ws.impl.xml.OutputStreamImpl.writeObject(OutputStreamImpl.java:122)
> at com.novell.soa.ws.impl.soap.ServerResponseImpl.writeException(ServerResponseImpl.java:81)
> at com.novell.soa.af.impl.soap.Provisioning_ServiceSkeleton._invoke(Provisioning_ServiceSkeleton.java:2659)
> at com.novell.soa.ws.server.ServletSkeleton.invokeEndPoint(ServletSkeleton.java:208)
> at com.novell.soa.ws.impl.soap.MessageHandlerInvoker.invokeServerMessageHandlers(MessageHandlerInvoker.java:348)
> at com.novell.soa.ws.impl.soap.SOAPHandler.handleServerRequest(SOAPHandler.java:84)
> at com.novell.soa.ws.impl.rpc.ServerDelegateImpl.handleServerRequest(ServerDelegateImpl.java:92)
> at com.novell.soa.ws.server.ServletSkeleton.handleRequest(ServletSkeleton.java:107)
> at com.novell.soa.ws.server.ServletSkeleton.doPost(ServletSkeleton.java:317)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
> 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.novell.common.auth.JAASFilter.doFilter(JAASFilter.java:104)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at com.novell.common.auth.saml.AuthTokenGeneratorFilter.doFilter(AuthTokenGeneratorFilter.java:88)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at com.novell.common.auth.sso.SSOFilter.doFilter(SSOFilter.java:87)
> at com.novell.common.auth.sso.SAPFilter.doFilter(SAPFilter.java:37)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at com.novell.soa.common.i18n.BestLocaleServletFilter.doFilter(BestLocaleServletFilter.java:242)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at com.novell.soa.common.i18n.URILoggerServletFilter.doFilter(URILoggerServletFilter.java:63)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 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:235)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:724)
> </ns1:dump></ns1:stackTrace></detail></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>
>
> --------------------
>
>
> Couldn't it? Even in your LDAP example, a 669 is far more descriptive
> then what looks like a missing class or JAR file (or other code) problem
> to me. Or even better, have a debug switch to turn on and off
> descriptive error messages (kinda like PWM has!). That would be the
> best of both worlds. Descriptive while testing, and then a production
> mode to obsfucate the errors.


That would be a really helpful switch!

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.