[JBoss JIRA] (JBIDE-19812) Refactor IConnection to be agnostic of authorization specifics
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19812?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19812:
-------------------------------
Fix Version/s: 4.5.0.AM1
(was: 4.4.x)
> Refactor IConnection to be agnostic of authorization specifics
> --------------------------------------------------------------
>
> Key: JBIDE-19812
> URL: https://issues.jboss.org/browse/JBIDE-19812
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.3.0.Beta1
> Reporter: Jeff Cantrill
> Labels: openshift_v3
> Fix For: 4.5.0.AM1
>
>
> The auth scheme can change in v3. A plain IConnection should be able to be refactored to support the auth details as an interface and details like get/set password, username, etc should be moved to those interface implementations.
> {code}
> public interface IConnection {
> ...
> public String getUsername();
> public void setUsername(String username);
> public String getPassword();
> public void setPassword(String password);
> public void setRememberPassword(boolean rememberPassword);
>
> public boolean isRememberPassword();
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (JBIDE-19822) Explorer: Refactor to properly handle object change notifications
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19822?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19822:
-------------------------------
Fix Version/s: 4.5.0.AM1
(was: 4.4.x)
> Explorer: Refactor to properly handle object change notifications
> -----------------------------------------------------------------
>
> Key: JBIDE-19822
> URL: https://issues.jboss.org/browse/JBIDE-19822
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Beta1
> Reporter: Jeff Cantrill
> Fix For: 4.5.0.AM1
>
>
> The content provider associated OpenShift Explorer view currently, manually refreshes the view in certain situations. Additionally there is not a way to provide the same refresh mechanism for classes that don't implement IRefreshable. Propose to refactor the model and view so that the model does not have a direct reference to the view and incorporate a way to handle classes that don't inherit from ObservablePojo (e.g. IResource)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (JBIDE-19594) SSL callback: provide meaningful hostname verifier, stop always accepting hostnames
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19594?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19594:
-------------------------------
Fix Version/s: 4.5.0.AM1
(was: 4.4.x)
> SSL callback: provide meaningful hostname verifier, stop always accepting hostnames
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-19594
> URL: https://issues.jboss.org/browse/JBIDE-19594
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Fix For: 4.5.0.AM1
>
>
> We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
> {code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
> public interface ISSLCertificateCallback {
> public boolean allowCertificate(X509Certificate[] chain);
> public boolean allowHostname(String hostname, SSLSession session);
> }
> {code}
> The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
> In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
> {code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
> @Override
> public boolean allowHostname(String hostname, SSLSession sslSession) {
> return true;
> }
> {code}
> We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
> This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification fail as in jdk. When fetching the quickstarts OSJC is reaching out to https://hub.openshift.com (https://hub.openshift.com/api/v1/quickstarts/promoted.json) while the ssl certificate presented only covers openshift.redhat.com:
> {code}
> * Server certificate:
> * subject: CN=openshift.redhat.com,O=Red Hat Inc.,L=Raleigh,ST=North Carolina,C=US
> * start date: Jul 23 00:00:00 2014 GMT
> * expire date: Jul 27 12:00:00 2017 GMT
> * common name: openshift.redhat.com
> * issuer: CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (JBIDE-19568) Disable the "Check for update" button while a check for update is in progress
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19568?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19568:
-------------------------------
Fix Version/s: 4.5.0.AM1
(was: 4.3.x)
> Disable the "Check for update" button while a check for update is in progress
> -----------------------------------------------------------------------------
>
> Key: JBIDE-19568
> URL: https://issues.jboss.org/browse/JBIDE-19568
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Fix For: 4.5.0.AM1
>
>
> while trying to check JBIDE-18559 I clicked "checked for updates" in central and got nothing, not even a dialog.
> In error log it was reporting this:
> org.eclipse.equinox.p2.core.ProvisionException: No repository found at file:/Users/max/code/jbdevstudio/linuxtools-docker/org.eclipse.linuxtools.docker.core/target/.
> at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.fail(AbstractRepositoryManager.java:395)
> at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.eclipse.oomph.util.ReflectUtil.invokeMethod(ReflectUtil.java:116)
> at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.fail(CachingRepositoryManager.java:284)
> at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.loadRepository(CachingRepositoryManager.java:191)
> at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager$Metadata.loadRepository(CachingRepositoryManager.java:378)
> at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96)
> at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92)
> at org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob.doLoad(LoadMetadataRepositoryJob.java:117)
> at org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob.runModal(LoadMetadataRepositoryJob.java:102)
> at org.eclipse.equinox.internal.p2.ui.sdk.PreloadingRepositoryHandler$2.runModal(PreloadingRepositoryHandler.java:83)
> at org.eclipse.equinox.p2.operations.ProvisioningJob.run(ProvisioningJob.java:177)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> would have expected we told the user about this error.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (JBIDE-19593) Minor UI issues in "Configure Repositories" wizard on OSX
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19593?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19593:
-------------------------------
Fix Version/s: 4.5.0.AM1
(was: 4.3.x)
> Minor UI issues in "Configure Repositories" wizard on OSX
> ---------------------------------------------------------
>
> Key: JBIDE-19593
> URL: https://issues.jboss.org/browse/JBIDE-19593
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven
> Reporter: Fred Bricon
> Priority: Minor
> Labels: uxp
> Fix For: 4.5.0.AM1
>
>
> On OSX, In the Window > Preferences > JBoss Tools > JBoss Maven Integration > Configure Maven Repositories...
> * The repo viewer should have a horizontal scroller, since adding the (inactive) suffix can make a pretty long label and you have to resize the whole dialog to be able to read the labels.
> This was fixed for Windows/Linux in 4.3.0.Alpha2
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (JBIDE-19454) Malformed strings when starting a remote host via localhost
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19454?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19454:
-------------------------------
Fix Version/s: 4.4.3.AM1
(was: 4.4.x)
> Malformed strings when starting a remote host via localhost
> -----------------------------------------------------------
>
> Key: JBIDE-19454
> URL: https://issues.jboss.org/browse/JBIDE-19454
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.3.Beta1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.3.AM1
>
>
> This is strange.
> When I create a remote WildFly 8.2 server on a remote server (I use a SSH-only remote host), everything works fine.
> But when I try to create a remote host that is actually localhost and then start WildFly, I get errors because some of the strings are broken.
> This is in the console in Eclipse:
> {code}
> echo $PWD'>'
> echo $PWD'>'
> java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.logmanager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-nattura:/ rasp$
> nattura:/ rasp$ cd /
> echo $PWD'>'
> echo $PWD'>'
> java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.logmanager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.janattura:/ rasp$
> nattura:/ rasp$ echo $PWD'>'
> echo $PWD'>'
> java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.logmanager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java "-Dne&/>
> nattura:/ rasp$ echo $PWD'>'
> />
> java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.logmanager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java "-Dne&
> eeeeeeeeTOOLnattura:/ rasp$ java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xm s64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net. preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.serve r.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.he adless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2. 0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jboss qa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-D jboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.log manager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/ jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa /runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.j boss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base .dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java "-Dne&
> > eeeeeeeeTOOLS_SERVER_START_CMD:WildFly 8 remote localhost:"$!
> 13:51:37,472 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final
> java.lang.IllegalStateException: JBAS018702: Server base directory does not exist: /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java
> at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:365)
> at org.jboss.as.server.Main.determineEnvironment(Main.java:262)
> at org.jboss.as.server.Main.main(Main.java:92)
> 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.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> nattura:/ rasp$
> {code}
> The correct path to the server is /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final as was set up. But for some reason, some of the strings are wrong in the startup command. Most notably this: -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java
> PS: I'm on OS X, so it might have something to do with that.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (JBIDE-19412) Cleanup ConnectionURL usage for v3 connections
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19412?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19412:
-------------------------------
Fix Version/s: 4.5.0.AM1
(was: 4.4.x)
> Cleanup ConnectionURL usage for v3 connections
> ----------------------------------------------
>
> Key: JBIDE-19412
> URL: https://issues.jboss.org/browse/JBIDE-19412
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: openshift_v3
> Fix For: 4.5.0.AM1
>
>
> In ConnectionsRegistry connections are stored by ConnectionURL. ConnectionURL is also used to persist v2 connections. v3 connections on the other hand are persisted in their very own json format. We need to clean this discrepany/inconsistency. We should either only use ConnectionURL for v2 connections or also store v3 connections in the ConnectionURL format.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months