Re: Karaf and Transaction Control Service Specification

2019-02-06 Thread Alex Soto
Tim: thank you for the clarification.

Best regards,
Alex soto




> On Feb 6, 2019, at 4:40 PM, Tim Ward  wrote:
> 
> The relevant specification for learning about scoped resources (which is what 
> the ResourceProvider gives you) is the Transaction Control Specification. In 
> this case your question is covered by Section 147.2.5 Multi Threading 
> .
>  
> 
> Scoped resources are always thread safe and designed to be singleton objects 
> used across multiple scopes. The underlying scoped resource implementation 
> then delegates to a real resource instance that is bound to the current 
> scope. The result is that the real resource never sees multi-threaded access 
> (a scope is bound to a single thread) and that you never need to worry about 
> creating/closing the resource because the “real resource” is automatically 
> created (or retrieved from a pool) on first use within a scope and then 
> closed (or returned to the pool) when the scope finishes. 
> 
> Best Regards,
> 
> Tim
> 
>> On 6 Feb 2019, at 22:14, Alex Soto > > wrote:
>> 
>> Actually, I took a stab at this again since I had some spare time now.  I am 
>> almost done. It looks promising.
>> 
>> The only question I have is about the entity manager.  In the examples, I 
>> see an entity manager is obtained in the activate method, and used for the 
>> rest of the life of the component:
>> 
>>  private EntityManager em;
>> 
>>  @Activate
>>  void init() {
>>  em = provider.getResource(txControl);
>>  }
>> 
>> 
>> Is this safe in a multi threaded environment? I expect the component to be 
>> called concurrently. 
>> Section 127.3.3 of OSGi Companion states that "An Entity Manager is intended 
>> to be used by a single session, it is not thread safe.” So I am confused 
>> since all examples seem to be ignoring this.
>> 
>> 
>> Best regards,
>> Alex soto
>> 
>> 
>> 
>> 
>>> On Feb 6, 2019, at 3:16 PM, Tim Jones >> > wrote:
>>> 
>>> Hi Alex,
>>> 
>>> yes it is possible to use tx-control with Karaf, we have been using it on
>>> v4.0.5 in our production system for about 18 months with no issues. One of
>>> the main reasons we use tx-control is that is it 'backed' by a standard.
>>> Rightly or wrongly we also didn't have confidence in Aries JPA Template at
>>> the time we were considering transaction managment solutions to manage our
>>> transactions in a production environment (perhaps this was misguided) but we
>>> were concerned that there were few integrated tests for that project where
>>> as there are over 2000 lines of test code for tx-control which demonstrate
>>> sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
>>> commit, rollback depending upon exception type and much more.
>>> 
>>> I think the enRoute project has some examples
>>> https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html 
>>>  and
>>> the tx-control test code is worth looking at.
>>> 
>>> Tim
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html 
>>> 
>> 
> 



Re: Karaf and Transaction Control Service Specification

2019-02-06 Thread Tim Ward
The relevant specification for learning about scoped resources (which is what 
the ResourceProvider gives you) is the Transaction Control Specification. In 
this case your question is covered by Section 147.2.5 Multi Threading 
.
 

Scoped resources are always thread safe and designed to be singleton objects 
used across multiple scopes. The underlying scoped resource implementation then 
delegates to a real resource instance that is bound to the current scope. The 
result is that the real resource never sees multi-threaded access (a scope is 
bound to a single thread) and that you never need to worry about 
creating/closing the resource because the “real resource” is automatically 
created (or retrieved from a pool) on first use within a scope and then closed 
(or returned to the pool) when the scope finishes. 

Best Regards,

Tim

