Re: Add a scope feature-url

[Chris Geer]

Maybe this isn't possible, but is there a way to make command text be
completely configurable? I know there are currently aliases, but that gets
real ugly real quick with multiple ways to do the same thing. It would be
nice to be able to define Command Sets that map command object to the term
that the shell will recognize which overwrites the default. It would be
even slicker if there were pre-defined sets that people could select
between like "legacy" and "new and fancy". That would give you the freedom
to restructure how the commands are actually implemented in code (sub
commands..) without impacting how the commands are called. So if the
default was "features:repo:add" but there was a way to make that
"features:addurl" by replacing the first one I think you could get
backwards compatibility and be able to refactor as needed.

Just a thought. It doesn't solve the "value" concern but it would fix the
backwards compatibility concern and allow people migrate to the new
commands at their own pace. I'm with Ioannis, I like the new proposed
structure in a lot of ways and dislike how some of the commands are now but
that is quickly outweighed by breaking compatibility.

Chris

On Fri, May 25, 2012 at 2:49 PM, Achim Nierbeck wrote:

> Christian,
>
> basically I just can repeat myself I don't see much of a difference, and
> again I have to
> second Ioannis for the reasons. And the thing that really made me do a -1
> here
> our Users don't see a reason to change either.
> This is just a repetition of all what has been said/written before
>
> Achim
>
>
> Am 25.05.2012 19:10, schrieb Ioannis Canellos:
>
>  So having "feature:repo:list" sounds better to me than
>>> "feature:repo-list".
>>>
>>>  The thing is that its not *that* better to justify a change and all the
>> effort that such a change requires (both from the broader community and
>> from our existing user).
>>
>> Just to clarify. I do like the idea of nesting sub shells and the concept
>> of separating them using the ":" as it might be useful for downstream
>> projects or people building their custom distribution and have tens of
>> commands under single scope. So I am +1 to that part.
>>
>> I am -1 on changing our existing commands, to adopt to such concept for
>> the
>> reasons already explained.
>>
>>
>
> --
> - Apache Karaf  Committer&  PMC
> - OPS4J Pax 
> Web>
>Committer&  Project Lead
> - Blog>
>
>

Re: [HEADS UP] Ssh agent and key authentication support

[Achim Nierbeck]

Hi Guillaume,

I'm fine with the way it is, and I think a documentation warning
together with a warning in the console is sufficient enough.
Since it's possible to color the input we should put a nice "nasty"
coloring to this warning that'll catch attention.

regards, Achim

Am 25.05.2012 18:34, schrieb Guillaume Nodet:

So Christian has expressed concerns with the current state:
   "Currently we create a private key at build time and allow full
access with this key by default. I think this opens a big security
hole. Of course the same is true for the karaf:karaf user. What makes
the private key more dangerous is that people might not see this hole
as easily as the default user. So I think we should not do this.
Instead I propose to create a key at runtime and use it to connect to
the local instance. We could store the generated private key in the
user dir to make sure it is at a safe place."

We had a chat on IRC so I'll try to summarize my thinking as well.

The current state uses a static private key.  The main idea was to be
able in development mode, to easily access remote instances without
any additional configurations.  The private key is used by the console
(when karaf is started with bin/karaf) and also by the bin/client for
default authentication.
To disable that (which is obviously bad when putting karaf in
production, as I explained in an earlier mail), one has to disable the
line in etc/keys.properties and etc/users.properties.
This is similar to what we had with the default login / password and
hardcoded password in ssh:ssh and bin/client, so I don't really see
that as a real problem.

I propose to add a warning to the console and log when starting karaf
with such a default key enabled (i.e. the default key is available to
log in) instead, so that we could keep the ability to easily connect
to any instance at development time without additional configuration.

Thoughts welcomed.

On Fri, May 18, 2012 at 1:56 PM, Guillaume Nodet  wrote:

I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
it to trunk next week).
This changes the way the ssh authentication default mechanism works to
leverage ssh agent forwarding and key based authentication.
In short, the default ssh and admin:connect command don't use the
karaf/karaf login/password authentication by default, but use the ssh
agent instead.
The default console uses an internal key which is accepted by adding
the public part in etc/authorized_keys and a local ssh agent which
will be used by default when using ssh / admin:connect command.
When connecting from the outside, one should use the ssh agent
forwarding on the client (ssh -l 8101 -A localhost), and that will
allow you to automatically connect to other karaf instances if the key
is supported too.
Basically, what this means is that the usual default (i.e. you don't
have to specify the password anyway) should work in a real environment
where the default password / key has been changed.

