[JBoss JIRA] (JBIDE-20071) Allow deploying exploded jars to war/WEB-INF/lib
by Vsevolod Golovanov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20071?page=com.atlassian.jira.plugi... ]
Vsevolod Golovanov edited comment on JBIDE-20071 at 6/15/15 11:13 AM:
----------------------------------------------------------------------
Project structure is:
* EAR
** EJB-1
** EJB-2
** WAR
*** JAR-UI-1
*** JAR-UI-2
(JAR-UIs are in WAR's WEB-INF/lib directory.)
Yes, JAR-UIs have both:
# classes;
# JSF/Facelet resources: XHTMLs, images, css, js...
Servlets look at JAR-UI's META-INF/web-fragment.xml and combine it with web.xml. JSF looks up resources in META-INF/resources.
Changes to classes get applied by Eclipse/JBDS on the fly as usual.
But changes to JSF resources don't get picked up. IDE/Tools deploy them, the new files are there in the server deployments, but VFS still returns old files from the temporary directory (more ramblings [here|http://stackoverflow.com/q/28326523/1341535]).
I've checked that when placing exploded JAR-UI in WAR/WEB-INF/lib:
* server does start successfully;
* when changing a JSF resource, and reloading a page, it does use the updated resources.
was (Author: vsevolodgolovanov):
Project structure is:
* EAR
** EJB-1
** EJB-2
** WAR
*** JAR-UI-1
*** JAR-UI-2
(JAR-UIs are in WAR's WEB-INF/lib directory.)
Yes, JAR-UIs have both:
# classes;
# JSF/Facelet resources: XHTMLs, images, css, js...
Servlets look at JAR-UI's META-INF/web-fragment.xml and combine it with web.xml. JSF looks up resources in META-INF/resources.
Changes to classes get applied by Eclipse/JBDS on the fly as usual.
But changes to JSF resources don't get picked up. IDE/Tools deploy them, the new files are there, but VFS still returns old files from the temporary directory (more ramblings [here|http://stackoverflow.com/q/28326523/1341535]).
I've checked that when placing exploded JAR-UI in WAR/WEB-INF/lib:
* server does start successfully;
* when changing a JSF resource, and reloading a page, it does use the updated resources.
> Allow deploying exploded jars to war/WEB-INF/lib
> ------------------------------------------------
>
> Key: JBIDE-20071
> URL: https://issues.jboss.org/browse/JBIDE-20071
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.2.3.Final
> Environment: JBoss Developer Studio 8.1.0.GA
> Reporter: Vsevolod Golovanov
>
> There were JBIDE-10318, JBIDE-9836 before. They were pretty strict in that deploying expoded JARs in WAR/WEB-INF/lib is not allowed for some reason. The only actual reason seemed to be that the server at the time refused to deploy such structure. Maybe the server was in the wrong?
> Now with Wildfly 8.2.0.Final exploded JARs in WAR/WEB-INF/lib deploy correctly, at least Weld, EJB, JSF seem to work fine.
> The main use case for this is creating a modular web application, with different parts implemented in separate projects. Hot deploying of resources, such as Facelets' XHTMLs, is crucial for development. So the JARs need to be exploded.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-20071) Allow deploying exploded jars to war/WEB-INF/lib
by Vsevolod Golovanov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20071?page=com.atlassian.jira.plugi... ]
Vsevolod Golovanov edited comment on JBIDE-20071 at 6/15/15 11:12 AM:
----------------------------------------------------------------------
Project structure is:
* EAR
** EJB-1
** EJB-2
** WAR
*** JAR-UI-1
*** JAR-UI-2
(JAR-UIs are in WAR's WEB-INF/lib directory.)
Yes, JAR-UIs have both:
# classes;
# JSF/Facelet resources: XHTMLs, images, css, js...
Servlets look at JAR-UI's META-INF/web-fragment.xml and combine it with web.xml. JSF looks up resources in META-INF/resources.
Changes to classes get applied by Eclipse/JBDS on the fly as usual.
But changes to JSF resources don't get picked up. IDE/Tools deploy them, the new files are there, but VFS still returns old files from the temporary directory (more ramblings [here|http://stackoverflow.com/q/28326523/1341535]).
I've checked that when placing exploded JAR-UI in WAR/WEB-INF/lib:
* server does start successfully;
* when changing a JSF resource, and reloading a page, it does use the updated resources.
was (Author: vsevolodgolovanov):
Project structure is:
* EAR
** EJB-1
** EJB-2
** WAR
*** JAR-UI-1
*** JAR-UI-2
(JAR-UIs are in WAR's WEB-INF/lib directory.)
Yes, JAR-UIs have:
# classes;
# JSF/Facelet resources: XHTMLs, images, css, js...
Servlets look at JAR-UI's META-INF/web-fragment.xml and combine it with web.xml. JSF looks up resources in META-INF/resources.
Changes to classes get applied by Eclipse/JBDS on the fly as usual.
But changes to JSF resources don't get picked up. IDE/Tools deploy them, the new files are there, but VFS still returns old files from the temporary directory (more ramblings [here|http://stackoverflow.com/q/28326523/1341535]).
I've checked that when placing exploded JAR-UI in WAR/WEB-INF/lib:
* server does start successfully;
* when changing a JSF resource, and reloading a page, it does use the updated resources.
> Allow deploying exploded jars to war/WEB-INF/lib
> ------------------------------------------------
>
> Key: JBIDE-20071
> URL: https://issues.jboss.org/browse/JBIDE-20071
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.2.3.Final
> Environment: JBoss Developer Studio 8.1.0.GA
> Reporter: Vsevolod Golovanov
>
> There were JBIDE-10318, JBIDE-9836 before. They were pretty strict in that deploying expoded JARs in WAR/WEB-INF/lib is not allowed for some reason. The only actual reason seemed to be that the server at the time refused to deploy such structure. Maybe the server was in the wrong?
> Now with Wildfly 8.2.0.Final exploded JARs in WAR/WEB-INF/lib deploy correctly, at least Weld, EJB, JSF seem to work fine.
> The main use case for this is creating a modular web application, with different parts implemented in separate projects. Hot deploying of resources, such as Facelets' XHTMLs, is crucial for development. So the JARs need to be exploded.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-20071) Allow deploying exploded jars to war/WEB-INF/lib
by Vsevolod Golovanov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20071?page=com.atlassian.jira.plugi... ]
Vsevolod Golovanov edited comment on JBIDE-20071 at 6/15/15 11:08 AM:
----------------------------------------------------------------------
Project structure is:
* EAR
** EJB-1
** EJB-2
** WAR
*** JAR-UI-1
*** JAR-UI-2
(JAR-UIs are in WAR's WEB-INF/lib directory.)
Yes, JAR-UIs have:
# classes;
# JSF/Facelet resources: XHTMLs, images, css, js...
Servlets look at JAR-UI's META-INF/web-fragment.xml and combine it with web.xml. JSF looks up resources in META-INF/resources.
Changes to classes get applied by Eclipse/JBDS on the fly as usual.
But changes to JSF resources don't get picked up. IDE/Tools deploy them, the new files are there, but VFS still returns old files from the temporary directory (more ramblings [here|http://stackoverflow.com/q/28326523/1341535]).
I've checked that when placing exploded JAR-UI in WAR/WEB-INF/lib:
* server does start successfully;
* when changing a JSF resource, and reloading a page, it does use the updated resources.
was (Author: vsevolodgolovanov):
Project structure is:
* EAR
** EJB
** WAR
*** JAR-UI-1
*** JAR-UI-2
(JAR-UIs are in WAR's WEB-INF/lib directory.)
Yes, JAR-UIs have:
# classes;
# JSF/Facelet resources: XHTMLs, images, css, js...
Servlets look at JAR-UI's META-INF/web-fragment.xml and combine it with web.xml. JSF looks up resources in META-INF/resources.
Changes to classes get applied by Eclipse/JBDS on the fly as usual.
But changes to JSF resources don't get picked up. IDE/Tools deploy them, the new files are there, but VFS still returns old files from the temporary directory (more ramblings [here|http://stackoverflow.com/questions/28326523/hot-deploying-resources-...]).
I've checked that when placing exploded JAR-UI in WAR/WEB-INF/lib:
* server does start;
* when changing a JSF resource, and reloading a page, it does use the updated resources.
> Allow deploying exploded jars to war/WEB-INF/lib
> ------------------------------------------------
>
> Key: JBIDE-20071
> URL: https://issues.jboss.org/browse/JBIDE-20071
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.2.3.Final
> Environment: JBoss Developer Studio 8.1.0.GA
> Reporter: Vsevolod Golovanov
>
> There were JBIDE-10318, JBIDE-9836 before. They were pretty strict in that deploying expoded JARs in WAR/WEB-INF/lib is not allowed for some reason. The only actual reason seemed to be that the server at the time refused to deploy such structure. Maybe the server was in the wrong?
> Now with Wildfly 8.2.0.Final exploded JARs in WAR/WEB-INF/lib deploy correctly, at least Weld, EJB, JSF seem to work fine.
> The main use case for this is creating a modular web application, with different parts implemented in separate projects. Hot deploying of resources, such as Facelets' XHTMLs, is crucial for development. So the JARs need to be exploded.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19996) [FeedHenry] Cannot create App in FH Cloud - Caused by: java.net.UnknownHostException: aerogear-t.sandbox.feedhenry.combox
by Pavol Srna (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19996?page=com.atlassian.jira.plugi... ]
Pavol Srna closed JBIDE-19996.
------------------------------
Verified in JBT 4.3.0.Beta1 respin-a build.
> [FeedHenry] Cannot create App in FH Cloud - Caused by: java.net.UnknownHostException: aerogear-t.sandbox.feedhenry.combox
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19996
> URL: https://issues.jboss.org/browse/JBIDE-19996
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: aerogear-hybrid
> Affects Versions: 4.3.0.Beta1
> Reporter: Pavol Srna
> Assignee: Gorkem Ercan
> Priority: Blocker
> Labels: respin-a
> Fix For: 4.3.0.Beta1
>
> Attachments: screen-fh.png
>
>
> {code}
> org.jboss.tools.feedhenry.ui.model.FeedHenryException: Unexpected error while communicating with aerogear-t.sandbox.feedhenry.com
> at org.jboss.tools.feedhenry.ui.model.FeedHenry.doPostAPICall(FeedHenry.java:162)
> at org.jboss.tools.feedhenry.ui.model.FeedHenry.importBareRepo(FeedHenry.java:110)
> at org.jboss.tools.feedhenry.ui.cordova.internal.wizards.NewApplicationWizard$1.run(NewApplicationWizard.java:99)
> at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:463)
> at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:371)
> at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:1002)
> at org.jboss.tools.feedhenry.ui.cordova.internal.wizards.NewApplicationWizard.performFinish(NewApplicationWizard.java:80)
> at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:799)
> at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:429)
> 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:4481)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1327)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3819)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3430)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:827)
> at org.eclipse.jface.window.Window.open(Window.java:803)
> 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.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:497)
> at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
> at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:252)
> at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:234)
> 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:493)
> at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:486)
> 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:160)
> 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:4481)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1327)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3819)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3430)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139)
> 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:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1488)
> Caused by: java.net.UnknownHostException: aerogear-t.sandbox.feedhenry.combox
> at java.net.InetAddress.getAllByName0(InetAddress.java:1259)
> at java.net.InetAddress.getAllByName(InetAddress.java:1171)
> at java.net.InetAddress.getAllByName(InetAddress.java:1105)
> at org.apache.http.impl.conn.SystemDefaultDnsResolver.resolve(SystemDefaultDnsResolver.java:44)
> at org.apache.http.impl.conn.DefaultClientConnectionOperator.resolveHostname(DefaultClientConnectionOperator.java:259)
> at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:159)
> at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
> at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
> at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
> at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
> at org.jboss.tools.feedhenry.ui.model.FeedHenry.doPostAPICall(FeedHenry.java:138)
> ... 65 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-20072) Connection refused exception is not clearly presented to the user
by Jeff Cantrill (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20072?page=com.atlassian.jira.plugi... ]
Jeff Cantrill commented on JBIDE-20072:
---------------------------------------
[~adietish] Agreed. My thought was to make it more obvious to the user that the server is not there.
> Connection refused exception is not clearly presented to the user
> -----------------------------------------------------------------
>
> Key: JBIDE-20072
> URL: https://issues.jboss.org/browse/JBIDE-20072
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.0.Beta1
> Reporter: Jeff Cantrill
> Fix For: 4.3.0.Beta2
>
> Attachments: Exception.png
>
>
> Trying to connect using an existing connection to a server that is not available does not display nice to the user and the console logs show:
> {code}
> com.openshift.restclient.OpenShiftException: Exception getting the resource
> at com.openshift.internal.restclient.DefaultClient.handleHttpClientException(DefaultClient.java:396)
> at com.openshift.internal.restclient.DefaultClient.get(DefaultClient.java:241)
> at com.openshift.internal.restclient.DefaultClient.getCurrentUser(DefaultClient.java:402)
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getContext(AuthorizationClient.java:93)
> at com.openshift.internal.restclient.DefaultClient.getContext(DefaultClient.java:407)
> at org.jboss.tools.openshift.core.connection.Connection.authorize(Connection.java:210)
> at org.jboss.tools.openshift.core.connection.Connection.connect(Connection.java:200)
> at org.jboss.tools.openshift.internal.common.ui.connection.ConnectionWizardPageModel.connect(ConnectionWizardPageModel.java:263)
> at org.jboss.tools.openshift.internal.common.ui.connection.ConnectionWizardPage$ConnectJob.doRun(ConnectionWizardPage.java:335)
> at org.jboss.tools.openshift.internal.common.core.job.AbstractDelegatingMonitorJob.run(AbstractDelegatingMonitorJob.java:36)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: com.openshift.internal.restclient.http.HttpClientException: java.net.ConnectException: Connection refused
> at com.openshift.internal.restclient.http.UrlConnectionHttpClient.createException(UrlConnectionHttpClient.java:217)
> at com.openshift.internal.restclient.http.UrlConnectionHttpClient.request(UrlConnectionHttpClient.java:151)
> at com.openshift.internal.restclient.http.UrlConnectionHttpClient.request(UrlConnectionHttpClient.java:130)
> at com.openshift.internal.restclient.http.UrlConnectionHttpClient.get(UrlConnectionHttpClient.java:92)
> at com.openshift.internal.restclient.DefaultClient.getVersion(DefaultClient.java:307)
> at com.openshift.internal.restclient.DefaultClient.getOpenShiftVersions(DefaultClient.java:283)
> at com.openshift.internal.restclient.DefaultClient.getOpenShiftAPIVersion(DefaultClient.java:297)
> at com.openshift.internal.restclient.DefaultClient.getTypeMappings(DefaultClient.java:332)
> at com.openshift.internal.restclient.DefaultClient.get(DefaultClient.java:232)
> ... 9 more
> Caused by: java.net.ConnectException: Connection refused
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1889)
> at sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1884)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1883)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1456)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1440)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
> at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
> at com.openshift.internal.restclient.http.UrlConnectionHttpClient.createException(UrlConnectionHttpClient.java:200)
> ... 17 more
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:656)
> at sun.security.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:173)
> at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
> at sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:275)
> at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:371)
> at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191)
> at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1104)
> at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:998)
> at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1512)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1440)
> at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
> at com.openshift.internal.restclient.http.UrlConnectionHttpClient.request(UrlConnectionHttpClient.java:147)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19739) Websockets: Content assist for endpoint classes
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19739?page=com.atlassian.jira.plugi... ]
Marián Labuda closed JBIDE-19739.
---------------------------------
Verified in JBDS 9.0.0.Beta1a build ID B50.
> Websockets: Content assist for endpoint classes
> -----------------------------------------------
>
> Key: JBIDE-19739
> URL: https://issues.jboss.org/browse/JBIDE-19739
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: webservices
> Reporter: Alexey Kazakov
> Assignee: Viacheslav Kabanovich
> Labels: new_and_noteworthy
> Fix For: 4.3.0.Beta1
>
> Attachments: scr.png
>
>
> Content assist for classes annotated @ServerEndpoint or @ClientEndpoint with the following proposals:
> - Add @OnMessage method (if not present yet)
> - Add @OnOpen method
> - Add @OnClose method
> - Add @OnError method
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months