> On 6 Feb 2019, at 22:14, Alex Soto  wrote:
> 
> Actually, I took a stab at this again since I had some spare time now.  I am 
> almost done. It looks promising.
> 
> The only question I have is about the entity manager.  In the examples, I see 
> an entity manager is obtained in the activate method, and used for the rest 
> of the life of the component:
> 
>   private EntityManager em;
> 
>   @Activate
>   void init() {
>   em = provider.getResource(txControl);
>   }
> 
> 
> Is this safe in a multi threaded environment? I expect the component to be 
> called concurrently. 
> Section 127.3.3 of OSGi Companion states that "An Entity Manager is intended 
> to be used by a single session, it is not thread safe.” So I am confused 
> since all examples seem to be ignoring this.
> 
> 
> Best regards,
> Alex soto
> 
> 
> 
> 
>> On Feb 6, 2019, at 3:16 PM, Tim Jones > > wrote:
>> 
>> Hi Alex,
>> 
>> yes it is possible to use tx-control with Karaf, we have been using it on
>> v4.0.5 in our production system for about 18 months with no issues. One of
>> the main reasons we use tx-control is that is it 'backed' by a standard.
>> Rightly or wrongly we also didn't have confidence in Aries JPA Template at
>> the time we were considering transaction managment solutions to manage our
>> transactions in a production environment (perhaps this was misguided) but we
>> were concerned that there were few integrated tests for that project where
>> as there are over 2000 lines of test code for tx-control which demonstrate
>> sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
>> commit, rollback depending upon exception type and much more.
>> 
>> I think the enRoute project has some examples
>> https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html 
>>  and
>> the tx-control test code is worth looking at.
>> 
>> Tim
>> 
>> 
>> 
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html 
>> 
> 



Re: Karaf and Transaction Control Service Specification

2019-02-06 Thread Alex Soto
Actually, I took a stab at this again since I had some spare time now.  I am 
almost done. It looks promising.

The only question I have is about the entity manager.  In the examples, I see 
an entity manager is obtained in the activate method, and used for the rest of 
the life of the component:

private EntityManager em;

@Activate
void init() {
em = provider.getResource(txControl);
}


Is this safe in a multi threaded environment? I expect the component to be 
called concurrently. 
Section 127.3.3 of OSGi Companion states that "An Entity Manager is intended to 
be used by a single session, it is not thread safe.” So I am confused since all 
examples seem to be ignoring this.


Best regards,
Alex soto




> On Feb 6, 2019, at 3:16 PM, Tim Jones  wrote:
> 
> Hi Alex,
> 
> yes it is possible to use tx-control with Karaf, we have been using it on
> v4.0.5 in our production system for about 18 months with no issues. One of
> the main reasons we use tx-control is that is it 'backed' by a standard.
> Rightly or wrongly we also didn't have confidence in Aries JPA Template at
> the time we were considering transaction managment solutions to manage our
> transactions in a production environment (perhaps this was misguided) but we
> were concerned that there were few integrated tests for that project where
> as there are over 2000 lines of test code for tx-control which demonstrate
> sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
> commit, rollback depending upon exception type and much more.
> 
> I think the enRoute project has some examples
> https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html and
> the tx-control test code is worth looking at.
> 
> Tim
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html



Re: Karaf and Transaction Control Service Specification

2019-02-06 Thread Jean-Baptiste Onofré
Thanks for the feedback Tim.

I created the following Jira to add a example about tx in general and
tx-control in particular:

https://issues.apache.org/jira/browse/KARAF-6140

By hte way, before the end of this week, I will send the first action of
the "kloud initiative". Especially, I will send a proposal to simplify
the developer perspective.

Regards
JB

On 06/02/2019 21:16, Tim Jones wrote:
> Hi Alex,
> 
> yes it is possible to use tx-control with Karaf, we have been using it on
> v4.0.5 in our production system for about 18 months with no issues. One of
> the main reasons we use tx-control is that is it 'backed' by a standard.
> Rightly or wrongly we also didn't have confidence in Aries JPA Template at
> the time we were considering transaction managment solutions to manage our
> transactions in a production environment (perhaps this was misguided) but we
> were concerned that there were few integrated tests for that project where
> as there are over 2000 lines of test code for tx-control which demonstrate
> sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
> commit, rollback depending upon exception type and much more.
> 
> I think the enRoute project has some examples
> https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html and
> the tx-control test code is worth looking at.
> 
> Tim
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: FeaturesProcessor and JDK11

2019-02-06 Thread Jean-Baptiste Onofré
Hi Jérémie,

can you please create a Jira (or I can do it for you) ?

I will fix that but for 4.2.4/4.3.0 as Karaf 4.2.3 release is in progress.

Regards
JB

