[JBoss JIRA] (JBWS-4091) Travis CI jobs
by Alessio Soldano (JIRA)
Alessio Soldano created JBWS-4091:
-------------------------------------
Summary: Travis CI jobs
Key: JBWS-4091
URL: https://issues.jboss.org/browse/JBWS-4091
Project: JBoss Web Services
Issue Type: Task
Components: jbossws-cxf, productization
Reporter: Alessio Soldano
Fix For: jbossws-cxf-5.2.1.Final
This is about having travis ci job(s) run automatically for each commit & opened PR on github.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (JBWS-4090) (7.1.z) WSDL system property expansion not working on endpoint address
by Ivo Studensky (JIRA)
Ivo Studensky created JBWS-4090:
-----------------------------------
Summary: (7.1.z) WSDL system property expansion not working on endpoint address
Key: JBWS-4090
URL: https://issues.jboss.org/browse/JBWS-4090
Project: JBoss Web Services
Issue Type: Bug
Components: jbossws-cxf
Reporter: Ivo Studensky
Assignee: Alessio Soldano
Fix For: jbossws-cxf-5.2.0.Final
Deployment of contract first SOAP-over-JMS endpoint with system property references in wsdl soap:address element value fails because the endpoint address is read before the property expansion takes place.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (JBWS-4088) Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-4088?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-4088:
----------------------------------
Issue Type: Enhancement (was: Feature Request)
> Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF
> ---------------------------------------------------------------------------------------------
>
> Key: JBWS-4088
> URL: https://issues.jboss.org/browse/JBWS-4088
> Project: JBoss Web Services
> Issue Type: Enhancement
> Reporter: david.boeren
> Priority: Minor
> Fix For: jbossws-cxf-5.2.1.Final
>
>
> I think the explanation comes from the way the response context is kept within the ClientImpl. The ClientImpl has the following:
> protected Map<Thread, Map<String, Object>> responseContext = Collections.synchronizedMap(new WeakHashMap<Thread, Map<String, Object>>());
> and the getResponseContext() is implemented this way:
> public Map<String, Object> getResponseContext() {
> if (!responseContext.containsKey(Thread.currentThread())) {
> responseContext.put(Thread.currentThread(), new HashMap<String, Object>());
> }
> return responseContext.get(Thread.currentThread());
> }
> Now, in the customer case, I believe the threads that serve as keys to the weak hashmap are never GCed (perhaps because they simply come from a thread pool that reuses them) and I don't see the response context being explicitly cleaned up in cxf except when the clientimpl is destroyed (which does not happen often in customer case as the clients are pooled).
> I would suggest to try explicitly cleaning up the response message context contents.
> The customer has successfully done this using this on their client side:
> dispatcher.getResponseContext().remove("org.apache.cxf.staxutils.W3CDOMStreamWriter");
> Is it possible to have this fix added to JBossWS as an enhancement? Full details are on the case link.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (JBWS-4088) Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF
by david.boeren (JIRA)
david.boeren created JBWS-4088:
----------------------------------
Summary: Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF
Key: JBWS-4088
URL: https://issues.jboss.org/browse/JBWS-4088
Project: JBoss Web Services
Issue Type: Feature Request
Reporter: david.boeren
Priority: Minor
Fix For: jbossws-cxf-5.2.1.Final
I think the explanation comes from the way the response context is kept within the ClientImpl. The ClientImpl has the following:
protected Map<Thread, Map<String, Object>> responseContext = Collections.synchronizedMap(new WeakHashMap<Thread, Map<String, Object>>());
and the getResponseContext() is implemented this way:
public Map<String, Object> getResponseContext() {
if (!responseContext.containsKey(Thread.currentThread())) {
responseContext.put(Thread.currentThread(), new HashMap<String, Object>());
}
return responseContext.get(Thread.currentThread());
}
Now, in the customer case, I believe the threads that serve as keys to the weak hashmap are never GCed (perhaps because they simply come from a thread pool that reuses them) and I don't see the response context being explicitly cleaned up in cxf except when the clientimpl is destroyed (which does not happen often in customer case as the clients are pooled).
I would suggest to try explicitly cleaning up the response message context contents.
The customer has successfully done this using this on their client side:
dispatcher.getResponseContext().remove("org.apache.cxf.staxutils.W3CDOMStreamWriter");
Is it possible to have this fix added to JBossWS as an enhancement? Full details are on the case link.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
Eclipse JBoss WebService wizard fails in Velocity library...
by Bessie, Timothy
Hi all...
I've posted this to the Velocity mailing list, and will create a support request with the Red Hat Developer Studio (a branded version of Eclipse) people, but thought I'd cover my bases and ask here as well/
I'm attempting to use Eclipse/JBoss to generate web service artefacts from an implementation class. Everything appears to proceed smoothly, but then we get the below stacktrace. Researching this, it appears to be related to Velocity 1.7 and its use of classloaders and default class implementations. Does anyone know a smart way around this? Given that this is part of the JBoss plugins for Eclipse, I don't have a lot of control over how it works, so the couple of clever ways around this I've found online aren't available to me (it's not a problem with code I'm writing, but with the Eclipse plugin's use of Apache CXF, and IT'S use of Velocity.
Any suggestions would be grand. :-)
We're using "Red Hat JBoss Developer Developer Studio" (a branded version of Eclipse) with this version info:
Version: 10.4.0.GA
Build id: GA-v20170511-1748-B62
Build date: 20170511-1748
This corresponds to Eclipse Neon.
JBoss version from server startup message: JBoss EAP 7.0.7.GA (WildFly Core 2.1.17.Final-redhat-1) Java version 1.8
The stacktrace appears to indicate that Apache CXF (version 3.1.10 or 3.1.14) is used at least for part of the generation, but that the end-product will use JBossWS annotations, etc. I tried to mimic the call in the stacktrace using Ant, but it generates files that, on startup, JBoss recognizes as Apache CXF only and won't allow them (it displays a warning message). So whatever the plugin is doing appears not to be JUST what the stacktrace indicates (I get the sense that that is just the first step, and it might munge the generated files to conform to JBossWS standards).
-------------------------------------
Failed to Generate Web Service code, please check the log for more details
org.eclipse.core.runtime.CoreException: Could not find log4j.properties or log4j.xml configuration, logging to console.
java2ws -s C:\Production\iknowmed\g2\src -classdir C:\Production\iknowmed\g2\war\WEB-INF\classes -d C:\Production\iknowmed\g2\wsdl -verbose -cp /C:/Users/eufjdzb/AppData/Local/Temp/temp7537020417576759813.jar; -wrapperbean -createxsdimports com.mscs.emr.web.webservices.elasticsearch.ElasticSearchMediatorImpl
java2ws - Apache CXF 3.1.10.redhat-1
JBWS024002: Failed to invoke org.apache.cxf.tools.java2ws.JavaToWS
org.apache.cxf.tools.common.ToolException: Failed to initialize velocity engine
at org.apache.cxf.tools.common.VelocityGenerator.initVelocity(VelocityGenerator.java:83)
at org.apache.cxf.tools.common.VelocityGenerator.<init>(VelocityGenerator.java:53)
at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generateAndCompile(BeanGenerator.java:65)
at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generate(BeanGenerator.java:58)
at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generate(BeanGenerator.java:35)
at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.generate(JavaToWSDLProcessor.java:156)
at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.process(JavaToWSDLProcessor.java:118)
at org.apache.cxf.tools.java2ws.JavaToWSContainer.processWSDL(JavaToWSContainer.java:110)
at org.apache.cxf.tools.java2ws.JavaToWSContainer.execute(JavaToWSContainer.java:75)
at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)
at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:45)
at org.apache.cxf.tools.java2ws.JavaToWS.run(JavaToWS.java:82)
at org.jboss.wsf.stack.cxf.tools.CXFProviderImpl.provide(CXFProviderImpl.java:200)
at org.jboss.wsf.stack.cxf.tools.CXFProviderImpl.provide(CXFProviderImpl.java:109)
at org.jboss.ws.tools.cmd.WSProvide.generate(WSProvide.java:217)
at org.jboss.ws.tools.cmd.WSProvide.main(WSProvide.java:87)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.modules.Module.run(Module.java:335)
at org.jboss.modules.Main.main(Main.java:505)
Caused by: org.apache.velocity.exception.VelocityException: Error initializing log: Failed to initialize an instance of org.apache.velocity.runtime.log.NullLogSystem with the current runtime configuration.
at org.apache.velocity.runtime.RuntimeInstance.initializeLog(RuntimeInstance.java:875)
at org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:262)
at org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:646)
at org.apache.velocity.runtime.RuntimeSingleton.init(RuntimeSingleton.java:226)
at org.apache.velocity.app.Velocity.init(Velocity.java:97)
at org.apache.cxf.tools.common.VelocityGenerator.initVelocity(VelocityGenerator.java:79)
... 21 more
Caused by: org.apache.velocity.exception.VelocityException: Failed to initialize an instance of org.apache.velocity.runtime.log.NullLogSystem with the current runtime configuration.
at org.apache.velocity.runtime.log.LogManager.createLogChute(LogManager.java:220)
at org.apache.velocity.runtime.log.LogManager.updateLog(LogManager.java:269)
at org.apache.velocity.runtime.RuntimeInstance.initializeLog(RuntimeInstance.java:871)
... 26 more
Caused by: org.apache.velocity.exception.VelocityException: The specified logger class org.apache.velocity.runtime.log.NullLogSystem does not implement the org.apache.velocity.runtime.log.LogChute interface.
at org.apache.velocity.runtime.log.LogManager.createLogChute(LogManager.java:181)
... 28 more
at org.jboss.tools.ws.creation.core.commands.AbstractGenerateCodeCommand.execute(AbstractGenerateCodeCommand.java:125)
at org.jboss.tools.ws.creation.core.commands.Java2WSCommand.execute(Java2WSCommand.java:1)
at org.eclipse.wst.command.internal.env.core.fragment.CommandFragmentEngine.runCommand(CommandFragmentEngine.java:419)
at org.eclipse.wst.command.internal.env.core.fragment.CommandFragmentEngine.visitTop(CommandFragmentEngine.java:359)
at org.eclipse.wst.command.internal.env.core.fragment.CommandFragmentEngine.moveForwardToNextStop(CommandFragmentEngine.java:212)
at org.eclipse.wst.command.internal.env.ui.widgets.SimpleCommandEngineManager$6.run(SimpleCommandEngineManager.java:294)
at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:437)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:353)
at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:993)
at org.eclipse.wst.command.internal.env.ui.widgets.SimpleCommandEngineManager.runForwardToNextStop(SimpleCommandEngineManager.java:264)
at org.eclipse.wst.command.internal.env.ui.widgets.WizardPageManager.runForwardToNextStop(WizardPageManager.java:91)
at org.eclipse.wst.command.internal.env.ui.widgets.WizardPageManager.getNextPage(WizardPageManager.java:154)
at org.eclipse.wst.command.internal.env.ui.widgets.SimpleWizardPage.getNextPage(SimpleWizardPage.java:136)
at org.eclipse.jface.wizard.WizardDialog.nextPressed(WizardDialog.java:869)
at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:419)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:618)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:249)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4418)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1079)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4236)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3824)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:818)
at org.eclipse.jface.window.Window.open(Window.java:794)
at org.eclipse.ui.internal.handlers.WizardHandler$New.executeHandler(WizardHandler.java:269)
at org.eclipse.ui.internal.handlers.WizardHandler.execute(WizardHandler.java:290)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:295)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
at sun.reflect.GeneratedMethodAccessor51.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:282)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:264)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:152)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:494)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:488)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:353)
at org.eclipse.ui.internal.actions.CommandAction.runWithEvent(CommandAction.java:155)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:565)
at org.eclipse.jface.action.ActionContributionItem.lambda$4(ActionContributionItem.java:397)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4418)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1079)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4236)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3824)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1121)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1022)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:150)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:693)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:610)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)
at org.eclipse.equinox.launcher.Main.run(Main.java:1519)
at org.eclipse.equinox.launcher.Main.main(Main.java:1492)
6 years, 10 months
[JBoss JIRA] (JBWS-3920) Default to using original thread for processing one-way messages
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWS-3920?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWS-3920:
-----------------------------------------------
Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1403939|https://bugzilla.redhat.com/show_bug.cgi?id=1403939] from ON_QA to VERIFIED
> Default to using original thread for processing one-way messages
> ----------------------------------------------------------------
>
> Key: JBWS-3920
> URL: https://issues.jboss.org/browse/JBWS-3920
> Project: JBoss Web Services
> Issue Type: Enhancement
> Components: jbossws-cxf
> Reporter: Alessio Soldano
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-5.0.1.Final, jbossws-cxf-5.1.0.Beta1
>
>
> We're currently setting OneWayProcessorInterceptor.USE_ORIGINAL_THREAD to true for EJB3 endpoints, as that's required for proper authorization in the ejb container. We should actually set that by default in the deployment bus, so that any deployment defaults to using the original thread for deailing with oneway message.
> The reason for this is also performances: when a new thread is used for dealing with a oneway message, the message needs to be cached which takes time and memory. Moreover, the user should actually be tuning the web container thread pool to control thread usage when serving ws requests.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months