[JBoss JIRA] (JBIDE-19687) Web Service wizard buttons act strangely if an error occurs creating CXF service
by Brian Fitzpatrick (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19687?page=com.atlassian.jira.plugi... ]
Brian Fitzpatrick edited comment on JBIDE-19687 at 5/7/15 2:07 PM:
-------------------------------------------------------------------
Recreated the issue with a Tomcat server, attached the two projects to recreate - https://bugs.eclipse.org/bugs/show_bug.cgi?id=466769
was (Author: bfitzpat):
Recreated the issue with a Tomcat server, attached the two projects to recreate
> Web Service wizard buttons act strangely if an error occurs creating CXF service
> --------------------------------------------------------------------------------
>
> Key: JBIDE-19687
> URL: https://issues.jboss.org/browse/JBIDE-19687
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.3.0.Alpha2
> Environment: Fedora 20 x64, openjdk 1.7.0_75
> Reporter: Jan Richter
> Assignee: Brian Fitzpatrick
> Labels: upstream
> Attachments: errorMessage
>
>
> Trying to create a bottom up Apache CXF web service. If after the "Apache CXF Wbe Service Java2WS Configuration" step an error occurs, the "back" and "next" buttons stop behaving in the expected fashion.
> So far I've found these cases:
> - The back button will loop through the last 3 pages of the wizard, while pressing "next" on any of these pages will return you to the first page.
> - You can return with the back button, but pressing next will open an error dialog with the same message as the original error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19687) Web Service wizard buttons act strangely if an error occurs creating CXF service
by Brian Fitzpatrick (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19687?page=com.atlassian.jira.plugi... ]
Brian Fitzpatrick updated JBIDE-19687:
--------------------------------------
Labels: upstream (was: )
> Web Service wizard buttons act strangely if an error occurs creating CXF service
> --------------------------------------------------------------------------------
>
> Key: JBIDE-19687
> URL: https://issues.jboss.org/browse/JBIDE-19687
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.3.0.Alpha2
> Environment: Fedora 20 x64, openjdk 1.7.0_75
> Reporter: Jan Richter
> Assignee: Brian Fitzpatrick
> Labels: upstream
> Attachments: errorMessage
>
>
> Trying to create a bottom up Apache CXF web service. If after the "Apache CXF Wbe Service Java2WS Configuration" step an error occurs, the "back" and "next" buttons stop behaving in the expected fashion.
> So far I've found these cases:
> - The back button will loop through the last 3 pages of the wizard, while pressing "next" on any of these pages will return you to the first page.
> - You can return with the back button, but pressing next will open an error dialog with the same message as the original error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19750) Install grinder fails to run on RHEL7: No more handles!
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19750?page=com.atlassian.jira.plugi... ]
Snjezana Peco commented on JBIDE-19750:
---------------------------------------
{quote}
Do you know which value should we pass here? And actually, what's supposed to work on our CI slaves? Webkit or Mozilla?
{quote}
If you are using GTK2, you can use Webkit or Mozilla. As to Gtk3, Webkit has to be used.
In this case, I think webkit native libraries aren't installed on RHEL7.
> Install grinder fails to run on RHEL7: No more handles!
> -------------------------------------------------------
>
> Key: JBIDE-19750
> URL: https://issues.jboss.org/browse/JBIDE-19750
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.0.Beta1
> Reporter: Nick Boldt
> Assignee: Mickael Istria
>
> {code}
> 16:48:30 Installing org.eclipse.swtbot.eclipse.test.junit.feature.group 2.2.1.201402241301.
> ...
> 13:39:08 !MESSAGE Internal browser is not available: No more handles [Browser style SWT.MOZILLA and Java system property org.eclipse.swt.browser.DefaultType=mozilla are not supported with GTK 3 as XULRunner is not ported for GTK 3 yet]
> 13:43:18 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 253.079 sec
> 13:43:18
> 13:43:18 Testcase: testInstall took 252.166 sec
> {code} - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
> I tried to run using `-Dorg.eclipse.swt.browser.DefaultType=webkit` as a script param for `testInstall.groovy` but it must not have passed through to the eclipse install process, as the above error suggests.
> Wondering if ...
> a) passing through a different *swt.browser.DefaultType*, &/or
> b) using a newer SWTBot (which works with Luna [1] now?)
> ... might help.
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=464619
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19638) Web Service wizard - drop-down menus too narrow by default
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19638?page=com.atlassian.jira.plugi... ]
Snjezana Peco updated JBIDE-19638:
----------------------------------
Component/s: upstream
> Web Service wizard - drop-down menus too narrow by default
> ----------------------------------------------------------
>
> Key: JBIDE-19638
> URL: https://issues.jboss.org/browse/JBIDE-19638
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: upstream, webservices
> Affects Versions: 4.3.0.Alpha2
> Reporter: Jan Richter
> Assignee: Brian Fitzpatrick
> Priority: Minor
> Fix For: 4.3.0.Beta1
>
> Attachments: bundles.info, ws.png, wstester.png
>
>
> By default the drop down menus for 'web service type' and 'client type' are too narrow (vertically) for the text inside them to be rendered properly.
> Resizing the wizard in any way will resize the drop downs to standard height which won't change from that moment on.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19756) jbosstools-src.zip has incomplete/misleading version info in folder names/structure
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19756?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-19756:
------------------------------------
How about this?
* jbosstools-4.3.0.Beta1-2015-05-07_09-32-54-B9842-src.zip!/jbosstools-4.3.0.Beta1-src/ (a snapshot in master branch)
* jbosstools-4.3.0.Beta1-2015-06-01_12-32-54-B48-src.zip!/jbosstools-4.3.0.Beta1-src/ (a snapshot in the future Beta1x branch)
So, the zip file contains the more detailed qualifier to differentiate it from subsequent CI builds, but the FOLDER inside is defined simply by the x.y.z.BUILD_ALIAS.
Does that work for you? Or do you want the root folder to include the full qualifier?
--
Where using BUILD_ALIAS inside the zip could be a problem is when we move from CR1 to Final *without having to rebuild*, such as for service releases where CRs are not released.
In such a case, we would have:
* jbosstools-4.3.1.CR1-2015-12-01_12-32-54-B98-src.zip!/jbosstools-4.3.1.CR1-src/ (a snapshot in the future 4.3.x branch)
and need to be adjusted by hand or simply rebuilt to be called:
* jbosstools-4.3.1.Final-2015-12-01_12-32-54-B98-src.zip!/jbosstools-4.3.1.Final-src/ (a snapshot in the future 4.3.x branch)
If we omit the BUILD_ALIAS from the root folder, we wouldn't need to rebuild or unpack-and-repack these zips to replace s/CR1/Final.
So...
would this work?
* jbosstools-4.3.0.Beta1-2015-05-07_09-32-54-B9842-src.zip!/jbosstools-4.3.0-src/ (a snapshot in master branch)
* jbosstools-4.3.0.Beta1-2015-06-01_12-32-54-B48-src.zip!/jbosstools-4.3.0-src/ (a snapshot in the future Beta1x branch)
and for a rename-without-releasing-CR1 case:
* jbosstools-4.3.1.CR1-2015-12-01_12-32-54-B98-src.zip!/jbosstools-4.3.1-src/ (a snapshot in the future 4.3.x branch)
* jbosstools-4.3.1.Final-2015-12-01_12-32-54-B98-src.zip!/jbosstools-4.3.1-src/ (a snapshot in the future 4.3.x branch)
> jbosstools-src.zip has incomplete/misleading version info in folder names/structure
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-19756
> URL: https://issues.jboss.org/browse/JBIDE-19756
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.3.0.Beta1
> Reporter: Max Rydahl Andersen
> Assignee: Nick Boldt
> Fix For: 4.3.0.Beta1
>
> Attachments: jbide19756.png
>
>
> Downloading latest jbosstools-src.zip from http://download.jboss.org/jbosstools/mars/snapshots/builds/jbosstools-bui... I see multiple files in root named:
> <componentname>_<buildqualifier>_<sha1>
> example:
> jbosstools-javaee_Beta1-v20150501-0413-B767_149f9a46d5c676fd7119515e8b6aa796859955ad
> A few issues with this:
> a) it would have been nice unzipping would not create multiple root level folders. Maybe have a jbosstools-source folder as root ?
> b) the buildqualifier is there but the version string for the component is not. Either put the full version string for that component (not overall jbosstools version) or just leave it as <component>-<sha> and have the root folder state the full version of jbosstools. since non-indulged user would not know this one had to do with 4.3.0.Beta1 or 4.2.3.Beta1 (for example).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19687) Web Service wizard buttons act strangely if an error occurs creating CXF service
by Brian Fitzpatrick (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19687?page=com.atlassian.jira.plugi... ]
Brian Fitzpatrick commented on JBIDE-19687:
-------------------------------------------
I'm definitely able to reproduce the issue. Unfortunately it's not in our code at all - this is further upstream at WST/JST in the Web Tools project. It's not anything I've encountered before, but I will open a Bugzilla in the Web Tools project and see if they can help out.
{code}
IWAB0014E Unexpected exception occurred.
The name "" is not legal for JDOM/XML namespaces: Namespace URIs must be non-null and non-empty Strings.
org.jdom.IllegalNameException: The name "" is not legal for JDOM/XML namespaces: Namespace URIs must be non-null and non-empty Strings.
at org.jdom.Namespace.getNamespace(Namespace.java:162)
at org.eclipse.jst.ws.internal.cxf.core.utils.SpringUtils.createJAXWSEndpoint(SpringUtils.java:414)
at org.eclipse.jst.ws.internal.cxf.creation.core.commands.Java2WSCommand.execute(Java2WSCommand.java:103)
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:466)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:374)
at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:1059)
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:935)
at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:434)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:619)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4353)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4172)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:832)
at org.eclipse.jface.window.Window.open(Window.java:808)
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:294)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:247)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:229)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:149)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:343)
at org.eclipse.ui.internal.actions.CommandAction.runWithEvent(CommandAction.java:159)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:595)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:511)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:420)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4353)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4172)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
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:380)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
{code}
> Web Service wizard buttons act strangely if an error occurs creating CXF service
> --------------------------------------------------------------------------------
>
> Key: JBIDE-19687
> URL: https://issues.jboss.org/browse/JBIDE-19687
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.3.0.Alpha2
> Environment: Fedora 20 x64, openjdk 1.7.0_75
> Reporter: Jan Richter
> Assignee: Brian Fitzpatrick
> Attachments: errorMessage
>
>
> Trying to create a bottom up Apache CXF web service. If after the "Apache CXF Wbe Service Java2WS Configuration" step an error occurs, the "back" and "next" buttons stop behaving in the expected fashion.
> So far I've found these cases:
> - The back button will loop through the last 3 pages of the wizard, while pressing "next" on any of these pages will return you to the first page.
> - You can return with the back button, but pressing next will open an error dialog with the same message as the original error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months