I'm trying to build a Pustefix web application based on Pustefix' 0.16 tutorial.
Initial setup went fine, basic web app works fine.
However, simple changes made in txt/pages/main_EnterData.xml (like changing color or some text labels) have no immediate effect and nothing happens either on mvn clean tomcat:run.
The culprit is easily identified: it is folder webapp/.cache containing cached web content; here EnterData.xml.
Folder webapp/.cache is generated by Pustefix's core servlet on startup. For yet unkown reasons, that cache folder is not updated if the input source file changed.
Question 1: How to configure Pustefix to automatically update its cache?
Question 2: How to configure Pustefix to disable each and every cache?
Question 3: How to tell Pustefix where the file cache should reside?
Answer for Q1:
Define environment variable MAKE_MODE and set it to some arbitrary answer but 'prod', i.e. like
% export MAKE_MODE=devel
% mvn tomcat:run
Things changed in Pustefix 0.19:
% mvn tomcat:run -Dpustefix.mode=devel
Alternatively, use context parameter 'mode' in web.xml like
<context-param>
<param-name>mode</param-name>
<param-value>devel</param-value>
</context-param>
Answer for Q3:
Run
% mvn tomcat:run-war
in order to run the unpacked war file. When doing so, target/firstapp-myversion/.cache becomes the new cache folder.
Answer for Q2:
Impossible without breaking Pustefix internals.
Related
I would like to have my:
spring.datasource.url = jdbc:mysql://666.666.666.666/prod_very_wow
Change into:
spring.datasource.url = jdbc:mysql://666.666.666.666/dev_very_wow
According to the branch I am currently on. I think I should also have it specified within the Dockerfile - I should have a property added next to docker's RUN which should determine which data source ought to be activated.
Namely, I would like my app to be connected to prod_very_wow when I am on master branch and dev_very_wow everytime I am checking out to dev or creating a new feature branch and have it all determined by a property added to RUN mvn package within the Dockerfile.
I apologise if the question makes no sense, but, frankly - I am a little bit clueless how to ask this question and so I have troubles googling for answers.
I just found a couple of leads about "environmental variables", but I can't find any connection between the datasource connected to and the branch I am currently on.
The best way to handle different configuration based on environment is to have decoupled your code from your configuration that is one of the twelve-factor apps principles. In this case you should have an external config server, like spring cloud config server, that will host the configurations files for the different environments and the application will ask this config server for the proper config file depending on the environment where it is deployed.
However, if you don't want to follow this approach you can create the different configuration files in the application and use an environment variable that tells spring which file to use. For example, in your case you can have an application-local.yaml and application-prod.yaml, and then if you want to specify it in the dockerfile in the mvn package command, you can use:
RUN mvn -Dspring.profiles.activ=local package
RUN mvn -Dspring.profiles.activ=prod package
My target platform is a WebLogic 12c application server.
I have an ear-project, which on startup requires e.g. org.apache.commons.logging.LogFactory.
I know that this class - an related classes - can be found in <WL_HOME>/modules/com.bea.core.apache.commons.logging.api_1.1.1.jar, but it is not by default available on the classspath.
In such cases - am I supposed to somehow make the jar file in <WL_HOME>/modulesavailable on the classpath - or should I provide whatever jar file I find suitable - either bundled in the application, or placed in <WL_HOME>/user_projects/domains/<mydomain>/lib?
If I am to use the one in the <WL_HOME>/modules folder - how do I configure my domain to make it available?
To me it seems reasonable that the jar files in the modules folder should be considered provided dependencies, but so far I have been unable to find the right way to enable them as such - I have been browsing for an answer for hours:-)
UPDATE:
I know I can simply add them to the CLASSPATH variable in the server startup script - my question is more like - should I? Is there a better way - or should I completely forget about <WL_HOME>/modules?
That's a short-sighted approach.
you need to reboot the server to upgrade libraries
every app on the server must be okay with those libraries in their claspath
Weblogic has the concept of Shared JEE Libraries (example). In short, you add extra lines to MANIFEST.MF and configure the jar differently, then you can reference it in other apps using weblogic-application.xml or whatever.
The point is that you can upgrade the library without restarting the server (provided you gave it a version like 1.1 (there were bugs last time I named it 1.1.1 - it needed to be able to cast it to a floating-point number to seamlessly upgrade)).
If you just want to include some libraries but not share them outside the app, then just specify the correct <prefer-application-packages> or < prefer-web-inf-classes> element, depending on whether you have an EAR or a WAR.
Although I have been working in java for a while, there are many small things I have been ignoring, which at times have become bottleneck in productivity. I have difficulty in understanding this:
This is one of the bean.xml which gets placed in the final .war file (in a web application, built with spring framework).
<context:property-placeholder
location="classpath:/${deploy.env}/com.example.config/db.properties"
ignore-resource-not-found="false" />
I have following doubts:
1) At the time of building the code, i did like this for passing value of deploy.env
mvn clean install -Ddeploy.env=local
I ran the mvn in debug mode and could see this set to local. Now, the thing is, in the .war that gets generated, it is still ${deploy.env} (see above snippet). Doesn't this get replaced in the final .war? If not, then how do we pass the value which we intend to set?
2) what does "classpath:/${deploy.env}/com.example.config/db.properties" mean? Who sets the value of classpath? Are classpath capable of providing the location of resource files as well?
Assuming deploy.set --> local, so would this get translated to:
classpath:"/local/com.example.config/db.properties"
So does this mean db.properties would be present at: /local/com.example.config/db.properties
Any inputs to understand this would be of great help.
deploy.env is either environment variable or system property available to the JVM at run time.
The classpath:/${deploy.env}/com.example.config/db.properties will be resolved at run when your war is running in the container.
Set deploy.env=whatever in the shell from where you starting the tomcat or set in the environment of the user which starts the tomcat.
mvn clean install -Ddeploy.env=local here the deploy.env system property is available at build time. This will not replace the value of your spring config.
classpath is where all your classes and libraries bundled in the war are available along with the tomcat libraries. The spring property configurer will look for the db.properties file in the classpath at location e.g. /local/com.example.config
Spring documentation to learn more
Some explanation on my blog post
As stated in the Oracle Web site: The CLASSPATH variable is one way to tell applications, including the JDK tools, where to look for user classes.
That classpath: is referring to that location in particular, whatever it is, so it will start looking for those resources defined by Spring from that location and on, until it finds the first match.
Also, if you have that as a property in Maven, the value can be replaced with the right plug-in and configuration; not quite useful when you want a build that can be used with many values within those .properties files for different environments.
You can use other prefixes as file:, http:, etcetera. But you are just wondering about classpath:.
We are new to Weblogic (12c). We try to choose how we're going to pass some configurations to the application depending on the environment it is running on (dev / staging /prod).
I'm currently trying to use a deployment plan. In WEB-INF/web.xml, I have :
<context-param>
<param-name>test</param-name>
<param-value>11111</param-value>
</context-param>
And I use a plan.xml for my application in Weblogic.
Some parts :
<variable-definition>
<variable>
<name>test</name>
<value xsi:nil="false">22222</value>
<description>some description</description>
</variable>
</variable-definition>
and
<module-descriptor external="false">
<root-element>web-app</root-element>
<uri>WEB-INF/web.xml</uri>
<variable-assignment>
<name>test</name>
<xpath>/web-app/context-param/[param-name="test"]/param-value</xpath>
<origin>planbased</origin>
<operation>replace</operation>
</variable-assignment>
</module-descriptor>
This works!
But I heard it could be possible to change the value of the variable from the administration console, is that true?
When I browse my application in the console (in the Deployment Plan tab or in the Configuration tab), I do not see any field which I could use to change the test variable... Am I missing something or must the values of overriding variables be set in the plan.xml file itself?
I do not think you can change the variable directly, I believe this is because it's a fundamental change to the deploy that requires a "hot update" BUT you can easily "redeploy/update" with a new plan. This is how you would do it in a production environment:
From the Weblogic admin console, click Deployments, click the checkbox next to your ear/war
Click Update
The next screen will ask you for the source path and the deployment plan path, you can change just the deployment plan path to set your new value(s)
You can also call java weblogic.Deployer with the update option if you want to do it from the command line.
It is also possible to do the same via WLST scripting - see these Oracle Docs
I have the problem to find the performances of the plugin sysdeo by using the integrated plugin WTP of eclipse.
To make the migration and thus the comparison, I installed both on separate projects within eclipse.
I noticed a difference of productivity, according to what I understood: WTP needs to publish sources in a directory build so that tomcat have them at arrangement. This "pulish" is long : need the recharging of the context so that the modifications are visible. (5 dry in most yard 15sec - 20sec in the longest).
Sysdeo no; it targets of the directory eclipse consequently build internal in the project as soon as a modification is made by a file, eclipse build and these modifications are available immediately (F5 on the browser and we have the result immediately).
Here is my configuration of server:
The option " Serves modules without publishing " allows to make exactly what makes sydeo: to choose the build directory of the project running. This configuration expresses himself in the file of context. (It is to be able to get back it that I have checked " Publish modulates contexts to serparate XML rows ")
Comparison of these files:
Here is the file of context to generate by sysdeo
< Context path="/tatoile _syseo" reloadable="false" docBase="D:\32bit\serveur32bit\workspace\tatoile _syseo" workDir="D:\32bit\serveur32bit\workspace\tatoile _syseo\work" />
The file context to generate by WTP
< ?xml version="1.0" encoding="UTF-8"?>
< Context
docBase="D:\32bit\serveur32bit\workspace\tatoile\web" path="/tatoile"
reloadable="true" source="org.eclipse.jst.jee.server:tatoile">
< Resources
className="org.eclipse.jst.server.tomcat.loader.WtpDirContext"
extraResourcePaths="/WEB-INF/classes|D:\32bit\serveur32bit\workspace\tatoile\build\classes"
virtualClasspath="D:\32bit\serveur32bit\workspace\tatoile\build\classes"/>
< Loader
className="org.eclipse.jst.server.tomcat.loader.WtpWebappLoader"
useSystemClassLoaderAsParent="false"
virtualClasspath="D:\32bit\serveur32bit\workspace\tatoile\build\classes"/>
< JarScanner scanAllDirectories="true"/> < /Context>
Later analyze those two files is alike.
Now let us return to the problem. I use the same server, consequently both files of context above are defined for this one. Experience: I launch the tomcat by the plugin sysdeo, the loads in two context is made the one to configure way WTP the other one by sysdeo. Both authorities reacts in the same way, the modifications are immediate in tatoile _syseo and tatoile.
On the other hand, I launch tomcat via the plugin WTP (tab server etc.) in eclipse, the modifications are not immediately made in both projects tatoile _syseo and tatoile. Note: Auto-reload has to be necessarily put in Enabled so that the modifications be taken into account. (When the server indicates us that it has reload the context we can see the modifications.)
I deduct that from it the configuration of contexts not is not the reason, but rather the way the plugin launches tomcat; and there or I dry …
Here is WTP project:
The answer quoted from #Vsplit
The problem was solved by adding MAVEN with WTP deployment. No
performance problems ... and I don't activate serve modules without
publishing
look in the plugin marketplace for a free plugin called m2e-wtp. That will take care of the provided scope issues. As for classes not being deployed, the usual places I look at are the deployment assembly and/or Java Build Path. Make sure that the entries (and the dependent modules) are all there and located in the right place.