I followed Apache Sling tutorials using its Launchpad. As I understood, it uses a built in jackrabbit repository within the Launchpad.
Is there a way to access a standalone jackrabbit repository using Sling API without using its launchpad?
Thanks.
The embedded repository is provided by the org.apache.sling.jcr.jackrabbit.server bundle, so if this bundle and the ones that it requires are active you should get the corresponding SlingRepository service, backed by an embedded Jackrabbit repository.
Related
Using "https://devspace.sh/" in Ubuntu, Is it possible to have KNIME, Kafka and python be used for containerizing in dev space? Currently their documentation is about the react, vue and other web based apps only.
Yes. DevSpace works with any language, any framework and any IDE. So, you can definitely work on a python application using the hot reloading feature and then also deploy a Kafka cluster using DevSpace which you are using from the python application.
Check out the Helm deployments section for details on how to deploy Kafka using DevSpace's Helm integration: https://devspace.sh/cli/docs/configuration/deployments/helm-charts
Hi I am new to Apache Camel, but in my application our team implemented this in so many places. Now we are migrating existing came implemented application to Micro services, here we are not finding any option to implement Spring cloud Sleuth with existing camel implemented service, any solution?
There's nothing there out of the box. You would have to create such a tracing implementation yourself.
I am trying to deploy a jax-ws webservice on Websphere 8.5.5.12. I am using CXF as my jax-ws engine. I have gone through the prerequisites and changed the class loader as well as desabled the JaxWs engine in websphere. I have set the property to disable Jax-WS engine in the manifest file of my war file.
My application is a Spring boot application. I am also using apache camel 2.20.1 and using the cxf end point to consume the messages.
As a spring boot application my application is working fine.
When I deploy on Websphere my application starts without any issues. But when it intercepts any incoming requests, it throws class not found exception for javax.servlet.WriteListener class. This class is part of the servlet api. It should have been part of the Websphere j2ee library.
Need to know what I did wrong. I don't want to take the shared library route. I have been suggested, that I need to move all my cxf dependencies, into a shared library and set my class loader for this library. I am not comfortable with this solution.
javax.servlet.WriteListener is a Servlet 3.1 / Java EE7 API.
WebSphere Application Server 8.5.5 implements Servlet 3.0 / Java EE6.
You should use either WebSphere Application Server 9.0.0.x or any recent WebSphere Liberty release (which has been versioned differently for quite some time).
(or, remove the 3.1 dependencies from your app if you must run it on WebSphere Application Server 8.5.5)
We are developing a camel route to be deployed on JBoss Fuse 6.
There are existing camel routes already deployed which are on version 2.10. But my camel application in on version 2.12.4 can both the version of the application reside on same fuse server?
It is not recommended to have two different versions of a project in the same container as you may end up in a dependency mess. That said, you can have two different versions of Camel, just make sure your manifest and osgi import sections uses the correct versions of the libraries.
I started building a web application and made it runnable with an embedded Jetty server. I then decided to try out Apache CXF (which I have never used before) to provide either a SOAP/XML or a REST/JSON interface (haven't decided which yet). Now I am slightly confused by the various posts / docs I have read.
I understand that CXF actually provides (using Jetty internally) its own endpoints that can be published. Is that correct? But it looks like it can also be bundled and deployed into existing web containers (eg Tomcat, and therefore I assume also Jetty) - is this also correct?
If both of these are correct, what are the pros / cons / gotchas of using the CXF Jetty endpoints out-of-the-box as opposed to using a separate container (especially if the separate container is also embedded Jetty)?
It really depends on your application and deployment strategy. Jetty is a lightweight, embedded application server that you can use to run your own web-server. If you choose Apache Tomcat or JBoss or any other application server your application will be likely packaged as a WAR and deployed. The difference is , in Jetty your application controls the container whereas with others its the other way around. Regardless of the choice of application server , CXF endpoints are designed to work with any container supporting JAX-RS or JAX-WS specifications.
Note: You don't need Jetty if you are going to deploy it on Tomcat or other containers.