One thing I just realized I forgot is to enhance the bin/client script
to also use the same private key by default.
Another thing I found (and need to fix), is that the public key
authentication mechanism does not really check the association between
the key used and the user: i.e. any username can be used with any
known key, which is quite bad.  Possible enhancements also include a
way to change the "default" key which is used when starting a usual
karaf ; however, given I don't think that's much used in real
production environment, I think this is quite minor and kinda force
the user to use karaf the "right" way.  The first step before putting
karaf in prod would be to disallow the default public key and start
karaf using bin/start instead of bin/karaf.

Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.

I'll fix some of the above things next week, and I then plan to start
working on role based authentication on the shell somehow (one thing
we can imagine is a su/sudo mode or something similar).  I really
can't bear the confirmation that are prompted any time you want to do
something with bundles anymore, so I think it's time for something
more powerful and flexible.

--

Guillaume Nodet

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

FuseSource, Integration everywhere
http://fusesource.com






--
- Apache Karaf  Committer&  PMC
- OPS4J Pax WebCommitter&  
Project Lead
- Blog

Re: Add a scope feature-url

[Achim Nierbeck]

Christian,

basically I just can repeat myself I don't see much of a difference, and 
again I have to
second Ioannis for the reasons. And the thing that really made me do a 
-1 here

our Users don't see a reason to change either.
This is just a repetition of all what has been said/written before

Achim


Am 25.05.2012 19:10, schrieb Ioannis Canellos:

So having "feature:repo:list" sounds better to me than "feature:repo-list".


The thing is that its not *that* better to justify a change and all the
effort that such a change requires (both from the broader community and
from our existing user).

Just to clarify. I do like the idea of nesting sub shells and the concept
of separating them using the ":" as it might be useful for downstream
projects or people building their custom distribution and have tens of
commands under single scope. So I am +1 to that part.

I am -1 on changing our existing commands, to adopt to such concept for the
reasons already explained.




--
- Apache Karaf  Committer&  PMC
- OPS4J Pax WebCommitter&  
Project Lead
- Blog

Re: [HEADS UP] Ssh agent and key authentication support

[Guillaume Nodet]

That's unix specific and we have windows users ...

On Fri, May 25, 2012 at 9:13 PM, Ioannis Canellos  wrote:
> I may lost some bits, but couldn't we just reuse the users keys and
> authorized hosts, instead of creating, adding or removing?
>
> --
> *Ioannis Canellos*
> *
> FuseSource 
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Twitter: iocanel
> *



-- 

Guillaume Nodet

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

FuseSource, Integration everywhere
http://fusesource.com

Re: [HEADS UP] Ssh agent and key authentication support

[Ioannis Canellos]

I may lost some bits, but couldn't we just reuse the users keys and
authorized hosts, instead of creating, adding or removing?

-- 
*Ioannis Canellos*
*
FuseSource 

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

Re: Add a scope feature-url

[Ioannis Canellos]

>
> So having "feature:repo:list" sounds better to me than "feature:repo-list".
>

The thing is that its not *that* better to justify a change and all the
effort that such a change requires (both from the broader community and
from our existing user).

Just to clarify. I do like the idea of nesting sub shells and the concept
of separating them using the ":" as it might be useful for downstream
projects or people building their custom distribution and have tens of
commands under single scope. So I am +1 to that part.

I am -1 on changing our existing commands, to adopt to such concept for the
reasons already explained.

-- 
*Ioannis Canellos*
*
FuseSource 

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

Re: [HEADS UP] Ssh agent and key authentication support

[Guillaume Nodet]

So Christian has expressed concerns with the current state:
  "Currently we create a private key at build time and allow full
access with this key by default. I think this opens a big security
hole. Of course the same is true for the karaf:karaf user. What makes
the private key more dangerous is that people might not see this hole
as easily as the default user. So I think we should not do this.
Instead I propose to create a key at runtime and use it to connect to
the local instance. We could store the generated private key in the
user dir to make sure it is at a safe place."

We had a chat on IRC so I'll try to summarize my thinking as well.

The current state uses a static private key.  The main idea was to be
able in development mode, to easily access remote instances without
any additional configurations.  The private key is used by the console
(when karaf is started with bin/karaf) and also by the bin/client for
default authentication.
To disable that (which is obviously bad when putting karaf in
production, as I explained in an earlier mail), one has to disable the
line in etc/keys.properties and etc/users.properties.
This is similar to what we had with the default login / password and
hardcoded password in ssh:ssh and bin/client, so I don't really see
that as a real problem.

