Re: Need help with and (OSGi-fication of TwelweMonkeys)

[Christian Lutz]

> Am 13.08.2023 um 15:29 schrieb Steinar Bang :
> 
>>>>>> Steinar Bang :
>>>>>> Christian Lutz :
>>> I have done the same for keycloak. Hope this helps.
> 
>>> Please see the attached PR.
>>> https://github.com/keycloak/keycloak/pull/9288/files
> 
>> Hm... the structure of the  in the above PR looks
>> identical to the one I've made for the TwelweMonkey's JPEG reader?
> 
> I have pushed my changes to the TwelweMonkeys JPEG plugin
> https://github.com/haraldk/TwelveMonkeys/commit/faf40a6882f1cd8a08ad110e3786ffa50df156bf
> (it's in a branch on my own fork of the repo)
> 
> I'm waiting until I get the JPEG plugin working before adding the rest
> of the plugins.
> 
> TwelweMonkeys has a *lot* of plugins for various image formats.
> 
Not sure, but you need the first part auf the required, as well.
Or am I wrong?

Re: Need help with and (OSGi-fication of TwelweMonkeys)

[Christian Lutz]

Hello Steiner,

I have done the same for keycloak. Hope this helps.

Please see the attached PR.
https://github.com/keycloak/keycloak/pull/9288/files

- Christian


> Am 13.08.2023 um 10:05 schrieb Steinar Bang :
> 
> I am trying to make a PR for OSGi-ifying the TwelveMonkeys library.
> https://github.com/haraldk/TwelveMonkeys/issues/794
> 
> TwelveMonkeys is a pure-java implementation of image format readers and
> writers for many graphics formats.
> 
> TwelveMonkeys plugs into the Java runtime ImageIO system, using the
> Service Provider Interface (SPI).
> https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/imageio/package-summary.html
> 
> I'm already using the SPI with liquibase with Aries SPI Fly, so I
> figured it must be possible to make SPI work for TwelveMonkeys and
> ImageIO as well.
> 
> But I have so far been unsuccessful in determining how the
>  and  instructions to
> maven-bundle-plugin should look like.
> 
> Does anyone know?
> 
> My latest attempts are:
> 
> When creating the bundle with the plugin:
> 
> 
>org.apache.felix
>maven-bundle-plugin
>
>
>   
>   osgi.serviceloader;
>   
> osgi.serviceloader=com.twelvemonkeys.imageio.plugins.jpeg.JPEGImageReader
>
>
>
> 
> 
> 
> When using the bundle with the plugin from a different bundle:
> 
> 
>org.apache.felix
>maven-bundle-plugin
>
>
>
>osgi.extender; 
> filter:="(osgi.extender=osgi.serviceloader.processor)",
>osgi.serviceloader; 
> filter:="(osgi.serviceloader=com.twelvemonkeys.imageio.plugins.jpeg.JPEGImageReader)";
>  cardinality:=multiple,
>
>
>
> 
> 
> But this gives me many error messages in the integration test (and when
> loading into karaf): 
> https://gist.github.com/steinarb/55d4814e000e6e4e2f2a6235c3a186ae
> 
> Suggestions are welcome!
> 
> Thanks!
> 

javax.servlet chain problems

[Christian Lutz]

Hello,

you have created the following Issue 
https://issues.apache.org/jira/browse/CXF-8335.
And I am running in exact this problem, too. How could I workaround this issue.

I have my own karaf distro created with karaf-assembly and kar file using the 
OpenAPI.

Any hint how I could fix this either in the distro or the kar file.

kind regards
Christian

kar not found, JIRA issues

[Christian Lutz]

Hello JB,

I have a problem with the current 4.2.12 (works with 4.2.11).
Every time I start the karaf clean (data folder empty) the kar file won’t be 
installed. Using kar:list is empty. Using car:install file:… works.
Or if I shutdown and start karaf again it works, also. 
Is this a known problem?

system: windows 10 and openjdk 11.

I tried to find an existing JIRA issue for it. But the JIRA doesn’t work.
I am able to see all JIRA issues here
https://issues.apache.org/jira/projects/KARAF/issues/KARAF-7149?filter=allopenissues

But if a try to search one it fails and I will redirected to a URL starting 
with https://issues.apache.org/undefined/issues/

I also tried to find a searchable mailing list archive. Ist there anyone?
Because I delete the mails on my computer after a certain time.

kind regards
Christian

Re: Error starting 4.2.9 with JDK 14.0.1 on Mac

[Christian Lutz]

Hello Oleg,

a few weeks ago JB mentioned that jdk 14 isnt supported, yet. Will be with 
4.2.10. 

kind regards. 

> Am 16.06.2020 um 13:57 schrieb Oleg Cohen :
> 
> 
> Greetings,
> 
> I installed a brand new Karaf 4.2.9 and a JDK 14.0.1.
> 
> I get the following error starting ./bin/karaf
> 
> tcsh% ./bin/karaf
> ERROR: Error parsing system bundle export statement: 
> org.osgi.dto;version="1.0",org.osgi.resource;version="1.0",org.osgi.resource.dto;version="1.0";uses:="org.osgi.dto",org.osgi.framework;version="1.8",org.osgi.framework.dto;version="1.8";uses:="org.osgi.dto",org.osgi.framework.hooks.bundle;version="1.1";uses:="org.osgi.framework",org.osgi.framework.hooks.resolver;version="1.0";uses:="org.osgi.framework.wiring",org.osgi.framework.hooks.service;version="1.1";uses:="org.osgi.framework",org.osgi.framework.hooks.weaving;version="1.1";uses:="org.osgi.framework.wiring",org.osgi.framework.launch;version="1.2";uses:="org.osgi.framework",org.osgi.framework.namespace;version="1.1";uses:="org.osgi.resource",org.osgi.framework.startlevel;version="1.0";uses:="org.osgi.framework",org.osgi.framework.startlevel.dto;version="1.0";uses:="org.osgi.dto",org.osgi.framework.wiring;version="1.2";uses:="org.osgi.framework,org.osgi.resource",org.osgi.framework.wiring.dto;version="1.2";uses:="org.osgi.dto,org.osgi.resource.dto",org.osgi.service.condpermadmin;version="1.1.1";uses:="org.osgi.framework,org.osgi.service.permissionadmin",org.osgi.service.packageadmin;version="1.2";uses:="org.osgi.framework",org.osgi.service.permissionadmin;version="1.2",org.osgi.service.resolver;version="1.0";uses:="org.osgi.resource",org.osgi.service.startlevel;version="1.1";uses:="org.osgi.framework",org.osgi.service.url;version="1.0",org.osgi.util.tracker;version="1.5.1";uses:="org.osgi.framework",org.apache.karaf.version;version="4.2.9",org.apache.karaf.jaas.boot.principal;uses:=javax.security.auth;version="4.2.9",org.apache.karaf.jaas.boot;uses:="javax.security.auth,javax.security.auth.callback,javax.security.auth.login,javax.security.auth.spi,org.osgi.framework";version="4.2.9",org.apache.karaf.info;version="4.2.9",,org.apache.karaf.branding,
>  sun.misc, com.sun.jmx.remote.protocol, com.sun.jmx.remote.protocol.jmxmp, 
> org.apache.karaf.jaas.boot.principal;uses:=javax.security.auth;version=4.2.9, 
> org.apache.karaf.jaas.boot;uses:="javax.security.auth,javax.security.auth.callback,javax.security.auth.login,javax.security.auth.spi,org.osgi.framework";version=4.2.9,
>  org.apache.karaf.diagnostic.core;uses:=org.osgi.framework;version=4.2.9, 
> org.apache.karaf.diagnostic.core.common;uses:=org.apache.karaf.diagnostic.core;version=4.2.9
> org.osgi.framework.BundleException: Exported package names cannot be zero 
> length.
> at 
> org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeExportClauses(ManifestParser.java:876)
> at 
> org.apache.felix.framework.util.manifestparser.ManifestParser.(ManifestParser.java:215)
> at 
> org.apache.felix.framework.ExtensionManager.(ExtensionManager.java:261)
> at org.apache.felix.framework.Felix.(Felix.java:429)
> at 
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:28)
> at org.apache.karaf.main.Main.launch(Main.java:256)
> at org.apache.karaf.main.Main.main(Main.java:178)
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.apache.felix.framework.URLHandlers 
> (file:/Users/ocohen/AppsLocal/Karaf/apache-karaf-4.2.9/system/org/apache/felix/org.apache.felix.framework/5.6.12/org.apache.felix.framework-5.6.12.jar)
>  to constructor sun.net.www.protocol.file.Handler()
> WARNING: Please consider reporting this to the maintainers of 
> org.apache.felix.framework.URLHandlers
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Error installing bundle listed in startup.properties with url: 
> mvn:org.apache.karaf.features/org.apache.karaf.features.extension/4.2.9 and 
> startlevel: 1
> 
> 
> Is there anything I need to do to configure? Is there a problem getting 
> artifacts?
> 
> Thank you!
> Oleg
> 
> -- 
> Oleg Cohen  |  Principal  |  A S S U R E B R I D G E
> Office: +1 617 564 0737  |  Mobile: +1 617 455 7927  |  Fax: +1 888 409 6995
> Email: oleg.co...@assurebridge.com  |  www.assurebridge.com

