Re: Karaf 4.1.0 console issues using putty

2017-04-10 Thread peter.berkman
oh, also, CTRL-D just beeps.  I have to run "logout" to close the Putty
session cleanly.



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-4-1-0-console-issues-using-putty-tp4049909p4050097.html
Sent from the Karaf - User mailing list archive at Nabble.com.


Re: Karaf 4.1.0 console issues using putty

2017-04-10 Thread peter.berkman
I am on Karaf 4.1.1 and accessing the console from Putty (basic config) the
tab completion completely messes up the screen.

if I run bin/client.bat, everything looks perfect.

any ideas?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-4-1-0-console-issues-using-putty-tp4049909p4050096.html
Sent from the Karaf - User mailing list archive at Nabble.com.


Re: Why is karaf so much easier to get working than older OSGi containers?

2017-04-10 Thread Dominik Przybysz
We have solved the OSGI quick start problem in another way in our internal
project, but it is perfeclty tied to our needs.

We have forked https://github.com/spring-io/initializr and customize it to
create poms, api and impl jars with configuration examples for each feature
(not karaf features, but conceptual features) that we need and all
dependencies added .

Now if i have to add new bundle, I just describe maven cordinates, package
and features. Feature example is rest, where I obtain blueprint file with
configured cxf exposing example service. Another feature is camel context
where example camel context is generated with some routes, producer
template and example beans.

2017-04-10 11:13 GMT+02:00 Serge Huber :

> I think that Karaf Boot is also important to get people started quickly.
> Or maybe even some kind of CLI interface and container integrations.
>
> I still find that building a new project with my own custom distribution
> is a big more work than I would like.
>
> Not to say that I don't love Karaf, I'm using it in more and more projects
> (4 professional and 2 personal !)
>
> cheers,
>   Serge...
>
> Serge Huber
> CTO & Co-Founder
> T +41 22 361 3424 <+41%2022%20361%2034%2024>
> 9 route des Jeunes | 1227 Acacias | Switzerland
> jahia.com 
> SKYPE | LINKEDIN  | TWITTER
>  | VCARD
> 
>
>
> > JOIN OUR COMMUNITY  to evaluate, get trained and
> to discover why Jahia is a leading User Experience Platform (UXP) for
> Digital Transformation.
>
> On Sun, Apr 9, 2017 at 8:50 AM, Jean-Baptiste Onofré 
> wrote:
>
>> Hi Steinar,
>>
>> Great e-mail !
>>
>> I think Karaf just works thanks to combination of what you said: features
>> and resolver, prepackage features, convenient functionalities (shell, ACL,
>> etc).
>>
>> I still think we should improve the dev experience providing samples in
>> the distribution (as started).
>>
>> Regards
>> JB
>>
>>
>> On 04/09/2017 08:37 AM, Steinar Bang wrote:
>>
>>> I first encountered OSGi in 2006.  The place I worked at that time had
>>> (prior to my hiring) selected OSGi as the platform for server side
>>> components.
>>>
>>> The team I worked on extended this into the GUI space by creating an
>>> eclipse GEF-based IDE for data flows in the server system, where we
>>> integrated the server components into the eclipse instance for
>>> debugging.
>>>
>>> At that time it was a very promising technology, it was defined in a
>>> standard document that was actually readable, and it had (at that time,
>>> if memory serves me right) one complete free software implementation
>>> (eclipse equinox), two commercial implementations, and one free
>>> implementation (apache felix) just getting started.
>>>
>>> For my own part I was attracted to the lego building block possibilities
>>> of OSGi, and the fact that we were able to get the server components
>>> running inside eclipse and talking to eclipse GUI components by
>>> using OSGi services (even though what the server side components and
>>> eclipse used on top of OSGi services was very different).
>>>
>>> But... the problem with OSGi both then, and when I started looking at it
>>> back in 2013, was the practicalities in getting all bundle dependencies
>>> satisfied, and finding, and working around bundle version issues.
>>>
>>> In contrast to this, karaf has just worked for me (I took the plunge
>>> into learning karaf in the autumn of 2016).
>>>
>>> Or let me qualify that a little: since I started creating features for
>>> my own bundles, as a part of the maven build, karaf has just worked for
>>> me.
>>>
>>> So what I'm wondering, is: why is karaf so easy when everything before
>>> has been so hard?
>>>
>>> Is it because there is something magical in the feature resolution,
>>> compared to other way of starting OSGi runtimes?
>>>
>>> Or is it just that karaf comes prepackaged with features for the pax
>>> stuff (web, jdbc)? And that it is these prepackaged features that just
>>> works?
>>>
>>> Just some idle curiosity on a Sunday morning...:-)
>>>
>>>
>>> - Steinar
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>