I propose to add a warning to the console and log when starting karaf
with such a default key enabled (i.e. the default key is available to
log in) instead, so that we could keep the ability to easily connect
to any instance at development time without additional configuration.

Thoughts welcomed.

On Fri, May 18, 2012 at 1:56 PM, Guillaume Nodet  wrote:
> I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
> it to trunk next week).
> This changes the way the ssh authentication default mechanism works to
> leverage ssh agent forwarding and key based authentication.
> In short, the default ssh and admin:connect command don't use the
> karaf/karaf login/password authentication by default, but use the ssh
> agent instead.
> The default console uses an internal key which is accepted by adding
> the public part in etc/authorized_keys and a local ssh agent which
> will be used by default when using ssh / admin:connect command.
> When connecting from the outside, one should use the ssh agent
> forwarding on the client (ssh -l 8101 -A localhost), and that will
> allow you to automatically connect to other karaf instances if the key
> is supported too.
> Basically, what this means is that the usual default (i.e. you don't
> have to specify the password anyway) should work in a real environment
> where the default password / key has been changed.
>
> One thing I just realized I forgot is to enhance the bin/client script
> to also use the same private key by default.
> Another thing I found (and need to fix), is that the public key
> authentication mechanism does not really check the association between
> the key used and the user: i.e. any username can be used with any
> known key, which is quite bad.  Possible enhancements also include a
> way to change the "default" key which is used when starting a usual
> karaf ; however, given I don't think that's much used in real
> production environment, I think this is quite minor and kinda force
> the user to use karaf the "right" way.  The first step before putting
> karaf in prod would be to disallow the default public key and start
> karaf using bin/start instead of bin/karaf.
>
> Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
>
> I'll fix some of the above things next week, and I then plan to start
> working on role based authentication on the shell somehow (one thing
> we can imagine is a su/sudo mode or something similar).  I really
> can't bear the confirmation that are prompted any time you want to do
> something with bundles anymore, so I think it's time for something
> more powerful and flexible.
>
> --
> 
> Guillaume Nodet
> 
> Blog: http://gnodet.blogspot.com/
> 
> FuseSource, Integration everywhere
> http://fusesource.com



-- 

Guillaume Nodet

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

FuseSource, Integration everywhere
http://fusesource.com

Re: Add a scope feature-url

[Christian Schneider]

Ok so I will keep the noun-verb structure. Still I think we should 
consider moving the nouns to sub scopes.
We already use the scope as a noun like in "feature:list" instead of 
"feature-list". So having "feature:repo:list" sounds better to me than 
"feature:repo-list".


You are right though that we should be consinstent. So we either have to 
change all or keep all.


Christian


Am 25.05.2012 17:50, schrieb Ioannis Canellos:

I see the following problems here:

1. We have already communicated to our users that our future commands
structure will be scope:noun-verb and provided alias for this. Changing the
structure again seems not right.
2. We need to make sure that the whole ecosystem is using similar
command structure (e.g. camel, cxf, smx). If we are to change again we need
to coordinate the rest of the projects, too.
3. The added value is really small to justify a change that will affect
so many things (mostly refering to the impact to the projects providing
karaf commands).

So, I would prefer to keep things as they are now.




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[Christian Schneider]

Thanks for the explanations.

I don´t think I can address these concerns while keeping the original 
idea of using features like the startup.properties. So I closed the 
issue as wont fix.


Christian

Am 25.05.2012 17:34, schrieb Guillaume Nodet:

David said he didn't want xml processing in the bootstrap.  This
clearly has not been addressed.
Andreas said there's no value in your change because the file is now
fully generated.  This hasn't been addressed.
I said only supporting a subset of features schema is a problem.  This
hasn't been addressed.

I may have missed something.  But when people disagree, letting time
pass does not usually change things.
AFAIK, those concerns has been raised on the patch you uploaded, so
there's something wrong here.

On Fri, May 25, 2012 at 5:30 PM, Christian Schneider
  wrote:

I thought we had settled all these concerns.
So what are the concerns regarding the commit that make you -1 it?

During the discussion there were some concerns but I think my implementation
should have addressed all concerns. I created an issue and put up a patch.
This was available for 4 days now. Besides you no one else took the time to
review the patch.

So from your review you wrote you were concernd that the implementation does
not implement all features of the feature file and people might want more.
Does this really warrant a -1 ?

Christian

Am 25.05.2012 17:08, schrieb Guillaume Nodet:


Can you please revert.  I think 3 people expressed concerns with the
patch, so i'm officially -1 it until this concerns have been fully
addressed and we've reached a consensus.

