Using Apache Camel Simple in custom Camel Components - apache-camel

I am creating my own custom component for doing various operations. I would like to know what is the best approach to be able to evaluate Simple in my uri, exactly in the remaining and the options. That way I can provide more flexibility. I have already taken a look to http://camel.apache.org/expression.html but I am not really sure how to integrate the evaluation into my java code.
Thanks in advance!

You can see how the file component uses simple/file language for the fileName option.
See the source code of these methods/classes
org.apache.camel.component.file.GenericFileEndpoint#setFileName
org.apache.camel.component.file.GenericFileConsumer#evaluateFileExpression

Related

Purpose of redux-cli

currently looking through a boilerplate called react-redux-start-kit by Dave Zuko, and there is a folder called blueprints. Apparently it is for a library called redux-cli, and having no clue what that is I did some research. (Link to redux-cli)
The problem is, the documentation for redux-cli didn't really say what it is. I have also read that redux-cli makes it faster to build apps. Could someone please explain to me what redux-cli is, and how it works?
redux-cli is a utility that speeds up development by reducing work required to create basic elements of your app, e.g. components. Usually, when you create such component, you have to create file for a component, test suite and they all start with a certain structure that you usually copy / paste from other, existing components. With redux-cli you just use simplified commands in your console to auto-generate those basic versions of a new component and you can just jump in and start writing the essence of it.
blueprints are simply templates, redux-cli uses when running commands (for example when running command to create new component it will look at blueprints directory first and see if you have customized template for how you want your components to be initialized). Documentation is pretty clear I'd say - https://github.com/SpencerCDixon/redux-cli#creating-blueprints

Create custom Consumer & Producer for an existing Component

I would like to extend the functionalities of an existing camel consumer/producer, and have the same camel component using the my implementation instead of the original consumer/producer.
Can this be done? If yes, how? Appreciate your guidance.
Its just java code, so you can extend the classes and override the methods you want. And if really needed the source code is open so you can copy the old code if you need in your component.
But you may ask yourself why do you need to do this. Its much better to use the standard components as-is.
If you need a new feature then talk to the Apache Camel community about that, and see what can be added to the standard.
http://camel.apache.org/support.html

Custom Request Handlers/Components with Solr-4.x

I was referring this http://sujitpal.blogspot.in/2011/02/solr-custom-search-requesthandler.html for making custom handlers in solr. They are pretty nice but conform to the old apis. Is there any similar example I can refer to for solr-4.3.0.
Your best bet is to download the Solr source and check the existing implementations Of RequestHandlers. There are some that are quiet simplistic and can give you a good grasp of the API and a starting point.PingRequestHandler comes first to mind, if your goal is to do something very simple. For more complex scenarios look for the ones that make use of components and take a look in solr config for their initialization parameters.
Best of luck!

Apache module FORM handling in C

I'm implementing an Apache 2.0.x module in C, to interface with an existing product we have. I need to handle FORM data, most likely using POST but I want to handle the GET case as well.
Nick Kew's Apache Modules book has a section on handling form data. It provides code examples for POST and GET, which return an apr_hash_t of the key+value pairs in the form. parse_form_from_POST marshalls the bucket brigade and flattens it into a buffer, while parse_form_from_GET can simply reference the URL. Both routines rely on a parse_form_from_string routine to walk through each delimited field and extract the information into the hash table.
That would be fine, but it seems like there should be an easier way to do this than adding a couple hundred lines of code to my module. Is there an existing module or routines within apache, apr, or apr-util to extract the field names and associated data from a GET or POST FORM into a structure which C code can more easily access? I cannot find anything relevant, but this seems like a common need for which there should be a solution.
I switched to G-WAN which offers a transparent ANSI C scripts interface for GET and POST forms (and many other goodies like charts, GIF I/O, etc.).
A couple of AJAX examples are available at the GWAN developer page
Hope it helps!
While, on it's surface, this may seem common, cgi-style content handlers in C on apache are pretty rare. Most people just use CGI, FastCGI, or the myriad of frameworks such as mod_perl.
Most of the C apache modules that I've written are targeted at modifying the particular behavior of the web server in specific, targeted ways that are applicable to every request.
If it's at all possible to write your handler outside of an apache module, I would encourage you to pursue that strategy.
I have not yet tried any solution, since I found this SO question as a result of my own frustration with the example in the "Apache Modules" book as well. But here's what I've found, so far. I will update this answer when I have researched more.
Luckily it looks like this is now a solved problem in Apache 2.4 using the ap_parse_form_data funciton.
No idea how well this works compared to your example, but here is a much more concise read_post function.
It is also possible that mod_form could be of value.

