I have a PHP application that I want to also publish with a different look and feel. We've chosen to do that using XSLT. That way we don't have to touch the PHP application and run risk introducing instability in the original. That's important since we're close to production.
I've looked into ways of doing XSLT processing in Apache webserver. And it seems that the only available xslt module hasn't been updated since 2005. I was hoping to use an xslt mod in a filter chain to accomplish what I want. But an unsupported module won't do.
Another option I can think of is to do the XSLT processing using a servletfilter in a java application server. It seems rather roundabout to have an http request arrive at apache webserver, be forwarded to a java application server to be forwarded back to the apache webserver to do the PHP processing, and the reverse way back for the response...
So my question is: Is there a way to do XSLT processing in apache webserver? Is there another way to do this?
Thank you in advance.
I do not know of a good way to do that in apache. You could do it with PHP using its XSL(T) module, though.
Related
I've seen that Jetty now supports HTTP/2. Spent some time researching and can't see a way of implementing this in Apache Camel-Jetty. Any idea whether this is something that Camel will need to implement? Or is it configurable using their RestConfigurationDefinition?
Thanks in advance.
I'm afraid you need to do some extra work to enable the HTTP/2 feature. Camel-Jetty Components has two parts, one is Consumer (Jetty Server) and the other is Producer (Jetty Client). If you want to enable the HTTP/2 feature, you need to make sure the Http module is loaded by modifying some code. I don't think you can do it by doing some configuration with the RestConfigurationDefinition.
Please send a feature request by creating a JIRA for it.
I am currently learning Camel, and have a specific project in mind that requires a Websphere MQ back-end, but I can't use JMS components, since I need a lot of non-jms headers, like MQIIH.
I found the camel-wmq project.
Is it the recommended solution ? Is it any good ?
You don't need to use jms. WMQ has a client API. Just download the wmq client jars and put them in your project and use them together with your Camel routes. You will probably put the wmq client code in a processor class or something similar. Off course best to test to put a message on a queue manually via RFHUTIL or something similar as a client so you are sure the environment setup is correct.
The suggested way of working with WMQ has always been through the JMS component since it enables you to painlessly switch to other providers if the need arises.
However, if you need to use some WMQ-specific function then my suggestion would be to extend the camel-wmq library - it contains only a subset of features supported by WMQ and does not support MQIIH headers that you need. Adding functionality to a component would probably involve more work than the solution Souciance Eqdam Rashti suggested but it would be a cleaner solution and more in line with Camel's philosophy. Also, you'd be giving back to the community and thus help make Camel a better tool for everyone :)
I would also suggest you go through the IBM MQ discussions on the Camel's official user group mailing list and see if you can salvage anything.
I've got client server application, with JBossAS7 and client which uses remote EJB provided by the server. I have to pass file from client to server, where it will be further processed via InputStream. Also have to pass file from server to client, where on server i get OutputStream. File size is not limited, it might be even 5GB. What can I do to implement solution to this case? Passing byte[] array seems not to be a good solution, RMI limits size what I've read. RMIIO is GPL (i need solution free for commercial use). Is http transfer the only reasonable way to do this?
edit: it seems that RMIIO was always LGPL!
You might consider setting up a Netty Server running on JBoss AS as showed in this Netty Tutorial and pass data using bare sockets.
Another option is HTTP by means of a simple HTTP Transfer using a Servlet for example.
I'd exclude EJB since they are transactional component, and admitted you managed to pass this data through RMI-IIOP, you still have to set up a huge Transactional timeout.
Hope it helps.
RMIIO is LGPL (different from just GPL), which is free for commercial use and is not viral (assuming you have not modified the rmiio library).
I would like my web app to log using SLF4j and logback. However, I am using ActiveMQ - which then requires that some if its jars go in /usr/share/tomcat6/lib (this is because the queues are defined outside of the web app so the classes to support them must be at container level).
ActiveMQ 5.5+ requires SLF4j-api so that jar has to go in to. Because SLF4j is now starting it needs to have a logging library added or it will simply nop. Thus, logback-core and logback-classic go in too.
After quite some frustration I got this working well enough that I can tidy it up shortly. I needed to configure logback to use a JNDI lookup to get the context. Then it can lookup logback-kenobi.xml in my web app and have a separate configuration there.
However, I'm wondering if this is the best way to do this. For one, the context handling appears not to support the groovy format. I did have a logback.groovy in my web app that logged to console when I was developing locally (which means that Eclipse WTP works nicely) but logs to file and to Splunk Storm when everywhere else. I'm going to want to do something similar with this setup but I'm not sure if I should do that by overwriting the logback-kenobi.xml or some other method.
Note that I don't, currently, need Tomcat itself to log with slf4j although I am planning to do that. Nor do I really need ActiveMQ to log with slf4j but I did need it to stop spewing debug messages every 30s as it was doing. I am aware of tomcat-slf4j-logbak but I don't believe it is directly useful as it is ActiveMQ requiring logging which is the issue.
However, I'm wondering if this is the best way to do this.
Best is an opinion, working is a fact.
We have a library with very complex logic implemented in C. It has a command line interface with not too complex string-based arguments. In order to access this, we would like to wrap the library so that it can be accessed with simple XML RPC or even straightforward HTTP POST calls.
Having some experience with Java, my first idea would be
Wrap the library in JNI/JNA
Use a thin WS stack and a servlet engine
Proxy requests through Apache to the servlet engine
I believe there should already be something simple that could be used, so I am posting this question here. A solution has the following requirements
It should be deployable to a current linux distribution, preferrably already available via package management
It should integrate with a standard web server (as in my example Apache)
Small changes to the library's interface should be manageable
End-to-end (HTTP-WS-library-WS-HTTP) the solution should not incur too much overhead, but reliability is very important
Alternatively to the JNI/JNA proposal, I think in the C# world it should not be too difficult to write a web service and call this unmanaged code module, but I hope someone can give me some pointers that are feasible in regards to the requirements.
If you're going with web services, perhaps Soaplab would be useful. It's basically a tool to wrap existing command line applications in SOAP web services. The web services it generates look a bit weird but it is quite a popular way to make something like this work.
Creating an apache module is quite easy and since your familiar with xmlrpc you should check out mod-xmlrpc2. You can easily add your C code to this apache module and have a running xmlrpc server in minutes
I think you may also publish it as a SOAP based web service. gSoap can be used to provide the service interface out of the library. Have you explored gSOAP? See http://www.cs.fsu.edu/~engelen/soap.html
Regards,
Kangkan
Depends what technology you're comfortable with, what you already have installed and working on your servers, and what your load requirements are.
How about raw CGI? Assuming the C code is stateless between requests, you can do this without modifying the library at all. Write a simple script which pulls the request parameters out of the CGI environment, perhaps sanitises the input, calls the library via the command-line interface, and packages the result into whatever HTTP response you want. Then configure Apache to dispatch the relevant URL(s) to this script. Python, for example, has library support for XML-RPC, and so does every other scripting language used on the web.
Servlets sound like overkill, but for instance if you want multiple requests per CGI process instantiation, and don't feel like getting involved in Apache configuration, then it might be easiest to stick with what you know.
I'm doing a similar thing with C++ at the moment. In my case, I'm writing a PHP module to allow PHP scripts to access the logic in my C++ library.
I can then use whatever format I want to allow the rest of the world to see it - initially it will just be through a PHP web application but I'll also be developing an XML-RPC interface.
If you're going down the JNI route, check out SWIG.
http://www.swig.org/Doc1.3/Java.html
Assuming you have headers to project bindings with, swig is pretty easy to work with.