[JBoss JIRA] (JBIDE-15766) openshift-java-client: dont refresh env variables on each addition/removal
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15766?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-15766 at 10/24/13 6:36 AM:
--------------------------------------------------------------------
[~mwigglesworth-redhat] very valid concerns, did not think about them when rushing for the rest of the UI, thanks for fiddling this out.
But thinking this API through a 2nd time I pretend that the whole backend API is broken. The general rule of thumb is that you need the diff to be done as close as possible to the peer that stores it. Having to do the diff in the remote client is imho the worst possible solution, it requires the client to constantly refresh while not gaining any significant guarantee, just increasing likelyhood. The constant refreshing also forces the user program (a UI or any other) to also constantly update it's env vars.
My personal opinion is that - also given the normal pattern of explicit refreshes we have - we should not refresh constantly. We could eventually refresh when there's an error, sticking to the explicit refresh.
On the long run we should IMHO ask the OpenShift team to change this API and switch to an API where we submit the whole map of vars at once, letting the backend fiddling out what operations are required (removal, addition, update)
was (Author: adietish):
[~mwigglesworth-redhat] very valid concerns, did not think about them when rushing for the rest of the UI. But thinking this API through a 2nd time I pretend that the whole backend API is broken. The general rule of thumb is that you need the diff to be done as close as possible to the peer that stores it. Having to do the diff in the remote client is imho the worst possible solution, it requires the client to constantly refresh while not gaining any significant guarantee, just increasing likelyhood. The constant refreshing also forces the user program (a UI or any other) to also constantly update it's env vars.
My personal opinion is that - also given the normal pattern of explicit refreshes we have - we should not refresh constantly. We could eventually refresh when there's an error, sticking to the explicit refresh.
> openshift-java-client: dont refresh env variables on each addition/removal
> --------------------------------------------------------------------------
>
> Key: JBIDE-15766
> URL: https://issues.jboss.org/browse/JBIDE-15766
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.1.Beta1, 4.2.0.Alpha1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
>
>
> When adding/removing environment variables, the openshift-java-client would always request the backend for the full list. This should not be required and avoided
> {code:title=ApplicationResource#addEnvironmentVariable}
> EnvironmentVariableResourceDTO environmentVariableResourceDTO =
> new AddEnvironmentVariableRequest().execute(name, value);
> IEnvironmentVariable environmentVariable = new EnvironmentVariableResource(environmentVariableResourceDTO, this);
> updateEnvironmentVariables();
> return environmentVariable;
> {code}
> {code:title=ApplicationResource#updateEnvironmentVariables}
> protected void updateEnvironmentVariables() throws OpenShiftException {
> if (environmentVariableByName == null) {
> environmentVariableByName = loadEnvironmentVariables();
> } else {
> environmentVariableByName.clear();
> environmentVariableByName.putAll(loadEnvironmentVariables());
> }
> }
> {code}
--
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, 6 months
[JBoss JIRA] (JBIDE-15766) openshift-java-client: dont refresh env variables on each addition/removal
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15766?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-15766 at 10/24/13 6:33 AM:
--------------------------------------------------------------------
[~mwigglesworth-redhat] very valid concerns, did not think about them when rushing for the rest of the UI. But thinking this API through a 2nd time I pretend that the whole backend API is broken. The general rule of thumb is that you need the diff to be done as close as possible to the peer that stores it. Having to do the diff in the remote client is imho the worst possible solution, it requires the client to constantly refresh while not gaining any significant guarantee, just increasing likelyhood. The constant refreshing also forces the user program (a UI or any other) to also constantly update it's env vars.
My personal opinion is that - also given the normal pattern of explicit refreshes we have - we should not refresh constantly. We could eventually refresh when there's an error, sticking to the explicit refresh.
was (Author: adietish):
[~mwigglesworth-redhat] very valid concerns, did not think about them when rushing for the rest of the UI. But thinking this API through a 2nd time I pretend that the whole backend API is broken. The general rule of thumb is that you need the diff to be done as close as possible to the peer that stores it. Having to do the diff in the remote client is the worst possible solution. There's 0 guarantee for the client to be up-to-date anyhow. It is verly likely that he'll run into a race condition. In this situation I still dont see the benefit of constantly refreshing the env vars.
> openshift-java-client: dont refresh env variables on each addition/removal
> --------------------------------------------------------------------------
>
> Key: JBIDE-15766
> URL: https://issues.jboss.org/browse/JBIDE-15766
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.1.Beta1, 4.2.0.Alpha1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
>
>
> When adding/removing environment variables, the openshift-java-client would always request the backend for the full list. This should not be required and avoided
> {code:title=ApplicationResource#addEnvironmentVariable}
> EnvironmentVariableResourceDTO environmentVariableResourceDTO =
> new AddEnvironmentVariableRequest().execute(name, value);
> IEnvironmentVariable environmentVariable = new EnvironmentVariableResource(environmentVariableResourceDTO, this);
> updateEnvironmentVariables();
> return environmentVariable;
> {code}
> {code:title=ApplicationResource#updateEnvironmentVariables}
> protected void updateEnvironmentVariables() throws OpenShiftException {
> if (environmentVariableByName == null) {
> environmentVariableByName = loadEnvironmentVariables();
> } else {
> environmentVariableByName.clear();
> environmentVariableByName.putAll(loadEnvironmentVariables());
> }
> }
> {code}
--
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, 6 months
[JBoss JIRA] (JBIDE-15779) Plugin removed via config.xml editor is not removed from <project>/plugins directory
by Vlado Pakan (JIRA)
Vlado Pakan created JBIDE-15779:
-----------------------------------
Summary: Plugin removed via config.xml editor is not removed from <project>/plugins directory
Key: JBIDE-15779
URL: https://issues.jboss.org/browse/JBIDE-15779
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: aerogear-hybrid
Affects Versions: 4.1.1.Beta1
Reporter: Vlado Pakan
Fix For: 4.1.1.CR1
Steps to reproduce:
1. Create new Hybrid Mobile project
2. Open project config.xml file, add some feature on tab. Platform Properties and save
ASSERT: Respective plugins are added to project plugins directory
3, Remove added feature from config.xml file similar way as in point 2.
ERROR: Removed plugin is still in plugins directory. When project is built for Android via calling menu Run As > Run on Android Emulator. This plugin is added to built project and it's not correct
--
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, 6 months
[JBoss JIRA] (JBIDE-15778) CordovaSim: Firebug lite is not opened when CordovaSim and browsersim windows are on second monitor
by Vlado Pakan (JIRA)
Vlado Pakan created JBIDE-15778:
-----------------------------------
Summary: CordovaSim: Firebug lite is not opened when CordovaSim and browsersim windows are on second monitor
Key: JBIDE-15778
URL: https://issues.jboss.org/browse/JBIDE-15778
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: browsersim
Affects Versions: 4.2.0.Alpha1
Environment: win7 with two monitors
Reporter: Vlado Pakan
Assignee: Konstantin Marmalyukov
Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
1. Open CordovaSim.
2. Place cordovaSim and browserSim windows on main monitor.
3. Open FirebugLite. ASSERT: Firebug window appears.
4. Move both windows on secondary monitor.
5. Open Firebug Lite. ASSERT: FBL window does not appears.
--
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, 6 months
[JBoss JIRA] (JBIDE-14579) Upgrade PhoneGap version in the generated application project
by Vlado Pakan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14579?page=com.atlassian.jira.plugi... ]
Vlado Pakan closed JBIDE-14579.
-------------------------------
Verified with JBT 4.1.1 Beta1-v20131020-0207-B454
> Upgrade PhoneGap version in the generated application project
> -------------------------------------------------------------
>
> Key: JBIDE-14579
> URL: https://issues.jboss.org/browse/JBIDE-14579
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: aerogear-hybrid
> Affects Versions: 4.1.0.Beta1
> Reporter: Stefan Bunciak
> Assignee: Gorkem Ercan
> Priority: Minor
> Fix For: 4.1.1.Beta1
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> While building sample application generated by Hybrid Mobile (Cordova) Application Project wizard, I got warning:
> {code}
> This app is using PhoneGap 1.9.0. We will be ending support for 1.9 and below on May 15 -- see our blog post*.
> {code}
> *[https://build.phonegap.com/apps/411297/blog/ending-support-for-phonegap-1-9]
> {code}
> This app isn't using the latest version of PhoneGap. We recommend upgrading to 2.5.0.
> {code}
> I suppose we should keep up.
--
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, 6 months
[JBoss JIRA] (JBIDE-14726) Cannot run Cordova project on iOS Emulator
by Vlado Pakan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14726?page=com.atlassian.jira.plugi... ]
Vlado Pakan closed JBIDE-14726.
-------------------------------
Verified with JBT 4.1.1 Beta1-v20131020-0207-B454
> Cannot run Cordova project on iOS Emulator
> ------------------------------------------
>
> Key: JBIDE-14726
> URL: https://issues.jboss.org/browse/JBIDE-14726
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: aerogear-hybrid
> Affects Versions: 4.1.0.Beta1
> Environment: Darwin machydra.brq.redhat.com 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan 6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64
> Reporter: Stefan Bunciak
> Assignee: Gorkem Ercan
> Priority: Critical
> Fix For: 4.1.1.Beta1
>
> Attachments: screenshot.png
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> {code}
> dyld: Library not loaded: @rpath/iPhoneSimulatorRemoteClient.framework/Versions/A/iPhoneSimulatorRemoteClient
> Referenced from: /Users/jbossqa/Downloads/eclipse/configuration/org.eclipse.osgi/bundles/264/data//ios-sim
> Reason: image not found
> {code}
> The files seems to be present:
> !screenshot.png|thumbnail!
--
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, 6 months