[jira] [Updated] (KARAF-4802) Auto Deploy does not release resource
[
https://issues.apache.org/jira/browse/KARAF-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frederic ARNOUD updated KARAF-4802:
---
Description:
*Calling getLastModified() opens the input stream.*
In org.apache.karaf.deployer.blueprint-4.0.7-sources.jar:
org/apache/karaf/deployer/blueprint/BlueprintTransformer.java:94:
{{url.openConnection().getLastModified()}}
=> calls
{{sun.net.www.protocol.file.FileURLConnection#getLastModified()}}
=> calls
{{sun.net.www.protocol.file.FileURLConnection#initializeHeaders()}}
=> calls
{{sun.net.www.protocol.file.FileURLConnection#connect()}}
in this function at line 57: {{this.connected}} is
{{false}}
and line 61: {{this.isDirectory}} is {{false}}
*Here they open the input stream:*
error source is at line 69: open input stream and keep
it in this.is
_Note:_
There's a mistake at line (since they try to open the stream):
sun/net/www/protocol/file/FileURLConnection.java:90 with a nice empty
try/catch!
AFAIK, there's no way to know if stream was open or not.
I checked {{HttpURLConnection}}, it does the same (and {{HttpsURLConnection}}
also).
*IMHO you should add a function like this one (in BlueprintTransformer.java):*
{code:java}
protected static long getLastModified(URL url) throws IOException {
URLConnection urlConnection = url.openConnection();
try(InputStream is = urlConnection.getInputStream()) {
return urlConnection.getLastModified();
}
}
{code}
To limit number of stream access, I did this in my code (in function similar to
{{transform(URL, OutputStream)}}):
{code:java}
final URLConnection urlConnection = url.openConnection();
// keep original last modification date
final long lastModified = urlConnection.getLastModified();
try (InputStream in = urlConnection.getInputStream()) {
source = readAllBytes(in);
}
{code}
*Note:*
When no object reference the InputStream, {{InputStream}} class will
automatically close the stream while processing finalizations.
Before this process, we cannot delete file in deploy directory.
(sorry I did not find component for this class)
Same issue should appear in other deployers (not checked).
was:
*Calling getLastModified() opens the input stream.*
In org.apache.karaf.deployer.blueprint-4.0.7-sources.jar:
org/apache/karaf/deployer/blueprint/BlueprintTransformer.java:94:
{{url.openConnection().getLastModified()}}
=> call
{{sun.net.www.protocol.file.FileURLConnection#getLastModified()}}
=> call
{{sun.net.www.protocol.file.FileURLConnection#initializeHeaders()}}
=> call
{{sun.net.www.protocol.file.FileURLConnection#connect()}}
line 57: {{this.connected}} is {{false}}
line 61: {{this.isDirectory}} is {{false}}
*Here they open the input stream:*
line 69: open input stream and keep it in this.is
_Note:_
Bad code at line (since they try to open the stream):
sun/net/www/protocol/file/FileURLConnection.java:90 with a nice empty
try/catch!
AFAIK, there's no way to know if stream was open or not.
I checked {{HttpURLConnection}}, it does the same (and {{HttpsURLConnection}}
also).
*IMHO you should add a function like this one:*
{code:java}
protected static long getLastModified(URL url) throws IOException {
URLConnection urlConnection = url.openConnection();
try(InputStream is = urlConnection.getInputStream()) {
return urlConnection.getLastModified();
}
}
{code}
To avoid risk to open remote stream twice, I did this in my code (in function
similar to {{transform(URL, OutputStream)}}):
{code:java}
final URLConnection urlConnection = url.openConnection();
// keep original last modification date
final long lastModified = urlConnection.getLastModified();
try (InputStream in = urlConnection.getInputStream()) {
source = readAllBytes(in);
}
{code}
*Note:*
Since no object reference the InputStream, InputStream class will automatically
close the stream while processing the finalization.
Before this process, we cannot delete file in deploy directory.
(sorry I did not find component for this class)
Same issue should appear in other deployer (not checked).
> Auto Deploy does not release resource
> -
>
> Key: KARAF-4802
> URL: https://issues.apache.org/jira/browse/KARAF-4802
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
>Affects Versions: 4.0.5, 4.0.7
> Environment: JDK 1.8.0_102 / Win10 (x64)
>Reporter: Frederic ARNOUD
[jira] [Commented] (KARAF-4487) LDAPLoginModule and GSSAPI
[ https://issues.apache.org/jira/browse/KARAF-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15601565#comment-15601565 ] ASF GitHub Bot commented on KARAF-4487: --- GitHub user acartapanis opened a pull request: https://github.com/apache/karaf/pull/254 Gssapi A GSSAPI login module. Only tested with Kerberos authentication. Typically allows to use an Active Directory Server with Kerberos Authentication as LDAP backend. https://issues.apache.org/jira/browse/KARAF-4487 You can merge this pull request into a Git repository by running: $ git pull https://github.com/acartapanis/karaf gssapi Alternatively you can review and apply these changes as the patch at: https://github.com/apache/karaf/pull/254.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #254 commit 33dc1f4c61a0bc398d3c719b42ed32b1829ea432 Author: alexandre.cartapa...@gmail.com Date: 2016-08-24T10:35:10Z Add support for GSSAPI authentication. Fix for KARAF-4487 commit 97416ac907f5223f51b05bd9e26ff45e1f1eb077 Author: alexandre.cartapa...@gmail.com Date: 2016-08-24T12:21:22Z Correction commit bf8f93bf93f598b4daa669ee9568afdda0f3d973 Author: alexandre.cartapa...@gmail.com Date: 2016-08-29T13:11:13Z Correction commit 80f7b75dc2c0d2fbc320b42d21d8304405736c04 Author: alexandre.cartapa...@gmail.com Date: 2016-08-29T13:42:26Z Correction commit cf963606381f344049248d7c4e058380094bee34 Author: alexandre.cartapa...@gmail.com Date: 2016-10-24T10:22:50Z Correction: adds KerberosPrincipal to the principals list commit c63375ceb8c044f40acb4af4b1cdc732aca4b2a4 Author: alexandre.cartapa...@gmail.com Date: 2016-10-24T10:23:17Z Working tests > LDAPLoginModule and GSSAPI > -- > > Key: KARAF-4487 > URL: https://issues.apache.org/jira/browse/KARAF-4487 > Project: Karaf > Issue Type: Improvement > Components: karaf-security >Affects Versions: 4.0.4 >Reporter: Alexandre Cartapanis > > LDAPLoginModule is restricted to "simple" or "none" authentication. A support > for other method like GSSAPI would be great. > Note that it is a common enterprise context : access to LDAP directory is not > made with username/password but through an other realm (a kerberos one for > exemple) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (KARAF-4487) LDAPLoginModule and GSSAPI
[ https://issues.apache.org/jira/browse/KARAF-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Cartapanis updated KARAF-4487: Comment: was deleted (was: https://github.com/apache/karaf/pull/254) > LDAPLoginModule and GSSAPI > -- > > Key: KARAF-4487 > URL: https://issues.apache.org/jira/browse/KARAF-4487 > Project: Karaf > Issue Type: Improvement > Components: karaf-security >Affects Versions: 4.0.4 >Reporter: Alexandre Cartapanis > > LDAPLoginModule is restricted to "simple" or "none" authentication. A support > for other method like GSSAPI would be great. > Note that it is a common enterprise context : access to LDAP directory is not > made with username/password but through an other realm (a kerberos one for > exemple) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4487) LDAPLoginModule and GSSAPI
[ https://issues.apache.org/jira/browse/KARAF-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15601566#comment-15601566 ] Alexandre Cartapanis commented on KARAF-4487: - https://github.com/apache/karaf/pull/254 > LDAPLoginModule and GSSAPI > -- > > Key: KARAF-4487 > URL: https://issues.apache.org/jira/browse/KARAF-4487 > Project: Karaf > Issue Type: Improvement > Components: karaf-security >Affects Versions: 4.0.4 >Reporter: Alexandre Cartapanis > > LDAPLoginModule is restricted to "simple" or "none" authentication. A support > for other method like GSSAPI would be great. > Note that it is a common enterprise context : access to LDAP directory is not > made with username/password but through an other realm (a kerberos one for > exemple) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4564) Can't start karaf using symbolic link
[
https://issues.apache.org/jira/browse/KARAF-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15601614#comment-15601614
]
Martin Lichtin commented on KARAF-4564:
---
As mentioned, I'd think it's ok to require "coreutils" in order to run Karaf on
AIX?
{noformat}
~> rpm -qlv coreutils-5.2.1-2 | grep readlink
-rwxr-xr-x root system21503 Jan 26 2006
/opt/freeware/bin/readlink
-rw-r--r-- root system 1393 Jan 26 2006
/opt/freeware/man/man1/readlink.1
lrwxrwxrwx root system 34 Jan 26 2006 /usr/linux/bin/readlink
-> ../../../opt/freeware/bin/readlink
{noformat}
Karaf startup works fine for me after adding {{/usr/linux/bin}} to PATH.
> Can't start karaf using symbolic link
> --
>
> Key: KARAF-4564
> URL: https://issues.apache.org/jira/browse/KARAF-4564
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 3.0.6
> Environment: Ubuntu (Linux vagrant 3.19.0-25-generic
> #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64
> GNU/Linux)
> OSX (Darwin inocybe.local 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1
> 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64)
> Solaris (SunOS solaris11.3 5.11 11.3 i86pc i386 i86pc)
>Reporter: Alexis de Talhouët
> Fix For: 4.1.0, 3.0.7, 4.0.6
>
>
> When using a symbolic link to use the scripts defined here:
> https://github.com/apache/karaf/tree/karaf-3.0.6/assemblies/features/framework/src/main/filtered-resources/resources/bin
> e.g. karaf or client and so on, it's failing to start the container and show
> this error:
> Error: Could not find or load main class org.apache.karaf.main.Main
> This issue is related to the DIRNAME variable and the way it is setup.
> This bug has been found in OpenDaylight, here is the ticket with more
> information https://bugs.opendaylight.org/show_bug.cgi?id=6027
> I have also propose a candidate fix in ODL:
> https://git.opendaylight.org/gerrit/#/c/39982/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-3147) Local JMX connect is not possible
[
https://issues.apache.org/jira/browse/KARAF-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15602088#comment-15602088
]
Sebastien Petrucci commented on KARAF-3147:
---
Hello,
We are currently hardening the security on our set of products embedding JBoss
Fuse (6.3) and we also have an issue with the security bypass that was
introduced.
We are putting in place a set of controls to make sure that the operator owning
the JBoss Fuse installation (read, the OS account running JBoss Fuse) can
start/stop JBoss Fuse, but *cannot* install new/updated bundles without
providing additionnal credentials (not related to the OS account). Outside of
the JVM, we also have a native process that regularly ensures that the JBoss
Fuse installation does not get tampered with manually (system bundles not
modified, config not changed, no change in the JVM binaries, ...).
Because of the security bypass, the operator owning the OS account can simply
fire JConsole and do whatever he wants to. Our other security controls should
come into play and prevent harmful operations but this is not a risk that we
are willing to take, especially that it would be very costly to test each and
every possibility :-)
Unfortunately, we cannot simply turn off JMX altogether because we have other
processes (authenticated ;-) connecting through a remote JMX connection to
perform some critical operations. We would rather completely get rid of the
local JMX access but it seems like it is not possible to activate the JMX
remote access while deactivating local access (understand, connect via PID).
Note that we opened a case with Oracle about this but I don't have much hope
there.
The last remaining option for us is to have the security bypass removed so that
any attempt to access JMX beans from a JConsole connected via PID get denied.
We understand that other users may not require such level of security but our
products are used in the financial sector, where cybercrime has become the #1
concern.
I however believe that having a system property controlling that bypass would
please everybody.
Can we help in any way ?
Best Regards,
> Local JMX connect is not possible
> -
>
> Key: KARAF-3147
> URL: https://issues.apache.org/jira/browse/KARAF-3147
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
>Affects Versions: 3.0.1
> Environment: OS X, JDK 7
>Reporter: Achim Nierbeck
>Assignee: Guillaume Nodet
>Priority: Critical
>
> With neither local process nor with remote jmx connection
> {code}
> service:jmx:rmi://0.0.0.0:4/jndi/rmi://0.0.0.0:1099/karaf-root
> {code}
> it's possible to connect to Karaf via JMX.
> Neither JConsole nor VisualVM is usable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KARAF-4720) NamespaceHandler implementations hijack namespaces
[
https://issues.apache.org/jira/browse/KARAF-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated KARAF-4720:
Fix Version/s: 4.0.8
4.1.0
> NamespaceHandler implementations hijack namespaces
> --
>
> Key: KARAF-4720
> URL: https://issues.apache.org/jira/browse/KARAF-4720
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.6
>Reporter: Svetoslav Neykov
> Fix For: 4.1.0, 4.0.8
>
>
> NamespaceHandler implementations in Karaf will return a schema location from
> getSchemaLocation even for namespaces they don't own, essentially replacing
> the xsd that corresponds to the requested namespace. That leads to errors
> that make no sense and inability to use the bundles that implement the
> handlers.
> Triggered by https://issues.apache.org/jira/browse/ARIES-1503 and
> https://github.com/apache/aries/commit/9a1ff22cbd29006d24a42e3e1274dfa493501ed9
> in particular.
> The error I was seeing when trying to use the JAAS module:
> {noformat}
> 18:07:39,892 ERROR 16 ntainer.BlueprintContainerImpl [pool-9-thread-1 ]
> Unable to start blueprint container for bundle
> org.apache.brooklyn.rest-resources/0.10.0.SNAPSHOT
> org.xml.sax.SAXParseException; systemId:
> bundle://31.0:1/org/apache/karaf/jaas/blueprint/config/karaf-jaas-1.1.0.xsd;
> lineNumber: 24; columnNumber: 66; src-import.3.1: The namespace attribute,
> 'http://cxf.apache.org/configuration/beans', of an element
> information item must be identical to the targetNamespace attribute,
> 'http://karaf.apache.org/xmlns/jaas/v1.1.0', of the imported document.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:437)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaErr(XSDHandler.java:4162)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaError(XSDHandler.java:4145)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:822)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1120)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:620)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:617)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:575)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:541)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:252)[:1.7.0_80]
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.createSchema(NamespaceHandlerRegistryImpl.java:641)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.doGetSchema(NamespaceHandlerRegistryImpl.java:458)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:443)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:343)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[20:org.apache.aries.util:1.1.1]
> at
> org.ap
[jira] [Resolved] (KARAF-4720) NamespaceHandler implementations hijack namespaces
[
https://issues.apache.org/jira/browse/KARAF-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved KARAF-4720.
Resolution: Fixed
> NamespaceHandler implementations hijack namespaces
> --
>
> Key: KARAF-4720
> URL: https://issues.apache.org/jira/browse/KARAF-4720
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.6
>Reporter: Svetoslav Neykov
> Fix For: 4.1.0, 4.0.8
>
>
> NamespaceHandler implementations in Karaf will return a schema location from
> getSchemaLocation even for namespaces they don't own, essentially replacing
> the xsd that corresponds to the requested namespace. That leads to errors
> that make no sense and inability to use the bundles that implement the
> handlers.
> Triggered by https://issues.apache.org/jira/browse/ARIES-1503 and
> https://github.com/apache/aries/commit/9a1ff22cbd29006d24a42e3e1274dfa493501ed9
> in particular.
> The error I was seeing when trying to use the JAAS module:
> {noformat}
> 18:07:39,892 ERROR 16 ntainer.BlueprintContainerImpl [pool-9-thread-1 ]
> Unable to start blueprint container for bundle
> org.apache.brooklyn.rest-resources/0.10.0.SNAPSHOT
> org.xml.sax.SAXParseException; systemId:
> bundle://31.0:1/org/apache/karaf/jaas/blueprint/config/karaf-jaas-1.1.0.xsd;
> lineNumber: 24; columnNumber: 66; src-import.3.1: The namespace attribute,
> 'http://cxf.apache.org/configuration/beans', of an element
> information item must be identical to the targetNamespace attribute,
> 'http://karaf.apache.org/xmlns/jaas/v1.1.0', of the imported document.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:437)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaErr(XSDHandler.java:4162)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaError(XSDHandler.java:4145)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:822)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1120)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:620)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:617)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:575)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:541)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:252)[:1.7.0_80]
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.createSchema(NamespaceHandlerRegistryImpl.java:641)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.doGetSchema(NamespaceHandlerRegistryImpl.java:458)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:443)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:343)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[20:org.apache.aries.util:1.1.1]
> at
> org.apache.aries.util.trac
[jira] [Commented] (KARAF-4720) NamespaceHandler implementations hijack namespaces
[
https://issues.apache.org/jira/browse/KARAF-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15602114#comment-15602114
]
Grzegorz Grzybek commented on KARAF-4720:
-
Fixed
[here|https://github.com/apache/karaf/commit/1d230955bd47c5b00880b105e8a20888b73d76f7]
in 4.0.x branch
Fixed
[here|https://github.com/apache/karaf/commit/4786a190cb5b50900aca289f6140be03389cd54f]
in master branch (4.1.x)
> NamespaceHandler implementations hijack namespaces
> --
>
> Key: KARAF-4720
> URL: https://issues.apache.org/jira/browse/KARAF-4720
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.6
>Reporter: Svetoslav Neykov
>
> NamespaceHandler implementations in Karaf will return a schema location from
> getSchemaLocation even for namespaces they don't own, essentially replacing
> the xsd that corresponds to the requested namespace. That leads to errors
> that make no sense and inability to use the bundles that implement the
> handlers.
> Triggered by https://issues.apache.org/jira/browse/ARIES-1503 and
> https://github.com/apache/aries/commit/9a1ff22cbd29006d24a42e3e1274dfa493501ed9
> in particular.
> The error I was seeing when trying to use the JAAS module:
> {noformat}
> 18:07:39,892 ERROR 16 ntainer.BlueprintContainerImpl [pool-9-thread-1 ]
> Unable to start blueprint container for bundle
> org.apache.brooklyn.rest-resources/0.10.0.SNAPSHOT
> org.xml.sax.SAXParseException; systemId:
> bundle://31.0:1/org/apache/karaf/jaas/blueprint/config/karaf-jaas-1.1.0.xsd;
> lineNumber: 24; columnNumber: 66; src-import.3.1: The namespace attribute,
> 'http://cxf.apache.org/configuration/beans', of an element
> information item must be identical to the targetNamespace attribute,
> 'http://karaf.apache.org/xmlns/jaas/v1.1.0', of the imported document.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:437)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaErr(XSDHandler.java:4162)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaError(XSDHandler.java:4145)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:822)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1120)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:620)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:617)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:575)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:541)[:1.7.0_80]
> at
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:252)[:1.7.0_80]
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.createSchema(NamespaceHandlerRegistryImpl.java:641)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.doGetSchema(NamespaceHandlerRegistryImpl.java:458)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:443)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:343)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)[16:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)[16:org.apache.aries.bluepri