-- 
Pozdrawiam / Regards,
Dominik Przybysz


Re: Karaf Support for Oracle Wallet

2017-04-10 Thread Martin Lichtin


The solution was to add "oracle.security.pki" to 
org.osgi.framework.bootdelegation (without the .*)

It works now.

From: Martin Lichtin 
To: "user@karaf.apache.org"  
Sent: Sunday, April 9, 2017 12:49 AM
Subject: Karaf Support for Oracle Wallet


Having trouble with adding support for Oracle Wallet. Has anyone had success 
with it?
One needs to register oracle.security.pki.OraclePKIProvider, therefore add 
three JARs

oraclepki.jar, osdt_cert.jar, osdt_core.jar

to "lib/ext" and extend org.apache.karaf.security.providers with the class name.

So I did that.

However, this doesn't seem to be enough, still getting:

Caused by: java.sql.SQLException: PKI classes not found. To use 'connect /' 
functionality, oraclepki.jar must be in the classpath: 
java.lang.NoClassDefFoundError: oracle/security/pki/OracleWallet

I checked Security.getProviders() and OraclePKIProvider is part of the list.
Also, I tried adding oracle.security.pki.* to org.osgi.framework.bootdelegation 
but that didn't help.

Any further ideas on what I could try?


Re: Why is karaf so much easier to get working than older OSGi containers?

2017-04-10 Thread Serge Huber
I think that Karaf Boot is also important to get people started quickly. Or
maybe even some kind of CLI interface and container integrations.

I still find that building a new project with my own custom distribution is
a big more work than I would like.

Not to say that I don't love Karaf, I'm using it in more and more projects
(4 professional and 2 personal !)

cheers,
  Serge...

Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com 
SKYPE | LINKEDIN  | TWITTER
 | VCARD



> JOIN OUR COMMUNITY  to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.

On Sun, Apr 9, 2017 at 8:50 AM, Jean-Baptiste Onofré 
wrote:

> Hi Steinar,
>
> Great e-mail !
>
> I think Karaf just works thanks to combination of what you said: features
> and resolver, prepackage features, convenient functionalities (shell, ACL,
> etc).
>
> I still think we should improve the dev experience providing samples in
> the distribution (as started).
>
> Regards
> JB
>
>
> On 04/09/2017 08:37 AM, Steinar Bang wrote:
>
>> I first encountered OSGi in 2006.  The place I worked at that time had
>> (prior to my hiring) selected OSGi as the platform for server side
>> components.
>>
>> The team I worked on extended this into the GUI space by creating an
>> eclipse GEF-based IDE for data flows in the server system, where we
>> integrated the server components into the eclipse instance for
>> debugging.
>>
>> At that time it was a very promising technology, it was defined in a
>> standard document that was actually readable, and it had (at that time,
>> if memory serves me right) one complete free software implementation
>> (eclipse equinox), two commercial implementations, and one free
>> implementation (apache felix) just getting started.
>>
>> For my own part I was attracted to the lego building block possibilities
>> of OSGi, and the fact that we were able to get the server components
>> running inside eclipse and talking to eclipse GUI components by
>> using OSGi services (even though what the server side components and
>> eclipse used on top of OSGi services was very different).
>>
>> But... the problem with OSGi both then, and when I started looking at it
>> back in 2013, was the practicalities in getting all bundle dependencies
>> satisfied, and finding, and working around bundle version issues.
>>
>> In contrast to this, karaf has just worked for me (I took the plunge
>> into learning karaf in the autumn of 2016).
>>
>> Or let me qualify that a little: since I started creating features for
>> my own bundles, as a part of the maven build, karaf has just worked for
>> me.
>>
>> So what I'm wondering, is: why is karaf so easy when everything before
>> has been so hard?
>>
>> Is it because there is something magical in the feature resolution,
>> compared to other way of starting OSGi runtimes?
>>
>> Or is it just that karaf comes prepackaged with features for the pax
>> stuff (web, jdbc)? And that it is these prepackaged features that just
>> works?
>>
>> Just some idle curiosity on a Sunday morning...:-)
>>
>>
>> - Steinar
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


[ANN] Apache Karaf 4.0.9 released

2017-04-10 Thread Jean-Baptiste Onofré

The Apache Karaf team is pleased to announce Karaf (Container) 4.0.9 release.

This is an update patch for Apache Karaf 4.0.x, containing many bug
fixes, dependency updates.

http://karaf.apache.org/

This release is available from

http://karaf.apache.org/download.html#container-409

and

Maven:

 
 org.apache.karaf
 apache-karaf
 4.0.8
 

Release Notes:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12338821

Enjoy!

--
The Apache Karaf Team