On Fri, May 25, 2012 at 4:41 PM, Christian Schneider
wrote:

I have now committed the patch. So you should be able to test from trunk
now.


Christian

Am 23.05.2012 17:44, schrieb Andrei Pozolotin:

 Christian:


 I am curious

 1) are your changes are in current karaf 3 snapshot?

 2) do you have example/test project that shows how to build
 karaf distro w/o startup.properties, with minimal feature=framework
 only?

 3) or is the idea discarded?

 Thank you,

 Andrei


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com





--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com







--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Add a scope feature-url

[Ioannis Canellos]

I see the following problems here:

   1. We have already communicated to our users that our future commands
   structure will be scope:noun-verb and provided alias for this. Changing the
   structure again seems not right.
   2. We need to make sure that the whole ecosystem is using similar
   command structure (e.g. camel, cxf, smx). If we are to change again we need
   to coordinate the rest of the projects, too.
   3. The added value is really small to justify a change that will affect
   so many things (mostly refering to the impact to the projects providing
   karaf commands).

So, I would prefer to keep things as they are now.

-- 
*Ioannis Canellos*
*
FuseSource 

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

Re: Add a scope feature-url

[Christian Schneider]

Hi Achim,

would you mind to explain what you dislike?

Christian

Am 25.05.2012 17:18, schrieb Achim Nierbeck:

I see this as a valid show-stopper.
To give this some more weight, here's my official -1 for this idea!

Achim



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Add a scope feature-url

[Christian Schneider]

Most of the commands changed in karaf 3 as we swapped the order of 
verb-subject to subject verb. So unfortunately you will have do adapt a 
lot in your scripting.

My changes will not really make it worse.

Christian


Am 25.05.2012 17:11, schrieb Chris Geer:

On Fri, May 25, 2012 at 12:17 AM, Christian Schneider<
ch...@die-schneider.net>  wrote:


I looked into the feature commands a little deeper and I think I can do
more than just changing the scope.

See 
https://issues.apache.org/**jira/browse/KARAF-1502

I already did some of the implementation and I think it looks much better
than what we have now.

If the command names are going to be changing will there at least be alias

matching the existing commands by default, or easily enabled? I tend to
agree that the changes are minor enough for a human to figure out but we
tend to do a decent amount of scripting that uses these commands so
changing them will require a decent amount of rework on our part. It's not
the end of the world but aliases would at least cause this change to be
relatively non-breaking (unless the arguments are changing too) until we
got a chance to update all our scripts.

Chris


Christian

Am 22.05.2012 21:21, schrieb Ioannis Canellos:


In terms of completion this would make a difference. However, it is
lacking

context in my opinion.
For example when a user sees the repo scope, he can be easily get confused
and think that this refers to maven repos etc.

Generally, speaking we need to be careful regarding the commands scope.
If the scope is too generic, then it will gather a lot of commands under
it
and in the it will loose its purpose (such case were the osgi commands,
they used to be an umbrella for many different things).
On the other hand, if we normalize scopes too much and start
splitting concepts across different scopes. the number of scope will be
hard for the users to follow. Moreover, it will weaken the sub
shells concept (there will be not much use to enter a subshells with only
just a couple of commands).

The key here is balance. I feel the currently the features scope is well
balance and I think we should leave them as they are.



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com





--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[Guillaume Nodet]

David said he didn't want xml processing in the bootstrap.  This
clearly has not been addressed.
Andreas said there's no value in your change because the file is now
fully generated.  This hasn't been addressed.
I said only supporting a subset of features schema is a problem.  This
hasn't been addressed.

I may have missed something.  But when people disagree, letting time
pass does not usually change things.
AFAIK, those concerns has been raised on the patch you uploaded, so
there's something wrong here.

On Fri, May 25, 2012 at 5:30 PM, Christian Schneider
 wrote:
> I thought we had settled all these concerns.
> So what are the concerns regarding the commit that make you -1 it?
>
> During the discussion there were some concerns but I think my implementation
> should have addressed all concerns. I created an issue and put up a patch.
> This was available for 4 days now. Besides you no one else took the time to
> review the patch.
>
> So from your review you wrote you were concernd that the implementation does
> not implement all features of the feature file and people might want more.
> Does this really warrant a -1 ?
>
> Christian
>
> Am 25.05.2012 17:08, schrieb Guillaume Nodet:
>
>> Can you please revert.  I think 3 people expressed concerns with the
>> patch, so i'm officially -1 it until this concerns have been fully
>> addressed and we've reached a consensus.
>>
>> On Fri, May 25, 2012 at 4:41 PM, Christian Schneider
>>   wrote:
>>>
>>> I have now committed the patch. So you should be able to test from trunk
>>> now.
>>>
>>>
>>> Christian
>>>
>>> Am 23.05.2012 17:44, schrieb Andrei Pozolotin:

     Christian:


     I am curious

     1) are your changes are in current karaf 3 snapshot?

     2) do you have example/test project that shows how to build
     karaf distro w/o startup.properties, with minimal feature=framework
     only?

     3) or is the idea discarded?

     Thank you,

     Andrei

