So what are the reasons why you dislike it? Delaying the start of the
shell till the deisred runlevel is reached mainly has the goal that all
commands are availble.
Currently we have this in 2.2.x:
A beginner types a command he knows should work on the shell as soon as
it opens. It complains t
yeah, thanks for the pointers, just with windows command-line is also
pita ... :/
2012/8/10 Freeman Fang :
> +1, the command line is more reliable in this case :-)
> －
> Freeman Fang
>
> FuseSource
> Email:ff...@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http:/
Fully agree.
Freeman
－
Freeman Fang
FuseSource
Email:ff...@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
On 2012-8-10, at 上午12:43, Andreas Pieber wrote:
> After
+1, the command line is more reliable in this case :-)
－
Freeman Fang
FuseSource
Email:ff...@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
On 2012-8-10, at 上午4:34,
see, that's the reason why I never ever let go of my console and give
the commit/push control to some ide toolings. command shell FTW :-D
On Thu, Aug 9, 2012 at 9:21 PM, Achim Nierbeck wrote:
> WTF, what happend here, just tried to get a disconnected repo
> connected again, sorry for this mess :/
WTF, what happend here, just tried to get a disconnected repo
connected again, sorry for this mess :/
I'll try to take care of it stupid eclipse
regards, Achim
2012/8/9 :
> Author: anierbeck
> Date: Thu Aug 9 19:18:19 2012
> New Revision: 1371394
>
> URL: http://svn.apache.org/viewvc?rev=
+1
2012/8/9 Johan Edstrom :
> I actually completely disagree.
> I don't think delaying a start is good, I think logging / screaming why it
> isn't starting might be good.
>
> On Aug 9, 2012, at 12:48 PM, Christian Schneider wrote:
>
>> I mostly agree besides for the default. I think we all agree
Christian,
I'm sorry but I don't see any agreement on delay beeing the better
option, or beeing the default.
If you think it's ok to have the delay for your customers I'm fine if
you apply it to your custom distribution.
I'm also fine with opening a way to tell the shell how long it should
wait. I
I actually completely disagree.
I don't think delaying a start is good, I think logging / screaming why it
isn't starting might be good.
On Aug 9, 2012, at 12:48 PM, Christian Schneider wrote:
> I mostly agree besides for the default. I think we all agree that the delayed
> start of the console
I mostly agree besides for the default. I think we all agree that the
delayed start of the console is the better option for beginners while
a lot of karaf developers like the console that starts directly.
For this reason I think we should have the delayed start as default for
two reasons:
1. We
nicely summed up; +1 :-)
Kind regards,
Andreas
On Thu, Aug 9, 2012 at 7:40 PM, Ioannis Canellos wrote:
> I've read a lot of interesting opinions and I'd like to share mine:
>
> i) The Karaf shell should start asap, unless explicitly configured. The
> enter thing is nice but should be optional im
I've read a lot of interesting opinions and I'd like to share mine:
i) The Karaf shell should start asap, unless explicitly configured. The
enter thing is nice but should be optional imho.
ii) Determining when Karaf is started is one thing, determining when an
application is started is another.
ii
what do you mean?
Kind regards,
Andreas
On Thu, Aug 9, 2012 at 6:45 PM, Johan Edstrom wrote:
> What about logging?
> Sorry :)
> On Aug 9, 2012, at 10:43 AM, Andreas Pieber wrote:
>
>> After reading the entire thread again I think we've got our wires
>> crossed. The entire point is NOT (!) to mak
What about logging?
Sorry :)
On Aug 9, 2012, at 10:43 AM, Andreas Pieber wrote:
> After reading the entire thread again I think we've got our wires
> crossed. The entire point is NOT (!) to make Karaf waiting for
> anything to start up per default; I second Christoph at this point: I
> think it's
After reading the entire thread again I think we've got our wires
crossed. The entire point is NOT (!) to make Karaf waiting for
anything to start up per default; I second Christoph at this point: I
think it's best if the default Karaf download works exactly as it does
in the 2.2.x branch: getting
@Charles, JB
I fully agree with you, where is the line to be drawn here?
Well anyone who is developing with Karaf should know it's a totally
different way of working instead of using a bloated JEE-Container.
This discussion somehow reminds me of a thread I once read on the
felix-ml "I don't want
Well said JB. This is exactly what I have explained this morning.
On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré wrote:
> Hi,
>
> I'm not fully agree.
>
> Karaf is a container, with the purpose to be fast, lightweight.
> So what does it mean "Karaf started" ?
>
> For instance, I gonna compa
Hi,
I'm not fully agree.
Karaf is a container, with the purpose to be fast, lightweight.
So what does it mean "Karaf started" ?
For instance, I gonna compare with JEE application server. When do you
consider that an application server is started:
- when the application server itself is up and
I understand that when using karaf as a developer one would want the
shell as fast as possible and don't wait for a minute or something.
That's why Christian implemented the "Press Enter to start it
anyway"-thing I think.
Maybe it's a better option to make it optional after all and disable it
in th
This is almost like the current solution.
The only difference is that the shell currently only starts when the
startlevel is reached or when the user presses enter.
I also thought about printing a message when karaf finished loading. The
problem is that the user might just be typing at that m
+2 pence.
On Aug 9, 2012, at 5:26 AM, Achim Nierbeck wrote:
> Hi,
>
> I have to second Jamie on this, cause right now I'm quite happy with
> having a shell right away so
> if I'm really in need for knowing if all bundles are up and runnig
> I'll do a "la" and I'm fine knowing how it's proceeding
Hi,
I have to second Jamie on this, cause right now I'm quite happy with
having a shell right away so
if I'm really in need for knowing if all bundles are up and runnig
I'll do a "la" and I'm fine knowing how it's proceeding.
For me there is no real need to hide the shell from users, cause let's
t
Just my 2 cents CAD...
I think that this effort may be leading to diminishing returns ..
there are many edge cases we may hit here, and i don't want to see
Karaf's console take minutes to become available. So here is my
alternative suggestion:
Allow Karaf console to come up as per start level as
Remember extenders can start bundles asynchronously, so the ReadyService
should be registered by the extender from an activator.
I'd think aries quiesce api could be a good location for that as it could
be included in blueprint.
However, failures should be taken into account in the api, as a failed
Hi Christoph,
the current implementation uses the start level as an indicator to start
the shell. So the shell starts once the FRAMEWORK_BEGINNING_STARTLEVEL
is reached. As by default we start blueprint contexts synchronously this
should be a quite good indicator that all desired bundles are up
25 matches
Mail list logo