Re: Why is a feature added?

[Christian Lutz]

Hello Alex, JB,

yes such a flag would be extremly helpful. 

Kind regards

> Am 11.06.2020 um 18:58 schrieb Alex Soto :
> 
> Hi JB, 
> 
> No, it is not Camel 3.3.0. It is Jetty.  Here is the output from the Maven 
> build:
> 
> 
> [INFO]Feature pax-jetty/9.4.28.v20200408 is defined as a boot feature
> [INFO]   adding maven artifact: 
> mvn:org.eclipse.jetty/jetty-util-ajax/9.4.28.v20200408
> [INFO]   adding maven artifact: 
> mvn:javax.annotation/javax.annotation-api/1.3
> [INFO]   adding maven artifact: 
> mvn:org.eclipse.jetty.websocket/javax-websocket-client-impl/9.4.28.v20200408
> 
> And
> 
> 
> [INFO]Feature pax-jetty/9.4.20.v20190813 is defined as a boot feature
> [INFO]   adding maven artifact: 
> mvn:org.eclipse.jetty/jetty-jaspi/9.4.20.v20190813
> [INFO]   adding maven artifact: 
> mvn:javax.annotation/javax.annotation-api/1.3
> 
> 
> I do not explicitly add Jetty, so it must be at a lower level.  What would be 
> nice, though, is to have a flag or something so that Karaf’s plugin can 
> display the hierarchy so I can easily spot who’s is bringing the dependency. 
> 
> 
> Best regards,
> Alex soto
> 
> 
> 
> 
>> On Jun 11, 2020, at 12:34 PM, Jean-Baptiste Onofre  wrote:
>> 
>> Hi,
>> 
>> You maybe have a range in another feature using  ?
>> 
>> If you talk about Camel 3.3.0 and Karaf feature, I already saw the issue and 
>> created a Jira at Camel to fix that: 
>> https://issues.apache.org/jira/browse/CAMEL-15166
>> 
>> It works fine with Camel 2.25.1 but with the "move" to the new 
>> feature/repository, it’s weird ;)
>> I have to do a cleanup/fix.
>> 
>> Regards
>> JB
>> 
>>> Le 11 juin 2020 à 18:31, Alex Soto  a écrit :
>>> 
>>> Hello,
>>> 
>>> I have a Karaf custom distribution project, using karaf-maven-plugin 
>>> plugin.  For some reason, 2 versions of the same feature are added to the 
>>> final distribution as boot features.  I’d like to clean it up so only on 
>>> version is used, but I don’t know why is being added.  Is there a way to 
>>> figure out why a particular feature is added to the distribution?  Some 
>>> tree output of the dependency hierarchy would be nice.  Thanks!
>>> 
>>> Best regards,
>>> Alex soto
>>> 
>>> 
>>> 
>>> 
>> 
> 

Re: Use configuration file with ObjectClassDefinition

[Christian Lutz]

Hello JB,

Ok it works. Thx. 

What surprised me was the fact, that I have to use the name attribute of the 
component to bind to the configuration service pid. Even though there is a 
configurationPid in the component available. 

It is the first time I use this kind of configuration (used blueprint so far) I 
havent been aware of that there several (at least two) ways of doing this. I 
guess there are some reason to use one or the other. Any hints?

Kind regards
Christian

> Am 04.06.2020 um 14:52 schrieb Jean-Baptiste Onofre :
> 
> Hi
> 
> By default it’s based on component name.
> 
> But you can provide any pid.
> 
> Metatype is enabled by default in Karaf. So, you can have your annotation 
> @ObjectClassDefintion.
> 
> However, you can’t mix SCR level property and metatype property.
> So it’s all one or the other.
> 
> Regards
> JB
> 
>> Le 4 juin 2020 à 14:49, Christian Lutz  a écrit :
>> 
>> Hello JB,
>> 
>> oh it is wired to the name of the component. I will give it a try. 
>> 
>> If I look into the OSGI compendium ObjectClassDefinition is a MetaType 
>> Annotation. What did I miss?
>> 
>> Kind regards
>> Christian 
>> 
>>>> Am 04.06.2020 um 14:44 schrieb Jean-Baptiste Onofre :
>>> 
>>> And by the way, you can also use metatype.
>>> 
>>> Regards
>>> JB
>>> 
>>>> Le 4 juin 2020 à 14:38, Christian Lutz  a écrit :
>>>> 
>>>> Hello,
>>>> 
>>>> is it possible with karaf (4.1.x or 4.2.x) to use a configuration file 
>>>> with an ObjectClassDefinition?
>>>> 
>>>> E.g. I have a simple ObjectClassDefinition with one boolean method. I set 
>>>> the pid property to de.xy
>>>> 
>>>> My idea was that if I want to change the default value all I need to do is 
>>>> to create a de.xy.cfg file in karaf /cfg set the boolean value to false 
>>>> and during the component active the value from the config file will be 
>>>> used instead of the default value. 
>>>> 
>>>> I found some tutorials of how to use the objectclassdefinition itself. But 
>>>> I didnt find anything about how I am able to wire this with the karaf 
>>>> Configuration Admin Service. 
>>>> 
>>>> Kind regards
>>>> Christian 
>>> 
>> 
> 

Re: Use configuration file with ObjectClassDefinition

[Christian Lutz]

Hello JB,

oh it is wired to the name of the component. I will give it a try. 

If I look into the OSGI compendium ObjectClassDefinition is a MetaType 
Annotation. What did I miss?

Kind regards
Christian 