>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>



-- 

Guillaume Nodet

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

FuseSource, Integration everywhere
http://fusesource.com

Re: [Discuss] Handling of initial bundles

[Christian Schneider]

I thought we had settled all these concerns.
So what are the concerns regarding the commit that make you -1 it?

During the discussion there were some concerns but I think my 
implementation should have addressed all concerns. I created an issue 
and put up a patch. This was available for 4 days now. Besides you no 
one else took the time to review the patch.


So from your review you wrote you were concernd that the implementation 
does not implement all features of the feature file and people might 
want more. Does this really warrant a -1 ?


Christian

Am 25.05.2012 17:08, schrieb Guillaume Nodet:

Can you please revert.  I think 3 people expressed concerns with the
patch, so i'm officially -1 it until this concerns have been fully
addressed and we've reached a consensus.

On Fri, May 25, 2012 at 4:41 PM, Christian Schneider
  wrote:

I have now committed the patch. So you should be able to test from trunk
now.


Christian

Am 23.05.2012 17:44, schrieb Andrei Pozolotin:

 Christian:


 I am curious

 1) are your changes are in current karaf 3 snapshot?

 2) do you have example/test project that shows how to build
 karaf distro w/o startup.properties, with minimal feature=framework
 only?

 3) or is the idea discarded?

 Thank you,

 Andrei


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com







--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Add a scope feature-url

[Guillaume Nodet]

Right, I think we need to try to keep compatibility as much as possible.
We've had already aliases in 2.2.x and I actually think they're bad
for the following reasons:
  * they make the completion harder
  * they can't be relied upon until 3.0 has been released
I'd think aliases may be better placed in 3.0 to have backward
compatibility (instead of 2.x for forward compatibility) and I also
think they may be better written has being optional (i.e. having a
simple way to enable them - or eventually disable, depending on what
we choose).

On Fri, May 25, 2012 at 5:18 PM, Achim Nierbeck  wrote:
> I see this as a valid show-stopper.
> To give this some more weight, here's my official -1 for this idea!
>
> Achim
>
> 2012/5/25 Chris Geer :
>> On Fri, May 25, 2012 at 12:17 AM, Christian Schneider <
>> ch...@die-schneider.net> wrote:
>>
>>> I looked into the feature commands a little deeper and I think I can do
>>> more than just changing the scope.
>>>
>>> See 
>>> https://issues.apache.org/**jira/browse/KARAF-1502
>>>
>>> I already did some of the implementation and I think it looks much better
>>> than what we have now.
>>>
>>> If the command names are going to be changing will there at least be alias
>> matching the existing commands by default, or easily enabled? I tend to
>> agree that the changes are minor enough for a human to figure out but we
>> tend to do a decent amount of scripting that uses these commands so
>> changing them will require a decent amount of rework on our part. It's not
>> the end of the world but aliases would at least cause this change to be
>> relatively non-breaking (unless the arguments are changing too) until we
>> got a chance to update all our scripts.
>>
>> Chris
>>
>>>
>>> Christian
>>>
>>> Am 22.05.2012 21:21, schrieb Ioannis Canellos:
>>>
 In terms of completion this would make a difference. However, it is
 lacking

 context in my opinion.
 For example when a user sees the repo scope, he can be easily get confused
 and think that this refers to maven repos etc.

 Generally, speaking we need to be careful regarding the commands scope.
 If the scope is too generic, then it will gather a lot of commands under
 it
 and in the it will loose its purpose (such case were the osgi commands,
 they used to be an umbrella for many different things).
 On the other hand, if we normalize scopes too much and start
 splitting concepts across different scopes. the number of scope will be
 hard for the users to follow. Moreover, it will weaken the sub
 shells concept (there will be not much use to enter a subshells with only
 just a couple of commands).

 The key here is balance. I feel the currently the features scope is well
 balance and I think we should leave them as they are.


>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>>
>
>
>
> --
>
> Apache Karaf  Committer & PMC
> OPS4J Pax Web 
> Committer & Project Lead
> OPS4J Pax for Vaadin
>  Commiter & Project
> Lead
> blog 



