[JBoss JIRA] (JBIDE-15798) Missing scroolbar in Cordova Feature Dialog
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15798?page=com.atlassian.jira.plugi... ]
Alexey Kazakov reassigned JBIDE-15798:
--------------------------------------
Assignee: Daniel Azarov (was: Alexey Kazakov)
> Missing scroolbar in Cordova Feature Dialog
> -------------------------------------------
>
> Key: JBIDE-15798
> URL: https://issues.jboss.org/browse/JBIDE-15798
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: aerogear-hybrid
> Affects Versions: 4.1.1.Beta1
> Environment: JBT 4.1.1 Beta1-v20131020-0207-B454
> Reporter: Vlado Pakan
> Assignee: Daniel Azarov
> Priority: Minor
> Fix For: 4.1.1.CR1
>
>
> 1. Create new Hybrid Mobile project
> 2. Open project config.xml file in Cordova Configuration Editor
> 3. Go to Platform Properties tab. and click on Add.... button to add features
> 4. Type some text to Find text field to specify search condition which cannot be fulfilled to get empty list of plugins
> 5. Clear Find: text field
> ERROR: Opened dialog has no scroll bar
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15937) All seam runtimes are checked after adding/removing
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15937?page=com.atlassian.jira.plugi... ]
Alexey Kazakov resolved JBIDE-15937.
------------------------------------
Resolution: Rejected
This is not a bug.
You can have one default runtime for every Seam version. So if you have three runtimes - 2.0, 2.2 and 2.3 then each of them can be default for corresponding Seam versions.
> All seam runtimes are checked after adding/removing
> ---------------------------------------------------
>
> Key: JBIDE-15937
> URL: https://issues.jboss.org/browse/JBIDE-15937
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: seam2
> Affects Versions: 4.1.1.Beta1
> Reporter: Radoslav Rábara
> Assignee: Alexey Kazakov
> Priority: Minor
> Fix For: 4.1.1.Final
>
> Attachments: seam runtimes - remaining are checked.jpg, seam runtimes - remove one.jpg
>
>
> All seam runtimes are checked after new seam runtime is added or existing one is removed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15864) Add dialog displaying errors when Plugins are added to Hybrid Mobile Project
by Gorkem Ercan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15864?page=com.atlassian.jira.plugi... ]
Gorkem Ercan commented on JBIDE-15864:
--------------------------------------
Releasing a fix to master to properly display error messages that occur during installation. Will also carry the fix to 4.1.1CR1
> Add dialog displaying errors when Plugins are added to Hybrid Mobile Project
> ----------------------------------------------------------------------------
>
> Key: JBIDE-15864
> URL: https://issues.jboss.org/browse/JBIDE-15864
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: aerogear-hybrid
> Affects Versions: 4.1.1.Beta1
> Reporter: Vlado Pakan
> Assignee: Gorkem Ercan
> Fix For: 4.1.1.CR1
>
>
> Sometimes when adding Plugins to Hybrid Mobile project via Cordova Configuration Editor some errors are happening and added Plugins are different than Plugins selected to be added. This is very confusing for user. Would be nice to have some dialog explaining errors which happened while adding Plugins so user know what has happened
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15798) Missing scroolbar in Cordova Feature Dialog
by Gorkem Ercan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15798?page=com.atlassian.jira.plugi... ]
Gorkem Ercan updated JBIDE-15798:
---------------------------------
Assignee: Alexey Kazakov
> Missing scroolbar in Cordova Feature Dialog
> -------------------------------------------
>
> Key: JBIDE-15798
> URL: https://issues.jboss.org/browse/JBIDE-15798
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: aerogear-hybrid
> Affects Versions: 4.1.1.Beta1
> Environment: JBT 4.1.1 Beta1-v20131020-0207-B454
> Reporter: Vlado Pakan
> Assignee: Alexey Kazakov
> Priority: Minor
> Fix For: 4.1.1.CR1
>
>
> 1. Create new Hybrid Mobile project
> 2. Open project config.xml file in Cordova Configuration Editor
> 3. Go to Platform Properties tab. and click on Add.... button to add features
> 4. Type some text to Find text field to specify search condition which cannot be fulfilled to get empty list of plugins
> 5. Clear Find: text field
> ERROR: Opened dialog has no scroll bar
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15830) openshift-java-client: incompatibility with OpenShift Enterprise and Origin when using the remote-user authentication plugin
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15830?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-15830 at 11/13/13 11:34 AM:
---------------------------------------------------------------------
The useragent is set via a properties file:
{code:title=RestService (constructor)}
setupClient(properties.getUseragent(clientId), protocolVersion, acceptedMediaType, client);
{code}
The properties file that shipped with the client library has the useragent that we're using in OpenShift. The properties file allows the maven build to substitute the plugin version in the user-agent:
{code:title=src\/main\/resources\/restservice.properties}
useragent=Java OpenShift REST/{0} ({1})
{code}
To my current understanding you should be able to override the user-agent by providing your own restservice.properties.
This would then in turn allow us to remove the magic code (discussed above) that mangles the useragent when keys are present.
was (Author: adietish):
The useragent is set via a properties file:
{code:title=RestService (constructor)}
setupClient(properties.getUseragent(clientId), protocolVersion, acceptedMediaType, client);
{code}
The properties file that shipped with the client library has the useragent that we're using in OpenShift. The properties file allows the maven build to substitute the plugin version in the user-agent:
{code:src/main/resources/restservice.properties}
useragent=Java OpenShift REST/{0} ({1})
{code}
To my current understanding you should be able to override the user-agent by providing your own restservice.properties.
This would then in turn allow us to remove the magic code (discussed above) that mangles the useragent when keys are present.
> openshift-java-client: incompatibility with OpenShift Enterprise and Origin when using the remote-user authentication plugin
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15830
> URL: https://issues.jboss.org/browse/JBIDE-15830
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.1.Beta1
> Reporter: Brenton Leanhardt
> Assignee: Andre Dietisheim
> Labels: openshift-java-client
> Fix For: 4.1.1.CR1, 4.2.0.Alpha1
>
>
> OpenShift Enterprise and Origin both ship an authentication plugin that allows parts of authentication to be handled by Apache and other parts to be delegated to the openshift-origin-controller codebase. I've found that all versions of openshift-java-client after 2.3.0.Final change a (poorly documented) requirement for the OpenShift remote-user plugin.
> In order for a request to bypass the Apache authentication and passthrough to the OpenShift Broker the user-agent header is inspected. If the user-agent is 'OpenShift' then the Broker will require an encrypted authentication token. Today this is used by the jenkins cartridge but I believe it's also still used for scaling.
> You can see this for details:
> https://github.com/openshift/origin-server/blob/master/documentation/arch...
> In 2.3.0.Final of the openshift-java-client the user-agent was 'OpenShift' however all versions after this set the user-agent to the java version (eg, User-Agent: Java/1.7.0_45).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15830) openshift-java-client: incompatibility with OpenShift Enterprise and Origin when using the remote-user authentication plugin
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15830?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-15830 at 11/13/13 11:34 AM:
---------------------------------------------------------------------
The useragent is set via a properties file:
{code:title=RestService (constructor)}
setupClient(properties.getUseragent(clientId), protocolVersion, acceptedMediaType, client);
{code}
The properties file that shipped with the client library has the useragent that we're using in OpenShift. The properties file allows the maven build to substitute the plugin version in the user-agent:
{code:title=src\/main\/resources\/restservice.properties}
useragent=Java OpenShift REST/{0} ({1})
{code}
To my current understanding you should be able to override the user-agent by providing your own restservice.properties (we load it via classpath).
This would then in turn allow us to remove the magic code (discussed above) that mangles the useragent when keys are present.
was (Author: adietish):
The useragent is set via a properties file:
{code:title=RestService (constructor)}
setupClient(properties.getUseragent(clientId), protocolVersion, acceptedMediaType, client);
{code}
The properties file that shipped with the client library has the useragent that we're using in OpenShift. The properties file allows the maven build to substitute the plugin version in the user-agent:
{code:title=src\/main\/resources\/restservice.properties}
useragent=Java OpenShift REST/{0} ({1})
{code}
To my current understanding you should be able to override the user-agent by providing your own restservice.properties.
This would then in turn allow us to remove the magic code (discussed above) that mangles the useragent when keys are present.
> openshift-java-client: incompatibility with OpenShift Enterprise and Origin when using the remote-user authentication plugin
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15830
> URL: https://issues.jboss.org/browse/JBIDE-15830
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.1.Beta1
> Reporter: Brenton Leanhardt
> Assignee: Andre Dietisheim
> Labels: openshift-java-client
> Fix For: 4.1.1.CR1, 4.2.0.Alpha1
>
>
> OpenShift Enterprise and Origin both ship an authentication plugin that allows parts of authentication to be handled by Apache and other parts to be delegated to the openshift-origin-controller codebase. I've found that all versions of openshift-java-client after 2.3.0.Final change a (poorly documented) requirement for the OpenShift remote-user plugin.
> In order for a request to bypass the Apache authentication and passthrough to the OpenShift Broker the user-agent header is inspected. If the user-agent is 'OpenShift' then the Broker will require an encrypted authentication token. Today this is used by the jenkins cartridge but I believe it's also still used for scaling.
> You can see this for details:
> https://github.com/openshift/origin-server/blob/master/documentation/arch...
> In 2.3.0.Final of the openshift-java-client the user-agent was 'OpenShift' however all versions after this set the user-agent to the java version (eg, User-Agent: Java/1.7.0_45).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15830) openshift-java-client: incompatibility with OpenShift Enterprise and Origin when using the remote-user authentication plugin
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15830?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-15830:
------------------------------------------
The useragent is set via a properties file:
{code:title=RestService (constructor)}
setupClient(properties.getUseragent(clientId), protocolVersion, acceptedMediaType, client);
{code}
The properties file that shipped with the client library has the useragent that we're using in OpenShift. The properties file allows the maven build to substitute the plugin version in the user-agent:
{code:src/main/resources/restservice.properties}
useragent=Java OpenShift REST/{0} ({1})
{code}
To my current understanding you should be able to override the user-agent by providing your own restservice.properties.
This would then in turn allow us to remove the magic code (discussed above) that mangles the useragent when keys are present.
> openshift-java-client: incompatibility with OpenShift Enterprise and Origin when using the remote-user authentication plugin
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15830
> URL: https://issues.jboss.org/browse/JBIDE-15830
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.1.Beta1
> Reporter: Brenton Leanhardt
> Assignee: Andre Dietisheim
> Labels: openshift-java-client
> Fix For: 4.1.1.CR1, 4.2.0.Alpha1
>
>
> OpenShift Enterprise and Origin both ship an authentication plugin that allows parts of authentication to be handled by Apache and other parts to be delegated to the openshift-origin-controller codebase. I've found that all versions of openshift-java-client after 2.3.0.Final change a (poorly documented) requirement for the OpenShift remote-user plugin.
> In order for a request to bypass the Apache authentication and passthrough to the OpenShift Broker the user-agent header is inspected. If the user-agent is 'OpenShift' then the Broker will require an encrypted authentication token. Today this is used by the jenkins cartridge but I believe it's also still used for scaling.
> You can see this for details:
> https://github.com/openshift/origin-server/blob/master/documentation/arch...
> In 2.3.0.Final of the openshift-java-client the user-agent was 'OpenShift' however all versions after this set the user-agent to the java version (eg, User-Agent: Java/1.7.0_45).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15941) Progress of deleting applications is not shown
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15941?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-15941:
------------------------------------------
The label (which should display: "Deleting application XXX") is not updated because I'm using the wrong method on the monitor to update the label:
{code:title=DeleteApplicationsJob}
@Override
protected IStatus doRun(IProgressMonitor monitor) {
int totalWork = applications.size();
monitor.beginTask("Deleting OpenShift Application(s)...", totalWork);
for (final IApplication application : applications) {
final String appName = application.getName();
try {
if (monitor.isCanceled()) {
return Status.CANCEL_STATUS;
}
monitor.subTask("Deleting Application " + application.getName());
application.destroy();
monitor.worked(1);
} catch (OpenShiftException e) {
return OpenShiftUIActivator.createErrorStatus(
NLS.bind("Failed to delete application \"{0}\"", appName), e);
} finally {
monitor.done();
}
}
return Status.OK_STATUS;
}
{code}
I should use *monitor#setTaskName* instead of *monitor#subTask*
updating the work that's done looks correct to me at first sight. The job is calling *monitor.worked(1)*
> Progress of deleting applications is not shown
> ----------------------------------------------
>
> Key: JBIDE-15941
> URL: https://issues.jboss.org/browse/JBIDE-15941
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.1.Beta1
> Reporter: Marián Labuda
> Assignee: Andre Dietisheim
> Priority: Minor
> Fix For: 4.2.x
>
> Attachments: delete1.png, delete2.png
>
>
> When deleting more applications at once (tried 2 and 3), there is a progress bar. For first application it shows correctly name. But for any other application (second, third...) there is missing text label and also missing percentage of progress. See attached images.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months