I have a library that relies on exporting a sun.reflect package from JRE.properties. During testing I have been manually adding this. What can I do to ensure this is automatically added within Apache Karaf?
Changes to the etc/jre.properties requires a container restart. If you are deploying this Karaf instance inside a Linux container (aka Docker), you would simply include this change as part of the linux container image build.
However, if you are deploying into a Virtual Machine environment, you'd want to make this part of your organization's custom build of Karaf. I suggest using a Maven project with the Assembly plugin to apply all your organization's changes-- ldap, security, ssl certs, etc/jre.properties... etc. It would then create a new .tar.gz or .zip file that and you would deploy your app into the modified Karaf instance.
There is an example in the HYTE Runtime build here:
HYTE Runtime
Technically, you could leverage the feature deployment mechanism to deploy an updated file, but this won't cause the Karaf instance to restart.
Related
I am new to Spring Boot from php world. In Php development, it is simple to make changes on the file, upload and run.
But on Spring boot, my development relies on remote ubuntu server, every time I make change in *.java, I have to build the Fat Jar, upload the Jar, kill the current java process on ubuntu, and run the java -jar my.jar again, which spend much time on the upload because the Jar is about 60 mb.
Is there any way I can work like php, just upload the changed file, so the spring boot just compile the class and run?
Does change to build *.war help to faster deployment?
There are a few option to mitigate the roundtrip of building the jar file and upload it.
Hot-swap: For minor changes, you can hot-swap changes automatially when you have a remote-debugger attached. I use Intellij as Ide, which provide this out of the box after a file is recompiled, see more at this link how to enable it.
Reloading tool: use a tool that are designed to reload Java classes, such as JRebel which extends the classloader and updates a class if a change has been detected. However, they are often only available in a paid version.
Spring Boot dev-tools: this tool also monitors changes and restart the application with the new changes (so no need to rebuild the jar file). It is possible to use on a remote application. See this link for more info.
Using a war file is different concept since a war file is executed inside an application container (e.g a Wildfly server). You can dynamically upload a war file to a running application server, which will only restart the war file. But I'm not sure if this will lead to faster deployment, however it is a different approach how the application is run.
Briefing
I'm having some issue while setting up a Continuous Deployment environment for an application built using SpringBoot and Angular IO, using Shippable as CI and Elastic Beanstalk as production environment.
The Current Scenario
1) Application JAR being correctly generated through Shippable (we use heroku as staging)
2) Local JAR correctly generated and manual deploy to Elastic BeansTalk working fine
The Problem
My problem is integrating Shippable to automate the deploy to Elastic Beanstalk.
I've followed this tutorial from shippable:
http://blog.shippable.com/how-to-deploy-to-elastic-beanstalk-part-1
and I've finished up with a successfully deploy from Shippable to Elastic Beanstalk, except that Shippable has generated a .zip with the source code (it was actually the purpose of the tutorial and I haven't noticed that hehe) and I need the executable JAR to be deployed on my Elastic Beantalk environment.
The Specific Question
So the question: Is there a way to deploy my Springboot executable JAR to Elastic BeansTalk using the built-in Shippable Integration? Or do I have to manually write the steps on shippable.yml and use eb deploy to make it work?
Thanks a lot!
Update one
In this Amazon link:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-configuration.html#eb-cli3-artifact
They specify a way to deploy an artifact instead of the source code.
As Shippable calls eb deploy, creating the configuration file makes shippable integration calls the deploy on the artifact passed as parameter
to eb deploy. I believe it's just a matter of finding where (in file hierarchy) Shippable is calling the eb deploy. I though it was from the root of the project but it gives an ERROR:
ERROR: Application Version does not exist locally
(project/backend/target/myjar.jar). Try uploading the
Application Version again.
Anyone knows from where shippable calls the commands from the deploy section (configured in shippable.yml, more info in the first link mentioned in this question)?
I'm having trouble understanding how to configure the Deployment URL for JRebel for JBoss, when our application is not deployed as an exploded war, but via a Maven deploy using JBoss's CLI features.
In the properties window for JRebel (in Eclipse) what is required in the Deployment URL? Generally it's something like http://my.server:1234/my-application. However if we have no such directory then how is configuration done? is it even possible?
Deployment URL requires an address in the format:
Deployment URL: http://serveraddress:port/???
You only need to use the JRebel remoting functionality (adding the deployment URL) if you're deploying your application onto a server that is on a different machine or VM than your IDE.
If you start JBoss from the CLI on the same machine as your IDE, then you don't need the deployment URL and should turn off remoting. Just need the Java agent and rebel.xml files.
JRebel remoting Deployment URL is your application home page URL. JRebel will start listening on that server on a specific path that IDE knows to send the changed files over HTTP POST requests.
It is also possible to make JRebel listen to these HTTP request on custom port if needed. JVM argument -Drebel.remoting_port=[portNumber] will make this happen.
This is where I am at:
I am using Drools 6.2 and calling drools engine remotely via KIE Execution Server running on jboss.
I used workbench to create my initial drl file and fact objects and then used Build & Deploy option of workbench to create and deploy the jar file. I then created the container using the jar file and got the end point that I am using to access the rule engine from my client application. At this point every thing is working fine and I am able to fire the rules remotely.
My requirement is to modify the rules file (.drl) outside the workbench, let's say in notepad and update the container with this new drl file. Is there an easy way to create the jar file programmatically that i can deploy to the central maven repository? I can then run the KIE scanner to look for the latest version of my jar file and automatically update my container. Or is there another recommended way to update the running container with an updated .drl file?
My client application is not in Java so I am not looking for an integrated solution where I can write java code to create the knowledge base and use kie builder to build the drl file.
Is there an easy way to create the jar file programmatically that i can deploy to the central maven repository?
2 options that I can think of, one "easy" and one not so much:
Option 1
Use Maven and the maven drools plugin (you don't have to write Java code, just create your maven project and run mvn package to get a jar. See here: https://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html/KIEChapter.html#KIEModuleIntroductionBuildingIntroductionSection
Option 2
A JAR file is simply a zip file with a specified structure. That means that you should be able to update your whatever.drl file, put it in the directory structure that the KIE server expects and deploy it.
For instance, create a directory structure like:
META-INF/kmodule.xml
com/site/project/drools/rules/myrule/SomeRule.drl
Zip those files into somefile.jar and deploy it.
I have problem with deploying JSR168 portlet using xmlaccess. I have no problem with deploy and join to conrete page but I would like to add shared library reference automatically. Is it possible?? I added shared library named 'libshared' using IBM WS console. Can I add this reference in input xml using by xmlaccess?
I don't think you can do this in xmlaccess. But you may try putting a reference to the library under the Manifest.MF file of the META-INF directory of your portlet's war file.
Or could just put the shared jar file under your /shared/ext directory. Or you could put it inside your wps.ear file. Mind you, either of these two solutions would share your library with the entire portal installation, rather than just select portlets.
You can deploy the application using wsadmin or similar and use that to update the classpath (i.e. for the shared library), you can then use xmlaccess to deploy the portlets and reference the previously deployed application - although I think this may only work in WebSphere Portal 6.1.
Give me a shout if you need further details.
I encountered this as well, a while ago... and researched it to the max, including spending some time chatting with IBM's support in various levels.
The XMLAccess protocol doesn't provide for such "system-level" configuration alongside Portlet application deployment; it can only be used to install, customize and uninstall Portlet applications and related artifacts.
If your deployment strategy involves deploying WAR files directly through XMLAccess, then you will have to manually add the shared-library to the application through the WAS admin console; this will have to be done manually because, when deploying WAR files through XMLAccess, an EAR with some random name is being created by WebSphere Portal to "host" your WAR file; hence you can't script the attachment of a shared library.
(alternatively, you may wish to add the shared library to the server's (WebSphere_Portal) classpath)
If your deployment strategy, instead, involves deploying Portlet applications packaged as EARs, then you're in a better position; you could automate the shared-library attachment as part of your EAR deployment process, then use XMLAccess to inform WebSphere Portal about the location, in the EAR, of your Portlet applications (which is what Michael mentioned above; it works in WebSphere Portal 6.0 as well).
Good luck.