I'm using Spring and Velocity templates to send emails. The new request is that the templates are no longer stored locally, but fetched from an external service. VelocityEngineUtils expects a relative path to the template, but all I now have is an URL. While I'm aware that I can fetch and save the template locally before calling VelocityEngineUtils, I'm asking if there already is something in Spring that can help (as it often happens).
what velocity resourceloader you are using at the moment? I assume that you are using ClasspathResourceLoader?
If you need to get velocity template from an external service through a URL, you can specify the resource loader to org.apache.velocity.runtime.resource.loader.URLResourceLoader
Related
This may be a bit of a rudimentary question, but I have a repository where I can do a find by username as follows:
....../items/search/byUsername/?username=myusername
However, this is generally inconsistent with how AngularJS Resources treat queries. Is there a way to instead make the request URI for the same thing to be
....../items/?username=myusername
Or does that functionality not exist with spring data rest? custom methods can be made in the angular resource but it is tedious to do that for every possible search category
If Angular (read: a client library) defines what URI's have to look like, then it's fundamentally violating a core REST principle — which is that clients follow links and URI templates.
That said, if you're using Querydsl and let your repository extend QuerydslPredicateExecutor, collection resources can be filtered by using property expressions. See the reference documentation for details.
Another option would be to manually expose resources under the URIs expected and manually forward the calls. But again, I'd argue you're better off teaching Angular to behave like a proper REST client in the first place 🙃.
I'm currently developing a Java backend together with JHipster 3 and ran into a problem I don't seem to be able to solve very easily.
I would like to serve static assets – in this case images – from a folder outside of the project in addition to the default front-end generated by JHipster. As of default JHipster seems to serve static assets from one directory out of two depending on environment, as configured in main/java/config/WebConfigurer.java. I would like to point /public/** to a folder in my home catalogue but keep the /** mapping for the Angular front-end.
In general Spring projects you seem to be able to add other sources for static assets by extending WebMvcConfigurerAdapter and override the addResourceHandlers method, but that doesn't seem to have an effect in my case. Adding the #EnableWebMvc annotation breaks the default JHipster mapping for their front-end. If I don't add the annotation I don't even seem to reach handleRequest() in DefaultServletHttpRequestHandler which handles the mapping to the correct servlet.
I can't give any other information on the subject at the moment, but I'm hoping someone with knowledge on JHipster will see this and point me in the right direction.
Thanks in advance, Max.
All app servers have an option to provide additional locations for class path.
For example, Tomcat's property is 'common.loader' in conf/catalina.properties.
You can then use e.g. Spring's ClassPathResource to load a resource manually, or just use a construct like '#Value("classpath:abc.txt") Resource r' to inject something known in advance.
I have some url that I need to read data from there and use it in my controller.
Usually in java application I use http client, to get data from some url.
My questions are:
What object to use in spring mvc to get data from some url (like http client) ?
How to reuse this objects, so every time not to create it ?
Thank you!
In agreement with the comment by #Evgeny and #Beau above, you can use any client library you like. HttpClient is VERY bean friendly and, for cases where it might be difficult to construct the configuration, you can always provide a Spring factory bean to construct the object.
If you are looking to abstract away the plumbing of the HttpClient API usage, utilize the RestTemplate suggested by #Evgeny (I believe that it is also his brainchild) It is a VERY rich and simple API to leverage.
We have a web application that uses spring, struts and camel right now and there is a lot of customization we have done to allow us to know when beans are added to the context.
So, we have gotten to a point where we would like to remove struts from the application, because we are only using it to handle actions and we figure we could either use spring or camel to do the same thing. So I was able to get it to work with camel/velocity, but we didn't like how we really couldn't use the request object directly in the jsp (afaik, you have to put everything in the header of the Exchange and in the jsp you would do ${header.someReqVariableName}).
So we wanted to go the spring route, but since we load the context.xml directly, we have a provider that extends ContextSingletonBeanFactoryLocator and we pass the xml file name as a param, we haven't been able to figure out how to get the DispatcherServlet to work without giving it another configuration xml.
Is there a way to either:
Have camel use jsp for processing a jsp (and have all the usage of jsp tags)?
or
Have spring to see that a context has already been loaded and use that instead of having another new one?
or
Something better I have thought up?
You can use camel-jetty to expose HTTP endpoints, but I wouldn't use it for any complex web app development (JPS, etc). I'd use use Spring MVC (or similar) and use Camel for any complex routing/messaging requirements...
Here is another way, you can use the producer template to send the request to the camel context if you can get the reference of the camel context from the spring.
I got following scenario. A web part needs certain configuration parameters (primitive data types) like e.g. an URL (string) to retrieve and show data from an external system. As each instance of the web part within a web application should retrieve the data from the same system, the parameters are stored in the SPPropertyBag of the web application so the web part knows where to look for it. The parameters are put to the property bag via an application page in the CA.
At the moment the web part uses a configuration object which implements the singleton pattern to access the configuration parameters stored in the property bag. The disadvantage is that the web part won't recognize a change of the configuration parameters until the application pool is reseted and the singleton object is newly created with the updated parameters.
Now I'm looking for a way to optimize this mechanism in such a way that the singleton object is able to recognized configuration changes and reread the parameters without killing the application pool.
I thought about some kind of caching mechanism which somehow informs the singleton object that the parameters have changed. I've read some articles about cache dependencies which might be a way to go but I'm not sure how to use them with SPPropertyBag objects.
So I'm wondering how you would handle this?