-- 

Guillaume Nodet

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

FuseSource, Integration everywhere
http://fusesource.com

Re: Add a scope feature-url

[Achim Nierbeck]

I see this as a valid show-stopper.
To give this some more weight, here's my official -1 for this idea!

Achim

2012/5/25 Chris Geer :
> On Fri, May 25, 2012 at 12:17 AM, Christian Schneider <
> ch...@die-schneider.net> wrote:
>
>> I looked into the feature commands a little deeper and I think I can do
>> more than just changing the scope.
>>
>> See 
>> https://issues.apache.org/**jira/browse/KARAF-1502
>>
>> I already did some of the implementation and I think it looks much better
>> than what we have now.
>>
>> If the command names are going to be changing will there at least be alias
> matching the existing commands by default, or easily enabled? I tend to
> agree that the changes are minor enough for a human to figure out but we
> tend to do a decent amount of scripting that uses these commands so
> changing them will require a decent amount of rework on our part. It's not
> the end of the world but aliases would at least cause this change to be
> relatively non-breaking (unless the arguments are changing too) until we
> got a chance to update all our scripts.
>
> Chris
>
>>
>> Christian
>>
>> Am 22.05.2012 21:21, schrieb Ioannis Canellos:
>>
>>> In terms of completion this would make a difference. However, it is
>>> lacking
>>>
>>> context in my opinion.
>>> For example when a user sees the repo scope, he can be easily get confused
>>> and think that this refers to maven repos etc.
>>>
>>> Generally, speaking we need to be careful regarding the commands scope.
>>> If the scope is too generic, then it will gather a lot of commands under
>>> it
>>> and in the it will loose its purpose (such case were the osgi commands,
>>> they used to be an umbrella for many different things).
>>> On the other hand, if we normalize scopes too much and start
>>> splitting concepts across different scopes. the number of scope will be
>>> hard for the users to follow. Moreover, it will weaken the sub
>>> shells concept (there will be not much use to enter a subshells with only
>>> just a couple of commands).
>>>
>>> The key here is balance. I feel the currently the features scope is well
>>> balance and I think we should leave them as they are.
>>>
>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>



-- 

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

Re: Add a scope feature-url

[Chris Geer]

On Fri, May 25, 2012 at 12:17 AM, Christian Schneider <
ch...@die-schneider.net> wrote:

> I looked into the feature commands a little deeper and I think I can do
> more than just changing the scope.
>
> See 
> https://issues.apache.org/**jira/browse/KARAF-1502
>
> I already did some of the implementation and I think it looks much better
> than what we have now.
>
> If the command names are going to be changing will there at least be alias
matching the existing commands by default, or easily enabled? I tend to
agree that the changes are minor enough for a human to figure out but we
tend to do a decent amount of scripting that uses these commands so
changing them will require a decent amount of rework on our part. It's not
the end of the world but aliases would at least cause this change to be
relatively non-breaking (unless the arguments are changing too) until we
got a chance to update all our scripts.

Chris

>
> Christian
>
> Am 22.05.2012 21:21, schrieb Ioannis Canellos:
>
>> In terms of completion this would make a difference. However, it is
>> lacking
>>
>> context in my opinion.
>> For example when a user sees the repo scope, he can be easily get confused
>> and think that this refers to maven repos etc.
>>
>> Generally, speaking we need to be careful regarding the commands scope.
>> If the scope is too generic, then it will gather a lot of commands under
>> it
>> and in the it will loose its purpose (such case were the osgi commands,
>> they used to be an umbrella for many different things).
>> On the other hand, if we normalize scopes too much and start
>> splitting concepts across different scopes. the number of scope will be
>> hard for the users to follow. Moreover, it will weaken the sub
>> shells concept (there will be not much use to enter a subshells with only
>> just a couple of commands).
>>
>> The key here is balance. I feel the currently the features scope is well
>> balance and I think we should leave them as they are.
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>

Re: svn commit: r1342652 - in /karaf/trunk/main/src: main/java/org/apache/karaf/main/ test/java/org/apache/karaf/main/ test/resources/test-karaf-home/etc/

[Guillaume Nodet]

-1 see dev thread.
Please revert.