On 06/02/2019 20:59, J. Brebec wrote:
> Hello,
> 
> I am using Karaf 4.2.2 and the karaf-maven-plugin to build a custom 
> distribution. This distribution uses a features-processor xml files in order 
> to blacklist/replaces some bundles.
> 
> This works fine under JDK8, however, it fails under JDK11. With this JDK, the 
> features-processor files is unmarshalled without any elements.
> 
> For example, If I use this file :
> 
>  xmlns="http://karaf.apache.org/xmlns/features-processing/v1.0.0";
> xmlns:f="http://karaf.apache.org/xmlns/features/v1.5.0";>
> 
> 
> 
> with JDK8, the xsd validation of this file is successful. However, in JDK11, 
> it fails because "blacklistedRepositories" should'nt have a namespace (and 
> jaxb doesn't see any child elements)
> 
> Is it a know issues ? I didn't find anything about it on github.
> 
> Regards,
> Jérémie
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Karaf and Transaction Control Service Specification

2019-02-06 Thread Tim Jones
Hi Alex,

yes it is possible to use tx-control with Karaf, we have been using it on
v4.0.5 in our production system for about 18 months with no issues. One of
the main reasons we use tx-control is that is it 'backed' by a standard.
Rightly or wrongly we also didn't have confidence in Aries JPA Template at
the time we were considering transaction managment solutions to manage our
transactions in a production environment (perhaps this was misguided) but we
were concerned that there were few integrated tests for that project where
as there are over 2000 lines of test code for tx-control which demonstrate
sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
commit, rollback depending upon exception type and much more.

I think the enRoute project has some examples
https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html and
the tx-control test code is worth looking at.

Tim



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html


FeaturesProcessor and JDK11

2019-02-06 Thread J . Brebec
Hello,

I am using Karaf 4.2.2 and the karaf-maven-plugin to build a custom 
distribution. This distribution uses a features-processor xml files in order to 
blacklist/replaces some bundles.

This works fine under JDK8, however, it fails under JDK11. With this JDK, the 
features-processor files is unmarshalled without any elements.

For example, If I use this file :

http://karaf.apache.org/xmlns/features-processing/v1.0.0";
xmlns:f="http://karaf.apache.org/xmlns/features/v1.5.0";>



with JDK8, the xsd validation of this file is successful. However, in JDK11, it 
fails because "blacklistedRepositories" should'nt have a namespace (and jaxb 
doesn't see any child elements)

Is it a know issues ? I didn't find anything about it on github.

Regards,
Jérémie


Re: Connecting via jaas module results in FileNotFoundException

2019-02-06 Thread Jean-Baptiste Onofré
Do you have the ssh role for the user ?

Regards
JB

On 06/02/2019 17:38, abdelb wrote:
> Hello, 
> 
> It does appear under realm-list. 
> 
> I had a closer look at the logs and it actually authenticates and generates
> an ssh key if the credentials are correct (however it still denies access
> for some reason). Incorrect credentials correctly lead to a
> javax.naming.AuthenticationException being thrown.  
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Connecting via jaas module results in FileNotFoundException

2019-02-06 Thread abdelb
Hello, 

It does appear under realm-list. 

I had a closer look at the logs and it actually authenticates and generates
an ssh key if the credentials are correct (however it still denies access
for some reason). Incorrect credentials correctly lead to a
javax.naming.AuthenticationException being thrown.  



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html


Re: Microkernel Karaf fit...

2019-02-06 Thread Ranx
JB,

Thanks for the feedback. I'll check out the blog and look at where you've
been going.

This is sort of on track for what I'm thinking about. One has to read
between the lines a bit because the example is using VirtualBox and Docker
but OSv is the microkernel being used. In reality, what I'd be after is the
microkernel - OSv or Mirage or whatever - directly running on the
hypervisor. Which is what OSv and other ukernels are really designed for.

What I wasn't sure about until I read this is one of the microkernels
running Java. Obviously once one has a JVM running then putting Karaf/Felix
on it is possible. 

https://github.com/solo-io/unik/blob/master/docs/getting_started_java.md

>From what I understand microkernels generally only permit a single process
to be booted. That can be a big challenge for many applications and 
architectures. Karaf has long worked in a way that when it runs on a VM you
really don't have to log into the VM itself because all the tools are built
in. That makes it ideal for use in a microkernel because I don't believe
most microkernels provide command lines or log ins. 

