Adjusted my filter to :
role.filter=((objectClass=group)(member=%dn,DC=corp,DC=local))
Verified that it returns 2 Groups : Mirth Admins DEV and ActiveMQ_Admins_DEV
role.mapping=ActiveMQ_Admins_DEV=admin,webconsole,manager,jmxUser,sshConsole,viewer;ActiveMQ_Users_DEV=viewer
2017-03-06
To add :
When using the bin\client it works fine seems to only happen when using the
web portals, system/console, hawtio, activemq
2017-03-06 11:03:48,057 | DEBUG | c]-nio2-thread-3 | LDAPLoginModule
| 116 - org.apache.karaf.jaas.modules - 4.0.8 | Get the user DN.
2017-03-06
Here is the ldap config from both systems.
I also tried a fresh install on the server with no luck.
Thanks for the help
Server Version
http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0;
Thanks for your support.
Let's jump into documentation
--
View this message in context:
http://karaf.922171.n3.nabble.com/Multiple-bundles-dependencies-injection-pax-cdi-or-blueprint-tp4049756p4049765.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Ah, ok. Like the other person who posted on this, had tried both pool and
pool.jdbc to no avail. That seems to be what the documentation indicates.
Thanks for the update.
From: Christian Schneider [mailto:cschneider...@gmail.com] On Behalf Of
Christian Schneider
Sent: Monday, March 06, 2017
Hi Scott,
sorry for the late response. Took a while until I found time to look
into the hikari pool code.
You need to prefix the hikari properties with "hikari.".
All these properties will be stripped of the prefix and given to Hikari
as the config map.
Christian
On 24.02.2017 18:35,
A simple @Inject only works inside a bundle.
If you want to inject an object from another bundle then Export the
object as a service in bundle B and inject it as a service in bundle C.
Btw. using the blueprint-maven-plugin you can even use the CDI/JEE
annotations for blueprint.
See this to
Sorry, I'm busy on Karaf Container fixes. I will resume my investigation
on your issue tomorrow.
Regards
JB
On 03/06/2017 01:08 PM, glopez wrote:
Ok, let me know if you need anything from me.
Thank you
--
View this message in context:
Ok, let me know if you need anything from me.
Thank you
--
View this message in context:
http://karaf.922171.n3.nabble.com/Cellar-Load-balancer-setup-tp4049717p4049760.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Hi,
That sounds a lot like you’re building a persistence service with a defined API
(a good thing!). As I think you’ve already realised, you will want to start by
defining the persistence service and the DTOs that it is responsible for
persisting/retrieving. These things should live in an API
Thanks for your quick reply.
What I have in mind is separate a persistence implementation in a bundle,
with an interface exposed to several other bundles in a second bundle (like
a pseudo shared bundle maybe?), these several other bundles using interface
injected.
getting back to the previous
Hi,
just some comments from the peanut gallery :-)
If you just want to wire services between different bundles, stick with DS.
If you also want to have the full Context and Dependency injection stuff
within your own bundle, for example some inner bundle bean wiring.
In that case go with Pax-CDI.
Hello,
I'm new to osgi world (coming from a JEE bck) and trying to use pax-cdi at
first to manage injection.
I have 3 bundles
Bundle A declares an interface:
/package com.eg;
public interface Itf {
public void PrintITf();
}/
with Manifest generation using maven:
com.eg*
Bundle B
13 matches
Mail list logo