On Fri, May 25, 2012 at 4:40 PM,   wrote:
> Author: cschneider
> Date: Fri May 25 14:40:34 2012
> New Revision: 1342652
>
> URL: http://svn.apache.org/viewvc?rev=1342652&view=rev
> Log:
> KARAF-1296 Adding startup feature loading to main
>
> Added:
>    karaf/trunk/main/src/main/java/org/apache/karaf/main/FeatureReader.java
>    karaf/trunk/main/src/test/java/org/apache/karaf/main/FeatureReaderTest.java
> Modified:
>    karaf/trunk/main/src/main/java/org/apache/karaf/main/BundleInfo.java
>    karaf/trunk/main/src/main/java/org/apache/karaf/main/ConfigProperties.java
>    karaf/trunk/main/src/main/java/org/apache/karaf/main/Main.java
>    karaf/trunk/main/src/test/resources/test-karaf-home/etc/config.properties
>    karaf/trunk/main/src/test/resources/test-karaf-home/etc/startup.properties
>
> Modified: karaf/trunk/main/src/main/java/org/apache/karaf/main/BundleInfo.java
> URL: 
> http://svn.apache.org/viewvc/karaf/trunk/main/src/main/java/org/apache/karaf/main/BundleInfo.java?rev=1342652&r1=1342651&r2=1342652&view=diff
> ==
> --- karaf/trunk/main/src/main/java/org/apache/karaf/main/BundleInfo.java 
> (original)
> +++ karaf/trunk/main/src/main/java/org/apache/karaf/main/BundleInfo.java Fri 
> May 25 14:40:34 2012
> @@ -1,3 +1,21 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements.  See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership.  The ASF licenses this file
> + * to you under the Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance
> + * with the License.  You may obtain a copy of the License at
> + *
> + *   http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> + * software distributed under the License is distributed on an
> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + * KIND, either express or implied.  See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
>  package org.apache.karaf.main;
>
>  import java.net.URI;
>
> Modified: 
> karaf/trunk/main/src/main/java/org/apache/karaf/main/ConfigProperties.java
> URL: 
> http://svn.apache.org/viewvc/karaf/trunk/main/src/main/java/org/apache/karaf/main/ConfigProperties.java?rev=1342652&r1=1342651&r2=1342652&view=diff
> ==
> --- 
> karaf/trunk/main/src/main/java/org/apache/karaf/main/ConfigProperties.java 
> (original)
> +++ 
> karaf/trunk/main/src/main/java/org/apache/karaf/main/ConfigProperties.java 
> Fri May 25 14:40:34 2012
> @@ -95,6 +95,10 @@ public class ConfigProperties {
>     private static final String KARAF_SHUTDOWN_COMMAND = 
> "karaf.shutdown.command";
>
>     private static final String KARAF_SHUTDOWN_PID_FILE = 
> "karaf.shutdown.pid.file";
> +
> +    static final String KARAF_STARTUP_FEATURE_URI = 
> "karaf.startup.feature.uri";
> +
> +    private static final String KARAF_STARTUP_FEATURE_NAME = 
> "karaf.startup.feature.name";
>
>     private static final String DEFAULT_SHUTDOWN_COMMAND = "SHUTDOWN";
>
> @@ -133,6 +137,8 @@ public class ConfigProperties {
>     String includes;
>     String optionals;
>     File etcFolder;
> +    URI startupFeatureUri;
> +    String startupFeatureName;
>
>     public ConfigProperties() throws Exception {
>         this.karafHome = Utils.getKarafHome(ConfigProperties.class, 
> PROP_KARAF_HOME, ENV_KARAF_HOME);
> @@ -183,6 +189,10 @@ public class ConfigProperties {
>         this.shutdownHost = props.getProperty(KARAF_SHUTDOWN_HOST, 
> "localhost");
>         this.portFile = props.getProperty(KARAF_SHUTDOWN_PORT_FILE);
>         this.shutdownCommand = props.getProperty(KARAF_SHUTDOWN_COMMAND, 
> DEFAULT_SHUTDOWN_COMMAND);
> +        if (props.getProperty(KARAF_STARTUP_FEATURE_URI) != null) {
> +            this.startupFeatureUri = new 
> URI(props.getProperty(KARAF_STARTUP_FEATURE_URI));
> +        }
> +        this.startupFeatureName = 
> props.getProperty(KARAF_STARTUP_FEATURE_NAME, "framework");
>     }
>
>     private String getProperyOrFail(String propertyName) {
>
> Added: karaf/trunk/main/src/main/java/org/apache/karaf/main/FeatureReader.java
> URL: 
> http://svn.apache.org/viewvc/karaf/trunk/main/src/main/java/org/apache/karaf/main/FeatureReader.java?rev=1342652&view=auto
> ==
> --- karaf/trunk/main/src/main/java/org/apache/karaf/main/FeatureReader.java 
> (added)
> +++ karaf/trunk/main/src/main/java/org/apache/karaf/main/FeatureReader.java 
> Fri May 25 14:40:34 2012
> @@ -0,0 +1,68 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements.  See the NOTICE file
> + * 

Re: [Discuss] Handling of initial bundles

[Guillaume Nodet]

Can you please revert.  I think 3 people expressed concerns with the
patch, so i'm officially -1 it until this concerns have been fully
addressed and we've reached a consensus.

On Fri, May 25, 2012 at 4:41 PM, Christian Schneider
 wrote:
> I have now committed the patch. So you should be able to test from trunk
> now.
>
>
> Christian
>
> Am 23.05.2012 17:44, schrieb Andrei Pozolotin:
>>
>>     Christian:
>>
>>
>>     I am curious
>>
>>     1) are your changes are in current karaf 3 snapshot?
>>
>>     2) do you have example/test project that shows how to build
>>     karaf distro w/o startup.properties, with minimal feature=framework
>>     only?
>>
>>     3) or is the idea discarded?
>>
>>     Thank you,
>>
>>     Andrei
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>



-- 

Guillaume Nodet

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

FuseSource, Integration everywhere
http://fusesource.com

Re: [Discuss] Handling of initial bundles

[Christian Schneider]

I have now committed the patch. So you should be able to test from trunk 
now.


Christian

Am 23.05.2012 17:44, schrieb Andrei Pozolotin:

 Christian:

 I am curious

 1) are your changes are in current karaf 3 snapshot?

 2) do you have example/test project that shows how to build
 karaf distro w/o startup.properties, with minimal feature=framework
 only?

 3) or is the idea discarded?

 Thank you,

 Andrei



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Accessing to OSGI bean from a War

