We would like to have our rules files managed outside of the service source code for our quarkus / kogito project. Can the be located in a location other than resources, specified by an env or application properties?
there are always one right solution and one simple solution :)
symbolic link can solve issue of place
this is currently not possible. We are considering supporting assets from the classpath (instead of the plain file system) "à la kjar"
source: I am a Kogito dev :-)
Related
I'd like to include a robots.txt file into a WAR file but use a different version based on the destination (e.g. sandbox or production).
What is the best way to achieve this with maven? My first thought it is
Create two different robots.txt in the source code; one called produdction.robots.txt and another called sandbox.robots.txt
Use https://coderplus.github.io/copy-rename-maven-plugin/rename-mojo.html to rename the appropriate file to robots.txt during the build process
use maven war configuration to exclude the other file
Is there a more elegant way? Note: we're using Gitlab CI/CD though I don't think that is too pertinent, assuming it is best to keep this process solely within the maven build cycle.
Thanks!
I'm using msdeploy on the command-line to deploy a windows service using the sync verb against dirPath source and destination providers. So far so good.
My project's build assets have per-environment config files, and during deploy to a particular environment I want to rename the targeted environment's config file to the default config file name using a replace rule, but no matter how I engineer my replace rule nothing seems to get me the results I want. I've tried with a number of different configurations of the rule with no luck but the one that seems the most logical is this one:
-replace:objectName=filePath,scopeAttributeName=path,scopeAttributeValue=Service\.Dev\.exe\.config,match=Service\.Dev\.exe\.config,replace=Service.exe.config
If I deploy without the replace rule both Service.Dev.exe.config and Service.exe.config are deployed with the expected respective content. Once I add the replace rule above I get just Service.exe.config and it's got the content of that file from the source, not the content of Service.Dev.exe.config as I am hoping for. If I swap the specifications of the match and replace components (and change regexp <-> plain text accordingly) to arrive at:
-replace:objectName=filePath,scopeAttributeName=path,scopeAttributeValue=Service\.Dev\.exe\.config,match=Service\.exe\.config,replace=Service.Dev.exe.config
I just get Service.Dev.exe.config with the content of Service.exe.config and no Service.exe.config in the destination.
I'm sure I'm missing something obvious, but what is it?
This doesn't directly answer your question but I think its a better solution to your root problem.
The real issue here is config management for different environments. Many developers create different configs for each environment like you do. This approach requires a lot of duplication across your different config files which can easily get out of sync.
The best approach I've found for managing configuration across different environments is WebDeploy Parameterization. It is similar to config transforms in that you have a single base config file that is tweaked, so there is far less duplication. Parameterization however is preferred because it applies the changes at deploy time instead of build time. We use this for 50+ applications with great success.
Here is a blog post with more details - http://www.dotnetcatch.com/2014/09/08/parameterizationpreview-visual-studio-extension/
The match and replace should swap
match=Service.Dev.exe.config,replace=Service\.exe\.config
I have deployed applications in Websphere 8.5, and I want to modify web.xml, but it seems not working. What I am supposed to do?
While there are documented ways of updating enterprise application files, those were conceived for multi-server deployments and partly are legacy of the previous decade of monster application servers. They are inconvenient for making changes to local development server and it wastes a lot of time.
Upon application deployment, WAS creates (copies/updates) deployment descriptors in the config directory. Then web.xml is used from that location.
You are probably changing web.xml in the location where original application files are kept, thus no effect. You should change the one in config\cells\<cell_name>\applications\<ear_name>\deployments\<app_name>\<war_name>\WEB-INF.
WebSphere writes a second file named web_merged.xml. If you only update the web.xml and replace it you will not update the runtime file used by the container.
Best result I had was using the single file upload function provided within the Admin console or to use the wsadmin or jacl cmd.
The proper way is to update application via console/script.
But I'm assuming you are editing file directly (very hard to guess from your description, I've asked you to describe your procedure).
You need to restart the application to pick up changes in web.xml. See the Hot deploy in WAR files
Two ways:
Update web.xml with WebSphere Web Console
Update web_merged.xml at the same time, and also update the two files in config\cells\<cell_name>\applications\<ear_name>\deployments\<app_name>\<war_name>\WEB-INF
In order to know which revision number the application is built from, we use to give the ears we deploy to Glassfish names like myapp_2012-01-20_rev22123.ear. Then we can simply login to Glassfish and see what version is deployed in the web interface (as the appname is the name of the ear file). A downside of this approach is that we need to do a manual undeploy/redeploy to update the name...
But I would like to script the undeploy/deploy process, and having each version of an ear get a different name is not very suitable to scripting this redeployment process. Glassfish 2 does not support the "list applications" goal that Glassfish 3 has, which I could have used to retrieve the application name to undeploy.
So is there any good strategy that will easily allow us to see what version is deployed of an application, and that does not suffer from the above fault?
It would be preferable if this meant we did not have to change the existing applications (like add a jsp page or something to show the current scm revision), but a change in a Maven build script would be acceptable.
I faced a similar issue, I finally came around it by using maven-buildnumber-plugin and writing a simple servlet to get build information. You can find the details in the blog post I made.
Why not use the built-in GlassFish Server versioning to assign a version number at deploy time? This will also enable you to rollback to prior versions. For example:
asadmin deploy --name MyApplication:2012-01-20_rev22123 MyApplication.ear
There is more information on application versioning here:
http://docs.oracle.com/cd/E18930_01/html/821-2417/gihzx.html#gkhhv
Hope this helps.
I use WebSphere 7 and I've set shared libraries as described in this example http://www-10.lotus.com/ldd/portalwiki.nsf/dx/06062009015816PMWEBP3Y.htm
My application is running with this setting, but I can't deploy it (update). At deploy it can't find the classes in the shared libraries. I don't have the error message right now because I had to revert the changes but maybe somebody knows what's missing from the example.
We edited the setupCmdLine.bat file and appended the path where our jars can be found to the classpath variables but i'm sure this is not the right way to do it :)
I assume that ejbdeploy is the cause of the problem? In an ND environment, ejbdeploy occurs on the dmgr as part of the installation, so using an application server shared library wouldn't make sense. For consistency, the same is true for a standalone server. You'll need to use the -deployejb.classpath option to AdminApp to point to your shared library classpath (in ND, the paths must exist on the dmgr). If you're deploying from the admin console, I believe there's an "extra classpath" field you can populate.