> Am 04.06.2020 um 14:44 schrieb Jean-Baptiste Onofre :
> 
> And by the way, you can also use metatype.
> 
> Regards
> JB
> 
>> Le 4 juin 2020 à 14:38, Christian Lutz  a écrit :
>> 
>> Hello,
>> 
>> is it possible with karaf (4.1.x or 4.2.x) to use a configuration file with 
>> an ObjectClassDefinition?
>> 
>> E.g. I have a simple ObjectClassDefinition with one boolean method. I set 
>> the pid property to de.xy
>> 
>> My idea was that if I want to change the default value all I need to do is 
>> to create a de.xy.cfg file in karaf /cfg set the boolean value to false and 
>> during the component active the value from the config file will be used 
>> instead of the default value. 
>> 
>> I found some tutorials of how to use the objectclassdefinition itself. But I 
>> didnt find anything about how I am able to wire this with the karaf 
>> Configuration Admin Service. 
>> 
>> Kind regards
>> Christian 
> 

Use configuration file with ObjectClassDefinition

[Christian Lutz]

Hello,

is it possible with karaf (4.1.x or 4.2.x) to use a configuration file with an 
ObjectClassDefinition?

E.g. I have a simple ObjectClassDefinition with one boolean method. I set the 
pid property to de.xy

My idea was that if I want to change the default value all I need to do is to 
create a de.xy.cfg file in karaf /cfg set the boolean value to false and during 
the component active the value from the config file will be used instead of the 
default value. 

I found some tutorials of how to use the objectclassdefinition itself. But I 
didnt find anything about how I am able to wire this with the karaf 
Configuration Admin Service. 

Kind regards
Christian 

Re: Using jetty instead of undertow with keycloak possible

[Christian Lutz]

Hello Alex, JB

I asked the same question some time ago here[1].
And it took me some time  to figure out how the get it up and running.

First of all there is a bug in keycloak that prevents it from using it with 
jetty. I have created a PR[2] to fix it. 
But it hasn’t been merged yet.  
Also the configuration wasn’t as easy as I hoped. As you can read in my 
previous mail I wasn’t able to 
to get it up running with the new shiny approach only with the old one 
documented here[3].

[1]: 
http://karaf.922171.n3.nabble.com/Using-jetty-instead-of-undertow-with-keycloak-possible-td4057988.html
 
<http://karaf.922171.n3.nabble.com/Using-jetty-instead-of-undertow-with-keycloak-possible-td4057988.html>
[2]: https://github.com/keycloak/keycloak/pull/6978 
<https://github.com/keycloak/keycloak/pull/6978>
[3]: 
https://github.com/jboss-fuse/karaf-quickstarts/blob/7.x.redhat-7-x/security/keycloak/fuse-keycloak.adoc#securing-embedded-cxf-server---previous-solution
 
<https://github.com/jboss-fuse/karaf-quickstarts/blob/7.x.redhat-7-x/security/keycloak/fuse-keycloak.adoc#securing-embedded-cxf-server---previous-solution>

best regards
Christian


> Am 01.06.2020 um 22:49 schrieb Alex Soto :
> 
> Thanks, JB, 
> 
> Unfortunately, my app depends heavily  on Camel.  I would be interested in a 
> way to make Keycloak work with default Jetty, this will probably be easier 
> than replacing Jetty with Undertow at this point.  Any help will be 
> appreciated.
> 
> Best regards,
> Alex soto
> 
> 
> 
> 
>> On Jun 1, 2020, at 3:32 PM, Jean-Baptiste Onofre > <mailto:j...@nanthrax.net>> wrote:
>> 
>> Add etc/org.apache.karaf.features.xml containing:
>> 
>> 
>> 
>>  
>>  pax-http-jetty
>>  
>> 
>> 
>> 
>> The purpose is to avoid to install this feature.
>> 
>> However, be careful, some third party projects (like camel or cxf) directly 
>> use jetty feature. I identify some issue about that and I will update these 
>> features to use http provider instead.
>> 
>> Regards
>> JB
>> 
>>> Le 1 juin 2020 à 21:25, Alex Soto >> <mailto:alex.s...@envieta.com>> a écrit :
>>> 
>>> Blacklist? How?
>>> 
>>> Best regards,
>>> Alex soto
>>> 
>>> 
>>> 
>>> 
>>>> On Jun 1, 2020, at 3:11 PM, Jean-Baptiste Onofre >>> <mailto:j...@nanthrax.net>> wrote:
>>>> 
>>>> Just installing the pax web undertow feature will add the HTTP undertow 
>>>> provider capability. You just have to blacklist jetty feature and it 
>>>> should be fine.
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>>> Le 1 juin 2020 à 21:09, Alex Soto >>>> <mailto:alex.s...@envieta.com>> a écrit :
>>>>> 
>>>>> If I have to use Undertow, I’d be willing to try it, but there is little 
>>>>> or no info on how to switch Pax-Web to use Undertow.
>>>>> I don’t have any particular need to use Jetty,  just trying to be 
>>>>> isolated from this by Pax-Web.
>>>>> 
>>>>> Best regards,
>>>>> Alex soto
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jun 1, 2020, at 12:45 PM, Jean-Baptiste Onofre >>>>> <mailto:j...@nanthrax.net>> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Yes, I have something (not with the latest keycloak) but I had to "fix" 
>>>>>> the keycloak feature.
>>>>>> 
>>>>>> Regards
>>>>>> JB
>>>>>> 
>>>>>>> Le 1 juin 2020 à 16:30, Alex Soto >>>>>> <mailto:alex.s...@envieta.com>> a écrit :
>>>>>>> 
>>>>>>> Hello, 
>>>>>>> 
>>>>>>> Anybody has a working example of Pax-Web with Jetty, and Keycloak? 
>>>>>>> The Jetty features are commented out in the Keycloak  
>>>>>>> keycloak-osgi-features-10.0.1 /features.xml file:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Alex soto
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On May 29, 2020, at 4:19 PM, Alex Soto >>>>&g

Re: Question regarding Karaf 4.2.8

[Christian Lutz]

Good morning,

one problem we had was that maven requires https now. Look into ...mvn.cfg 
repositories. If the s is missing add it and your fine. 

kind regards. 
Christian 

> Am 19.05.2020 um 06:55 schrieb Jean-Baptiste Onofre :
> 
> Hi Scott,
> 
> All "core" dependencies are in system folder, so I don’t think it’s related. 
> I’m more suspecting some environment changes (JDK, env variables), like 
> shell, locale, ...
> 
> Still the same if you purge the data folder ?
> 
> Regards
> JB
> 
>> Le 19 mai 2020 à 04:38, Leschke, Scott  a écrit :
>> 
>> I’ve been running 4.2.8 for months (on Win64) without any issues but after I 
>> did a reinstall on my test system last week, Karaf comes up with many of the 
>> commands not being recognized, like the “bundle” commands, “source” and 
>> “logout” for example.  Since this issue didn’t exist when I originally 
>> installed I’m wondering what might could cause this to occur now. The log 
>> doesn’t show anything out of the ordinary.
>>  
>> As a sanity check, I tried dropping back to v4.2.7 and get the same 
>> behavior. I’m thinking that some Karaf dependencies have been updated that 
>> could be causing this even though the version hasn’t changed but I’m also 
>> wondering if something in my environment could cause it.
>>  
>> Thoughts?
>>  
>> Scott
> 

Re: Using jetty instead of undertow with keycloak possible

[Christian Lutz]

Hello,

I tried to get the keycloak integration up and running with karat (4.2.8) cxf 
(3.3.5) jetty (9.4.x) and keycloak (9.0.3).

* 
https://github.com/jboss-fuse/karaf-quickstarts/blob/7.x.redhat-7-x/security/keycloak/fuse-keycloak.adoc#securing-embedded-cxf-server---previous-solution
 
<https://github.com/jboss-fuse/karaf-quickstarts/blob/7.x.redhat-7-x/security/keycloak/fuse-keycloak.adoc#securing-embedded-cxf-server---previous-solution>
* 
https://github.com/jboss-fuse/karaf-quickstarts/blob/7.x.redhat-7-x/security/keycloak/fuse-keycloak.adoc#securing-embedded-cxf-server---new-solution
 
<https://github.com/jboss-fuse/karaf-quickstarts/blob/7.x.redhat-7-x/security/keycloak/fuse-keycloak.adoc#securing-embedded-cxf-server---new-solution>

At first both solutions didn’t work. I found a bug within the jetty adapter. I 
created PR for this[1]
With this fix the previous solutions works, now.

However I wasn’t able to get the new solution working. 
The questions is, is it a bug within one of the components pax-web, keycloak 
adapter or just a configuration error. 
Does anyone have a running instance with the new solution.

kind regards
Christian

[1]: https://github.com/keycloak/keycloak/pull/6978 
<https://github.com/keycloak/keycloak/pull/6978>

> Am 07.04.2020 um 23:06 schrieb Christian Lutz :
> 
> Hello,
> 
> I just wanted to ask if someone has a running karaf 4.2.8 instance with REST 
> services protected by keycloak.
> Based on this 
> https://github.com/jboss-fuse/karaf-quickstarts/tree/7.x.redhat-7-x/security/keycloak/keycloak-cxf#testing-embedded-undertow-servlet-engine
>  
> <https://github.com/jboss-fuse/karaf-quickstarts/tree/7.x.redhat-7-x/security/keycloak/keycloak-cxf#testing-embedded-undertow-servlet-engine>
>  approach,
> but instead of using cxf with undertow using this approach with jetty.
> 
> If so, did the description work out of box or are any changes necessary?
> 
> For some reason the keycloak-pax-http-jetty feature is commented out.
> https://github.com/keycloak/keycloak/blob/master/distribution/adapters/osgi/features/src/main/resources/features.xml
>  
> <https://github.com/keycloak/keycloak/blob/master/distribution/adapters/osgi/features/src/main/resources/features.xml>
> Any idea why? 
> 
> Sincerely
> Christian

Using jetty instead of undertow with keycloak possible

[Christian Lutz]

Hello,

I just wanted to ask if someone has a running karaf 4.2.8 instance with REST 
services protected by keycloak.
Based on this 
https://github.com/jboss-fuse/karaf-quickstarts/tree/7.x.redhat-7-x/security/keycloak/keycloak-cxf#testing-embedded-undertow-servlet-engine
 

 approach,
but instead of using cxf with undertow using this approach with jetty.

If so, did the description work out of box or are any changes necessary?

For some reason the keycloak-pax-http-jetty feature is commented out.
https://github.com/keycloak/keycloak/blob/master/distribution/adapters/osgi/features/src/main/resources/features.xml
 

Any idea why? 

Sincerely
Christian

propertyFileEdits notes

[Christian Lutz]

Hello,
 
I tried to set set the serviceRequirements=disable with the karaf-maven-plugin.
As mentioned here 
(http://karaf.922171.n3.nabble.com/How-do-i-change-a-single-line-in-a-custom-distro-file-td4053462.html)
 I am able todo this with the assembly-property-edits.xml file.
 
Three points to note:
1. There is an open issue (https://issues.apache.org/jira/browse/KARAF-4223) 
because of the missing documentation. Where should the documentation be 
defined. If it is easy a can create a pull request.
2. The xmlns url is invalid because it doesn't exist 
http://karaf.apache.org/tools/property-edits/1.0.0 and it is inconsistent 
compared to the other xmlns it should be something like
http://karaf.apache.org/xmlns/tools/property-edits/v1.0.0
3. The format of the file will be changed and the format isn't preserved. If we 
could use Apache Commons Configurations 
(http://commons.apache.org/proper/commons-configuration/index.html) it should 
be possible to preserve the format. What do you think?
 
kind regards
christian

Re: javax.xml.bind.annotation issue with Karaf-4.2.5 with Java-8

[Christian Lutz]

Hello Erwin,

in my case it was because I used CXF 3.3.2 with OpenApi. 

In your case another dependency may be the reason. 

kind regards
Christian

> Am 28.05.2019 um 00:48 schrieb Erwin Hogeweg :
> 
> All -
> 
> I am pretty sure I have seen a discussion here re. Karaf, 
> javax.xml.bind.annotation and Java 8. I can’t find the thread anymore though.
> 
> The issue I am running into is this:
> 
>   missing requirement [com.my.service/1.2.1.SNAPSHOT_20190527-1640] 
> osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=javax.xml.bind.annotation)(version>=2.3.0)(!(version>=3.0.0)))”]]
> 
> Obviously that is because the jre-1.8 section in jre.properties specifies 
> 2.2.8.
> 
> If I change that section to:
> 
>   javax.xml.bind;version="2.3.0", \
>   javax.xml.bind.annotation;version="2.3.0", \
>   javax.xml.bind.annotation.adapters;version="2.3.0", \
>   javax.xml.bind.attachment;version="2.3.0", \
>   javax.xml.bind.helpers;version="2.3.0", \
>   javax.xml.bind.util;version="2.3.0", \
>  
> Everything is fine again. I assume I can also find a 2.3.0 api bundle and 
> include that in my distro. Haven’t tried that yet.
> 
> Couple of questions remain…
> 
> 1. Where does that 2.3.0 dependency come from when I compile against 
> Karaf-4.2.5? 
> 2. Is this the right approach, if not, what is the recommended way? 
> 
> 
> Thanks as always,
> 
> Erwin

Re: Enforce specific bundle?!

[Christian Lutz]

Good morning JB,

I updated my own distribution. 
I added the new jaxb-api as dependency and changed the jre.properties. 

Thank you for helping. 

kind regards
christian

> Am 17.05.2019 um 07:31 schrieb Jean-Baptiste Onofré :
> 
> Good morning Christian,
> 
> Yes, updating the Karaf vanilla distro (overriding system folder with
> JAXB 2.3.1 and updating etc/jre.properties), or building your own custom
> one.
> 
> Regards
> JB
> 
>> On 17/05/2019 06:26, Christian Lutz wrote:
>> Good morning JB,
>> 
>> with the karaf-maven-plugin? If so is it enough to add jaxb-api as 
>> dependency?
>> 
>> kind regards
>> christian
>> 
>>> Am 17.05.2019 um 05:54 schrieb Jean-Baptiste Onofré :
>>> 
>>> Hi Christian,
>>> 
>>> Maybe you can upgrade jaxb directly provided by Karaf ?
>>> 
>>> Regards
>>> JB
>>> 
>>>> On 16/05/2019 21:38, Christian Lutz wrote:
>>>> Hello,
>>>> 
>>>> I am using karat 4.1.7 (jdk8) on Windows 10 and I got in the situation 
>>>> where the bundle start fails because java.xml.bind can be found via two 
>>>> different paths.
>>>> The first path is from my own deployed kar file. The other one is provided 
>>>> by the karat itself.
>>>> 
>>>> The reason why I have added jaxb-api is one of my required bundles 
>>>> requires jaxb-api in version >=2.3.0 so I added this bundle to the kar 
>>>> file.
>>>> If I execute bundle:refresh manually after the karat has been started on 
>>>> jaxb-api 2.3.1 bundle. I am able to start my own bundle.
>>>> 
>>>> So my question is how can I enforce that the jaxb-api 2.3.1 bundle will be 
>>>> used and no manual bundle:refresh is necessary anymore.
>>>> 
>>>> What I tried so far:
>>>> - Removing javax.xml.bind from jre.properties and config.properties -> 
>>>> karat doesn’t even start anymore
>>>> - set dependency=„true“ for jab-api within feature.xml (kar source) -> 
>>>> same problem
>>>> - change start-level within feature.xml for jaxb-api within feature.xml -> 
>>>> same problem
>>>> 
>>>> kind regards 
>>>> christian
>>>> 
>>>> 
>>>> 
>>> 
>>> -- 
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Enforce specific bundle?!

[Christian Lutz]

Good morning JB,

with the karaf-maven-plugin? If so is it enough to add jaxb-api as dependency?

kind regards
christian

> Am 17.05.2019 um 05:54 schrieb Jean-Baptiste Onofré :
> 
> Hi Christian,
> 
> Maybe you can upgrade jaxb directly provided by Karaf ?
> 
> Regards
> JB
> 
> On 16/05/2019 21:38, Christian Lutz wrote:
>> Hello,
>> 
>> I am using karat 4.1.7 (jdk8) on Windows 10 and I got in the situation where 
>> the bundle start fails because java.xml.bind can be found via two different 
>> paths.
>> The first path is from my own deployed kar file. The other one is provided 
>> by the karat itself.
>> 
>> The reason why I have added jaxb-api is one of my required bundles requires 
>> jaxb-api in version >=2.3.0 so I added this bundle to the kar file.
>> If I execute bundle:refresh manually after the karat has been started on 
>> jaxb-api 2.3.1 bundle. I am able to start my own bundle.
>> 
>> So my question is how can I enforce that the jaxb-api 2.3.1 bundle will be 
>> used and no manual bundle:refresh is necessary anymore.
>> 
>> What I tried so far:
>> - Removing javax.xml.bind from jre.properties and config.properties -> karat 
>> doesn’t even start anymore
>> - set dependency=„true“ for jab-api within feature.xml (kar source) -> same 
>> problem
>> - change start-level within feature.xml for jaxb-api within feature.xml -> 
>> same problem
>> 
>> kind regards 
>> christian
>> 
>> 
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Enforce specific bundle?!

[Christian Lutz]

Hello,

I am using karat 4.1.7 (jdk8) on Windows 10 and I got in the situation where 
the bundle start fails because java.xml.bind can be found via two different 
paths.
The first path is from my own deployed kar file. The other one is provided by 
the karat itself.

The reason why I have added jaxb-api is one of my required bundles requires 
jaxb-api in version >=2.3.0 so I added this bundle to the kar file.
If I execute bundle:refresh manually after the karat has been started on 
jaxb-api 2.3.1 bundle. I am able to start my own bundle.

So my question is how can I enforce that the jaxb-api 2.3.1 bundle will be used 
and no manual bundle:refresh is necessary anymore.

What I tried so far:
- Removing javax.xml.bind from jre.properties and config.properties -> karat 
doesn’t even start anymore
- set dependency=„true“ for jab-api within feature.xml (kar source) -> same 
problem
- change start-level within feature.xml for jaxb-api within feature.xml -> same 
problem

kind regards 
christian

Re: vaadin 8 wrapped jar dependency doesn't go active

[Christian Lutz]

Good Morning Steiner,

Your bundle doesnt have version specified
> Bundle-Version: 0

To fix this you need to add the bundle-version to your wrap like
> wrap:mvn:com.googlecode.gentyref/gentyref/1.2.0&Bundle-Version=1.2.0

I hope this helps

Christian

> Am 05.10.2017 um 21:48 schrieb Steinar Bang :
> 
> I'm trying to create a karaf 4.1.2 feature that installs vaadin 8.1.5.
> 
> One dependency is com.googlecode.gentyref.  The newest version of
> gentyref I've found is this non-OSGi jar file:
> https://mvnrepository.com/artifact/com.googlecode.gentyref/gentyref/1.2.0
> 
> I've tried to add this jar as a wrap bundle in the feature file:
> http://karaf.apache.org/xmlns/features/v1.4.0"; 
> name="fildele.application">
>
>wrap
> dependency="false">pax-http-whiteboard
> start-level="80">wrap:mvn:com.googlecode.gentyref/gentyref/1.2.0
> start-level="80">mvn:no.priv.bang.fildele/fildele.application/1.0.0-SNAPSHOT
>mvn:com.vaadin/vaadin-shared/8.1.5
>mvn:com.vaadin/vaadin-server/8.1.5
>mvn:com.vaadin/vaadin-push/8.1.5
> start-level="80">mvn:com.vaadin/vaadin-client-compiled/8.1.5
>mvn:com.vaadin/vaadin-themes/8.1.5
>
> 
> 
> But this feature fails in the installation:
> karaf@root()> feature:repo-add 
> mvn:no.priv.bang.fildele/fildele.application/LATEST/xml/features
> Adding feature url 
> mvn:no.priv.bang.fildele/fildele.application/LATEST/xml/features
> karaf@root()> feature:install fildele
> Error executing command: Unable to resolve root: missing requirement [root] 
> osgi.identity; osgi.identity=fildele; type=karaf.feature; 
> version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; 
> filter:="(&(osgi.identity=fildele)(type=karaf.feature)(version>=1.0.0.SNAPSHOT)(version<=1.0.0.SNAPSHOT))"
>  [caused by: Unable to resolve fildele/1.0.0.SNAPSHOT: missing requirement 
> [fildele/1.0.0.SNAPSHOT] osgi.identity; osgi.identity=com.vaadin.server; 
> type=osgi.bundle; version="[8.1.5,8.1.5]"; resolution:=mandatory [caused by: 
> Unable to resolve com.vaadin.server/8.1.5: missing requirement 
> [com.vaadin.server/8.1.5] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=com.googlecode.gentyref)(version>=1.2.0)(!(version>=2.0.0)))"]]
> karaf@root()>
> 
> When I try to install the troublesome jar directly, it doesn't go active:
> karaf@root()> bundle:install wrap:mvn:com.googlecode.gentyref/gentyref/1.2.0
> Bundle ID: 52
> karaf@root()> bundle:list
> START LEVEL 100 , List Threshold: 50
> ID | State | Lvl | Version | Name
> ---+---+-+-+
> 28 | Active|  80 | 4.1.2   | Apache Karaf :: OSGi Services :: Event
> 52 | Installed |  80 | 0   | 
> wrap_mvn_com.googlecode.gentyref_gentyref_1.2.0
> karaf@root()> bundle:capabilities 52
> Bundle 52 is not resolved.
> karaf@root()>
> 
> The manifest.mf of data/cache/bundle52/version0.0 has no imports:
> Manifest-Version: 1.0
> Archiver-Version: Plexus Archiver
> Bnd-LastModified: 1507232709268
> Build-Jdk: 1.7.0_51
> Built-By: wouter
> Bundle-ManifestVersion: 2
> Bundle-Name: wrap_mvn_com.googlecode.gentyref_gentyref_1.2.0
> Bundle-SymbolicName: wrap_mvn_com.googlecode.gentyref_gentyref_1.2.0
> Bundle-Version: 0
> Created-By: 1.8.0_141 (Oracle Corporation)
> Export-Package: com.googlecode.gentyref
> Generated-By-Ops4j-Pax-From: wrap:mvn:com.googlecode.gentyref/gentyref/1
>  .2.0
> Originally-Created-By: Apache Maven 3.2.1
> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.5))"
> Tool: Bnd-2.3.0.201405100607
> 
> What am I doing wrong?
> 
> Thanks!
> 
> 
> - Steinar
> 

Re: Blueprint System Properties not resolved

[Christian Lutz]

Hello Alex,

I did use the same, but in my case I had to update the version of the schemas 
to.

http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.3.0 

and 
http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.5.0 



- christian


> Am 01.09.2016 um 20:47 schrieb Alex Soto :
> 
> No, I checked. This is still in integration test mode, with Pax-Exam, so the 
> directory does not yet have any cfg files other than Karaf’s own.
> 
> Best regards,
> Alex soto
> 
> 
> 
>> On Sep 1, 2016, at 2:12 PM, Guillaume Nodet > > wrote:
>> 
>> Are you sure you don't have this value coming from the configuration in 
>> etc/my.config.id.cfg or something like that  ?
>> We had such a pattern in multiple places in Karaf 2.x and it was working 
>> fine.
>> 
>> 2016-09-01 19:45 GMT+02:00 Alex Soto > >:
>> Hello,  I have a blueprint bundle defined as:
>> 
>> >  xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0 
>> "
>>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance 
>> " 
>>  xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0 
>> "
>>  xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0 
>> "
>>  xsi:schemaLocation="
>>  http://www.osgi.org/xmlns/blueprint/v1.0.0 
>>  
>>  https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd 
>> ">
>> 
>>  > placeholder-suffix="]" />
>> 
>>  http://my.config.id/>" update-strategy="reload" placeholder-prefix="#{" 
>> placeholder-suffix="}">
>>  
>>  http://my.file.name/>" 
>> value="$[user.home]/.other/somefile" />
>>  
>>  
>>  
>>  
>>  http://my.file.name/>}" />
>>  
>>  
>> 
>> The $[user.home]  place holder is never substituted , so I get file not 
>> found error on file name "$[user.home]/.other/somefile"
>> I have search everywhere but I can’t figure out what I am doing wrong.
>> 
>> 
>> Best regards,
>> Alex soto
>> alex.s...@envieta.com 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> 
>> Guillaume Nodet
>> 
>> Red Hat, Open Source Integration
>> 
>> Email: gno...@redhat.com 
>> Web: http://fusesource.com 
>> Blog: http://gnodet.blogspot.com/ 
>> 
> 

Re: Bundles activating then immediately de-activating

[Christian Lutz]

Hello, 

I saw the same and mentioned it already in Issue with a reproducable example. I 
will post the issue number later. 

Christian

> Am 11.08.2016 um 17:19 schrieb Marc Durand :
> 
> Since upgrading to Karaf 4.0.5 (from 3.0.5) I've noticed that many of our
> bundles get activated and then immediately get de-activated.  Is this
> normal?  If not, how can I troubleshoot this problem in order to find the
> root cause?
> 
> We are using a custom distribution of Karaf...
> 
> Thanks,
> Marc
> 
> 
> 
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/Bundles-activating-then-immediately-de-activating-tp4047493.html
> Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Access control of OSGi Web app?

[Christian Lutz]

Hello,

Three months ago, we started to use keycloak for this purpose. In the first 
step we are using it only for authentication but in the second step we will 
also use it with all the rolles etc. 

Christian

> Am 01.08.2016 um 17:58 schrieb Nick Baker :
> 
> Is Shiro even active at this point?
>  
> We do some of what you’re looking for, but it’s all custom code. We have the 
> concept of logical permissions which can be bound to Users and/or Groups. Our 
> UI queries for these and uses the information to remove/disable UI elements. 
> As was mentioned though, you need to be doing the same checks on the 
> server-side or you’re going to get hacked.
>  
> -Nick
>  
> From: Jason Pratt 
> Reply-To: "user@karaf.apache.org" 
> Date: Monday, August 1, 2016 at 11:05 AM
> To: "user@karaf.apache.org" 
> Subject: Re: Access control of OSGi Web app?
>  
> Take a look at Shiro and JWT. You should be able to string something together 
> from that.
>  
> On Sun, Jul 31, 2016 at 11:08 PM, Sigmund Lee  wrote:
> Hi all,
>  
> Thanks for advice and solutions you guys provided.
>  
> Seems like they are all proper ways to protect server-side services. But as I 
> said we are a website, what I need is a solution can integrate frontend & 
> backend together, provide page-level access control. basically two steps 
> involved:
>  
> 1. A externalized access control system to protect access to exposed 
> services(for example, restful service, web url, etc).
> 2. After access is permitted, return corresponding respond page to 
> client(aka, browser), and every button or link on this responded page can be 
> display or hidden based on permissions of current user. 
>  
> Basically, what I need is a solution not only free backend engineers from 
> hard-coded authz code, but also free frontend engineers from hard-coding.
>  
> Thanks again!
>  
> Bests.
> --
> Sig 
>  
>  
>  
> On Fri, Jul 29, 2016 at 10:02 PM, Achim Nierbeck  
> wrote:
> yes, as filters without servlets can't be served. They don't have a URI 
> binding. 
>  
> regards, Achim 
>  
> 2016-07-29 15:33 GMT+02:00 Nick Baker :
> Hey Achim,
>  
> Thanks for this example. We’re looking part of our ongoing OSGi migration 
> will be URL security as well. We’re using Spring Security in the legacy 
> non-OSGI space. So this is a timely conversation for us J
>  
> Quick question: are we still working with the limitation that Filters are 
> only invoked if a Servlet or Resource would already serve the URL?
>  
> -Nick
>  
> From: Achim Nierbeck 
> Reply-To: "user@karaf.apache.org" 
> Date: Friday, July 29, 2016 at 8:54 AM
> To: "user@karaf.apache.org" 
> Subject: Re: Access control of OSGi Web app?
>  
> Hi Sigmund, 
>  
> sorry for being late to the party ... if those solutions above don't work for 
> you you still have the possibility to create a customized filter which you 
> can re-use with your own applications. 
> For this you can either go the "classical" way of using web-fragments, or you 
> can share the httpContext between your osgi bundles. For this you need to 
> declare your httpContext to be sharable and after that you just need to 
> attach your filter bundle to that sharable httpContext. 
>  
> Take a look at the following Sample, or better integration test of Pax Web 
> [1]. 
>  
> regards, Achim 
>  
> [1] - 
> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-itest/pax-web-itest-container/pax-web-itest-container-jetty/src/test/java/org/ops4j/pax/web/itest/jetty/CrossServiceIntegrationTest.java#L59-L95
>  
> 2016-07-26 16:05 GMT+02:00 Christian Schneider :
> In karaf authentication is based on JAAS. Using login modules you can define 
> what source to authenticate against.
> The karaf web console is protected by this by default. It is also possible to 
> enable JAAS based authentication for CXF e.g. for your REST services.
> There is also role based  and group based authentication out of the box.
> 
> There is no attribute based access control available but you can create this 
> based on the JAAS authentication.
> 
> This code can give you an idea of how to get the subject and the principals 
> from JAAS in karaf: 
> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-authz/src/main/java/org/apache/aries/blueprint/authorization/impl/AuthorizationInterceptor.java#L69-L81
> 
> You could create your own annotations or OSGi service to handle the attribute 
> based authorization based on the authentication information.
> 
> Christian
> 
> 
> On 26.07.2016 08:29, Sigmund Lee wrote:
> We are a website, using OSGi as microservices implementation. every feature 
> of our site is a standalone osgi-based webapp, and splited into several OSGi 
> bundles(api, impl, webapp, rest, etc). 
>  
> But there are functions that coupled with more that one bundle, for example 
> Access Control & Authorization. Currently our authorization code is 
> hard-coded everywhere and was so hard to maintain. 
>  
> My question is, what's the proper way to handle wi

Re: Problems with Karaf 4.0.5 vs. Karaf 4.0.4

[Christian Lutz]

Hello Michael,

there is an old related question in stack overflow.

http://stackoverflow.com/questions/1729307/spring-schemalocation-fails-when-there-is-no-internet-connection
 


if you can manipulate your .xsd files you may add classpath before your 
location e.g.
classpath:spring-context-2.1.xsd
in this case the local xsd file will be used. 
(As far as I understand this problem :)

So maybe in your case this helps.

Christian




> Am 11.07.2016 um 17:19 schrieb Michael Täschner :
> 
> Hi,
> 
> I have run into the same issue with ServiceMix 6.1.2 / Karaf 3.0.7 and added 
> a comment to the referenced jira issue. As we are operating our containers in 
> a backbone environment there is no internet access available, which makes 
> this issue critical for us. Strangely enough the referenced schema is located 
> in cxf-core/schemas/configuration/parameterized-types.xsd but is not read 
> from there ?!
> 
> Best Regards,
> Michael
> 
> 2016-07-06 15:46 GMT+02:00 kotoole  >:
> I am using felix.
> 
> 
> 
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/Problems-with-Karaf-4-0-5-vs-Karaf-4-0-4-tp4047129p4047134.html
>  
> 
> Sent from the Karaf - User mailing list archive at Nabble.com.
> 

Re: Problems with Karaf 4.0.5 vs. Karaf 4.0.4

[Christian Lutz]

Issue Karaf-4608. I do know that the exception is different. But I saw the same 
exception if the blueprint is different. 

Christian

> Am 06.07.2016 um 07:20 schrieb Jean-Baptiste Onofré :
> 
> Thanks Christian for the Jira,
> 
> I will take a look and fix in Blueprint (or downgrade for Karaf 4.0.6).
> 
> Regards
> JB
> 
>> On 07/06/2016 07:12 AM, Christian Lutz wrote:
>> I created a bug report for this yesterday. I dont have the issue number by 
>> hand. So just look in jira. I guess the problem is because of a chaning in 
>> aries blueprint 1.6.1.
>> 
>> Which framework did you use felix or equinox?
>> 
>>> Am 06.07.2016 um 05:43 schrieb kotoole :
>>> 
>>> With Karaf 4.0.5, it appears Internet access is required to resolve
>>> namespaces.
>>> 
>>> When Internet access is disabled, I receive the following error among
>>> others:
>>> 21:56:21,785 | WARN  |  1.6.1 |  | Dynamically adding namespace handler
>>> http://cxf.apache.org/configuration/parameterized-types to bundle xxx/1.0.0
>>> 21:56:42,778 | ERROR |  1.6.1 |  | Unable to start blueprint container for
>>> bundle xxx/1.0.0
>>> org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name
>>> 'pt:ParameterizedBoolean' to a(n) 'simpleType definition' component.
>>>at
>>> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
>>> Source)[:]
>>>at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)[:]
>>> 
>>> Also, I am unable to use shell commands using old schemas:
>>> org.xml.sax.SAXParseException: src-import.3.1: The namespace attribute,
>>> 'http://schemas.xmlsoap.org/wsdl/', of an  element information item
>>> must be identical to the targetNamespace attribute,
>>> 'http://karaf.apache.org/xmlns/shell/v1.1.0', of the imported document.
>>>at
>>> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
>>> Source)[:]
>>>at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)[:]
>>>at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)[:]
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context: 
>>> http://karaf.922171.n3.nabble.com/Problems-with-Karaf-4-0-5-vs-Karaf-4-0-4-tp4047129.html
>>> Sent from the Karaf - User mailing list archive at Nabble.com.
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Problems with Karaf 4.0.5 vs. Karaf 4.0.4

[Christian Lutz]

I created a bug report for this yesterday. I dont have the issue number by 
hand. So just look in jira. I guess the problem is because of a chaning in 
aries blueprint 1.6.1. 

Which framework did you use felix or equinox?

> Am 06.07.2016 um 05:43 schrieb kotoole :
> 
> With Karaf 4.0.5, it appears Internet access is required to resolve
> namespaces.
> 
> When Internet access is disabled, I receive the following error among
> others:
> 21:56:21,785 | WARN  |  1.6.1 |  | Dynamically adding namespace handler
> http://cxf.apache.org/configuration/parameterized-types to bundle xxx/1.0.0
> 21:56:42,778 | ERROR |  1.6.1 |  | Unable to start blueprint container for
> bundle xxx/1.0.0
> org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name
> 'pt:ParameterizedBoolean' to a(n) 'simpleType definition' component.
>at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)[:]
>at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)[:]
> 
> Also, I am unable to use shell commands using old schemas:
> org.xml.sax.SAXParseException: src-import.3.1: The namespace attribute,
> 'http://schemas.xmlsoap.org/wsdl/', of an  element information item
> must be identical to the targetNamespace attribute,
> 'http://karaf.apache.org/xmlns/shell/v1.1.0', of the imported document.
>at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)[:]
>at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)[:]
>at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)[:]
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/Problems-with-Karaf-4-0-5-vs-Karaf-4-0-4-tp4047129.html
> Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Unable to create Jira Issues

[Christian Lutz]

:)) But today is may 13 or where do you live?? :))

> Am 13.05.2016 um 13:55 schrieb Achim Nierbeck :
> 
> Jira is in Temporary Lockdown mode as a spam countermeasure. Only logged-in 
> users with active roles (committer, contributor, PMC, etc.) will be able to 
> create issues or comments during this time. Lockdown period from 11 May 2300 
> UTC to estimated 12 May 2300 UTC.
> 
> basically report your issues after may 12th then. 
> 
> regards, Achim
> 
> 2016-05-13 13:32 GMT+02:00 bartoszm :
>> Hi,
>> How can we than report issues while you are investigating ?
>> 
>> Bartosz
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://karaf.922171.n3.nabble.com/Unable-to-create-Jira-Issues-tp4046612p4046615.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
> 
> 
> 
> -- 
> 
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer & 
> Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 
> 
> Software Architect / Project Manager / Scrum Master 
> 

Unable to create Jira Issues

[Christian Lutz]

Good morning,

currently I am not able to create Jira Issues. Does anybody know when it is 
possible again?

Christian

Add feature to karaf .kar file

[Christian Lutz]

Hello,
 
I do have feature.xml as basic for my kar file.
 

http://karaf.apache.org/xmlns/features/v1.3.0";>
 
  cxf-rs-security-cors
  own-adapter-feature
  mvn:de.spray.server/server-orm/1.0.0
  mvn:de.spray.server/spray-server/1.0.0
 

 
I create the kar file with karaf-maven-plugin. 
 
 
   

 org.apache.karaf.tooling
karaf-maven-plugin
4.0.5
true

 false
 true
 true

   
  
 
 
I do have two different feature within my feature.xml cxf-rs-security-cors and 
own-adapter-feature. 
Is it somehow possible to add all bundles from the own-adapter-feature (but not 
from cxf-rs-security-cors ) into the kar file? I did expect that this should be 
possible with aggregateFeatures=true but nothing from own-adapter-feature or 
cxf-rs-security-cors  had been added. 
 
I also tried to add the feature as dependency within 
 

  
   de.spray
   own-adapter-feature
   features
   1.0.0
   xml
   runtime
  
 
 
But this didn't work either. I do know i could copy alle the dependencies into 
my own feature.xml but then I do have to care about to features.
 
Thanks
Christian
 
 

Re: javax/annotation/Priority is missing

[Christian Lutz]

Hello Micheal,

yes this fixed my problem. Is there a reason why this hasnt been fixed, 
already? Even I didnt find an issue for it. 

Christian. 

> Am 15.03.2016 um 17:31 schrieb Michael Täschner :
> 
> Hi Christian,
> 
> set javax.annotation to version 1.1 and it will resolve against the 
> annotation-spec provided by cxf features. The container provided packages are 
> not complete for JDK 1.8.
> 
> Ref: 
> http://karaf.922171.n3.nabble.com/Platform-packages-export-issue-with-Java-8-and-javax-annotation-td4041567.html
> 
> Cheers,
> Michael
> 
> 2016-03-15 12:09 GMT+01:00 Christian Lutz :
>> Hello,
>>  
>> I tried to use the cxf feature "cxf-rs-security-cors" like descripted here 
>> http://cxf.apache.org/docs/jax-rs-cors.html
>> But the blueprint does fail with the following error:
>>  
>> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to 
>> initialize bean publicAPI
>>  at 
>> org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:738)[27:org.apache.aries.blueprint.core:1.5.0]
>>  at 
>> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:848)[27:org.apache.aries.blueprint.core:1.5.0]
>>  at 
>> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:811)[27:org.apache.aries.blueprint.core:1.5.0]
>>  at 
>> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[27:org.apache.aries.blueprint.core:1.5.0]
>>  at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_45]
>>  at 
>> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[27:org.apache.aries.blueprint.core:1.5.0]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)[27:org.apache.aries.blueprint.core:1.5.0]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)[27:org.apache.aries.blueprint.core:1.5.0]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:712)[27:org.apache.aries.blueprint.core:1.5.0]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:399)[27:org.apache.aries.blueprint.core:1.5.0]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:273)[27:org.apache.aries.blueprint.core:1.5.0]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:294)[27:org.apache.aries.blueprint.core:1.5.0]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:263)[27:org.apache.aries.blueprint.core:1.5.0]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:253)[27:org.apache.aries.blueprint.core:1.5.0]
>>  at 
>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[37:org.apache.aries.util:1.1.1]
>>  at 
>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[37:org.apache.aries.util:1.1.1]
>>  at 
>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[37:org.apache.aries.util:1.1.1]
>>  at 
>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[37:org.apache.aries.util:1.1.1]
>>  at 
>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[37:org.apache.aries.util:1.1.1]
>>  at 
>> org.eclipse.osgi.internal.framework.EquinoxEventPublisher$2.call(EquinoxEventPublisher.java:189)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>>  at 
>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1280)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>>  at 
>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1263)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>>  at 
>> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.notifyEventHooksPrivileged(EquinoxEventPublisher.java:186)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>>  at 
>> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:146)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>>  at 
>> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBu

javax/annotation/Priority is missing

[Christian Lutz]

Hello,
 
I tried to use the cxf feature "cxf-rs-security-cors" like descripted here 
http://cxf.apache.org/docs/jax-rs-cors.html
But the blueprint does fail with the following error:
 
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to 
initialize bean publicAPI
 at 
org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:738)[27:org.apache.aries.blueprint.core:1.5.0]
 at 
org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:848)[27:org.apache.aries.blueprint.core:1.5.0]
 at 
org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:811)[27:org.apache.aries.blueprint.core:1.5.0]
 at 
org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[27:org.apache.aries.blueprint.core:1.5.0]
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_45]
 at 
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[27:org.apache.aries.blueprint.core:1.5.0]
 at 
org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)[27:org.apache.aries.blueprint.core:1.5.0]
 at 
org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)[27:org.apache.aries.blueprint.core:1.5.0]
 at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:712)[27:org.apache.aries.blueprint.core:1.5.0]
 at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:399)[27:org.apache.aries.blueprint.core:1.5.0]
 at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:273)[27:org.apache.aries.blueprint.core:1.5.0]
 at 
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:294)[27:org.apache.aries.blueprint.core:1.5.0]
 at 
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:263)[27:org.apache.aries.blueprint.core:1.5.0]
 at 
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:253)[27:org.apache.aries.blueprint.core:1.5.0]
 at 
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[37:org.apache.aries.util:1.1.1]
 at 
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[37:org.apache.aries.util:1.1.1]
 at 
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[37:org.apache.aries.util:1.1.1]
 at 
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[37:org.apache.aries.util:1.1.1]
 at 
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[37:org.apache.aries.util:1.1.1]
 at 
org.eclipse.osgi.internal.framework.EquinoxEventPublisher$2.call(EquinoxEventPublisher.java:189)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
 at 
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1280)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
 at 
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1263)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
 at 
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.notifyEventHooksPrivileged(EquinoxEventPublisher.java:186)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
 at 
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:146)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
 at 
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:75)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
 at 
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:67)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
 at 
org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:102)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
 at 
org.eclipse.osgi.container.Module.publishEvent(Module.java:466)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
 at 
org.eclipse.osgi.container.Module.start(Module.java:457)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
 at 
org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:393)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
 at 
org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:412)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
 at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1199)[7:org.apache.karaf.features.core:4.0.4]
 at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:840)[7:org.apache.karaf.features.core:4.0.4]
 at 
org.

set.default.KARAF_DATA is null

[Christian Lutz]

> Hello,
>  
> I think we found a small bug.
>  
> If you call wrapper:install from the karaf console everthing works fine.
> However if you call bin/shell "wrapper:install ..." the wrapper.conf is wrong.
>  
> #
> # Wrapper Properties
> #
> set.default.JAVA_HOME=C:\Program Files\inovel\merlin-server\bin\..\opt\jdk
> set.default.KARAF_HOME=C:\Program Files\inovel\merlin-server\bin\..
> set.default.KARAF_BASE=C:\Program Files\inovel\merlin-server\bin\..
> set.default.KARAF_DATA=null
> set.default.KARAF_ETC=C:\Program Files\inovel\merlin-server\bin\..\etc
>  
>  
> You see the the null, which is wrong.
> We tested this with the current karaf 4.0.4 and a karaf 3.0.x on Windows 7
>  
> best regards
> Christian
> 

Manual correction - dynamically wrapping jars

[Christian Lutz]

Hello, 

there are some small mistakes in the latest manual, for dynamically wrapping 
jars.

——
root@karaf> bundle:install wrap:mvn:commons-lang/commons-lang/2.4
The wrap protocol creates a bundle dynamically using the bnd. Confiugurations 
can be added in the wrap URL:

from the shell

root@karaf> bundle:install 
'wrap:mvn:commons-lang/commons-lang/2.4$Bundle-SymbolicName=commons-lang&Bundle-Version=2.4'
from feature.xml

wrap:mvn:commons-lang/commons-lang/2.4$Bundle-SymbolicName=commons-lang&Bundle-Version=2.4
— — 
Christian

Questions from update to karaf 4.0.2

[Christian Lutz]

Hello,

today I started to update from karat 3.0.5 to 4.0.2 in this process I stumbled 
across some questions you may be able to answer.

1. What is the correct replacement for the deprecated OsgiCommandSupport class?

2. The feature standard is not available anymore within the 
current org.apache.karaf.features.standard.xml, is it intended or a bug? 
If intended please update you minimal help distribution example 
http://karaf.apache.org/manual/latest/developers-guide/custom-distribution.html 


3. I asked a question on stackoverflow, what is your preferred channel for 
questions?
http://stackoverflow.com/questions/33626713/how-to-disable-karaf-maven-plugin-4-tight-dependency-constraint-checks
 


Sincerely
Christian

Env: Windows, JDK8, Maven 3.3.3