[JBoss JIRA] (JBIDE-19181) correct naming of internal packages so that they're consistent across all openshift plugins
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19181?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19181:
-------------------------------------
Fix Version/s: 4.5.x
(was: 4.5.0.AM1)
> correct naming of internal packages so that they're consistent across all openshift plugins
> -------------------------------------------------------------------------------------------
>
> Key: JBIDE-19181
> URL: https://issues.jboss.org/browse/JBIDE-19181
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: openshift
> Affects Versions: 4.3.0.Alpha1
> Reporter: Andre Dietisheim
> Fix For: 4.5.x
>
>
> Internal packages across the openshift plugins are non-consistent:
> ex.
> org.jboss.tools.openshift.client: org.jboss.tools.openshift.client.internal
> org.jboss.tools.openshift.express.client: org.jboss.tools.openshift.express.client.internal
> the base is imho org.jboss.tools.openshift and thus internal packages should always be at org.jboss.tools.openshift.internal across plugins.
> For reference, here's the official Eclipse documentation on the topic: http://wiki.eclipse.org/index.php/Naming_Conventions#Java_Packages
> {quote}
> org.eclipse.jdt.internal.core.compiler - Correct usage
> org.eclipse.jdt.core.internal.compiler - Incorrect. internal should immediately follow subproject name.
> org.eclipse.core.internal.resources - Correct usage
> org.eclipse.internal.core.resources - Incorrect. internal should never immediately follow org.eclipse.
> org.eclipse.core.resources.internal - Incorrect. internal should immediately follow Eclipse Platform component name.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JBIDE-19412) Cleanup ConnectionURL usage for v3 connections
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19412?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19412:
-------------------------------------
Fix Version/s: 4.5.x
(was: 4.5.0.AM1)
> 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
> Labels: connection, openshift_v3
> Fix For: 4.5.x
>
>
> 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)
8 years, 10 months
[JBoss JIRA] (JBIDE-19412) Cleanup ConnectionURL usage for v3 connections
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19412?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19412:
-------------------------------------
Labels: connection openshift_v3 (was: openshift_v3)
> 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
> Labels: connection, 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)
8 years, 10 months
[JBoss JIRA] (JBIDE-19822) Explorer: Refactor to properly handle object change notifications
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19822?page=com.atlassian.jira.plugi... ]
Andre Dietisheim closed JBIDE-19822.
------------------------------------
Nothing for QE to verify here. Closing.
> 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
> Assignee: Andre Dietisheim
> Labels: explorer, openshift_v3
> 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)
8 years, 10 months
[JBoss JIRA] (JBIDE-19822) Explorer: Refactor to properly handle object change notifications
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19822?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-19822 at 6/6/17 7:42 AM:
------------------------------------------------------------------
Automatic updates are implemented. Resolving.
was (Author: adietish):
Automatic updates are implemented. Resolving.
> 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
> Assignee: Andre Dietisheim
> Labels: explorer, openshift_v3
> 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)
8 years, 10 months
[JBoss JIRA] (JBIDE-19594) SSL callback: provide meaningful hostname verifier, stop always accepting hostnames
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19594?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19594:
-------------------------------------
Labels: connection (was: )
> 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
> Assignee: Andre Dietisheim
> Labels: connection
> Fix For: 4.5.x
>
>
> 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)
8 years, 10 months
[JBoss JIRA] (JBIDE-19811) Refactor IConnection interface to support connection specific display formating
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19811?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19811:
-------------------------------------
Labels: connection openshift_v3 (was: connection)
> Refactor IConnection interface to support connection specific display formating
> -------------------------------------------------------------------------------
>
> Key: JBIDE-19811
> URL: https://issues.jboss.org/browse/JBIDE-19811
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.3.x
> Reporter: Jeff Cantrill
> Labels: connection, openshift_v3
> Fix For: 4.5.x
>
>
> Ultimately, IConnection should be oblivious to username and password since those are authentication specific. There are a few places where we should introduce a 'display' interface which each type can implement in order to remove the dependency of the common label provider on username and password
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JBIDE-19812) Refactor IConnection to be agnostic of authorization specifics
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19812?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19812:
-------------------------------------
Labels: connection openshift_v3 (was: openshift_v3)
> 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: connection, openshift_v3
> Fix For: 4.5.x
>
>
> 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)
8 years, 10 months