I want to create endpoints that can be local in one setup and remote (via jms) in another.
What is the best approach?
I thought of creating my own component, 'abstract', then send to abstract:foo and in one setup have abstract:foo behave like direct:foo and in another setup behave like jms:queue:foo.
However, I'm not sure this is the cookbook approach and how to implement it exactly (how to do the "in one setup behave like X and in another behave like Y"), without being fragile (relying on different contents of META-INF/services/org/apache/camel/component/abstract in each setup)
So, what is the best approach?
You can use the camel PropertiesComponent for this. This allows to use placeholders in endpoints. See http://camel.apache.org/properties.html
E.g.
from("{{myendpoint}}")...
You can use a properties file in setup A to define "myendpoint=direct:foo" and "myendpoint=jms:queue:foo" in another case.
I found the best approach was to create a bean with my own schema name and have it create the desired endpoint (DirectEndpoint or other) according to properties
Related
I'm rather unexperienced in GWT, and I have large codebase with working project in this technology. My task refers to assigning id's to html elements witch will be used in automatic testing. We can't use some dynamically assigned id's because in automatic test we have to specify exact values of id's. My way for now was to use method ensureDebug(id), written by hand in code for specific elements.
I think that doing it this way mean that code will be more spaghetti-like, with mixed ensureDebug(id) methods usages there and here. I was thinking if there is any way of doing it that will be more manageable and cleaner than current. Is is maybe possible to use AOP? (I have never used AOP, so I don't know if it is any good idea, or possible in GWT) Or maybe other way than using ensureDebug?
You also can set the IDs for HTML elements like
element.setId("myId");
But this is as much spaghetti like as your approach adding the IDs in the code.
Another possibility would be to use an UiBinder and set the id there. With this approach you have all your ui elements of one view, which should have an id, at one place. With bootstrap for example it would look like this:
<b:TextBox ui:field="searchTextBox" b:id="search-text-box"/>
Like this you can access the field in your view-class via searchTextBox and the id search-text-boxis added to the HTML element (which you could also use for styling etc.)
We have faced same issue for our project while adding test automation. As per my knowledge unfortunately GWT doesn't support anything like AOP yet. So we have to follow any of the spaghetti-like approach only from one mentioned above by #mxlse or the one you are already following.
Based on my experience I can recommend you to create separate constant/property at client or server end. Use this file to save all your id's which you can share latter on with test team as well.
I know by default JAX-RS endpoints lifecycle is once-per-request, so that the request specific informations can be injected into the instance.
And we can also make an endpoints Singleton meaning once-per-application, in which the request specific informations cannot be injected into the instance rather it can be injected into the requested method.
1. So i would like to know which approach is better in terms of performance, either once-per-request or once-per-application.
2. I would also like to know the pros and cons of these approaches other the injecting request specific informations
3. Which approach you prefer to use in your API applications
Note: i have been using the once-per-request approach so far, but i always wonder is that is efficient, definitely its make coding easier and reusable.
To start with your last question: I'm always using the default (per-request) and I seldom came to a point where I wanted to change this.
What might be a reason to prefer one over the other?
If you want to serve some static content (maybe a welcome-document of your API) it makes sense to produce this content only once and hold it in a singleton resource class. But you can achieve the same by e.g. injecting an #ApplicationScoped CDI bean in a per-request scoped resource class.
If you prefer injecting the #xxxParam values like #QueryParam as fields instead of method parameters you should use the per-request lifecycle. This is not supported for singletons. (This does not include injecting via #Context).
I made a little test to compare the performance of both. You can find the sources and the results on github. In short: I measured a difference from about 1.5 %. I don't think this should affect your application too much.
Comparing the results of the JVisualVM monitoring I would tend to say that the per-request test is using more memory but you should decide on your own if this really affects your application.
I have the following requirement: before each method, I need to perform some set-ups, and, after each method, I need to perform some clean-ups. For example, after each method is executed, I need to dump logs in SQL Server.
How can I create custom annotations for this type of repetitive tasks?
Please note that, due to certain design considerations, I cannot accommodate JUnit in my application.
It sounds like you are trying to recreate spring aspects, see this:
http://docs.spring.io/spring/docs/2.0.x/reference/aop.html
However, you may feel like adding a dependency on spring is too large an undertaking, you could consider just depending on aspectj:
http://www.eclipse.org/aspectj/
As a last alternative, you could make your class implement an interface, and then write a "wrapper" implementation of that interface, that merely wraps another implementation and does before/after logic. That is by far the simplest way to do this, and I do that all the time.
One last alternative is to use a duck typed proxy:
http://docs.oracle.com/javase/6/docs/api/java/lang/reflect/Proxy.html
However, I don't recommend doing that.
On a side note, I have never heard of a project that can't accomodate junit or some kind of testing framework. If you are not planning to write unit tests, you're going to have an exponentially tough time writing large applications.
I am search the web without luck about something I thought would be simple but apparently it is not.
All I want to do is to do, is create a HashSet in a method that is called in a camel route and then pass this HashSet to a method in another camel route.
What my search returned is that I should use a cache but I can't find any example (a simple one) that will show me how implement this.
Method "findProperties" in first route creates a HashSet which I want to use in the second route in "parseFile" method.
from("file:{{List}}?noop=true")
.autoStartup(true)
.unmarshal().csv()
.to("bean:ParserUtils?method=findProperties")
.end();
from("file:{{Path}}?move={{processedPath}}")
.autoStartup(true)
.unmarshal().csv()
.to("bean:Parser?method=parseFile")
.end()
I would really appreciate a simple example of getting and setting an object in cache or another solution maybe.
since your first route doesn't invoke your second route, there is no messaging between them to pass data around...so yes, you need to use some external means to access data that is shared between routes/threads...
this can be as simple as a class/static level variable in your ParserUtils instance or using camel-cache (ehcache, etc), camel-hazelcast, etc...the choice is yours
here are some examples using camel-cache...
https://svn.apache.org/repos/asf/camel/trunk/components/camel-cache/src/test/java/org/apache/camel/component/cache/CacheProducerTest.java
I am writing some helper code to add builders to my domain model using the Builder Pattern. I have the basic portion of the code built, but I want to added another build method that will validate the newly built object. I envision this new method would accept a class to match up with the groups in my bean validation. Therefore, when I get the object back from the builder I know it is a valid object for the state I want. I have two questions concerning this approach.
First, does this sound like a good approach? I have not seen anything on the net about doing this, but I think it would be a good idea to have it in the builder.
Next question, What is a good way to get a validator into the builder? Should I try to auotwire it in or something else?
Using the builder pattern is a nice way to construct objects, so it should work well for your purposes. You said you want to add another build method. Is this implying that you would have 2 build methods - one that validates and one that doesn't? I would only have one method so you can be sure your object validates.
For how to validate, the Spring docs discuss validating using JSR-303 http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/validation.html
Just something to keep in mind as you're building a Spring app. Consider if grails might be something of interest to you. One part of it is domain object validation and it has capabilities to build objects for testing that will validate. Obviously you would want to use more features than just that if you're going to use grails, but just wanted to note it.