Re: Text editing in the Karaf console

[Andreas Pieber]

@Ioannis: That's a really great idea! You'll definitely have my Kudos for
that :-)

@Guillaume: Why unix specifc? You've e.g. edit in windows (as Ioannis
noticed).

@JB Executing native commands could be kind of dangerous. For example, just
because Karaf need some permissions to modify /etc/xyz you might don't like
your users to do so directly via Karaf (rm -rf /etc/xyz).

Kind regards,
Andreas

On Sun, Dec 2, 2012 at 10:35 PM, Jean-Baptiste Onofré wrote:

> Hi Ioannis,
>
> interesting, especially if it works with multiple platform.
>
> It could be tricky to "maintain" ;) but interesting for the users.
>
> Around the same area, I would like to add an escape character (like !) to
> execute native command directly from the Karaf shell (like !ls -l for
> instance).
>
> Regards
> JB
>
>
> On 12/02/2012 06:40 PM, Ioannis Canellos wrote:
>
>> Hi guys,
>>
>> One feature I've always liked to have in the karaf console is the ability
>> to edit text files. See https://issues.apache.org/**
>> jira/browse/KARAF-2044 
>>
>> I took a stub last night, to integrate existing editors that might be
>> present in the system with the Karaf console (e.g. vi, nano or edit in
>> windows).
>> To my surprise starting the editor as a new Process and wiring input and
>> output seems to just work.
>>
>> There are just a few things I'd like to solve before committing and I
>> wanted some ideas:
>>
>> i) I can pass the terminal height and width to the process, but how do I
>> get those values get updated if I resize while the editor is open?
>> ii) Some editor don't take kindly the delete character and prefer
>> backspace
>> (changing ascii 127 to ascii 8). Is this safe to do. Is there a better way
>> to handle it?
>> iii) After closing the editor, the console sometimes gets "flaky" arrow
>> keys might stop working etc.
>>
>> Thoughts?
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Board report for December, 2012

[Jamie G.]

Looks good :)

On Sun, Dec 2, 2012 at 5:04 PM, Jean-Baptiste Onofré  wrote:
> FYI,
>
> I added a note about the progress that we made on EIK.
>
> Regards
> JB
>
>
> On 12/01/2012 07:39 PM, Jean-Baptiste Onofré wrote:
>>
>> Hi all,
>>
>> I prepared the board report for December, 2012:
>>
>> https://cwiki.apache.org/confluence/display/KARAF/Board+Reports
>>
>> Please, review it and update it if I forgot something.
>> I would like to send the report quickly.
>>
>> Thanks,
>> Regards
>> JB
>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: RFC on proposal to allow hooks into Karaf shutdown

[Łukasz Dywicki]

Roman,
I don't uderstand why you try to force us to introduce some code necessary for 
YOUR very custom secnario. As pointed before in this thread, there is plenty of 
ways to listen for framework shutdown - starting from FrameworkListener up to 
BundleListener. 
If you will digg deeper you will find the way which works for you. From our 
point of view there is no need to implement any shutdown listeners as our code 
works well with vanilla OSGi.

Best regards,
Lukasz Dywicki
--
Code-House
http://code-house.org

Wiadomość napisana przez Raman Gupta w dniu 2 gru 2012, o godz. 21:05:

> On 12/02/2012 02:44 PM, Guillaume Nodet wrote:
>> As I explained, I don't think that's possible.
>> The Main class is only responsible for shutting the framework when using
>> the bin/stop script and it does not have anything to do when shutting down
>> the framework from the inside using osgi:shutdown (or anything calling stop
>> on the system bundle).
> 
> It's not possible or its not optimal? Presumably, each place in the
> Karaf source that initiates a framework shutdown could place a
> "FrameworkShutdownStarted" event onto the OSGi EventAdmin?
> 
> Perhaps this is also an opportunity to refactor the shutdown code and
> move all the framework shutdown related stuff into one place.
> 
>> Another way to ensure that the listener will be called first would be to
>> give to its bundle a very low start level so that it's listener will be
>> registered first.
> 
> True, but this is a bit messy. The bundle that I want to act on the
> event uses Spring-DM, so I can't start it before Spring-DM. I could
> pull out just this functionality into a separate bundle, but its a bit
> messy. Nevertheless, it seems to be the only option now.
> 
> Regards,
> Raman
> 
> 
>> 
>> On Sun, Dec 2, 2012 at 5:47 PM, Raman Gupta  wrote:
>> 
>>> On 11/30/2012 01:56 AM, Jean-Baptiste Onofré wrote:
 On 11/30/2012 05:15 AM, Raman Gupta wrote:
> I sent this to the users mailing list, but it probably belongs more on
> dev. I'd like to hook into the Karaf shutdown process at a higher
> level than the OSGi bundle shutdown. The bundle shutdown starts
> prematurely shutting down services and such that are necessary for
> work in progress to complete.
 
 it's more or less already available. I'm not against enhancement
 around that, but, maybe it's redundant with the following.
 
 You can more or less already do something like this using a
 SynchronousBundleListener (you will received the STOPPING event on
 bundleId 0, so the framework), or a FrameworkListener (to hook on
 the framework).
>>> 
>>> I think there might still be some room for improvement here...
>>> 
>>> The problem I'm having is that Spring-DM also hooks a
>>> SynchronousBundleListener into the OSGi framework. Because Spring-DM's
>>> listener is registered first, and executes first, it goes ahead and
>>> shuts down all my bundles *before* my listener gets a chance to do
>>> anything useful.
>>> 
>>> (As an aside, for a STOPPING/STOPPED event, IMO it would make sense to
>>> execute listeners in reverse order i.e. the higher level listeners
>>> registered later should be executed first, rather than last. However,
>>> I guess this wasn't specified in the OSGi spec so nothing can be done
>>> there. There also appears to be no way specified to control the order
>>> explicitly.)
>>> 
>>> So... I still think it would be useful if Karaf provided an event or
>>> hook for just before a shutdown begins. Thoughts?
>>> 
>>> Regards,
>>> Raman
>>> 

Re: Text editing in the Karaf console

[Jean-Baptiste Onofré]

Hi Ioannis,

interesting, especially if it works with multiple platform.

It could be tricky to "maintain" ;) but interesting for the users.

Around the same area, I would like to add an escape character (like !) 
to execute native command directly from the Karaf shell (like !ls -l for 
instance).


Regards
JB

On 12/02/2012 06:40 PM, Ioannis Canellos wrote:

Hi guys,

One feature I've always liked to have in the karaf console is the ability
to edit text files. See https://issues.apache.org/jira/browse/KARAF-2044

I took a stub last night, to integrate existing editors that might be
present in the system with the Karaf console (e.g. vi, nano or edit in
windows).
To my surprise starting the editor as a new Process and wiring input and
output seems to just work.

There are just a few things I'd like to solve before committing and I
wanted some ideas:

i) I can pass the terminal height and width to the process, but how do I
get those values get updated if I resize while the editor is open?
ii) Some editor don't take kindly the delete character and prefer backspace
(changing ascii 127 to ascii 8). Is this safe to do. Is there a better way
to handle it?
iii) After closing the editor, the console sometimes gets "flaky" arrow
keys might stop working etc.

Thoughts?



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

Re: Text editing in the Karaf console

[Guillaume Nodet]

Interesting.  I had this in mind since a long time but had not thought
about bridging a native text editor.
One obvious downside is that this would kinda be unix specific ...

Now, as to your questions, you're going into dark areas here.  You've been
warned ;-)

On Sun, Dec 2, 2012 at 6:40 PM, Ioannis Canellos  wrote:

> Hi guys,
>
> One feature I've always liked to have in the karaf console is the ability
> to edit text files. See https://issues.apache.org/jira/browse/KARAF-2044
>
> I took a stub last night, to integrate existing editors that might be
> present in the system with the Karaf console (e.g. vi, nano or edit in
> windows).
> To my surprise starting the editor as a new Process and wiring input and
> output seems to just work.
>
> There are just a few things I'd like to solve before committing and I
> wanted some ideas:
>
> i) I can pass the terminal height and width to the process, but how do I
> get those values get updated if I resize while the editor is open?
>

If the connection is done through ssh, the native terminal on the other
side
will send events that could be intercepted.  However, when using a locale
console, there's no easy way to be notified afaik.


> ii) Some editor don't take kindly the delete character and prefer backspace
> (changing ascii 127 to ascii 8). Is this safe to do. Is there a better way
> to handle it?
> iii) After closing the editor, the console sometimes gets "flaky" arrow
> keys might stop working etc.
>

When creating a shell through ssh, the terminal configuration is passed
through ssh. Those parameters are available at
   org.apache.sshd.server.Environment#getPtyModes()
Now, the problem is to pass those terminal settings to the native process
and this should be done by calling stty to configure the terminal.
However, I'm not sure really what would happen when not using a real
terminal, i.e. when calling from ssh.  I suppose we'd have to create
a pseudo-terminal and use it, but i fear this kinda rely on fork/exec unix
stuff.

