Re: Karaf 4.0.5: bundle:info only shows bundle name (id)

[Allan C.]

Hi Archim, Thank you!

Regards,
Allan C.

On Wed, Jul 13, 2016 at 1:05 PM, Achim Nierbeck 
wrote:

> Hi,
>
> bundle:list -l will give you the required information.
>
> regards, Achim
>
>
> 2016-07-13 2:46 GMT+02:00 Allan C. :
>
>> Hi,
>>
>> I need to know the location of a bundle in the file system. I looked into
>> the karaf commands that are available and "bundle:info" seems like it. But
>> the information returned is the name and id of the bundle only.
>>
>> For instance:
>> karaf@root()> bundle:info 102
>>
>> camel-jpa (102)
>> ---
>> karaf@root()>
>>
>> This is also the same for my custom bundles. Am I missing something in my
>> setup or there are other commands that I should use?
>>
>> Regards,
>> Allan C.
>>
>
>
>
> --
>
> 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
>
>

Re: Karaf 4.0.5 - Jetty features different versions: pax-jetty and jetty

[Achim Nierbeck]

The jetty feature is actually a duplicate feature ... it's required since a
couple other upstream projects still depend on the jetty feature.
The don't depend on each other, if you want to use jetty just for your
webapplications, use the war or http features, those will delegate to the
corresponding pax web features. As Jetty is the default container for pax
web you don't need to install it prior to installing other features. If you
want to use another container instead make sure you did install undertow
for example prior to installing the other pax-web features.

regards, Achim


2016-07-13 4:56 GMT+02:00 Allan C. :

> Hi JB,
>
> Just seeking clarifications.
>
> 1. When you say jetty is an alias feature, what does alias feature means?
>
> 2. Is it safe to say pax-jetty depends on jetty and not the other way
> round?
>
> Thanks in advance.
>
> Regards,
> Allan C.
>
> On Tue, Jul 5, 2016 at 9:01 AM, Allan C.  wrote:
>
>> Noted. Thanks.
>>
>> Regards,
>> Allan C.
>>
>> On Tue, Jul 5, 2016 at 3:40 AM, Jean-Baptiste Onofré 
>> wrote:
>>
>>> Thanks Allan,
>>>
>>> jetty is an alias feature on top of pax-jetty (for backward
>>> compatibility).
>>>
>>> Definitely, we upgraded in pax-web, but forgot to update the jetty alias
>>> feature.
>>>
>>> Let me create a Jira to fix that.
>>>
>>> Thanks !
>>> Regards
>>> JB
>>>
>>> On 07/04/2016 10:20 AM, Allan C. wrote:
>>>
 I am playing around with 4.0.5 and I noticed that the versions for the
 jetty and pax-jetty are different. In Fuse 6.2.1 (I think it is based on
 Karaf 2.4.0), the versions are the same.

 JBossFuse:karaf@root> features:list | grep jetty
 [installed  ] [*8.1.17.v20150415* ] jetty
karaf-2.4.0.redhat-621084
  Provide Jetty engine support
 [installed  ] [2.15.1.redhat-621084 ] camel-jetty
  camel-2.15.1.redhat-621084

 [uninstalled] [2.15.1.redhat-621084 ] camel-jetty9
 camel-2.15.1.redhat-621084

 [installed  ] [*8.1.17.v20150415* ] pax-jetty
org.ops4j.pax.web-3.2.5
  Provide Jetty engine support
 [installed  ] [3.0.4.redhat-621084  ] cxf-http-jetty
 cxf-3.0.4.redhat-621084

 Karaf 4.0.5:

 karaf@root(feature)> list | grep jetty
 jetty   | *9.2.10.v20150310* |
   | Started | standard-4.0.5  |
 jetty   | 8.1.14.v20131031 |  |
 Uninstalled | standard-4.0.5  |
 cxf-http-jetty  | 3.1.5|  |
 Started | cxf-3.1.5   |
 pax-jetty   | *9.2.15.v20160210* |
   | Started | org.ops4j.pax.web-4.2.6 | Provide Jetty engine
 support
 pax-jetty-spdy  | 4.2.6|  |
 Uninstalled | org.ops4j.pax.web-4.2.6 | Optional additional feature
 to run Jetty with SPDY
 pax-http-jetty  | 4.2.6|  |
 Started | org.ops4j.pax.web-4.2.6 |
 camel-jetty | 2.16.3   |  |
 Uninstalled | camel-2.16.3|
 camel-jetty9| 2.16.3   |  |
 Started | camel-2.16.3|
 karaf@root(feature)>

 Would it be a concern?

 Regards,
 Allan C.

>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.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

Re: Karaf 4.0.5: bundle:info only shows bundle name (id)

[Achim Nierbeck]

Hi,

bundle:list -l will give you the required information.

regards, Achim


2016-07-13 2:46 GMT+02:00 Allan C. :

> Hi,
>
> I need to know the location of a bundle in the file system. I looked into
> the karaf commands that are available and "bundle:info" seems like it. But
> the information returned is the name and id of the bundle only.
>
> For instance:
> karaf@root()> bundle:info 102
>
> camel-jpa (102)
> ---
> karaf@root()>
>
> This is also the same for my custom bundles. Am I missing something in my
> setup or there are other commands that I should use?
>
> Regards,
> Allan C.
>



-- 

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

Re: Karaf 4.0.5 - Jetty features different versions: pax-jetty and jetty

[Allan C.]

Hi JB,

Just seeking clarifications.

1. When you say jetty is an alias feature, what does alias feature means?

2. Is it safe to say pax-jetty depends on jetty and not the other way round?

Thanks in advance.

Regards,
Allan C.

On Tue, Jul 5, 2016 at 9:01 AM, Allan C.  wrote:

> Noted. Thanks.
>
> Regards,
> Allan C.
>
> On Tue, Jul 5, 2016 at 3:40 AM, Jean-Baptiste Onofré 
> wrote:
>
>> Thanks Allan,
>>
>> jetty is an alias feature on top of pax-jetty (for backward
>> compatibility).
>>
>> Definitely, we upgraded in pax-web, but forgot to update the jetty alias
>> feature.
>>
>> Let me create a Jira to fix that.
>>
>> Thanks !
>> Regards
>> JB
>>
>> On 07/04/2016 10:20 AM, Allan C. wrote:
>>
>>> I am playing around with 4.0.5 and I noticed that the versions for the
>>> jetty and pax-jetty are different. In Fuse 6.2.1 (I think it is based on
>>> Karaf 2.4.0), the versions are the same.
>>>
>>> JBossFuse:karaf@root> features:list | grep jetty
>>> [installed  ] [*8.1.17.v20150415* ] jetty
>>>karaf-2.4.0.redhat-621084
>>>  Provide Jetty engine support
>>> [installed  ] [2.15.1.redhat-621084 ] camel-jetty
>>>  camel-2.15.1.redhat-621084
>>>
>>> [uninstalled] [2.15.1.redhat-621084 ] camel-jetty9
>>> camel-2.15.1.redhat-621084
>>>
>>> [installed  ] [*8.1.17.v20150415* ] pax-jetty
>>>org.ops4j.pax.web-3.2.5
>>>  Provide Jetty engine support
>>> [installed  ] [3.0.4.redhat-621084  ] cxf-http-jetty
>>> cxf-3.0.4.redhat-621084
>>>
>>> Karaf 4.0.5:
>>>
>>> karaf@root(feature)> list | grep jetty
>>> jetty   | *9.2.10.v20150310* |
>>>   | Started | standard-4.0.5  |
>>> jetty   | 8.1.14.v20131031 |  |
>>> Uninstalled | standard-4.0.5  |
>>> cxf-http-jetty  | 3.1.5|  |
>>> Started | cxf-3.1.5   |
>>> pax-jetty   | *9.2.15.v20160210* |
>>>   | Started | org.ops4j.pax.web-4.2.6 | Provide Jetty engine
>>> support
>>> pax-jetty-spdy  | 4.2.6|  |
>>> Uninstalled | org.ops4j.pax.web-4.2.6 | Optional additional feature
>>> to run Jetty with SPDY
>>> pax-http-jetty  | 4.2.6|  |
>>> Started | org.ops4j.pax.web-4.2.6 |
>>> camel-jetty | 2.16.3   |  |
>>> Uninstalled | camel-2.16.3|
>>> camel-jetty9| 2.16.3   |  |
>>> Started | camel-2.16.3|
>>> karaf@root(feature)>
>>>
>>> Would it be a concern?
>>>
>>> Regards,
>>> Allan C.
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>

Karaf 4.0.5: bundle:info only shows bundle name (id)

[Allan C.]

Hi,

I need to know the location of a bundle in the file system. I looked into
the karaf commands that are available and "bundle:info" seems like it. But
the information returned is the name and id of the bundle only.

For instance:
karaf@root()> bundle:info 102

camel-jpa (102)
---
karaf@root()>

This is also the same for my custom bundles. Am I missing something in my
setup or there are other commands that I should use?

Regards,
Allan C.

Re: Best way to intercept "shutdown" command

[Martin Lichtin]

A bundle listener can be used, but one needs to use the 
"SynchronousBundleListener" interface.
Only with this interface does one receive the 'STOPPING' events.

On 11.07.2016 16:22, Martin Lichtin wrote:

Hi All

What is the best approach to intercept the Karaf "shutdown" command, before it 
starts shutting down any bundles?
Karaf does a getBundle(0).stop() on receiving a "shutdown" command.

There's no FrameworkEvent raised on bundle(0).stop afaics.
A bundle listener on bundle 0 should work, but does not seem to, it's not 
called with a STOPPING or STOPPED event.

I do see the event in the log as the first thing after "shutdown":

2016-07-11 16:02:17,096 | DEBUG | FelixShutdown| framework  
  | 0 - org.apache.felix.framework - 4.2.1 | BundleEvent STOPPING - 
org.apache.felix.framework

However that event never makes it to my bundle listener.

Any help appreciated :)
- Martin

Re: Karaf 4.0.3 ACL group in group not working

[Jean-Baptiste Onofré]

Thanks for the update Christian. Sorry, I wasn't able to get back to you 
early (busy with a customer).


Good to know and thanks again for sharing.

Regards
JB

On 07/12/2016 05:23 PM, Christian wrote:

Lookl like my property based login configuration is not really usable to
reproduce my issue. I found a specific Active Directory Solution which fits
to my requirements.

I added a matching rule in the LDAP login module configuration. It looks
like this:


http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0;

xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0;>



initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory
connection.username=***
connection.password=***
connection.protocol=
connection.url=ldap://***:389
user.base.dn=OU=NeastedGroupsTest,DC=test,DC=***,DC=***
user.filter=(sAMAccountName=%u)
user.search.subtree=true
role.base.dn=OU=NeastedGroupsTest,DC=test,DC=***,DC=***
role.name.attribute=cn
role.filter=(member:1.2.840.113556.1.4.1941:=%fqdn)
role.search.subtree=true
role.mapping =
neastedGroupAdmin=admin;neastedGroupManager=manager;neastedGroupViewer=viewer




The magic is done by the member filter with the ":1.2.840.113556.1.4.1941:".
then it works with neasted groups.

With best regards
Christian



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-4-0-3-ACL-group-in-group-not-working-tp4047197p4047206.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: Karaf 4.0.3 ACL group in group not working

[Christian]

Lookl like my property based login configuration is not really usable to
reproduce my issue. I found a specific Active Directory Solution which fits
to my requirements. 

I added a matching rule in the LDAP login module configuration. It looks
like this:

 
http://www.osgi.org/xmlns/blueprint/v1.0.0;
   xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0;
  
xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0;>



   initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory
   connection.username=***
   connection.password=***
   connection.protocol=
   connection.url=ldap://***:389
   user.base.dn=OU=NeastedGroupsTest,DC=test,DC=***,DC=***
   user.filter=(sAMAccountName=%u)
   user.search.subtree=true
   role.base.dn=OU=NeastedGroupsTest,DC=test,DC=***,DC=***
   role.name.attribute=cn
   role.filter=(member:1.2.840.113556.1.4.1941:=%fqdn)
   role.search.subtree=true
   role.mapping = 
neastedGroupAdmin=admin;neastedGroupManager=manager;neastedGroupViewer=viewer




The magic is done by the member filter with the ":1.2.840.113556.1.4.1941:".
then it works with neasted groups.

With best regards
Christian



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-4-0-3-ACL-group-in-group-not-working-tp4047197p4047206.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Bengt Rodehav]

OK - thanks for trying.

/Bengt

2016-07-12 11:12 GMT+02:00 Achim Nierbeck :

> Hi Bengt,
>
> sorry been very busy lately. I did give it a try but couldn't find a
> reason why Log4j2 should be used or Pax Logging should be triggered to be
> restarted. There isn't any reason for the pax web bundles to do so ... :/
> sorry didn't get any further on this ..
>
> regards, Achim
>
>
>
>
> 2016-07-11 14:47 GMT+02:00 Bengt Rodehav :
>
>> Did you have a chance to look at this Achim? If there is a problem with
>> the pax-jetty feature it would be nice to have it fixed in Karaf 4.0.6
>> which I understand is in the works.
>>
>> /Bengt
>>
>> 2016-07-07 9:13 GMT+02:00 Bengt Rodehav :
>>
>>> OK - thanks Achim,
>>>
>>> /Bengt
>>>
>>> 2016-07-06 22:08 GMT+02:00 Achim Nierbeck :
>>>
 Hi Bengt,

 I'll try to find out if one of the bundles in that feature depends on
 log4j2 ... but I'm not aware of such a dependency.

 Your suspicion about dynamic loading of DLLs is correct in case of the
 location of the dll is inside of a bundle and does have dependencies to
 another dll. If it's a dll loaded via the root classloader that shouldn't
 be of an issue.

 regards, Achim


 2016-07-04 16:04 GMT+02:00 Bengt Rodehav :

> Another theory: Looking at the stack trace this seems to be triggered
> by a configuration update. Could the problem be that Pax-logging is trying
> to load the DLL again and failing since it is already loaded? Perhaps the
> initial load works but subsequent configuration updates does not?
>
> I tried to verify this...
>
> After successful start of Karaf (after step 9 in my previous post), I
> edit org.ops4j.pas.logging.cfg (by changing the root logger between INFO
> and DEBUG). This causes no error.
>
> But after having installed feature pax-jetty (after step 10 in my
> previous post), every change in org.ops4j.pas.logging.cfg causes the same
> error to appear (the stack trace included in my previous post).
>
> It's as if installing the pax-jetty feature takes gives control of
> org.ops4j.pas.logging.cfg to someone who cannot load the DLL. I have no
> idea how this could happen.
>
> Anyone else has an idea?
>
> /Bengt
>
>
>
>
>
>
>
> /Bengt
>
> 2016-07-04 15:51 GMT+02:00 Bengt Rodehav :
>
>> A theory: Could one of the bundles installed by feature pax-jetty be
>> using log4j 2.x directly without using Pax-logging? If so, would it too 
>> try
>> to read the log4j configuration file? I guess it would fail to load the 
>> DLL
>> since it is probably not compatible with log4j 2.x.
>>
>> Could this happen? If so, how can I find out which bundle?
>>
>> /Bengt
>>
>> 2016-07-04 15:15 GMT+02:00 Bengt Rodehav :
>>
>>> Back to the Karaf mailing list
>>>
>>> I can actually get this problem on a standard vanilla Karaf 4.0.5.
>>> It seems to be triggered when installing the feature pax-jetty.
>>>
>>> *1. Install standard Karaf 4.0.5*
>>>
>>> *2. Replace org.ops4j.pax.logging.cfg with the following:*
>>>
>>> log4j.rootLogger=INFO, stdout
>>>
>>> # CONSOLE appender
>>> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>>> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>>> log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} | %-5.5p
>>> | %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
>>> log4j.appender.stdout.threshold=ERROR
>>>
>>> # Windows event log
>>> log4j.appender.nteventlog=org.apache.log4j.nt.NTEventLogAppender
>>> log4j.appender.nteventlog.source=Test source
>>> log4j.appender.nteventlog.layout=org.apache.log4j.PatternLayout
>>> log4j.appender.nteventlog.layout.ConversionPattern=Time:
>>> %d{ISO8601}%n%nSeverity: %p%n%nThread: %t%n%n%m%n
>>> log4j.appender.nteventlog.threshold=DEBUG
>>>
>>> *3. Start Karaf: "bin\karaf clean"*
>>>
>>> This should work.
>>>
>>> *4. Exit Karaf*
>>>
>>> *5. Change the root looger line to:*
>>>
>>> log4j.rootLogger=INFO, stdout, nteventlog
>>>
>>> *6. Start Karaf again*
>>>
>>> I get the following error:
>>>
>>> 2016-07-04 15:05:39,534 | ERROR | s4j.pax.logging) | configadmin
>>>  | ?? | [org.osgi.service.log.LogService,
>>> org.knopflerfish.service.log.LogService,
>>> org.ops4j.pax.logging.PaxLoggingService,
>>> org.osgi.service.cm.ManagedService, id=12,
>>> bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]: 
>>> Unexpected
>>> problem updating configuration org.ops4j.pax.logging
>>> java.lang.UnsatisfiedLinkError: no NTEventLogAppender in
>>> 

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Achim Nierbeck]

Hi Bengt,

sorry been very busy lately. I did give it a try but couldn't find a reason
why Log4j2 should be used or Pax Logging should be triggered to be
restarted. There isn't any reason for the pax web bundles to do so ... :/
sorry didn't get any further on this ..

regards, Achim




2016-07-11 14:47 GMT+02:00 Bengt Rodehav :

> Did you have a chance to look at this Achim? If there is a problem with
> the pax-jetty feature it would be nice to have it fixed in Karaf 4.0.6
> which I understand is in the works.
>
> /Bengt
>
> 2016-07-07 9:13 GMT+02:00 Bengt Rodehav :
>
>> OK - thanks Achim,
>>
>> /Bengt
>>
>> 2016-07-06 22:08 GMT+02:00 Achim Nierbeck :
>>
>>> Hi Bengt,
>>>
>>> I'll try to find out if one of the bundles in that feature depends on
>>> log4j2 ... but I'm not aware of such a dependency.
>>>
>>> Your suspicion about dynamic loading of DLLs is correct in case of the
>>> location of the dll is inside of a bundle and does have dependencies to
>>> another dll. If it's a dll loaded via the root classloader that shouldn't
>>> be of an issue.
>>>
>>> regards, Achim
>>>
>>>
>>> 2016-07-04 16:04 GMT+02:00 Bengt Rodehav :
>>>
 Another theory: Looking at the stack trace this seems to be triggered
 by a configuration update. Could the problem be that Pax-logging is trying
 to load the DLL again and failing since it is already loaded? Perhaps the
 initial load works but subsequent configuration updates does not?

 I tried to verify this...

 After successful start of Karaf (after step 9 in my previous post), I
 edit org.ops4j.pas.logging.cfg (by changing the root logger between INFO
 and DEBUG). This causes no error.

 But after having installed feature pax-jetty (after step 10 in my
 previous post), every change in org.ops4j.pas.logging.cfg causes the same
 error to appear (the stack trace included in my previous post).

 It's as if installing the pax-jetty feature takes gives control of
 org.ops4j.pas.logging.cfg to someone who cannot load the DLL. I have no
 idea how this could happen.

 Anyone else has an idea?

 /Bengt







 /Bengt

 2016-07-04 15:51 GMT+02:00 Bengt Rodehav :

> A theory: Could one of the bundles installed by feature pax-jetty be
> using log4j 2.x directly without using Pax-logging? If so, would it too 
> try
> to read the log4j configuration file? I guess it would fail to load the 
> DLL
> since it is probably not compatible with log4j 2.x.
>
> Could this happen? If so, how can I find out which bundle?
>
> /Bengt
>
> 2016-07-04 15:15 GMT+02:00 Bengt Rodehav :
>
>> Back to the Karaf mailing list
>>
>> I can actually get this problem on a standard vanilla Karaf 4.0.5. It
>> seems to be triggered when installing the feature pax-jetty.
>>
>> *1. Install standard Karaf 4.0.5*
>>
>> *2. Replace org.ops4j.pax.logging.cfg with the following:*
>>
>> log4j.rootLogger=INFO, stdout
>>
>> # CONSOLE appender
>> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>> log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} | %-5.5p |
>> %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
>> log4j.appender.stdout.threshold=ERROR
>>
>> # Windows event log
>> log4j.appender.nteventlog=org.apache.log4j.nt.NTEventLogAppender
>> log4j.appender.nteventlog.source=Test source
>> log4j.appender.nteventlog.layout=org.apache.log4j.PatternLayout
>> log4j.appender.nteventlog.layout.ConversionPattern=Time:
>> %d{ISO8601}%n%nSeverity: %p%n%nThread: %t%n%n%m%n
>> log4j.appender.nteventlog.threshold=DEBUG
>>
>> *3. Start Karaf: "bin\karaf clean"*
>>
>> This should work.
>>
>> *4. Exit Karaf*
>>
>> *5. Change the root looger line to:*
>>
>> log4j.rootLogger=INFO, stdout, nteventlog
>>
>> *6. Start Karaf again*
>>
>> I get the following error:
>>
>> 2016-07-04 15:05:39,534 | ERROR | s4j.pax.logging) | configadmin
>>  | ?? | [org.osgi.service.log.LogService,
>> org.knopflerfish.service.log.LogService,
>> org.ops4j.pax.logging.PaxLoggingService,
>> org.osgi.service.cm.ManagedService, id=12,
>> bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]: Unexpected
>> problem updating configuration org.ops4j.pax.logging
>> java.lang.UnsatisfiedLinkError: no NTEventLogAppender in
>> java.library.path
>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
>> at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>> at java.lang.System.loadLibrary(System.java:1122)
>> at
>> 

Re: Problems with Karaf 4.0.5 vs. Karaf 4.0.4

[Michael Täschner]

Hi Christian,

unfortunately this is not under my control. The referenced type ("
pt:ParameterizedBoolean") and the corresponding namespace are not actually
configured by me but seem to be used internally. This made the issue even
more irritating ...

Thanks and Best Regards,
Michael

2016-07-11 18:15 GMT+02:00 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
>> .
>>
>
>
>