As far as I got into Apache Camel, I understood that an Endpoint can be created using an URI.
from("jms:queue:myqueue").to("seda:myseda");
While I understand this pattern, I'm asking myself and you, is there a way to build those URIs using type-safe (or just safe) Java objects?
The usecase is obviously inside a custom RouteBuilder.
I know an Endpoint can also be retrieved using the endpoint method inherited from BuilderSupport
final SedaEndpoint seda = endpoint("seda:myseda", SedaEndpoint.class)
But that's just like writing the pure String.
Are there other ways to build Endpoints?
ParameterConfiguration or ComponentConfiguration classes/interfaces are deprecated, but without pointing to an alternative or saying there is none.
You can build those endpoints via plain Java with the new constructor, and then call the setter/getters. Its a bit cumbersome to do, and the vast majority of the Camel users use the URI style.
We have on the roadmap for Camel 3 to generate type-safe fluent builder for all the endpoints, for all the out of the box components, and provide this as a maven tooling plugin so 3rd party component developers can do this as well.
Related
I have to applications running on a single Wildfly container using single database. Currently they are communicated with each other using JAX-RS and I wonder is there more faster way?
What I have already found:
JAX-RS
Local EJB
Remote EJB
JMS
Seems that the most fastest way is to use Local EJB. But I am not sure about JMS. And what about Websockets?
Ok, one could complain about the question being too broad formulated but providing one possible answer would also be nice ;)
So here is my suggestion:
Simply create a clean API for the communication between the modules and deploy it as a JAR to your server. The module that contains the JAX-RS endpoint could also implement the API to provide the services you need (not only for internal usage but also for your REST service which then would simply delegate the request processing). Now you can simply inject a service using CDI when you need it for internal usage and as far as I know this is the fastest possible way to go for internal communication since it works directly with JAVA objects. Using CDI for the injection of the service implementation has also the benefit of decoupling the modules.
I hope this helps ;)
Have you looked at memory-mapped files? They can offer some very high throughput. Check out the NIO FileChannel class. For a ready-to-run solution, take a look at Jocket.
I have a Java EE based REST api application. It has a layered architecture like the following:
Resources (Jax-rs resources)
Object Validation
Object Mapper
Service Layer
Repository Layer
JPA Entities
Everything is wired using Spring dependency injection.
I need to design this core application in such a way that it allows other external developers to write extensions/plugins and override or extends any minor or major functionality in the core. Think of it like Wordpress CMS in Java EE if that helps. How would you design a plugin system around the current architecture?
One obvious way that I can think of is override or add new functionality to the proper resource (with validation, objectmapper), service, repository and entity and create a jar + xml out of it. But I want to make sure that the plugin developer has to write the absolutely minimum amount of code to get the new functionality working, while reusing mush of the core code.
Assume, you want to create a wordpress blog post extension that lets you create blog posts with few extra fields that don't exist in core yet. What would be the simplest and cleanest way to go about designing the current Java EE app, so its easy for the plugin/extension developers? Any patterns that could be useful like strategy or template method pattern?
Are there any open source Java CMS that follow the model using Spring/JPA and standard technologies?
I think you mean to extend the functionality, rather than override the core. Typical architecture examples define concerns which can be overridden (separate from core) and make provisions. Eclipse framework achieves this using a combination of plugin-extensions & extension-points mechanism. This is taken further using OSGI bundling.
Another alternative is to breakdown the application into smaller independent modules/services. All you need to do is host these modules over an ESB/Application Integrator (like Mule/Spring Integration) and allow users to configure their version of routing/transformation. Extension would mean creation of new transformers which get added to the message flow.
At work, we currently have a WSDL interface as well as a semi-RESTful interface that we're looking to expand upon and take it to the next level.
The main application runs using Servlets + JSPs as well as Spring.
The idea is that the REST and WSDL are interfaces for an API that will be designed. These (and potentially other things in future) are simply a method through which clients will be able to integrate with the interface.
I'm wondering if there are any suggestions or recommendations on frameworks / methodologies, etc for implementing that under-lying API or does it make sense simply to create some Spring beans which is called either by WSDL or REST?
Hope that makes sense.
Have a look at Eunicate it is great . You are using spring , Spring has had support of SOAP for a while and Spring 3 has support of REST (Creating and Consuming).
Your approach makes sense. Probably the most important advice is to make the external API layer as thin as possible. You can use Axis, Apache CXF, Jersey, etc. to handle the implementation of the REST or SOAP protocols, but the implementation of those services should just load the passed in data into a common request object, and pass that into a separate service that handles the request and returns a response object which the external API layer will marshall into the correct format for you.
This approach works especially well when you have a competitor providing similar services and you want to make it easy for their customers to switch. You just build a new external API that mirrors the competitors, and simply translates their format to your internal api model and provided your services are functionally equivalent, you're done.
This is a really late response, but I have a different view on this topic. The traditional way as we know it is to unmarshall xml to java and marshall java to xml. However if the wsdl changes then it would effectively be a structural change in the code which would again require a deployment.
Instead of the above approach if we list the fields mentioned in the wsdl in a presistent store, load the mappings in memory and prepare our structures based on these mappings we would have to have many less changes for this..Thus IMO instead of using existing libraries a configurable approach to unmarshalling and marshalling should be taken.
I am using netbeans 6.9. I have made a JAX-WS service that returns a complex type, I have also made a JAX-WS client to consume it.
The JAX-WS system automaticly creates a class for the client, inferred from the WSDl spec. I want to make my own class for this using JAXB annotations, so that I can add some extra functions to it.
How do I go about replacing the autogenerated file with my own one? Could I also use the same class in the service to control how it is transmitted?
Thanks!
Why replace the generated class?
From your description, it sounds like a good case for using the Decorator design pattern.
I have done this on a JAX-RPC project, and it worked very well.
What is a good way to render data produced by a Java process in the browser?
I've made extensive use of JSP and the various associated frameworks (JSTL, Struts, Tapestry, etc), as well as more comprehensive frameworks not related to JSP (GWT, OpenLaszlo). None of the solutions have ever been entirely satisfactory - in most cases the framework is too constrained or too complex for my needs, while others would require extensive refactoring of existing code. Additionally, most frameworks seem to have performance problems.
Currently I'm leaning towards the solution of exposing my java data via a simple servlet that returns JSON, and then rendering the data using PHP or Ruby. This has the added benefit of instantly exposing my service as a web service as well, but I'm wondering if I'm reinventing the wheel here.
I personally use Tapestry 5 for creating webpages with Java, but I agree that it can sometimes be a bit overkill. I would look into using JAX-RS (java.net project, jsr311) it is pretty simple to use, it supports marshalling and unmarshalling objects to/from XML out of the box. It is possible to extend it to support JSON via Jettison.
There are two implementations that I have tried:
Jersey - the reference implementation for JAX-RS.
Resteasy - the implementation I prefer, good support for marshalling and unmarshalling a wide-range of formats. Also pretty stable and has more features that Jersey.
Take a look at the following code to get a feeling for what JAX-RS can do for you:
#Path("/")
class TestClass {
#GET
#Path("text")
#Produces("text/plain")
String getText() {
return "String value";
}
}
This tiny class will expose itself at the root of the server (#Path on the class), then expose the getText() method at the URI /text and allow access to it via HTTP GET. The #Produces annotation tells the JAX-RS framework to attempt to turn the result of the method into plain text.
The easiest way to learn about what is possible with JAX-RS is to read the specification.
We're using Stripes. It gives you more structure than straight servlets, but it lets you control your urls through a #UrlBinding annotation. We use it to stream xml and json back to the browser for ajax stuff.
You could easily consume it with another technology if you wanted to go that route, but you may actually enjoy developing with stripes.
Check out Restlet for a good framework for exposing your domain model as REST services (including JSON and trivial XML output).
For rendering your info, maybe you can use GWT on the client side and consume your data services? If GWT doesn't float your boat, then maybe JQuery would?
Perhaps you could generate the data as XML and render it using XSLT?
I'm not sure PHP or Ruby are the answer if Java isn't fast enough for you!