I initially had in mind rewriting the editor, but given the huge task, I
alwasy deferred it.  Interfacing with a real native terminal is certainly
easier, but the problems may be largely more difficult to solve, because
java is not really the best way to interface with unix executable.

Anyway, good work so far ...



>
> Thoughts?
>
> --
> *Ioannis Canellos*
> *
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Twitter: iocanel
> *
>



-- 

Guillaume Nodet

Blog: http://gnodet.blogspot.com/

FuseSource, Integration everywhere
http://fusesource.com

Re: Board report for December, 2012

[Jean-Baptiste Onofré]

FYI,

I added a note about the progress that we made on EIK.

Regards
JB

On 12/01/2012 07:39 PM, Jean-Baptiste Onofré wrote:

Hi all,

I prepared the board report for December, 2012:

https://cwiki.apache.org/confluence/display/KARAF/Board+Reports

Please, review it and update it if I forgot something.
I would like to send the report quickly.

Thanks,
Regards
JB


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

Re: RFC on proposal to allow hooks into Karaf shutdown

[Raman Gupta]

On 12/02/2012 02:44 PM, Guillaume Nodet wrote:
> As I explained, I don't think that's possible.
> The Main class is only responsible for shutting the framework when using
> the bin/stop script and it does not have anything to do when shutting down
> the framework from the inside using osgi:shutdown (or anything calling stop
> on the system bundle).

It's not possible or its not optimal? Presumably, each place in the
Karaf source that initiates a framework shutdown could place a
"FrameworkShutdownStarted" event onto the OSGi EventAdmin?

Perhaps this is also an opportunity to refactor the shutdown code and
move all the framework shutdown related stuff into one place.

> Another way to ensure that the listener will be called first would be to
> give to its bundle a very low start level so that it's listener will be
> registered first.

True, but this is a bit messy. The bundle that I want to act on the
event uses Spring-DM, so I can't start it before Spring-DM. I could
pull out just this functionality into a separate bundle, but its a bit
messy. Nevertheless, it seems to be the only option now.

Regards,
Raman


> 
> On Sun, Dec 2, 2012 at 5:47 PM, Raman Gupta  wrote:
> 
>> On 11/30/2012 01:56 AM, Jean-Baptiste Onofré wrote:
>>> On 11/30/2012 05:15 AM, Raman Gupta wrote:
 I sent this to the users mailing list, but it probably belongs more on
 dev. I'd like to hook into the Karaf shutdown process at a higher
 level than the OSGi bundle shutdown. The bundle shutdown starts
 prematurely shutting down services and such that are necessary for
 work in progress to complete.
>>>
>>> it's more or less already available. I'm not against enhancement
>>> around that, but, maybe it's redundant with the following.
>>>
>>> You can more or less already do something like this using a
>>> SynchronousBundleListener (you will received the STOPPING event on
>>> bundleId 0, so the framework), or a FrameworkListener (to hook on
>>> the framework).
>>
>> I think there might still be some room for improvement here...
>>
>> The problem I'm having is that Spring-DM also hooks a
>> SynchronousBundleListener into the OSGi framework. Because Spring-DM's
>> listener is registered first, and executes first, it goes ahead and
>> shuts down all my bundles *before* my listener gets a chance to do
>> anything useful.
>>
>> (As an aside, for a STOPPING/STOPPED event, IMO it would make sense to
>> execute listeners in reverse order i.e. the higher level listeners
>> registered later should be executed first, rather than last. However,
>> I guess this wasn't specified in the OSGi spec so nothing can be done
>> there. There also appears to be no way specified to control the order
>> explicitly.)
>>
>> So... I still think it would be useful if Karaf provided an event or
>> hook for just before a shutdown begins. Thoughts?
>>
>> Regards,
>> Raman
>>

Re: RFC on proposal to allow hooks into Karaf shutdown

[Guillaume Nodet]

As I explained, I don't think that's possible.
The Main class is only responsible for shutting the framework when using
the bin/stop script and it does not have anything to do when shutting down
the framework from the inside using osgi:shutdown (or anything calling stop
on the system bundle).
Another way to ensure that the listener will be called first would be to
give to its bundle a very low start level so that it's listener will be
registered first.


On Sun, Dec 2, 2012 at 5:47 PM, Raman Gupta  wrote:

> On 11/30/2012 01:56 AM, Jean-Baptiste Onofré wrote:
> > On 11/30/2012 05:15 AM, Raman Gupta wrote:
> >> I sent this to the users mailing list, but it probably belongs more on
> >> dev. I'd like to hook into the Karaf shutdown process at a higher
> >> level than the OSGi bundle shutdown. The bundle shutdown starts
> >> prematurely shutting down services and such that are necessary for
> >> work in progress to complete.
> >
> > it's more or less already available. I'm not against enhancement
> > around that, but, maybe it's redundant with the following.
> >
> > You can more or less already do something like this using a
> > SynchronousBundleListener (you will received the STOPPING event on
> > bundleId 0, so the framework), or a FrameworkListener (to hook on
> > the framework).
>
> I think there might still be some room for improvement here...
>
> The problem I'm having is that Spring-DM also hooks a
> SynchronousBundleListener into the OSGi framework. Because Spring-DM's
> listener is registered first, and executes first, it goes ahead and
> shuts down all my bundles *before* my listener gets a chance to do
> anything useful.
>
> (As an aside, for a STOPPING/STOPPED event, IMO it would make sense to
> execute listeners in reverse order i.e. the higher level listeners
> registered later should be executed first, rather than last. However,
> I guess this wasn't specified in the OSGi spec so nothing can be done
> there. There also appears to be no way specified to control the order
> explicitly.)
>
> So... I still think it would be useful if Karaf provided an event or
> hook for just before a shutdown begins. Thoughts?
>
> Regards,
> Raman
>



-- 

Guillaume Nodet

Blog: http://gnodet.blogspot.com/

FuseSource, Integration everywhere
http://fusesource.com

Text editing in the Karaf console

[Ioannis Canellos]

Hi guys,

One feature I've always liked to have in the karaf console is the ability
to edit text files. See https://issues.apache.org/jira/browse/KARAF-2044

I took a stub last night, to integrate existing editors that might be
present in the system with the Karaf console (e.g. vi, nano or edit in
windows).
To my surprise starting the editor as a new Process and wiring input and
output seems to just work.

There are just a few things I'd like to solve before committing and I
wanted some ideas:

i) I can pass the terminal height and width to the process, but how do I
get those values get updated if I resize while the editor is open?
ii) Some editor don't take kindly the delete character and prefer backspace
(changing ascii 127 to ascii 8). Is this safe to do. Is there a better way
to handle it?
iii) After closing the editor, the console sometimes gets "flaky" arrow
keys might stop working etc.

Thoughts?

-- 
*Ioannis Canellos*
*

**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*

Re: RFC on proposal to allow hooks into Karaf shutdown

[Raman Gupta]

On 11/30/2012 01:56 AM, Jean-Baptiste Onofré wrote:
> On 11/30/2012 05:15 AM, Raman Gupta wrote:
>> I sent this to the users mailing list, but it probably belongs more on
>> dev. I'd like to hook into the Karaf shutdown process at a higher
>> level than the OSGi bundle shutdown. The bundle shutdown starts
>> prematurely shutting down services and such that are necessary for
>> work in progress to complete.
>
> it's more or less already available. I'm not against enhancement
> around that, but, maybe it's redundant with the following.
>
> You can more or less already do something like this using a
> SynchronousBundleListener (you will received the STOPPING event on
> bundleId 0, so the framework), or a FrameworkListener (to hook on
> the framework).

I think there might still be some room for improvement here...

The problem I'm having is that Spring-DM also hooks a
SynchronousBundleListener into the OSGi framework. Because Spring-DM's
listener is registered first, and executes first, it goes ahead and
shuts down all my bundles *before* my listener gets a chance to do
anything useful.

(As an aside, for a STOPPING/STOPPED event, IMO it would make sense to
execute listeners in reverse order i.e. the higher level listeners
registered later should be executed first, rather than last. However,
I guess this wasn't specified in the OSGi spec so nothing can be done
there. There also appears to be no way specified to control the order
explicitly.)

So... I still think it would be useful if Karaf provided an event or
hook for just before a shutdown begins. Thoughts?

Regards,
Raman

Re: Board report for December, 2012

[Achim Nierbeck]

+1

fine with me.

regards, Achim


2012/12/1 Andreas Pieber 

> +1; nothing to add from my point of view
>
> Kind regards,
> Andreas
>
>
> On Sat, Dec 1, 2012 at 7:39 PM, Jean-Baptiste Onofré  >wrote:
>
> > Hi all,
> >
> > I prepared the board report for December, 2012:
> >
> > https://cwiki.apache.org/**confluence/display/KARAF/**Board+Reports<
> https://cwiki.apache.org/confluence/display/KARAF/Board+Reports>
> >
> > Please, review it and update it if I forgot something.
> > I would like to send the report quickly.
> >
> > Thanks,
> > Regards
> > JB
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>



-- 

Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog