Trying the Fuse Karaf quickstarts "rest-dsl-simple" build and install in Fuse appears successful, however the tests do not. The both just say site cannot be reached.
Looking in Fuse.log I see...
2021-03-28 08:34:34,680 | INFO | FelixStartLevel | o.a.k.s.i.a.o.CommandExtension | 152 - org.apache.karaf.shell.core - 4.2.9.fuse-780023-redhat-00001 | Command registration delayed for bundle org.apache.karaf.http.core/4.2.9.fuse-780023-redhat-00001. Missing service: [org.apache.karaf.http.core.ServletService, org.apache.karaf.http.core.ProxyService]
Then later I see my bundle set to failure...
2021-03-28 08:34:43,066 | ERROR | Event Dispatcher: 1 | o.a.c.b.BlueprintCamelContext | 62 - org.apache.camel.camel-blueprint - 2.23.2.fuse-780036-redhat-00001 | Error occurred during starting CamelContext: fusequickstart-restdsl-simple-camel
org.apache.camel.FailedToCreateRouteException: Failed to create route route3: Route(route3)[[From[rest://get:/simplerest:/get?componentNam... because of No bean could be found in the registry for: restlet of type: org.apache.camel.spi.RestConsumerFactory
at
What feature(s) do I need to install to rectify this error?
I fixed it by going to the http://localhost:8181/hawtio/osgi/features and filtering on REST features and installing them. Yes I know shotgun approach but it will ensure whatever technology I choose down the road will likely be covered.
Now rest-dsl-simple fuse karaf quickstart is working and now I can move to my code, knowing the fuse-karaf engine is running normally.
:-)
Related
I have an application running on a Jetty Server encapsulated in a Docker container. The same container deploys and works correctly on a local docker environment.
When deploying the container on OpenShift Kubernetes, Jetty errors with :
2021-11-13 18:07:01.667:WARN:oejw.WebAppContext:main: Failed startup of context o.e.j.q.QuickStartWebApp#39c0f4a{/,file:///opt/application/webapps/application/,UNAVAILABLE}{/application/}
java.lang.reflect.InvocationTargetException
Caused by:
java.lang.IllegalArgumentException: java.net.URISyntaxException: Expected authority at index 7: file://
at org.eclipse.jetty.quickstart.AttributeNormalizer.toCanonicalURI(AttributeNormalizer.java:93)
at org.eclipse.jetty.quickstart.AttributeNormalizer.add(AttributeNormalizer.java:208)
I understand the error is related to a URI which might be incorrectly formatted, but I'm struggling to understand where this one is configured, given that it works in a local docker environment.
Any suggestions on how to debug this are very welcome.
Looks like you have an incomplete file uri.
file://
That does not produce a valid URI on Java.
$ jshell
| Welcome to JShell -- Version 11.0.12
| For an introduction type: /help intro
jshell> new URI("file://")
| Exception java.net.URISyntaxException: Expected authority at index 7: file://
| at URI$Parser.fail (URI.java:2913)
| at URI$Parser.failExpecting (URI.java:2919)
| at URI$Parser.parseHierarchical (URI.java:3163)
| at URI$Parser.parse (URI.java:3114)
| at URI.<init> (URI.java:600)
| at (#1:1)
More of the stacktrace would help identify where that is coming from.
On my karaf 4.0.8 I've installed the feature pax-jdbc-postgresql. The DataFactory for PostgreSQL is installed:
org.osgi.service.jdbc.DataSourceFactory]
osgi.jdbc.driver.class org.postgresql.Driver
osgi.jdbc.driver.name PostgreSQL JDBC Driver
osgi.jdbc.driver.version PostgreSQL 9.4 JDBC4.1 (build 1203)
service.bundleid 204
service.scope singleton
Using Bundles com.eclipsesource.jaxrs.publisher (184)
I've create the file etc/org.ops4j.datasource-psql-sandbox.cfg:
osgi.jdbc.driver.class=org.postgresql.Driver
osgi.jdbc.driver.name=PostgreSQL
url=jdbc:postgresql://localhost:5432/sandbox
dataSourceName=psql-sandbox
user=sandbox
password=sandbox
After that, I see the confirmation in karaf.log that the file was processed:
2017-02-10 14:54:17,468 | INFO | 41-88b277ae0921) |
DataSourceRegistration | 154 - org.ops4j.pax.jdbc.config -
0.9.0 | Detected config for DataSource psql-sandbox. Tracking DSF with filter
(&(objectClass=org.osgi.service.jdbc.DataSourceFactory)(osgi.jdbc.driver.class=org.postgresql.Driver)(osgi.jdbc.driver.name=PostgreSQL))
However, I see no new DataSource in services list in console. What went wrong? I see no exceptions in log ....
The log message tell you that the config was processed and it is now searching for a suitable DataSourceFactory OSGi service.
The problem in your case is that it does not find such a service. So to debug this you should list all DataSourceFactory services and check their properties.
service:list DataSourceFactory
In my case it shows this:
[org.osgi.service.jdbc.DataSourceFactory]
-----------------------------------------
osgi.jdbc.driver.class = org.postgresql.Driver
osgi.jdbc.driver.name = PostgreSQL JDBC Driver
...
As you see it does not match the filter you see in the log. Generally you should only provide either osgi.jdbc.driver.class or osgi.jdbc.driver.name not both. If you remove the osgi.jdbc.driver.name line the config will work.
There is no error message as the system can not know if the error is transient or not. Basically as soon as you install a matching OSGi service the DataSource will be created.
I’m trying to use the Monitoring GE / Sextant tool called NGSI Adapter. I am trying to run the command line suggestion from https://github.com/telefonicaid/fiware-monitoring/blob/develop/README.rst#api-overview
I always get this response:
time=2016-03-16T11:06:18.794Z | lvl=INFO | trans=ciluqsqi1000077m2u9zwb8x5 | op=POST | msg=Request on resource /check_load with params id=host_1&type=host
time=2016-03-16T11:06:18.800Z | lvl=INFO | trans=ciluqsqi1000077m2u9zwb8x5 | op=POST | msg=Response status 200 OK
time=2016-03-16T11:05:07.004Z | lvl=INFO | trans=ciluqr73e0000umm2nir549ts | op=UpdateContext | msg=Request to ContextBroker at http://orion:1026...
time=2016-03-16T11:05:07.013Z | lvl=INFO | trans=ciluqr73e0000umm2nir549ts | op=UpdateContext | msg=Response status 415 Unsupported Media Type
From looking at the release notes to Orion 3.4.1, "Unsupported Media Type" indicates that the Content-Type in the request header is unacceptable. From browsing the code in lib/parsers/common/base.js it seems like NGSI Adapter only currently supports xml. I think that Orion now only supports JSON.
Am I correct that this incompatibility between NGSI Adapter and Orion exists?
When is a fix expected?
You're right.
Taking a look at the release notes, you’ll find that Orion 0.28.0 is the last version which includes XML support (deprecated since 0.23.0).
For that reason, a new NGSI Adapter v1.4.0 (included as part of FIWARE Monitoring 5.2.3) has been released. Please follow these instructions to install it and check documentation at ReadTheDocs.
Thank you for using FIWARE Monitoring.
Good morning,
I'm looking for help please.I'm only a beginner.
I am using cxf-dosgi from (DOSGi Apache Karaf Feature distribution)
I want to make transparent use of services between two remote machines. So I have a karaf container on each of these two machines.
I tested this example : to start with two containers karaf hosted on the same machine then I changed the configuration to test with two containers hosted on two different remote machines. And it works great !
So I want to do the same thing to export to export my web services. I am using Spring DM. So I do this on the server side :
<osgi:service id="osgi-service" ref="myservice" interface="org.apache.camel.Endpoint"> <osgi:service-properties> <entry key="name" value="service"/> <entry key="service.exported.interfaces" value="*"/> </osgi:service-properties> </osgi:service>
I did the installations like in the tutorial with cxf dosgi version 1.6 But I get this error:
16:25:53,256 | ERROR | pool-21-thread-3 | w.service.RemoteServiceAdminCore 193 | 184 - cxf-dosgi-ri-dsw-cxf - 1.6.0 | failed to create server for interface org.apache.camel.Endpoint
java.lang.NullPointerException
at java.lang.reflect.Array.newArray(Native Method)[:1.7.0_79]
at java.lang.reflect.Array.newInstance(Array.java:70)[:1.7.0_79]
at org.apache.cxf.aegis.type.TypeUtil.getTypeRelatedClass(TypeUtil.java:259)
at org.apache.cxf.aegis.type.AbstractTypeCreator.createTypeForClass(AbstractTypeCreator.java:108)
at org.apache.cxf.aegis.type.AbstractTypeCreator.createType(AbstractTypeCreator.java:402)
at org.apache.cxf.aegis.type.basic.BeanTypeInfo.getType(BeanTypeInfo.java:192)
at org.apache.cxf.aegis.type.basic.BeanType.getDependencies(BeanType.java:547)
at org.apache.cxf.aegis.databinding.AegisDatabinding.addDependencies(AegisDatabinding.java:394)
at org.apache.cxf.aegis.databinding.AegisDatabinding.addDependencies(AegisDatabinding.java:399)
at org.apache.cxf.aegis.databinding.AegisDatabinding.addDependencies(AegisDatabinding.java:399)
at org.apache.cxf.aegis.databinding.AegisDatabinding.initializeMessage(AegisDatabinding.java:371)
at org.apache.cxf.aegis.databinding.AegisDatabinding.initializeOperation(AegisDatabinding.java:283)
at org.apache.cxf.aegis.databinding.AegisDatabinding.initialize(AegisDatabinding.java:242)
at org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:490)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:550)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:265)
at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102)
at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:159)
at org.apache.cxf.dosgi.dsw.handlers.AbstractPojoConfigurationTypeHandler.createServerFromFactory(AbstractPojoConfigurationTypeHandler.java:191)
at org.apache.cxf.dosgi.dsw.handlers.PojoConfigurationTypeHandler.createServer(PojoConfigurationTypeHandler.java:119)
at org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportInterfaces(RemoteServiceAdminCore.java:184)
at org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:140)
at org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:59)
at org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:57)
at java.security.AccessController.doPrivileged(Native Method)[:1.7.0_79]
at org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:57)[184:cxf-dosgi-ri-dsw-cxf:1.6.0]
at org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:41)[184:cxf-dosgi-ri-dsw-cxf:1.6.0]
at org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport.exportServiceUsingRemoteServiceAdmin(TopologyManagerExport.java:185)[183:cxf-dosgi-ri-topology-manager:1.6.0]
at org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport.doExportService(TopologyManagerExport.java:168)[183:cxf-dosgi-ri-topology-manager:1.6.0]
at org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport$3.run(TopologyManagerExport.java:143)[183:cxf-dosgi-ri-topology-manager:1.6.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_79]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_79]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_79]
Have you an idea of what is wrong?
Ouch .. what are you doing with 1.4-SNAPSHOT. First it is not a release and second it is quite old.
Another thing that looks suspicious is the service.exported.interfaces=myInterface. It should be a fully qualified java interface name. For the start try service.exported.interfaces=* for it.
You should start with my CXF DOSGi tutorial. The code there should work out of the box. You can then add your changes in the config. So it is easier than to start completely new.
I used the grails cloudfoundry plugin and tunnel to remote Mongo DB service. The connection is fine since I can do search for the first time, but after couple seconds, the terminal starts print out 502 Bad Gateway error and I am not able to execute any mongo db commands.
| Run cf-tunnel-disconnect to close the current tunnel
|
Error Exception in thread "ThreadPoolTaskExecutor-3"
| Error org.cloudfoundry.caldecott.TunnelException: Error while reading from tunnel
| Error at org.cloudfoundry.caldecott.client.TunnelHandler$Reader.run(TunnelHandler.java:172)
| Error at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
| Error at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
| Error at java.lang.Thread.run(Thread.java:680)
| Error Caused by: org.springframework.web.client.HttpServerErrorException: **502 Bad Gateway
| Error** at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:92)
| Error at org.springframework.web.client.RestTemplate.handleResponseError(RestTemplate.java:494)
| Error at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:451)
| Error at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:409)
| Error at org.cloudfoundry.caldecott.client.HttpTunnel.receiveDataBuffered(HttpTunnel.java:150)
| Error at org.cloudfoundry.caldecott.client.HttpTunnel.receiveBytes(HttpTunnel.java:140)
| Error at org.cloudfoundry.caldecott.client.HttpTunnel.read(HttpTunnel.java:83)
| Error at org.cloudfoundry.caldecott.client.TunnelHandler$Reader.run(TunnelHandler.java:148)
| Error ... 3 more
That looks like an error handling problem that was fixed in later releases of the cloudfoundry-caldecott-lib. The latest is 0.1.3 and is available from the Spring Source milestone repo (http://repo.springsource.org/libs-milestone/org/cloudfoundry/cloudfoundry-caldecott-lib/).
I'm not sure what version the Grails plugin uses, but if it's an older version, that would explain why you are seeing this.
Thanks #trisberg 's explanation and #scott 's finding, now I am able to use VMC to tunnel to my remote DB. Problem solved.