I am working on Spring based standalone application , Once xml message enter into system .We are doing some technical validations using java code using exceptions and regular expressions.Now i am trying to plugin one more feature ,based on some flag in the database we need few more validations on incoming xml message, but all existing clients dont require. I know there is a concept fork/join in java 7.But i am limited upto java 1.6. So how can i implement similar feature using java 1.6.
Below is the approach .
main class -handler thread--> calls action class --->every action class extends abstract action class-->performs technical validations using xml file.
public class AbstractAction {
public abstract void processMsg(String msg);
}
public Class GenericAction extends AbstractAction {
public void processMsg(String str){
// existing code already doing validations
//now i have to check flag in table ,whether that client requires new validations,these validations are in xml file in the form of spring beans.
//Java code read that bean validate using some helper classes.There is no third party code here,Here i want to put some new code.So i have to break down existing into
//some small piceses
}
}
Regards,
chaitu hara
Related
I am currently have a spring service consuming an REST service via autogenerated code.
I placed an internal interface to have an abstraction from the REST interface since it is still in development.
The REST service is in fact two on the same host.
So I generate two times code having two components I can inject into my internal interface implementation.
In the interface implementation I do adapt the base paths of the REST client components via #PostConstruct since the URL is dependent on the deployment environment.
This works so far so good. Even though I believe it would be better to adapt the base path not in the internal interface implementation but instead in another place.
Thankful for any hints here.
The Problem
Now the tricky part.
The REST Services I consume exists multiple times with different data in the environment.
Some times there are two, some times three and so on.
The user of our website should be able to select which backend he wants to consume.
The information about which service backends are available should be configurable for the environment.
To be able to configure these environment dependent I would thought about adding a map in the properties like:
service-name: url
second-name: url
and so on.
This map would contain a default with the always existing service.
Via environment variables it can be overwritten to list more backend services.
So, now I want to be able to route the website request to the chosen backend service.
My idea is, that I would need some kind of service.
The service holds the internal interfaces with the different backend instances and can identify which to use based on the name.
The question is now, how to build this with Spring?
More specifically:
How do I construct multiple time my InternalRestClient with different dependencies?
How can I tell them apart/Identify and use them?
Thank you very much for your suggestions in advance.
Code Examples
The internal Rest Interface
public interface InternalRestClient {
String someAbstractMethodUsingBothServices(String someDate);
}
The Implementation
#Service
public class InternalRestClientImpl implements InternalRestClient{
#Value("${url}")
private String url;
private FirstRestService firstService;
private SecondRestService secondService;
public InternalRestClientImpl(FirstRestService firstService, SecondRestService secondService) {
this.firstService = firstService;
this.secondService = secondService;
}
#PostConstruct
void correctPaths() {
firstService.setBasePath(url);
secondService.setBasePath(url);
}
#Override
public String someAbstractMethodUsingBothServices(String someDate) {
return null;
}
}
The autogenerated openapi components
#Component
public class FirstRestService {
private String basePath;
public void setBasePath(String basePath) {
this.basePath = basePath;
}
// some methods
}
#Component
public class SecondRestService {
private String basePath;
public void setBasePath(String basePath) {
this.basePath = basePath;
}
// some other methods
}
i have a little kont in my brain about structuring our code. We have a REST Backend based on SpringBoot. To handle requests regarding to security checks we use HandlerInterceptors. In some specific cases we need a specific interceptor and not our default one. The default one is registered in a 3rd party lib that no one can forget it. But i want all coders to think about this specific interceptor.
Actually, i just said it to them to achieve this.
Here's my question: Is there an option to create required (or necessary) interfaces which must be implemented? This would be a way to provide our security code by lib and to have the security that every coder implemented our specific interface (also if he just does nothing with it).
pseudo code:
public interface thinkForIt(){
Object SecBean specificSecBean;
public void methodToThinkOn();
}
public SecImpl implements thinkForIt(){
#Override
public void methodToThinkOn(){
return null; // i thought about it but i do not need to do anyting!
}
If the interface thinkForIt would have any annotations like #required, users could get warning or error if they did not implement it...
Looking for a solution and thanks for your comments in advance!
Your overall design is questionable; you are reinventing security code, which is always a red flag. Use Spring Security instead.
However, there's a simple way to ensure that "some bean of type Foo" has been registered with the context:
#Component
#RequiredArgsConstructor
public class ContextConfigurationVerifier {
final Foo required;
}
I am reading a code of GWT
Basically in this project they are getting some constant value like button text from a properties file.
so they have an interface LocalizableResource and getting the instance like
public interface LocalizableResource extends Constants {
public static class Util {
public static LocalizableResource getInstance() {
return GWT.create(LocalizableResource.class);
}
}
String lblName_text_1();
}
and use this instance to get a button text
String buttonText = LocalizableResource.Util.getInstance().lblName_text_1();
Button b = new Button(buttonText);
in java we can not Instantiates an interface then,
How GWT doing this such like. I have not so much Idea about deferred binding and GWT.
That's the beauty of GWT and one of its way to manage multiple clients which is the core advantages of GWT framework.
http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsDeferred.html
Deferred binding is a feature of the GWT compiler that works by generating many versions of code at compile time, only one of which needs to be loaded by a particular client during bootstrapping at runtime. Each version is generated on a per browser basis, along with any other axis that your application defines or uses. For example, if you were to internationalize your application using GWT’s Internationalization module, the GWT compiler would generate various versions of your application per browser environment, such as “Firefox in English”, “Firefox in French”, “Internet Explorer in English”, etc… As a result, the deployed JavaScript code is compact and quicker to download than hand coded JavaScript, containing only the code and resources it needs for a particular browser environment.
A tag interface that facilitates locale-sensitive, compile-time
binding of constant values supplied from properties files. Using
GWT.create(class) to "instantiate" an interface that extends Constants
returns an instance of an automatically generated subclass that is
implemented using values from a property file selected based on
locale. more info
So I'm writing a web service architecture which includes FunctionProvider classes which do the actual processing of requests, and a main Endpoint class which receives and delegates requests to the proper FunctionProvider.
I don't know exactly the FunctionProviders available at runtime, so I need to be able to 'register' (if that's the right word) them with my main Endpoint class, and query them to see if they match an incoming request.
public class MyFunc implements FunctionProvider{
static {
MyEndpoint.register(MyFunc);
}
public Boolean matchesRequest(Request req){...}
public void processRequest(Request req){...}
}
public class MyEndpoint{
private static ArrayList<FunctionProvider> functions = new ArrayList<FunctionProvider>();
public void register(Class clz){
functions.add(clz);
}
public void doPost(Request request){
//find the FunctionProvider in functions
//matching the request
}
}
I've really not done much reflective Java like this (and the above is likely wrong, but hopefully demonstrates my intentions).
What's the nicest way to implement this without getting hacky?
Do not let the FunctionProviders self register. Bootstrap the endpoint through some application init. call with a list of FunctionProviders. That way you can configure priority (what if two providers both claim they can process a request?). The way you set it up now you need to invoke the class somehow to trigger the static constructor, too indirect.
If detecting whether or not a FunctionProvider supports a given request is trivial consider making it part of configuration. If this is in the request map it to that FunctionProvider. This would seperate concerns a bit better. If the detection is complicated consider doing it in seperate classes from the FunctionProvider.
By configuring a delegate/function pointer you can possibly prevent from needing a FunctionProvider altogether (not sure if/how Java supports delegates).
Should a bean dto always have an associated interface ?
Below dto is used by jackson to send json over the wire :
public class Bean {
private String date;
public Bean(String date)
{
this.link = date;
}
public String getDate() {
return date;
}
}
Should this class always implement an interface to match its structure ?
I wouldn't unless you're using an API or Framework that requires an interface or are writing an API yourself.
Older versions of J2EE (before it became Java EE) required interfaces for enterprise beans, and some other frameworks use an interface to generate a proxy; however that has mostly been replaced by the runtime generation of synthetic proxies. If you start with a well defined class, you can later add an interface you discover a need for one.
Currently one of my tasks is maintaining an existing web application. Essentially everything in it has the Interface + Class pattern, but for no real reason as its all self contained. The extra files for the interfaces just clutter up the workspace and make tracking down the source of the actual code take a couple seconds longer in each case (can't just highlight and press F3 in Eclipse).