You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Matt Sicker <bo...@gmail.com> on 2014/09/13 22:45:53 UTC
Would anyone be against simply copying the lifecycle standards from OSGi?
They're the most flexible. Quick overview of the life cycle in OSGi:
installed -> resolved -> (starting) -> active -> (stopping) resolved ->
uninstalled
Installed is the initial state. Resolved is when all its dependencies have
been fulfilled. During the starting state, if there is an error, then it
goes back to resolved. Active for while it's, well, active. Stopping puts
the thing back into resolved. Then, if you go from resolved to uninstalled,
this means that it's no longer available for use (and the only reason you'd
find something in this state for very long is due to a memory leak).
Any objections? This would make our LifeCycle interface more compatible
with OSGi while providing a well-understood standard for the life cycle of
plugin-type objects.
--
Matt Sicker <bo...@gmail.com>
Re: Would anyone be against simply copying the lifecycle standards from OSGi?
Posted by Ralph Goers <ra...@dslextreme.com>.
I think you are going to need something more concrete to convince me that emulating the OSGi Lifecycle is necessary.
Ralph
On Sep 13, 2014, at 7:07 PM, Matt Sicker <bo...@gmail.com> wrote:
> Having at least more than one boolean state will help with concurrency issues when starting/stopping a thing. Using the OSGi life cycle means that all platforms can have sufficient life cycle support for things that need to be managed as such. Spring may have only those three methods as Ralph pointed out, but it also provides several more life cycle related interfaces for more advanced life cycle behavior.
>
> As a Log4j plugin developer, I want to be able to add and remove my plugins at runtime (quite possibly after log4j-core et al. have already been started) in order to support OSGi in a more complete fashion. If my plugins get reloaded by OSGi for instance, then Log4j will have no idea what to do with the classes OSGi wants to unload (and most likely cause a memory leak). Having a more well-defined plugin life cycle will help me to develop and debug my own plugins.
>
> Also, as a Log4j customer, I want to be able to be able to start and stop plugins at runtime through JMX. This would work well with the failover appender as well as provide new opportunities for programmatic configuration.
>
> On 13 September 2014 20:58, Gary Gregory <ga...@gmail.com> wrote:
> Well... this is an interesting topic.
>
> At work and here at Log4j, and other personal projects I've introduced life cycle classes of different types.
>
> I've specifically not reused other frameworks for a simple reason, I was not going to pretend to co-exist and jump through hoops to follow the proper semantics of a 3rd party f/w. Call it NIH, call it YAGNI, call it what you will, that was my thought. The log4j LC f/w is a Log4j Core private thing.
>
> Now, I do understand that there are well thought out LC bits out there. OSGi is clearly high on the do it all list especially considering that it has been implemented many times (Eclipse is one example).
>
> So the question for me is: Is it worth redoing/changing the Log4j LC?
>
> At one extreme I see dumping as much of our bits as possible and using OSGi interfaces/classes. Could we get to the point where we could integrate "perfectly" and in the most OSGi-native manner with an OSGi container, sure. I bet we already do since we have an Activator.
>
> At the other extreme, I could see just adding the missing states and renaming the ones we have to match OSGi concepts.
>
> So, what are we trying to do here? What are our "user stories"? "As a Log4j developer, I want..."; "As a Log4j 3rd party plugin developer, I want..."; "As a Log4j customer, I want..."
>
> Let's start with those, shall we?
>
> :-)
>
> Gary
>
>
> On Sat, Sep 13, 2014 at 4:45 PM, Matt Sicker <bo...@gmail.com> wrote:
> They're the most flexible. Quick overview of the life cycle in OSGi:
>
> installed -> resolved -> (starting) -> active -> (stopping) resolved -> uninstalled
>
> Installed is the initial state. Resolved is when all its dependencies have been fulfilled. During the starting state, if there is an error, then it goes back to resolved. Active for while it's, well, active. Stopping puts the thing back into resolved. Then, if you go from resolved to uninstalled, this means that it's no longer available for use (and the only reason you'd find something in this state for very long is due to a memory leak).
>
> Any objections? This would make our LifeCycle interface more compatible with OSGi while providing a well-understood standard for the life cycle of plugin-type objects.
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Would anyone be against simply copying the lifecycle standards
from OSGi?
Posted by Matt Sicker <bo...@gmail.com>.
Having at least more than one boolean state will help with concurrency
issues when starting/stopping a thing. Using the OSGi life cycle means that
all platforms can have sufficient life cycle support for things that need
to be managed as such. Spring may have only those three methods as Ralph
pointed out, but it also provides several more life cycle related
interfaces for more advanced life cycle behavior.
As a Log4j plugin developer, I want to be able to add and remove my plugins
at runtime (quite possibly after log4j-core et al. have already been
started) in order to support OSGi in a more complete fashion. If my plugins
get reloaded by OSGi for instance, then Log4j will have no idea what to do
with the classes OSGi wants to unload (and most likely cause a memory
leak). Having a more well-defined plugin life cycle will help me to develop
and debug my own plugins.
Also, as a Log4j customer, I want to be able to be able to start and stop
plugins at runtime through JMX. This would work well with the failover
appender as well as provide new opportunities for programmatic
configuration.
On 13 September 2014 20:58, Gary Gregory <ga...@gmail.com> wrote:
> Well... this is an interesting topic.
>
> At work and here at Log4j, and other personal projects I've introduced
> life cycle classes of different types.
>
> I've specifically not reused other frameworks for a simple reason, I was
> not going to pretend to co-exist and jump through hoops to follow the
> proper semantics of a 3rd party f/w. Call it NIH, call it YAGNI, call it
> what you will, that was my thought. The log4j LC f/w is a Log4j Core
> private thing.
>
> Now, I do understand that there are well thought out LC bits out there.
> OSGi is clearly high on the do it all list especially considering that it
> has been implemented many times (Eclipse is one example).
>
> So the question for me is: Is it worth redoing/changing the Log4j LC?
>
> At one extreme I see dumping as much of our bits as possible and using
> OSGi interfaces/classes. Could we get to the point where we could integrate
> "perfectly" and in the most OSGi-native manner with an OSGi container,
> sure. I bet we already do since we have an Activator.
>
> At the other extreme, I could see just adding the missing states and
> renaming the ones we have to match OSGi concepts.
>
> So, what are we trying to do here? What are our "user stories"? "As a
> Log4j developer, I want..."; "As a Log4j 3rd party plugin developer, I
> want..."; "As a Log4j customer, I want..."
>
> Let's start with those, shall we?
>
> :-)
>
> Gary
>
>
> On Sat, Sep 13, 2014 at 4:45 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> They're the most flexible. Quick overview of the life cycle in OSGi:
>>
>> installed -> resolved -> (starting) -> active -> (stopping) resolved ->
>> uninstalled
>>
>> Installed is the initial state. Resolved is when all its dependencies
>> have been fulfilled. During the starting state, if there is an error, then
>> it goes back to resolved. Active for while it's, well, active. Stopping
>> puts the thing back into resolved. Then, if you go from resolved to
>> uninstalled, this means that it's no longer available for use (and the only
>> reason you'd find something in this state for very long is due to a memory
>> leak).
>>
>> Any objections? This would make our LifeCycle interface more compatible
>> with OSGi while providing a well-understood standard for the life cycle of
>> plugin-type objects.
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: Would anyone be against simply copying the lifecycle standards
from OSGi?
Posted by Gary Gregory <ga...@gmail.com>.
Well... this is an interesting topic.
At work and here at Log4j, and other personal projects I've introduced life
cycle classes of different types.
I've specifically not reused other frameworks for a simple reason, I was
not going to pretend to co-exist and jump through hoops to follow the
proper semantics of a 3rd party f/w. Call it NIH, call it YAGNI, call it
what you will, that was my thought. The log4j LC f/w is a Log4j Core
private thing.
Now, I do understand that there are well thought out LC bits out there.
OSGi is clearly high on the do it all list especially considering that it
has been implemented many times (Eclipse is one example).
So the question for me is: Is it worth redoing/changing the Log4j LC?
At one extreme I see dumping as much of our bits as possible and using OSGi
interfaces/classes. Could we get to the point where we could integrate
"perfectly" and in the most OSGi-native manner with an OSGi container,
sure. I bet we already do since we have an Activator.
At the other extreme, I could see just adding the missing states and
renaming the ones we have to match OSGi concepts.
So, what are we trying to do here? What are our "user stories"? "As a Log4j
developer, I want..."; "As a Log4j 3rd party plugin developer, I want...";
"As a Log4j customer, I want..."
Let's start with those, shall we?
:-)
Gary
On Sat, Sep 13, 2014 at 4:45 PM, Matt Sicker <bo...@gmail.com> wrote:
> They're the most flexible. Quick overview of the life cycle in OSGi:
>
> installed -> resolved -> (starting) -> active -> (stopping) resolved ->
> uninstalled
>
> Installed is the initial state. Resolved is when all its dependencies have
> been fulfilled. During the starting state, if there is an error, then it
> goes back to resolved. Active for while it's, well, active. Stopping puts
> the thing back into resolved. Then, if you go from resolved to uninstalled,
> this means that it's no longer available for use (and the only reason you'd
> find something in this state for very long is due to a memory leak).
>
> Any objections? This would make our LifeCycle interface more compatible
> with OSGi while providing a well-understood standard for the life cycle of
> plugin-type objects.
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Would anyone be against simply copying the lifecycle standards from OSGi?
Posted by Ralph Goers <ra...@dslextreme.com>.
Are you planning on implementing something for each of those phases? Spring’s Lifecycle contains start(), stop(), and isRunning(). JSF and Swing and I am sure many other things also have life cycles. We should implement the states we need because we need them, not to match some other technology.
Ralph
On Sep 13, 2014, at 1:45 PM, Matt Sicker <bo...@gmail.com> wrote:
> They're the most flexible. Quick overview of the life cycle in OSGi:
>
> installed -> resolved -> (starting) -> active -> (stopping) resolved -> uninstalled
>
> Installed is the initial state. Resolved is when all its dependencies have been fulfilled. During the starting state, if there is an error, then it goes back to resolved. Active for while it's, well, active. Stopping puts the thing back into resolved. Then, if you go from resolved to uninstalled, this means that it's no longer available for use (and the only reason you'd find something in this state for very long is due to a memory leak).
>
> Any objections? This would make our LifeCycle interface more compatible with OSGi while providing a well-understood standard for the life cycle of plugin-type objects.
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Would anyone be against simply copying the lifecycle standards
from OSGi?
Posted by Matt Sicker <bo...@gmail.com>.
Well, I think uninstalled would only apply when using OSGi unless we
implemented our own ClassLoaders that could unload code. Otherwise, we'd
have different semantics for what uninstalled means.
On 9 October 2014 08:58, Gary Gregory <ga...@gmail.com> wrote:
> If we were to use OSGi states, one thing that we would need to make sure
> works for us is: "An UNINSTALLED bundle can not be set to another state;
> it is a zombie and can only be reached because references are kept
> somewhere." [1]
>
> Gary
>
> [1] http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Bundle.html
>
> On Sun, Sep 14, 2014 at 1:01 AM, Matt Sicker <bo...@gmail.com> wrote:
>
>> Sounds good to me.
>>
>> On 13 September 2014 23:53, Gary Gregory <ga...@gmail.com> wrote:
>>
>>> Which ever way we go on this, let's get 2.1 out the door first. We have
>>> some nice new functionality for 2.1 already (JUL, IO streams). Once we fix
>>> our clock threading issue, I say we clean thing up and prepare 2.1.
>>>
>>> Gary
>>>
>>> On Sat, Sep 13, 2014 at 4:45 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> They're the most flexible. Quick overview of the life cycle in OSGi:
>>>>
>>>> installed -> resolved -> (starting) -> active -> (stopping) resolved ->
>>>> uninstalled
>>>>
>>>> Installed is the initial state. Resolved is when all its dependencies
>>>> have been fulfilled. During the starting state, if there is an error, then
>>>> it goes back to resolved. Active for while it's, well, active. Stopping
>>>> puts the thing back into resolved. Then, if you go from resolved to
>>>> uninstalled, this means that it's no longer available for use (and the only
>>>> reason you'd find something in this state for very long is due to a memory
>>>> leak).
>>>>
>>>> Any objections? This would make our LifeCycle interface more compatible
>>>> with OSGi while providing a well-understood standard for the life cycle of
>>>> plugin-type objects.
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: Would anyone be against simply copying the lifecycle standards
from OSGi?
Posted by Gary Gregory <ga...@gmail.com>.
If we were to use OSGi states, one thing that we would need to make sure
works for us is: "An UNINSTALLED bundle can not be set to another state; it
is a zombie and can only be reached because references are kept somewhere."
[1]
Gary
[1] http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Bundle.html
On Sun, Sep 14, 2014 at 1:01 AM, Matt Sicker <bo...@gmail.com> wrote:
> Sounds good to me.
>
> On 13 September 2014 23:53, Gary Gregory <ga...@gmail.com> wrote:
>
>> Which ever way we go on this, let's get 2.1 out the door first. We have
>> some nice new functionality for 2.1 already (JUL, IO streams). Once we fix
>> our clock threading issue, I say we clean thing up and prepare 2.1.
>>
>> Gary
>>
>> On Sat, Sep 13, 2014 at 4:45 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> They're the most flexible. Quick overview of the life cycle in OSGi:
>>>
>>> installed -> resolved -> (starting) -> active -> (stopping) resolved ->
>>> uninstalled
>>>
>>> Installed is the initial state. Resolved is when all its dependencies
>>> have been fulfilled. During the starting state, if there is an error, then
>>> it goes back to resolved. Active for while it's, well, active. Stopping
>>> puts the thing back into resolved. Then, if you go from resolved to
>>> uninstalled, this means that it's no longer available for use (and the only
>>> reason you'd find something in this state for very long is due to a memory
>>> leak).
>>>
>>> Any objections? This would make our LifeCycle interface more compatible
>>> with OSGi while providing a well-understood standard for the life cycle of
>>> plugin-type objects.
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Would anyone be against simply copying the lifecycle standards
from OSGi?
Posted by Matt Sicker <bo...@gmail.com>.
Sounds good to me.
On 13 September 2014 23:53, Gary Gregory <ga...@gmail.com> wrote:
> Which ever way we go on this, let's get 2.1 out the door first. We have
> some nice new functionality for 2.1 already (JUL, IO streams). Once we fix
> our clock threading issue, I say we clean thing up and prepare 2.1.
>
> Gary
>
> On Sat, Sep 13, 2014 at 4:45 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> They're the most flexible. Quick overview of the life cycle in OSGi:
>>
>> installed -> resolved -> (starting) -> active -> (stopping) resolved ->
>> uninstalled
>>
>> Installed is the initial state. Resolved is when all its dependencies
>> have been fulfilled. During the starting state, if there is an error, then
>> it goes back to resolved. Active for while it's, well, active. Stopping
>> puts the thing back into resolved. Then, if you go from resolved to
>> uninstalled, this means that it's no longer available for use (and the only
>> reason you'd find something in this state for very long is due to a memory
>> leak).
>>
>> Any objections? This would make our LifeCycle interface more compatible
>> with OSGi while providing a well-understood standard for the life cycle of
>> plugin-type objects.
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: Would anyone be against simply copying the lifecycle standards
from OSGi?
Posted by Gary Gregory <ga...@gmail.com>.
Which ever way we go on this, let's get 2.1 out the door first. We have
some nice new functionality for 2.1 already (JUL, IO streams). Once we fix
our clock threading issue, I say we clean thing up and prepare 2.1.
Gary
On Sat, Sep 13, 2014 at 4:45 PM, Matt Sicker <bo...@gmail.com> wrote:
> They're the most flexible. Quick overview of the life cycle in OSGi:
>
> installed -> resolved -> (starting) -> active -> (stopping) resolved ->
> uninstalled
>
> Installed is the initial state. Resolved is when all its dependencies have
> been fulfilled. During the starting state, if there is an error, then it
> goes back to resolved. Active for while it's, well, active. Stopping puts
> the thing back into resolved. Then, if you go from resolved to uninstalled,
> this means that it's no longer available for use (and the only reason you'd
> find something in this state for very long is due to a memory leak).
>
> Any objections? This would make our LifeCycle interface more compatible
> with OSGi while providing a well-understood standard for the life cycle of
> plugin-type objects.
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory