[JBoss JIRA] (JBIDE-25504) Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25504?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-25504 at 4/4/18 5:54 PM:
------------------------------------------------------------------
[~rhuss] I get the spring-boot app restarting fine but fail to have it load classes that I'd expect to hot swap:
I run the camel spring-boot example as exploded jar. I have the camel spring-boot example classes deployed to **/deployments/BOOT-INF/classes. The dependency is present as a jar in **/deployments/BOOT-INF/lib**.
I then try to hot swap the dependency by replacing the dependency jar with an exploded version (I tried both variants, adding an exploded folder with a different name or then replacing the jar with an exploded folder that has the same name). Spring-Boot then detects the change, restarts the whole app but wont use the new classes in the dependency. It still runs the classes that it had from the jar.
I have the classpath pointing to the following:
{code}
-cp /deployments/BOOT-INF/classes/:/deployments/BOOT-INF/lib/*:/deployments/BOOT-INF/lib/:/deployments
{code}
I also have the following file in /deployments/BOOT-INF/classes/META-INF/spring-devtools.properties where I try to push project B into the restart classloader
{code}
restart.include.dependency=/dependency-.*
{code}
Do you have any idea what I a missing so that I can hot swap classes in the dependency?
was (Author: adietish):
[~rhuss] I get the spring-boot app restarting fine but fail to have it load classes that I'd expect to hot swap:
I run the camel spring-boot example as exploded jar. I am deploying the dependency as a jar to /deployments/BOOT-INF/lib as a jar initially.
I then try to hot swap the dependency by replacing the dependency jar with an exploded version (I tried both variants, adding an exploded folder with a different name or then replacing the jar with an exploded folder that has the same name). Spring-Boot then detects the change, restarts the whole app but wont use the new classes in the dependency. It still runs the classes that it had from the jar.
I have the classpath pointing to the following:
{code}
-cp /deployments/BOOT-INF/classes/:/deployments/BOOT-INF/lib/*:/deployments/BOOT-INF/lib/:/deployments
{code}
I also have the following file in /deployments/BOOT-INF/classes/META-INF/spring-devtools.properties where I try to push project B into the restart classloader
{code}
restart.include.dependency=/dependency-.*
{code}
Do you have any idea what I a missing so that I can hot swap classes in the dependency?
> Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
> --------------------------------------------------------------------------------------
>
> Key: JBIDE-25504
> URL: https://issues.jboss.org/browse/JBIDE-25504
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.5.2.AM2
> Reporter: Jeff MAURY
> Assignee: Andre Dietisheim
> Labels: openshift, openshift_v3, server_adapter
> Fix For: 4.5.3.Final
>
> Attachments: springboot-dependencies.zip
>
>
> When a SpringBoot application is being deployed on OpenShift with the server adapter, we should support the following use case:
> * the SpringBoot app has a dependency which is avalailable in the workspace
> * when a modifiction is done on the dependency code, it should be synced to OpenShift by the server adapter
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25504) Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25504?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-25504 at 4/4/18 5:52 PM:
------------------------------------------------------------------
[~rhuss] I get the spring-boot app restarting fine but fail to have it load classes that I'd expect to hot swap:
I run the camel spring-boot example as exploded jar. I am deploying the dependency as a jar to /deployments/BOOT-INF/lib as a jar initially.
I then try to hot swap the dependency by replacing the dependency jar with an exploded version (I tried both variants, adding an exploded folder with a different name or then replacing the jar with an exploded folder that has the same name). Spring-Boot then detects the change, restarts the whole app but wont use the new classes in the dependency. It still runs the classes that it had from the jar.
I have the classpath pointing to the following:
{code}
-cp /deployments/BOOT-INF/classes/:/deployments/BOOT-INF/lib/*:/deployments/BOOT-INF/lib/:/deployments
{code}
I also have the following file in /deployments/BOOT-INF/classes/META-INF/spring-devtools.properties where I try to push project B into the restart classloader
{code}
restart.include.dependency=/dependency-.*
{code}
Do you have any idea what I a missing so that I can hot swap classes in the dependency?
was (Author: adietish):
[~rhuss] I get the spring-boot app restarting fine but fail to have it load classes that I'd expect to hot swap:
I run the camel spring-boot example as exploded jar. I am deploying the dependency as a jar to /deployments/BOOT-INF/lib as a jar initially.
I then try to hot swap the dependency by replacing the dependency jar with an exploded version (I tried both variants, adding an exploded folder with a different name or then replacing the jar with an exploded folder that has the same name). Spring-Boot then detects the change, restarts the whole app but wont use the new classes in the dependency. It still runs the classes that it had from the jar.
I have the classpath pointing to the following:
-cp /deployments/BOOT-INF/classes/:/deployments/BOOT-INF/lib/*:/deployments/BOOT-INF/lib/:/deployments
I also have the following file in /deployments/BOOT-INF/classes/META-INF/spring-devtools.properties where I try to push project B into the restart classloader
restart.include.dependency=/dependency-.*
Do you have any idea what I a missing so that I can hot swap classes in the dependency?
> Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
> --------------------------------------------------------------------------------------
>
> Key: JBIDE-25504
> URL: https://issues.jboss.org/browse/JBIDE-25504
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.5.2.AM2
> Reporter: Jeff MAURY
> Assignee: Andre Dietisheim
> Labels: openshift, openshift_v3, server_adapter
> Fix For: 4.5.3.Final
>
> Attachments: springboot-dependencies.zip
>
>
> When a SpringBoot application is being deployed on OpenShift with the server adapter, we should support the following use case:
> * the SpringBoot app has a dependency which is avalailable in the workspace
> * when a modifiction is done on the dependency code, it should be synced to OpenShift by the server adapter
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25504) Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25504?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-25504:
------------------------------------------
[~rhuss] I get the spring-boot app restarting fine but fail to have it load classes that I'd expect to hot swap:
I run the camel spring-boot example as exploded jar. I am deploying the dependency as a jar to /deployments/BOOT-INF/lib as a jar initially.
I then try to hot swap the dependency by replacing the dependency jar with an exploded version (I tried both variants, adding an exploded folder with a different name or then replacing the jar with an exploded folder that has the same name). Spring-Boot then detects the change, restarts the whole app but wont use the new classes in the dependency. It still runs the classes that it had from the jar.
I have the classpath pointing to the following:
-cp /deployments/BOOT-INF/classes/:/deployments/BOOT-INF/lib/*:/deployments/BOOT-INF/lib/:/deployments
I also have the following file in /deployments/BOOT-INF/classes/META-INF/spring-devtools.properties where I try to push project B into the restart classloader
restart.include.dependency=/dependency-.*
Do you have any idea what I a missing so that I can hot swap classes in the dependency?
> Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
> --------------------------------------------------------------------------------------
>
> Key: JBIDE-25504
> URL: https://issues.jboss.org/browse/JBIDE-25504
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.5.2.AM2
> Reporter: Jeff MAURY
> Assignee: Andre Dietisheim
> Labels: openshift, openshift_v3, server_adapter
> Fix For: 4.5.3.Final
>
> Attachments: springboot-dependencies.zip
>
>
> When a SpringBoot application is being deployed on OpenShift with the server adapter, we should support the following use case:
> * the SpringBoot app has a dependency which is avalailable in the workspace
> * when a modifiction is done on the dependency code, it should be synced to OpenShift by the server adapter
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25901) MINISHIFT_HOME is not propagated to new detected cdk binary properly
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25901?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-25901:
---------------------------------------
[~rob.stryker] the main problem here is that you never told anybody about those choices that you made. I may admit that it makes sense, but I cannot guess how you made things work - I was operating under the assumption that we honor $MINISHIFT_HOME at all times. So when I see it not being the case what do I do? I report a bug!
So this is not about me feeling it should work one way or the other. This is about me inferring the correct behavior based on the information you gave me previously.
OK, now about minishift home. You're right that the situation is not ideal. Especially for the use case of avoiding the CLI altogether (i.e. when downloading using runtime detection) it seems to make sense to make up a unique minishift home directory for each new binary/adapter. But in another case it may be desirable. Consider this scenario: You're all set in CLI - you have your custom $MINISHIFT_HOME and a cdk binary somewhere. You start devstudio and search your cdk dir or start creating a cdk server adapter manually - in both cases it would be preferable to use the $MINISHIFT_HOME variable. So now which one is more common - to have multiple cdk adapters where we don't want to use one minishift home path for all of them OR users having $MINISHIFT_HOME setup and dealing with just one cdk binary. I'm afraid I cannot answer this one with high level of confidence, but I would guess that multiple cdk binaries/adapters is not a common setup for our end users.
One more question: Can you please some up the use cases where having $MINISHIFT_HOME will make a difference? I just did a quick test to see what happens if I have that and install devstudio and then run it. The result was that runtime detection had both paths - ~/.minishift and $MINISHIFT_HOME. Is that intended? What are the other use cases for $MINISHIFT_HOME? Thanks!
> MINISHIFT_HOME is not propagated to new detected cdk binary properly
> --------------------------------------------------------------------
>
> Key: JBIDE-25901
> URL: https://issues.jboss.org/browse/JBIDE-25901
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, runtime-detection
> Affects Versions: 4.5.3.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> Following some of the changes to how cdk and runtime detection works (most notably that path to cdk binary can now be used for searching), I wanted to try and see if $MINISHIFT_HOME is still respected and works properly. And it seems to fail.
> I started devstudio with MINISHIFT_HOME=/Users/rasp/minishift_home, then ran runtime detection against /Users/rasp/tmp where a cdk binary was found. But the newly created adapter had this set up as minishift home: /Users/rasp/tmp/MINISHIFT_HOME
> That seems totally wrong.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25901) MINISHIFT_HOME is not propagated to new detected cdk binary properly
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25901?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-25901:
-------------------------------------
a server adapter needs 2 things really: 1) minishift binary location, and 2) a minishift_home
if a user makes a runtime detection path of /home/user/some_minishift_home, then my runtime detection will use that minishift_home when creating the server adapter. We will then try to find a minishift binary somewhere, to create the server adapter
however, if a user makes a runtime detection path of /home/user/apps/cdk32 which has a valid cdk / minishift binary inside it, then we have the binary, and we need to find a minishift_home for it
if 4 server adapter are all using the same minishift_home, it will get corrupted. you cant have 4 different versions of something using the same minishift_home . its a recipe for it to get corrupted
[~mmalina] feels all newly detected runtimes should use the minishift_home set on the environment... which will usually be ~/.minishift but could be something else this seems very bad to me, because 4 different cdks being detected will all be configured to use the same minishift_home
[~jeffmaury] [~adietish] What do you guys think here? Should we use the default minishift_home passed in via the environment? Or should we create a new one for each detected runtime?
> MINISHIFT_HOME is not propagated to new detected cdk binary properly
> --------------------------------------------------------------------
>
> Key: JBIDE-25901
> URL: https://issues.jboss.org/browse/JBIDE-25901
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, runtime-detection
> Affects Versions: 4.5.3.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> Following some of the changes to how cdk and runtime detection works (most notably that path to cdk binary can now be used for searching), I wanted to try and see if $MINISHIFT_HOME is still respected and works properly. And it seems to fail.
> I started devstudio with MINISHIFT_HOME=/Users/rasp/minishift_home, then ran runtime detection against /Users/rasp/tmp where a cdk binary was found. But the newly created adapter had this set up as minishift home: /Users/rasp/tmp/MINISHIFT_HOME
> That seems totally wrong.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25901) MINISHIFT_HOME is not propagated to new detected cdk binary properly
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25901?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-25901:
-------------------------------------
It seemed extremely common to me that users (or other testers) would complain of their cdk / minishift not functioning properly, and this was caused by an old minishift_home which had data from an old version of cdk.
This happened so often that it became extremely annoying. Having 3 different versions of CDK all using the same minishift_home, and testing each version, having one version clobber or corrupt the home directory for the other two, etc etc.
It really seems to me that best practices should indicate that each server has its own minishift_home. I really don't know if what I'm doing is best, but it seems to me it's the cleanest.
I guess we can ask for an executive opinion here. But I really don't think encouraging everyone to use the same minishift_home is smart.
> MINISHIFT_HOME is not propagated to new detected cdk binary properly
> --------------------------------------------------------------------
>
> Key: JBIDE-25901
> URL: https://issues.jboss.org/browse/JBIDE-25901
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, runtime-detection
> Affects Versions: 4.5.3.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> Following some of the changes to how cdk and runtime detection works (most notably that path to cdk binary can now be used for searching), I wanted to try and see if $MINISHIFT_HOME is still respected and works properly. And it seems to fail.
> I started devstudio with MINISHIFT_HOME=/Users/rasp/minishift_home, then ran runtime detection against /Users/rasp/tmp where a cdk binary was found. But the newly created adapter had this set up as minishift home: /Users/rasp/tmp/MINISHIFT_HOME
> That seems totally wrong.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25858) Minishift binary is not set up after CDK runtime download
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25858?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-25858:
---------------------------------------
For the record, I did click on the link ;) But didn't really read the code - just checked what was that commit. I admit I could have at least briefly read the code.
> Minishift binary is not set up after CDK runtime download
> ---------------------------------------------------------
>
> Key: JBIDE-25858
> URL: https://issues.jboss.org/browse/JBIDE-25858
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.5.3.AM3
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.5.3.Final
>
>
> This is a followup of JBIDE-25835 .
> Recently a new feature was added - cdk can be downloaded directly from the IDE now.
> As with other runtimes, there are two main paths you can take:
> a) New Server -> Download
> b) Preferences -> Runtime Detection -> Download
> tl;dr: b) doesn't work properly with cdk because minishift binary is still not set after the download.
> There is quite a big difference between a) and b). With a), you are adding a server manually and once your download is finished, the correct path is predefined for you. Runtime detection is not involved.
> With b), the server is downloaded, extracted and then the path is added to runtime detection which is in turn run. This will result in the new server being detected and added.
> Now cdk should theoretically support both of these paths. a) works - you're in the middle of adding a cdk server manually, you invoke the download and once that's done, the minishift binary field is filled properly for you.
> But b) doesn't work properly for cdk, because runtime detection for cdk is built around your minishift home and not the minishift binary path. (I don't really know why that's the case, but I guess you had a good reason for it.) So when you do b), cdk binary is downloaded, but what's added to runtime detection is ~/.minishift (or $MINISHIFT_HOME if set). The result is that the cdk server adapter is added once the download is finished, but the minishift binary remains empty. So the usefulness of this feature is questionable.
> Maybe you will say that there is no way to fix this. I hope you will at least agree that this is not ideal and b) doesn't really work properly right now.
> I don't know what the proper solution for this is but let me start with a question: Wouldn't it make sense to change runtime detection of cdk so that it uses the minishift binary as the main path? What's stopping us from doing that?
> Sorry for the lengthy description, I felt I needed to explain the whole context here.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25858) Minishift binary is not set up after CDK runtime download
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25858?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-25858:
-------------------------------------
If you clicked on teh code link I sent, you'd see it does both.
{code}
+ if( isValidMinishiftHome(root)) {
+ return createHomeDefinition(root);
+ }
+
+ if( folderContainsMinishiftBinary(root)) {
+ return createBinaryDefinition(root);
+ }
+ return null;
+ }
{code}
> Minishift binary is not set up after CDK runtime download
> ---------------------------------------------------------
>
> Key: JBIDE-25858
> URL: https://issues.jboss.org/browse/JBIDE-25858
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.5.3.AM3
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.5.3.Final
>
>
> This is a followup of JBIDE-25835 .
> Recently a new feature was added - cdk can be downloaded directly from the IDE now.
> As with other runtimes, there are two main paths you can take:
> a) New Server -> Download
> b) Preferences -> Runtime Detection -> Download
> tl;dr: b) doesn't work properly with cdk because minishift binary is still not set after the download.
> There is quite a big difference between a) and b). With a), you are adding a server manually and once your download is finished, the correct path is predefined for you. Runtime detection is not involved.
> With b), the server is downloaded, extracted and then the path is added to runtime detection which is in turn run. This will result in the new server being detected and added.
> Now cdk should theoretically support both of these paths. a) works - you're in the middle of adding a cdk server manually, you invoke the download and once that's done, the minishift binary field is filled properly for you.
> But b) doesn't work properly for cdk, because runtime detection for cdk is built around your minishift home and not the minishift binary path. (I don't really know why that's the case, but I guess you had a good reason for it.) So when you do b), cdk binary is downloaded, but what's added to runtime detection is ~/.minishift (or $MINISHIFT_HOME if set). The result is that the cdk server adapter is added once the download is finished, but the minishift binary remains empty. So the usefulness of this feature is questionable.
> Maybe you will say that there is no way to fix this. I hope you will at least agree that this is not ideal and b) doesn't really work properly right now.
> I don't know what the proper solution for this is but let me start with a question: Wouldn't it make sense to change runtime detection of cdk so that it uses the minishift binary as the main path? What's stopping us from doing that?
> Sorry for the lengthy description, I felt I needed to explain the whole context here.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25858) Minishift binary is not set up after CDK runtime download
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25858?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-25858:
--------------------------------
Fix Version/s: 4.5.3.Final
> Minishift binary is not set up after CDK runtime download
> ---------------------------------------------------------
>
> Key: JBIDE-25858
> URL: https://issues.jboss.org/browse/JBIDE-25858
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.5.3.AM3
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.5.3.Final
>
>
> This is a followup of JBIDE-25835 .
> Recently a new feature was added - cdk can be downloaded directly from the IDE now.
> As with other runtimes, there are two main paths you can take:
> a) New Server -> Download
> b) Preferences -> Runtime Detection -> Download
> tl;dr: b) doesn't work properly with cdk because minishift binary is still not set after the download.
> There is quite a big difference between a) and b). With a), you are adding a server manually and once your download is finished, the correct path is predefined for you. Runtime detection is not involved.
> With b), the server is downloaded, extracted and then the path is added to runtime detection which is in turn run. This will result in the new server being detected and added.
> Now cdk should theoretically support both of these paths. a) works - you're in the middle of adding a cdk server manually, you invoke the download and once that's done, the minishift binary field is filled properly for you.
> But b) doesn't work properly for cdk, because runtime detection for cdk is built around your minishift home and not the minishift binary path. (I don't really know why that's the case, but I guess you had a good reason for it.) So when you do b), cdk binary is downloaded, but what's added to runtime detection is ~/.minishift (or $MINISHIFT_HOME if set). The result is that the cdk server adapter is added once the download is finished, but the minishift binary remains empty. So the usefulness of this feature is questionable.
> Maybe you will say that there is no way to fix this. I hope you will at least agree that this is not ideal and b) doesn't really work properly right now.
> I don't know what the proper solution for this is but let me start with a question: Wouldn't it make sense to change runtime detection of cdk so that it uses the minishift binary as the main path? What's stopping us from doing that?
> Sorry for the lengthy description, I felt I needed to explain the whole context here.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25901) MINISHIFT_HOME is not propagated to new detected cdk binary properly
by Martin Malina (JIRA)
Martin Malina created JBIDE-25901:
-------------------------------------
Summary: MINISHIFT_HOME is not propagated to new detected cdk binary properly
Key: JBIDE-25901
URL: https://issues.jboss.org/browse/JBIDE-25901
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: cdk, runtime-detection
Affects Versions: 4.5.3.Final
Reporter: Martin Malina
Assignee: Rob Stryker
Following some of the changes to how cdk and runtime detection works (most notably that path to cdk binary can now be used for searching), I wanted to try and see if $MINISHIFT_HOME is still respected and works properly. And it seems to fail.
I started devstudio with MINISHIFT_HOME=/Users/rasp/minishift_home, then ran runtime detection against /Users/rasp/tmp where a cdk binary was found. But the newly created adapter had this set up as minishift home: /Users/rasp/tmp/MINISHIFT_HOME
That seems totally wrong.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months