This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 86705 - Execution java ee5 based Web app on remote system failed.
Summary: Execution java ee5 based Web app on remote system failed.
Status: VERIFIED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Identity (show other bugs)
Version: 5.x
Hardware: All All
: P1 blocker (vote)
Assignee: Peter Liu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-06 19:58 UTC by _ hlu
Modified: 2006-10-12 21:45 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
list of files (24.19 KB, image/png)
2006-10-06 19:59 UTC, _ hlu
Details
appserver log (1.91 MB, text/plain)
2006-10-06 21:34 UTC, _ hlu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ hlu 2006-10-06 19:58:00 UTC
Netbeans rc1+EP061005:

Execution java ee5 based Web app with wss on remote system(Solaris10 x86) failed.
The same apps worked without wss.
Exception in the outoup window below. Noticed in the remote system there is file
called /home/hlu/AccessManager/amserver/idRepo/agent/helloServiceWSC 

org.netbeans.modules.identity.profile.api.configurator.ConfiguratorException:
com.sun.identity.wss.provider.ProviderException: idRepo exception: Plug-in
com.sun.identity.idm.plugins.files.FilesRepo: Unable to find entry:
/home/hlu/AccessManager/amserver/idRepo/agent/HelloServiceWSC
        at
org.netbeans.modules.identity.profile.api.configurator.impl.dynamic.ProviderConfigImpl.createConfiguratorException(ProviderConfigImpl.java:541)
        at
org.netbeans.modules.identity.profile.api.configurator.impl.dynamic.ProviderConfigImpl.saveProvider(ProviderConfigImpl.java:338)
        at
org.netbeans.modules.identity.profile.api.configurator.ProviderConfigurator.save(ProviderConfigurator.java:394)
        at
org.netbeans.modules.identity.ant.AMDeploy.deployWSCProviders(AMDeploy.java:139)
        at org.netbeans.modules.identity.ant.AMDeploy.execute(AMDeploy.java:92)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
        at org.apache.tools.ant.Task.perform(Task.java:364)
        at org.apache.tools.ant.Target.execute(Target.java:341)
        at org.apache.tools.ant.Target.performTasks(Target.java:369)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
        at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
        at
org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:240)
        at
org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:293)
        at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:131)
Caused by: com.sun.identity.wss.provider.ProviderException: idRepo exception:
Plug-in com.sun.identity.idm.plugins.files.FilesRepo: Unable to find entry:
/home/hlu/AccessManager/amserver/idRepo/agent/HelloServiceWSC
        at
com.sun.identity.wss.provider.plugins.AgentProvider.store(AgentProvider.java:348)
        at
com.sun.identity.wss.provider.ProviderConfig.saveProvider(ProviderConfig.java:431)
        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.netbeans.modules.identity.profile.api.configurator.impl.dynamic.ProviderConfigImpl.saveProvider(ProviderConfigImpl.java:336)
        ... 14 more
Comment 1 _ hlu 2006-10-06 19:59:06 UTC
Created attachment 35003 [details]
list of files
Comment 2 Srividhya Narayanan 2006-10-06 21:06:24 UTC
Talking to Hong seems like since she had already deployed a service names hello
there was a pre-exisinting WSC configuration file named helloServiceWSC. While
deployment it updated the existing file with the configuration for HelloService
since both file names resolved to the same file (this should be solaris and
linux specific issue).. but at runtime it looks for the correct named file and
fails because it cant find it.

We removed the old file and now it properly created a HelloServiceWSC file but
the runtime stil failed for which Hong will attach more data. Peter, pls work
with Hong on this and make sure its no regression from the other fixes she has
been testing.
Comment 3 _ hlu 2006-10-06 21:34:29 UTC
Created attachment 35007 [details]
appserver log
Comment 4 Peter Liu 2006-10-10 07:12:11 UTC
From the server log, the validation for the request is successful. However,
validation for the response is unsuccessful.  I am currently looking through the
am debug files to find out why.  Also, I am trying to verify if the same
application works locally.

Comment 5 Peter Liu 2006-10-10 10:42:44 UTC
The application works if we uncheck verify response in the wsc panel.
Comment 6 Peter Liu 2006-10-10 19:59:13 UTC
The application also fails the same way locally with verify response turned on
so this is not a remote-only issue.

Comment 7 Srividhya Narayanan 2006-10-10 20:32:41 UTC
The application works fine on the local case. The annotation should have the
pattern servicename + "Service" in it.. pls ensure this is correct. I have
working javaee 5 projects for SAML_SenderVouches in the local instance.
Comment 8 Srividhya Narayanan 2006-10-11 00:11:38 UTC
The application works fine on the local case. The annotation should have the
pattern servicename + "Service" in it.. pls ensure this is correct. I have
working javaee 5 projects for SAML_SenderVouches in the local instance.
Comment 9 Peter Liu 2006-10-12 07:09:23 UTC
Just tried build22 and I was able to get the hello app to work locally on my
machine and remotely on mang and palmulra.  So, basically, the problem is that
the annotation workaround to change the name of the web service to match the
port-component-name didn't work reliably which caused the am server
authentication module not get invoked which, in turn, caused response validation
to fail. 

With  nb rc2, the port-component-name is now correctly set to match the name of
the web service and am authentication module is now properly invoked. 

I am closing this bug as fixed.
Comment 10 _ hlu 2006-10-12 21:45:36 UTC
verfied with coke bundle build22.