Would anyone be against simply copying the lifecycle standards from OSGi?

[Matt Sicker]

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.

[Ralph Goers]

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

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.
--

[Gary Gregory]

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

Post by Matt Sicker
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]

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.

Post by Gary Gregory
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

Post by Matt Sicker
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.
--

--
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

[Ralph Goers]

I think you are going to need something more concrete to convince me that emulating the OSGi Lifecycle is necessary.

Ralph

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.
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
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.
--
--
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
--

[Gary Gregory]

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

Post by Matt Sicker
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]

Sounds good to me.

Post by Gary Gregory
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

Post by Matt Sicker
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.
--

--
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

[Gary Gregory]

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

Post by Matt Sicker
Sounds good to me.

Post by Gary Gregory
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

Post by Matt Sicker
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.
--

--
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]

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.

Post by Gary Gregory
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

Post by Matt Sicker
Sounds good to me.

Post by Gary Gregory
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

Post by Matt Sicker
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.
--

--
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

--

--
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