I am using Apache Camel on a web-app and I want to call external xslt stylesheet.
I am using the absolute file URI (until now I was not able to use the relative file URI on Tomcat)
The Camel doc refer the following option :
contentCache default:true Camel 2.6: Cache for the resource content (the stylesheet file) when it is loaded. If set to false Camel will reloader the stylesheet file on each message processing. This is good for development.
But I haven't find anything about the duration of this cache.
Is there anyway to know the default value of this cache duration and to change it?
The content is cached without a timeout and there currently isn't an option to change it (see the source code here).
Feel free to log a CAMEL enhancement request in JIRA and we can possibly add support for specifying a custom timeout.
Related
I have configuration files which are in HOCON (.conf) format. I would like to use Spring Cloud Config to fetch them from a BitBucket repo, and send them to an application (which is NOT a Spring application) when it boots.
I am using the "Serving Plain Text" feature of Spring Cloud Config to fetch and serve a single HOCON file, which defines a particular environment. For example, the client application requests the development.conf environment configuration file, and by specifiying it's exact path in the BitBucket repo, say myApp/development/master/development.conf, the client is served that plaintext file.
However, as is usually desired, I would like base properties from the base.conf to be included in development.conf and have values overridden by the dev enviroment property values if there are common properties in both files.
Previously there was no config server, and so by simply writing the include "base" command at the top of the development.conf file, a HOCON parser (part of the TypeSafe library) in the client app requested the base.conf file (both files being in local directories), and did the overriding when necessary.
When including a Spring Config server, development.conf can be fetched in plain text as mentioned, but it is only (as before) at the client side that the application parses the include "base" command and then refetches the base.conf file. This makes the boot phase of the app very slow (probably) because fetching the additional files requires additional authorization on BitBucket.
Question: how to make it faster?
I have tried spring.cloud.config.server.git.cloneOnStart: true, but this has apparently no improvement (maybe I'm using it incorrectly?)
Should I consider converting the .conf format to .properties format, and using spring.profiles.include: base property at the top of the new developement.properties file?
Perhaps embed the Spring server in another Spring Boot application?
I like the property overriding and inclusion feature of Spring Cloud. I just don't know how to make it work with HOCON formatted files.
I am looking at externalizing certain configuration parameters for ehcache in our Grails application and I am running into something not working that the documentation claims ought to.
Likely there is something I am missing.
I am using the grails ehcache plugin version 1.0.1 with Grails 2.4.0 and grails cache plugin 1.1.7. I am using hibernate plugin 3.6.10.16.
Here's what I have in my CacheConfig.groovy configuration...
...
cacheManagerPeerProviderFactory {
peerDiscovery 'automatic'
factoryType 'rmi'
multicastGroupAddress '${ehcacheMulticastGroupAddress}'
multicastGroupPort '${ehcacheMulticastGroupPort}'
timeToLive 'site'
}
I've turned on debug-level logging so I can see what XML it generates. Here's the relevant snippet:
<cacheManagerPeerProviderFactory class='net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory'
properties="peerDiscovery=automatic,multicastGroupAddress=${ehcacheMulticastGroupAddress},multicastGroupPort=${ehcacheMulticastGroupPort},timeToLive=32"
propertySeparator=','
/>
The grails ehcache plugin documentation has the following note, which I was hoping to "prove out"...
(note that ${ehcacheMulticastGroupAddress} and ${ehcacheMulticastGroupPort} are an Ehcache feature that lets you use system property names as variables to be resolved at runtime)
Great. Except that it doesn't work when I start the application. It fails to create CacheManagerPeerProvider due to the following
...
Caused by UnknownHostException: ${ehcacheMulticastGroupAddress}
->> 901 | lookupAllHostAddr in java.net.InetAddress$1
...
I have a myApplication-config.groovy file living in an accessible area that I point to when assigning a value to grails.config.locations in Config.groovy. But I am not sure it is making any effort to really interpolate that value at all.
I tried double quotes but they were a bad idea as well -- at the time of interpreting CacheConfig.groovy it doesn't see the configuration I put into myApplication-config.groovy. I do know it reads that file in successfully at some point because I successfully use it to drive some Quartz job logic, so the placement of that config file is probably not the issue.
The answer is that I need to set SYSTEM PROPERTIES for ehcache to find. Using Grails configuration files such as myApplication-config.groovy is completely incorrect.
The CacheConfig.groovy file is correct, as is the XML it generates. So the question becomes, how do the properties it looks for get set correctly in the first place?
I am deploying to Tomcat. For Tomcat, setting system properties makes the most sense in a setenv.bat file (or setenv.sh on *nix).
I created setenv.bat, put the following into it
set CATALINA_OPTS=%CATALINA_OPTS% -DehcacheMulticastGroupAddress=230.0.0.1 -DehcacheMulticastGroupPort=4446 -DehcachePeerListenerPort=40001
...And it worked. Ehcache was able to find the system properties and start everything appropriately.
tl;dr: system properties != grails application config
Velocity, Freemarker, Japid, Rythm, any other?
What i am looking for is a solution similar to what JSP provides in servlet environment. It should be a form of ViewProcessor implementation, but working on standalone embedded Grizzly deployment(NIO architecture).
Jersey has support for freemarker templates - see jersey-freemarker module on maven. It works with any container (i.e. is not depending on servlet). There is also freemarker sample in Jersey workspace that shows how to use it - see here.
I think all the template engines you listed could be used in an independent environment. Specifically for Rythm (coz I am the author of this stuff), it loads template files from different sources:
from the String content supplied:
String result = Rythm.render("hello #who", "world");
from a file found from the rythm.root setting:
String result = Rythm.render("helloWorld.html", "world");
from a file found from the class path if you have no rythm.root setup
It just doesn't depend on any servlet container, so you are free to use it as long as you have JRE. Be sure to set rythm.noFileWrite to true if you want to use it in GAE where no file write is allowed.
The Open Source Project
http://www.bitplan.com/index.php/SimpleRest
supplies a TemplateResource base class which will do most of the "heavy lifting" to make Jersey, Grizzly and the Rythm template engine work together nicely.
I have a jboss seam 2.2.2 project and it is my first time using internationalization with this framework. I have already set the default locale and using the global messages_XX.properties is already working.
Well, this project is growing fast and for better organization and for ease of maintance I would like to have the messages better organized in various properties files for specific pages.
Seam documentation on internationalization mention this and in a specific paragraph it says:
If you want to define a message just for a particular page, you can
specify it in a resource bundle with the same name as the JSF view id,
with the leading / and trailing file extension removed. So we could
put our message in welcome/hello_en.properties if we only needed to
display the message on /welcome/hello.jsp
This paragraph can be found at: http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/i18n.html#d0e14166
The docs mention pages with .jsp extension but in my case I am using facelets and what I have is a .xhtml file so for my home.xhtml page I have created a home_pt_BR.properties file being pt_BR the default locale for my app and I have placed messages for this specific page in this .properties file.
Actually this approach did not work for me.
I have also tryed to register the page in faces-config.xml and also in pages.xml but again this does not seem to work.
So, how do I configure Seam to support multiple bundle files for my application?
You could add the bundle files to components.xml
For example:
<core:resource-loader>
<core:bundle-names>
<value>messages</value>
<value>strings</value>
</core:bundle-names>
</core:resource-loader>
I'm using Spring 2.5.6. I have a bean whose properties are being assign from a property file via a PropertyPlaceholderConfigurer. I'm wondering whether its possible to have the property of the bean updated when the property file is modified. There would be for example some periodic process which checks the last modified date of the property file, and if it has changed, reload the bean.
I'm wondering if there is already something that satisfies my requirements. If not, what would be the best approach to solving this problem?
Thanks for your help.
Might also look into useing Spring's PropertyOverrideConfigurer. Could re-read the properties and re-apply it in some polling/schedular bean.
It does depend on how the actual configured beans use these properties. They might, for example, indirectly cache them somewhere themself.
If you want dynamic properties at runtime, perhaps another way to do it is JMX.
One way to do this is to embed a groovy console in your application. Here's some instructions. They were very simple to do, btw - took me very little time even though I'm not that familiar with groovy.
Once you do that you can simply go into the console and change values inside the live application on the fly.
You might try to use a custom scope for the bean that recreates beans on changes of the properties file. See my more extensive answer here.
Spring Cloud Config has facilities to change configuration properties at runtime via the Spring Cloud Bus and using a Cloud Config Server. The configuration or .properties or .yml files are "externalized" from the Spring app and instead retrieved from a Spring Cloud Config Server that the app connects to on startup. That Cloud Config Server retrieves the appropriate configuration .properties or .yml files from a GIT repo (there are other storage solutions, but GIT is the most common). You can then change configuration at runtime by changing the contents of the GIT repo's configuration files--The Cloud Config Server broadcasts the changes to any Client Spring applications via the Spring Cloud Bus, and those applications' configuration is updated without needing a restart of the app. You can find a working simple example here: https://github.com/ldojo/spring-cloud-config-examples