[Achim Nierbeck]

Hi,

I'd suggest using BluePrint or SpringDM too, that's something I have
done in the past and it worked quite well :)
Never the less I'm planning to add some specialties in the future to
pax-web to simplify this even more, see [1]

regards, Achim

[1] - http://team.ops4j.org/browse/PAXWEB-367

2012/5/24 Romain Gilles :
> If you want I can try to retrieve the configuration I was using at this
> time. What I know is that it was strongly based / inspired on the sample
> application of Virgo Greenpages sample
> http://www.eclipse.org/virgo/samples/ have
> a look to the documentation.
>
> Romain
>
> Le jeudi 24 mai 2012, Romain Gilles a écrit :
>
>> I'm remember that I was using spring dm feature to do it in a blueprint
>> way.
>> There is a specific filter to add to you web.xml and then you will get a
>> OsgiApplicationContext.
>> This application context is osgi ready and can work with spring and
>> blueprint file and therefore service published in your registry by other
>> bundles.
>>
>> Romain.
>>
>> Le jeudi 24 mai 2012, Guillaume Nodet a écrit :
>>
>>> Yes, it should work too, though the problem will be to communicate
>>> from the blueprint beans to the servlets (or the other way around),
>>> and there's no nice mechanism for that atm.
>>>
>>> On Thu, May 24, 2012 at 5:36 PM, djos06  wrote:
>>> > there is not a way to do it using blueprint ?
>>> >
>>> > --
>>> > View this message in context:
>>> http://karaf.922171.n3.nabble.com/Re-Accessing-to-OSGI-bean-from-a-War-tp4013579p4013750.html
>>> > Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> --
>>> 
>>> Guillaume Nodet
>>> 
>>> Blog: http://gnodet.blogspot.com/
>>> 
>>> FuseSource, Integration everywhere
>>> http://fusesource.com
>>>
>>



-- 

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

Re: Add a scope feature-url

[Christian Schneider]

I looked into the feature commands a little deeper and I think I can do 
more than just changing the scope.


See https://issues.apache.org/jira/browse/KARAF-1502

I already did some of the implementation and I think it looks much 
better than what we have now.


Christian

Am 22.05.2012 21:21, schrieb Ioannis Canellos:

In terms of completion this would make a difference. However, it is lacking
context in my opinion.
For example when a user sees the repo scope, he can be easily get confused
and think that this refers to maven repos etc.

Generally, speaking we need to be careful regarding the commands scope.
If the scope is too generic, then it will gather a lot of commands under it
and in the it will loose its purpose (such case were the osgi commands,
they used to be an umbrella for many different things).
On the other hand, if we normalize scopes too much and start
splitting concepts across different scopes. the number of scope will be
hard for the users to follow. Moreover, it will weaken the sub
shells concept (there will be not much use to enter a subshells with only
just a couple of commands).

The key here is balance. I feel the currently the features scope is well
balance and I think we should leave them as they are.




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com