Think about a compare and contrast of Karaf running on OSv versus Spring
Boot. Karaf would run on the JVM and you could SSH in or go to Hawtio or
interact with it and its file system in many different manners. With Spring
Boot, once you've run it on the microkernel that's it. You can't log into it
or look at its file system or tweak configurations for the running instance. 

Hypervisor->OSv ukernel->JVM->Karaf

Very fast start up. Low overhead. JVM running in kernel mode with privileged
acess and low latency. Karaf console/SSH, Maven deployment of artifacts,
etc. 

While I understand Docker and Kubernetes, I've always thought of it as an
"elegant hack". Virtual machines are big and slow and resource hungry so how
do we get around that problem? Hack security barriers into the virtual
machine to partition it and then create management technologies. It seems to
solve the problem at the wrong level of abstraction and with Java that
creates a problem - the JVM isn't shared across Docker images.

So we end up with a way to share the resources of a virtual machine with
multiple Docker images but if they are JVM based, each JVM is going to grab
its own chunk of threads, memory and so on. Of course, if you're running
Spring Boot instance then each of those instances loads a large number of
identical classes and bytecode - even if it is just the JDK. That problem
persists even if you run Spring Boot on a microkernel.

Running Karaf on a microkernel is another matter. If I structure my features
along functional lines I can install them all in one Karaf container or if I
want to break them out later I can run them in separate containers in their
own microkernel instance. Obviously that's not unique to microkernels as you
can do that today in Docker images if you desired. But Karaf in Docker
doesn't make a lot of sense to me.

But let's get to the original problem - VMs are big and slow and take a lot
of resources to boot up an operating system that lets your run your
applications. Docker partitions the VM to make it a little more parsimonious
and faster.  Kubernetes manages the resources for you. Now, let's get rid of
the VM, Docker and Kubernetes and run a microkernel directly on the
hypervisor which spins up a JVM and Karaf. Fast. Streamlined. Managing my
Java applications on that stack is no different than interacting with it
running on my desktop or on a server or on a VM or in a Docker image running
in a VM. 








--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html


Re: Connecting via jaas module results in FileNotFoundException

2019-02-06 Thread Jean-Baptiste Onofré
Hi,

Can you see the login module in the jaas:realm-list ?

If not, can you add debug option in LDAPLoginModule configuration:

debug=true

Please, send me the log in debug.

Thanks,
Regards
JB

On 06/02/2019 10:32, abdelb wrote:
> Sure: 
> 
> 
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.1.0";
>   
> xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0";>
> 
>   
>className="org.apache.karaf.jaas.modules.ldap.LDAPLoginModule"
> flags="required">
>   connection.url = ldap://xxx:xxx
> connection.username = CN=xxx,OU=xxx,OU=xxx,DC=xxx,DC=xxx
> connection.password = xxx
> user.base.dn = DC=xxx,DC=xxx
> user.filter = (uid=%u)
> user.search.subtree = true
> role.base.dn = OU=xxx,OU=xxx,DC=xxx,DC=xxx
> role.filter = (member:=%fqdn)
> role.name.attribute = CN
> role.search.subtree = true
> role.mapping = xxx=admin,viewer,systembundles,manager
> authentication = simple
>   
>   
> 
> 
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Connecting via jaas module results in FileNotFoundException

2019-02-06 Thread Jean-Baptiste Onofré
By the way, I'm not sure that the FileNotFoundException coming from sshd
(WARN) is actually the problem.

Regards
JB

On 05/02/2019 19:26, abdelb wrote:
> Hi, 
> 
> I'm copying over a jaas module xml from an older version of karaf to 4.2.2
> and get this error when trying to ssh: 
> 
> WARN  | sshd-SshServer[61072017]-nio2-thread-1 |
> VersionProperties$LazyHolder | 114 - org.apache.sshd.core - 1.7.0 |
> Failed (FileNotFoundException) to load version properties: Resource does not
> exists
> 
> I'm using the exact same file and credentials - is this a bug in 4.2.2? 
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Connecting via jaas module results in FileNotFoundException

2019-02-06 Thread Jean-Baptiste Onofré
Hi,

I did the following test (on Karaf 4.2.3-SNAPSHOT):

1. In etc/org.apache.karaf.features.cfg, I added aries-blueprint as
featuresBoot
2. I created deploy/config.xml containing:


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";>






users = $[karaf.etc]/mybackend.properties





In etc/mybackend.properties, I added my user (jbonofre).

3. Then I started Karaf. I can see the realm using jaas:* commands:

karaf@root()> jaas:realm-list
Index │ Realm Name │ Login Module Class Name
──┼┼───
1 │ karaf  │
org.apache.karaf.jaas.modules.properties.PropertiesLoginModule

karaf@root()> jaas:realm-manage --index 1
karaf@root()> jaas:user-list
User Name │ Group  │ Role
──┼┼──
jbonofre  │ admingroup │ admin
jbonofre  │ admingroup │ manager
jbonofre  │ admingroup │ viewer
jbonofre  │ admingroup │ systembundles
jbonofre  │ admingroup │ ssh

4. Now, I connect using ssh with my jbonofre user:

ssh -p 8101 jbonofre@localhost

So, it seems to work at least with the PropertiesLoginModule.

Let me try a Apache Directory to test with the LDAPLoginModule.

Regards
JB

On 06/02/2019 15:55, abdelb wrote:
> Thanks for investigating. If it helps I have just tested this module in the
> standard 4.0.8 and 4.2.2 distributions downloaded from the Karaf website. 
> 
> It works fine on 4.0.8; 4.2.2 is failing with the same message as my custom
> distribution. 
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Microkernel Karaf fit...

2019-02-06 Thread Jean-Baptiste Onofré
Hi Brad

I know multiple Karaf use cases:
- embedded (I know in trucks, in the ESA spatial station ;))
- on prem
- on cloud

About hypervisor/cloud/container, I did a blog about
Karaf/Docker/Kubernetes:

http://blog.nanthrax.net/?p=849

So, what are you looking for ? A dedicated hypervisor for Karaf (a bit
like in Cellar and the kloud initiative I started).

By the way about the kloud initiative, the first action around this is to:
1. provide tooling for dev (easily create a custom karaf runtime
embedded business code, based on annotations for instance)
2. provide tooling for devops (easily create jar/docker image/tar.gz
turnkey to start powered by Karaf)

I would be more than happy to chat with you about the target ;)

Thanks for bringing the discussion anyway !

Regards
JB

On 06/02/2019 16:06, r...@enjekt.org wrote:
> Is anyone aware of a microkernel running a JVM/Karaf? I think Karaf
> could really take advantage of microkernels avoiding the need for
> Kubernetes, Docker and so on. Karaf is uniquely qualified for this by
> the fact that it has its own hooks to repositories, a console and
> monitoring with things like HawtIO. If the JVM/Karaf/Felix is running in
> the kernel itself and that is running on the hypervisor, there’s not a
> lot of overhead. That’s a stark contrast to the world of
> Kubernetes/Docker/VM/hypervisor.
> 
>  
> 
> With microkernels and rump kernels getting a lot of attention and
> development these days, there seems to be a great opportunity for Karaf
> running in a microkernel’s
> 
>  
> 
> Camel->Spring Boot->JVM->Docker->Kubernetes->Linux->VM->hypervisor->server.
> 
> Camel K->JVM->Docker->Kubernetes->Linux->VM->hypervisor->server.
> 
>  
> 
> Server->hypervisor->microkernel->JVM->Karaf(!)
> 
>  
> 
> Recently I was reading a bit more about Camel K. That’s Camel running
> directly on Kubernettes sans container – no Spring Boot, Karaf/Felix, or
> EAP.  It’s a move in the right direction, I think, but as I think about
> it Karaf seems uniquely poised to really jump to the front of the line.
> James Strachan recently commented that he was concerned about the future
> of the JVM due to the enormous overhead of running it in a Docker world.
> 
>  
> 
> It isn’t simply that Karaf/Felix can run on a JVM in the kernel space
> and avoid all the other overhead. OSGi bundles and Karaf features
> essentially allow one to create microservices as groups of bundles that
> can be deployed to separate Karaf instances or to the same Karaf
> instances. That simply isn’t possible with Spring Boot, Camel K or other
> stacks.
> 
>  
> 
> If anyone is aware of a microkernel or rump kernel or exokernel running
> a JVM/Karaf I’d really appreciate a pointer.
> 
>  
> 
> Brad
> 
>  
> 
>  
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Microkernel Karaf fit...

2019-02-06 Thread ranx
Is anyone aware of a microkernel running a JVM/Karaf? I think Karaf could
really take advantage of microkernels avoiding the need for Kubernetes,
Docker and so on. Karaf is uniquely qualified for this by the fact that it
has its own hooks to repositories, a console and monitoring with things like
HawtIO. If the JVM/Karaf/Felix is running in the kernel itself and that is
running on the hypervisor, there's not a lot of overhead. That's a stark
contrast to the world of Kubernetes/Docker/VM/hypervisor. 

 

With microkernels and rump kernels getting a lot of attention and
development these days, there seems to be a great opportunity for Karaf
running in a microkernel's 

 

Camel->Spring Boot->JVM->Docker->Kubernetes->Linux->VM->hypervisor->server. 

Camel K->JVM->Docker->Kubernetes->Linux->VM->hypervisor->server.

 

Server->hypervisor->microkernel->JVM->Karaf(!)

 

Recently I was reading a bit more about Camel K. That's Camel running
directly on Kubernettes sans container - no Spring Boot, Karaf/Felix, or
EAP.  It's a move in the right direction, I think, but as I think about it
Karaf seems uniquely poised to really jump to the front of the line. James
Strachan recently commented that he was concerned about the future of the
JVM due to the enormous overhead of running it in a Docker world. 

 

It isn't simply that Karaf/Felix can run on a JVM in the kernel space and
avoid all the other overhead. OSGi bundles and Karaf features essentially
allow one to create microservices as groups of bundles that can be deployed
to separate Karaf instances or to the same Karaf instances. That simply
isn't possible with Spring Boot, Camel K or other stacks. 

 

If anyone is aware of a microkernel or rump kernel or exokernel running a
JVM/Karaf I'd really appreciate a pointer.

 

Brad

 

 



Re: Connecting via jaas module results in FileNotFoundException

2019-02-06 Thread Jean-Baptiste Onofré
Thanks for the update.

I'm testing a properties login module on Karaf 4.2.3-SNAPSHOT.

Regards
JB

On 06/02/2019 15:55, abdelb wrote:
> Thanks for investigating. If it helps I have just tested this module in the
> standard 4.0.8 and 4.2.2 distributions downloaded from the Karaf website. 
> 
> It works fine on 4.0.8; 4.2.2 is failing with the same message as my custom
> distribution. 
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Connecting via jaas module results in FileNotFoundException

2019-02-06 Thread abdelb
Thanks for investigating. If it helps I have just tested this module in the
standard 4.0.8 and 4.2.2 distributions downloaded from the Karaf website. 

It works fine on 4.0.8; 4.2.2 is failing with the same message as my custom
distribution. 



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html


Re: Connecting via jaas module results in FileNotFoundException

2019-02-06 Thread Jean-Baptiste Onofré
Thanks, I will try and I keep you posted.

Regards
JB

On 06/02/2019 10:32, abdelb wrote:
> Sure: 
> 
> 
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.1.0";
>   
> xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0";>
> 
>   
>className="org.apache.karaf.jaas.modules.ldap.LDAPLoginModule"
> flags="required">
>   connection.url = ldap://xxx:xxx
> connection.username = CN=xxx,OU=xxx,OU=xxx,DC=xxx,DC=xxx
> connection.password = xxx
> user.base.dn = DC=xxx,DC=xxx
> user.filter = (uid=%u)
> user.search.subtree = true
> role.base.dn = OU=xxx,OU=xxx,DC=xxx,DC=xxx
> role.filter = (member:=%fqdn)
> role.name.attribute = CN
> role.search.subtree = true
> role.mapping = xxx=admin,viewer,systembundles,manager
> authentication = simple
>   
>   
> 
> 
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Connecting via jaas module results in FileNotFoundException

2019-02-06 Thread abdelb
Sure: 


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



connection.url = ldap://xxx:xxx
connection.username = CN=xxx,OU=xxx,OU=xxx,DC=xxx,DC=xxx
connection.password = xxx
user.base.dn = DC=xxx,DC=xxx
user.filter = (uid=%u)
user.search.subtree = true
role.base.dn = OU=xxx,OU=xxx,DC=xxx,DC=xxx
role.filter = (member:=%fqdn)
role.name.attribute = CN
role.search.subtree = true
role.mapping = xxx=admin,viewer,systembundles,manager
authentication = simple







--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html