[JBossWS] - NullPointerException with jbossws 2.0.1
by koganty
I was trying to use jbossws 2.0.1 relased t'day 'cos it fixed some inheritance problems on JBoss 4.0.5 with jdk1.6.
I had a working web service with jbossws 2.0.0.
When I upgraded to 2.0.1 there is an exception at the very beginning.
The annotation on the SLSB look like :
@WebService
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
@Stateless
@RemoteBinding(jndiBinding=LookupConstants.CLIENT_MANAGER)
@Depends({LookupConstants.CLIENT_SERVICE_OBJECT_NAME})
public class ClientManagerBean implements ClientManager
And here is the exception :
java.lang.NullPointerException
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.getPublishLocation(WSDLFilePublisher.java:303)
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:103)
at org.jboss.wsf.stack.jbws.PublishContractDeploymentAspect.create(PublishContractDeploymentAspect.java:52)
at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:115)
at org.jboss.wsf.container.jboss40.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:97)
at org.jboss.wsf.container.jboss40.DeployerInterceptor.start(DeployerInterceptor.java:90)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy29.start(Unknown Source)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:490)
at java.lang.Thread.run(Thread.java:619)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075412#4075412
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075412
18Â years, 10Â months
[JBoss Seam] - Re: Application config file outside the EAR
by modoc
It may be the best option currently, however, this is an issue that is near and dear to me.
My day job has me working on a pretty nice commercial Java web application framework, which includes a really well thought out (in my opinion) configuration mechanism involving a config path (like a classpath). You configure your components using .properties files with the name of the component placed in the path of the component hierarchy, etc...
The cool part is that you can have a component, let's say one that is part of the framework itself (not a new one you made), which has it's default configuration as part of the framework. In your application/project you have a config directory, where you override or update a few of those settings, as needed. In your project you also have a liveconfig directory, where your non-server specific production settings go (say upping the cache size, or database connection pool size, or whatever). In the server instance on your desktop/laptop you also have a localconfig where you put settings specific to your computer (mail server, a local instance of an external webservice, etc... And in the server instance on the shared dev, or test, or staging, or preview, or production servers, they also have the environment and server specific settings there.
That way you can build and deploy the project locally, testing it, push that kit to shared dev, then to test, then to stage, etc... all the way into production, and the application just works. It's really brilliant, and pretty essential for big enterprise type environments.
Maybe I'm missing something, but I haven't found the parallel functionality in JBoss or Seam.
As part of my rant here, I want to ask for component specific properties files, instead of having to use the more cumbersome xml files, or a shared seam.properties:) I'd also love to see a standard component naming scheme that isn't so similar to package and class naming. A component's namespace and name shouldn't be related to it's package and class necessarily, and by formatting them the same, there's some implied link and confusion (imho).
I'd like to get a discussion going on configuration mechanisms, layers, etc... in general.
Devon
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075409#4075409
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075409
18Â years, 10Â months
[JBoss Seam] - how to use s:button to execute action first before jump to v
by tim_ph
Is there a way to for action on s:button first before it jumps to the view page with params?
This is JSF code:
| <rich:dataTable values="#{locations}" var="location"...>
| ...
| <a:commandLink value="Remove" action="#{applicationHome.deleteLocation}"/>
| ...
| </rich:dataTable>
| <s:button value="Add New Location"
| action="#{applicationHome.addLocation}"
| view="/LocationEdit.xhtml"
| propagation="join"
| >
| <f:param name="locationId" value="#{applicationHome.location.id}"/>
| </s:button>
|
I need new location added to current application before edit it in LocationEdit.xhtml
Application.addLocation() is defined as followed
| @DataModelSelection("locations")
| private Location location;
| public Location getLocation() { return location; }
|
| public void deleteLocation()
| {
| getInstance().getLocations().remove(location);
| getEntityManager().remove(location);
| location = null;
| }
|
| public void addLocation()
| {
| location = new Location();
| getInstance().getLocations().add(location);
| getEntityManager().persist(location);
| }
|
location is DataModelSelection to be used within dataTable but also be used when added new. If I use the edit panel in the same page, that will be no problem, but I have to jump to new page to do it, that same code won't work because addLocation() didn't get called before #{applicationHome.location.id} assignment.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075396#4075396
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075396
18Â years, 10Â months