What is a DSL and where should I use it?

I'm hearing more and more about domain specific languages being thrown about and how they change the way you treat business logic, and I've seen Ayende's blog posts and things, but I've never really gotten exactly why I would take my business logic away from the methods and situations I'm using in my provider.
If you've got some background using these things, any chance you could put it in real laymans terms:
What exactly building DSLs means?
What languages are you using?
Where using a DSL makes sense?
What is the benefit of using DSLs?
DSL's are good in situations where you need to give some aspect of the system's control over to someone else. I've used them in Rules Engines, where you create a simple language that is easier for less-technical folks to use to express themselves- particularly in workflows.
In other words, instead of making them learn java:
DocumentDAO myDocumentDAO = ServiceLocator.getDocumentDAO();
for (int id : documentIDS) {
Document myDoc = MyDocumentDAO.loadDoc(id);
if (myDoc.getDocumentStatus().equals(DocumentStatus.UNREAD)) {
ReminderService.sendUnreadReminder(myDoc)
}
I can write a DSL that lets me say:
for (document : documents) {
if (document is unread) {
document.sendReminder
}
There are other situations, but basically, anywhere you might want to use a macro language, script a workflow, or allow after-market customization- these are all candidates for DSL's.
DSL stands for Domain Specific Language i.e. language designed specifically for solving problems in given area.
For example, Markdown (markup language used to edit posts on SO) can be considered as a DSL.
Personally I find a place for DSL almost in every large project I'm working on. Most often I need some kind of SQL-like query language. Another common usage is rule-based systems, you need some kind of language to specify rules\conditions.
DSL makes sense in context where it's difficult to describe\solve problem by traditional means.
If you use Microsoft Visual Studio, you are already using multiple DSLs -- the design surface for web forms, winforms, etc. is a DSL. The Class Designer is another example.
A DSL is just a set of tools that (at least in theory) make development in a specific "domain" (i.e. visual layout) easier, more intuitive, and more productive.
As far as building a DSL, some of the stuff people like Ayende have written about is related to "text parsing" dsls, letting developers (or end users) enter "natural text" into an application, which parses the text and generates some sort of code or output based on it.
You could use any language to build your own DSL. Microsoft Visual Studio has a lot of extensibility points, and the patterns & practices "Guidance Automation Toolkit" and Visual Studio SDK can assist you in adding DSL functionality to Visual Studio.
DSL are basic compilers for custom languages. A good 'free and open' tool to develop them is available at ANTLR. Recently, I've been looking at this DSL for a state machine language use on a new project . I agree with Tim Howland above, that they can be a good way to let someone else customize your application.
FYI, a book on DSLs is in the pipeline as part of Martin Fowler's signature series.
If its of the same standard as the other books in the series, it should be a good read.
More information here
DSL is just a fancy name and can mean different things:
Rails (the Ruby thing) is sometimes called a DSL because it adds special methods (and overwrites some built-in ones too) for talking about web applications
ANT, Makefile syntax etc. are also DSLs, but have their own syntax. This is what I would call a DSL.
One important aspect of this hype: It does make sense to think of your application in terms of a language. What do you want to talk about in your app? These should then be your classes and methods:
Define a "language" (either a real syntax as proposed by others on this page or a class hierarchy for your favorite language) that is capable of expressing your problem.
Solve your problem in terms of that language.
DSL is basically creating your own small sublanguage to solve a specific domain problem. This is solved using method chaining. Languages where dots and parentheses are optional help make these expression seem more natural. It can also be similar to a builder pattern.
DSL aren't languages themselves, but rather a pattern that you apply to your API to make the calls be more self explanatory.
One example is Guice, Guice Users Guide http://docs.google.com/View?docid=dd2fhx4z_5df5hw8 has some description further down of how interfaces are bound to implementations, and in what contexts.
Another common example is for query languages. For example:
NewsDAO.writtenBy("someUser").before("someDate").updateStatus("Deleted")
In the implementation, imagine each method returning either a new Query object, or just this updating itself internally. At any point you can terminate the chain by using for example rows() to get all the rows, or updateSomeField as I have done above here. Both will return a result object.
I would recommend taking a look at the Guice example above as well, as each call there returns a new type with new options on them. A good IDE will allow you to complete, making it clear which options you have at each point.
Edit: seems many consider DSLs as new, simple, single purpose languages with their own parsers. I always associate DSL as using method chaining as a convention to express operations.

Resources