[JBoss JIRA] (JBIDE-17698) Server view could show all deployed modules, obtained from the server
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17698?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-17698:
--------------------------------
Fix Version/s: 4.3.0.Alpha1
> Server view could show all deployed modules, obtained from the server
> ---------------------------------------------------------------------
>
> Key: JBIDE-17698
> URL: https://issues.jboss.org/browse/JBIDE-17698
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.2.0.Beta2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.3.0.Alpha1
>
>
> Pavol Srna pointed out to me that when he deletes a project in workspace while it's deployed on a running AS7, it disappears from the server view and he can't undeploy it from Eclipse.
> I understand that this is somewhat expected, but we have a suggestion: Could the server view get its deployed modules from the server via the management api and use that to show the modules? Similar to what the web console of AS7/WildFly/EAP6 shows.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBIDE-17698) Server view could show all deployed modules, obtained from the server
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17698?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-17698:
-------------------------------------
There does exist an API for displaying modules that are external to the workspace, though I've never had a chance to investigate its limitations or how it's intended to be used or what functionality such modules could provide.
Once concern I have (but again, haven't verified) is that the server may respond with a list of all of its deployments. This may sound great to you, but, it could turn out that we end up with 100 results (if, for example, all the different parts of the server itself count as a deployment, and we end up with a list of all jboss modules that have been deployed (of which our servers tend to have hundreds)) This would utterly clog the view if it were to happen, and would make the tools very difficult to use.
And then depending on the jboss / wf API, we'd need to decide whether or how to filter such a list, which module types are acceptable (web? ejb? ear? osgi? jboss-modules?)
> Server view could show all deployed modules, obtained from the server
> ---------------------------------------------------------------------
>
> Key: JBIDE-17698
> URL: https://issues.jboss.org/browse/JBIDE-17698
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.2.0.Beta2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.3.0.Alpha1
>
>
> Pavol Srna pointed out to me that when he deletes a project in workspace while it's deployed on a running AS7, it disappears from the server view and he can't undeploy it from Eclipse.
> I understand that this is somewhat expected, but we have a suggestion: Could the server view get its deployed modules from the server via the management api and use that to show the modules? Similar to what the web console of AS7/WildFly/EAP6 shows.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBDS-3071) JBDS Installer shouldn't contain source features/plugins
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBDS-3071?page=com.atlassian.jira.plugin.... ]
Mickael Istria commented on JBDS-3071:
--------------------------------------
All those differences are actually showing how good it is to rely on the product definition to produce the installer instead of putting the whole site in!
org.jboss.tools.jst.jsdt and tern are supposed to come from Central, not from main JBDS repo.
> JBDS Installer shouldn't contain source features/plugins
> --------------------------------------------------------
>
> Key: JBDS-3071
> URL: https://issues.jboss.org/browse/JBDS-3071
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 8.0.0.Beta2
> Reporter: Fred Bricon
> Assignee: Nick Boldt
> Fix For: 8.0.0.Beta3
>
>
> {quote}
> So the basic JBDS installer is 70MB fatter. From my understanding it's because we now ship a *huge* forge2 runtime (50MB), Tern, the JVM Monitor and probably some other minor stuff.
> Fair enough. But do we *really* need to add all the source features/plugins to the installer? *If* we're legally bound to provide sources for JBoss plugins, couldn't we provide them via an other way? (p2 only).
> I reckon we could save ~37 MB by not shipping sources in the installer. I know storage is cheap and d/l speeds are faster but that's not an excuse.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBIDE-12351) Remote JMX connection to servers cannot be established with IPv6
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-12351?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-12351:
-------------------------------------
1) I haven't been able to get a server running in ip-v6 (as far as I can tell. Maybe I did and didn't know?)
2) I have no idea how to fix it
3) I tried digging into the authentication code in remoting but couldn't make heads or tails of it, so no idea why this would be occurring
4) I also tried digging into remoting-jmx code as well, with, again, absolutely nothing to show for it.
> Remote JMX connection to servers cannot be established with IPv6
> ----------------------------------------------------------------
>
> Key: JBIDE-12351
> URL: https://issues.jboss.org/browse/JBIDE-12351
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jmx
> Affects Versions: 3.3.0.Final
> Environment: Fedora 17 32bit
> EAP 6.0.0.GA
> Reporter: Martin Malina
>
> When I set up a remote server accessible over IPv6, start the server and then try to open the server in MBean Explorer, it's stuck on "Loading" and keeps printing this error in the log:
> {code}
> ERROR: JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> Jul 20, 2012 2:41:24 PM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.4.GA-redhat-1
> Jul 20, 2012 2:41:25 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.4.GA-redhat-1
> Jul 20, 2012 2:41:25 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.8.GA-redhat-1
> Jul 20, 2012 2:41:25 PM org.jboss.remoting3.remote.RemoteConnection handleException
> ERROR: JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> Jul 20, 2012 2:41:25 PM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.4.GA-redhat-1
> Jul 20, 2012 2:41:25 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.4.GA-redhat-1
> Jul 20, 2012 2:41:25 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.8.GA-redhat-1
> Jul 20, 2012 2:41:26 PM org.jboss.remoting3.remote.RemoteConnection handleException
> ERROR: JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBIDE-17700) Cannot deploy jsf war with eclipse luna and jboss 7.1.x
by Oliver Pfau (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17700?page=com.atlassian.jira.plugi... ]
Oliver Pfau commented on JBIDE-17700:
-------------------------------------
At this time the problem does not occur anymore. Added/removed the war multiple times and it worked. It is a web app with primefaces 4 UI and dependencies. If the error comes up again I will check the error log and generate the zip.
> Cannot deploy jsf war with eclipse luna and jboss 7.1.x
> -------------------------------------------------------
>
> Key: JBIDE-17700
> URL: https://issues.jboss.org/browse/JBIDE-17700
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Win 7, Eclilpse Luna, JBoss Tools (via market place)
> Reporter: Oliver Pfau
> Priority: Critical
>
> When I publish my war to jboss 7.1 the following error occurs:
> An internal error occurred during: "Publishing to JBoss AS 7.1...".
> Could not initialize class de.schlichtherle.io.ArchiveControllers
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBDS-3071) JBDS Installer shouldn't contain source features/plugins
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3071?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3071:
-------------------------------------
It seems this is all good differences, because all those items is not required for installation and are not installed by current original installer.
Potential issue if jst.jsdt and tern features are part of JBDS p2 repository, aren't they?
> JBDS Installer shouldn't contain source features/plugins
> --------------------------------------------------------
>
> Key: JBDS-3071
> URL: https://issues.jboss.org/browse/JBDS-3071
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 8.0.0.Beta2
> Reporter: Fred Bricon
> Assignee: Nick Boldt
> Fix For: 8.0.0.Beta3
>
>
> {quote}
> So the basic JBDS installer is 70MB fatter. From my understanding it's because we now ship a *huge* forge2 runtime (50MB), Tern, the JVM Monitor and probably some other minor stuff.
> Fair enough. But do we *really* need to add all the source features/plugins to the installer? *If* we're legally bound to provide sources for JBoss plugins, couldn't we provide them via an other way? (p2 only).
> I reckon we could save ~37 MB by not shipping sources in the installer. I know storage is cheap and d/l speeds are faster but that's not an excuse.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBDS-3071) JBDS Installer shouldn't contain source features/plugins
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3071?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3071:
-------------------------------------
>> installer-standalone.jar/jbds/features/org.eclipse.equinox.executable_3.6.100.v20140603-1326.jar
is not needed, because JBDS has its own IU for launchers
>>installer-standalone.jar/jbds/features/org.jboss.tools.aerogear.hybrid.feature_1.1.0.Beta3-v20140613-0534-B261.jar
Is not part of JBDS product feature
>> installer-standalone.jar/jbds/features/org.jboss.tools.common.mylyn.feature_3.6.0.Beta3-v20140616-1249-B497.jar
Is not part of JBDS product feature
>>installer-standalone.jar/jbds/features/org.jboss.tools.maven.jbosspackaging.feature_1.6.0.Beta3-v20140616-1458-B504.jar
Is not part of JBDS product feature
>>installer-standalone.jar/jbds/features/org.jboss.tools.usage.feature_2.0.0.Beta3-v20140616-1249-B497.jar
Is not part of JBDS product feature
>>installer-standalone.jar/jbds/features/org.jboss.tools.vpe.cordovasim.feature_3.5.100.Beta3-v20140613-0534-B261.jar
Is not part of JBDS product feature
installer-standalone.jar/jbds/features/org.jboss.tools.xulrunner.feature_3.5.100.Beta3-v20140616-2028-B539.jar
Is not part of JBDS product feature
installer-standalone.jar/jbds/features/org.mozilla.xulrunner.feature_1.9.218.Final-v20121126-2356-B155.jar
Is not part of JBDS product feature
>>installer-standalone.jar/jbds/plugins/com.google.gson_2.1.0.v201303041604.jar
>>installer-standalone.jar/jbds/plugins/minimal-json_0.9.1.jar
Tern related features should not be in installer and JBDS update site as well
>>installer-standalone.jar/jbds/plugins/org.eclipse.jetty.rewrite_8.1.14.v20131031.jar
not in studio/plugins for original installer
>>installer-standalone.jar/jbds/plugins/org.eclipse.mylyn.commons.identity.core_1.4.0.v20140331-0927.jar
>>installer-standalone.jar/jbds/plugins/org.eclipse.mylyn.commons.notifications.core_1.4.0.v20140331-0927.jar
>>installer-standalone.jar/jbds/plugins/org.eclipse.mylyn.commons.notifications.feed_1.4.0.v20140331-0927.jar
>>installer-standalone.jar/jbds/plugins/org.eclipse.mylyn.commons.notifications.ui_1.4.0.v20140331-0927.jar
>>installer-standalone.jar/jbds/plugins/org.eclipse.mylyn.commons.repositories.core_1.4.0.v20140331-0927.jar
>>installer-standalone.jar/jbds/plugins/org.eclipse.mylyn.commons.repositories.ui_1.4.0.v20140331-0927.jar
>>installer-standalone.jar/jbds/plugins/org.eclipse.mylyn.context.core_3.12.0.v20140328-2338.jar
>>installer-standalone.jar/jbds/plugins/org.eclipse.mylyn.monitor.core_3.12.0.v20140331-0927.jar
>>installer-standalone.jar/jbds/plugins/org.eclipse.mylyn.monitor.ui_3.12.0.v20140331-0927.jar
>>installer-standalone.jar/jbds/plugins/org.eclipse.mylyn.tasks.bugs_3.12.0.v20140401-2350.jar
>>installer-standalone.jar/jbds/plugins/org.eclipse.mylyn.tasks.core_3.12.0.v20140522-2107.jar
>>installer-standalone.jar/jbds/plugins/org.eclipse.mylyn.tasks.ui_3.12.0.v20140521-2340.jar
>>installer-standalone.jar/jbds/plugins/org.jboss.tools.common.mylyn_3.6.0.Beta3-v20140616-1249-B497.jar
all above should not be in installer because org.jboss.tools.common.mylyn.feature is not part of JBDS product feature
>>installer-standalone.jar/jbds/plugins/org.jboss.tools.jst.jsdt_3.6.0.Beta3-v20140612-1053-B637.jar
Tern, related stuff should not be in JBDS
>>installer-standalone.jar/jbds/plugins/org.jboss.tools.maven.jbosspackaging_1.6.0.Beta3-v20140616-1458-B504.jar
Not sure about this one, but it is not installed for original installer before PR applied
>>installer-standalone.jar/jbds/plugins/org.jboss.tools.vpe.cordovasim_3.5.100.Beta3-v20140613-0534-B261.jar
>>installer-standalone.jar/jbds/plugins/org.jboss.tools.vpe.cordovasim.eclipse_3.5.100.Beta3-v20140613-0534-B261.jar
>>installer-standalone.jar/jbds/plugins/org.jboss.tools.vpe.cordovasim.ripple_3.5.100.Beta3-v20140613-0534-B261.jar
ccordova feature is not included into JBDS product feature
>>installer-standalone.jar/jbds/plugins/org.jboss.tools.xulrunner_3.5.100.Beta3-v20140616-2028-B539.jar
this is branding plugin for xulrunner feature is not present after installing from original installer, sxulrunner feature is not included into JBDS product feature and xulrunner platform specific bundles are installed as greedy optional dependencies
>>installer-standalone.jar/jbds/plugins/tern.core_0.2.0.201405210810.jar
>>installer-standalone.jar/jbds/plugins/tern.eclipse_0.2.0.201405210810.jar
>>installer-standalone.jar/jbds/plugins/tern.eclipse.ide.core_0.2.0.201405210810.jar
>>installer-standalone.jar/jbds/plugins/tern.eclipse.ide.jsdt_0.2.0.201405210810.jar
>>installer-standalone.jar/jbds/plugins/tern.eclipse.ide.server.nodejs.core_0.2.0.201405210810.jar
>>installer-standalone.jar/jbds/plugins/tern.eclipse.ide.server.nodejs.ui_0.2.0.201405210810.jar
>>installer-standalone.jar/jbds/plugins/tern.eclipse.ide.tools.core_0.2.0.201405210810.jar
>>installer-standalone.jar/jbds/plugins/tern.eclipse.ide.tools.ui_0.2.0.201405210810.jar
>>installer-standalone.jar/jbds/plugins/tern.eclipse.ide.ui_0.2.0.201405210810.jar
>>installer-standalone.jar/jbds/plugins/tern.server.nodejs_0.2.0.201405210810.jar
Tern related features are not supposed to be in JBDS update site at all, that could be a different issue.
> JBDS Installer shouldn't contain source features/plugins
> --------------------------------------------------------
>
> Key: JBDS-3071
> URL: https://issues.jboss.org/browse/JBDS-3071
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 8.0.0.Beta2
> Reporter: Fred Bricon
> Assignee: Nick Boldt
> Fix For: 8.0.0.Beta3
>
>
> {quote}
> So the basic JBDS installer is 70MB fatter. From my understanding it's because we now ship a *huge* forge2 runtime (50MB), Tern, the JVM Monitor and probably some other minor stuff.
> Fair enough. But do we *really* need to add all the source features/plugins to the installer? *If* we're legally bound to provide sources for JBoss plugins, couldn't we provide them via an other way? (p2 only).
> I reckon we could save ~37 MB by not shipping sources in the installer. I know storage is cheap and d/l speeds are faster but that's not an excuse.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months