Architecture Rules Forums › architecture-rules-dev

Re: Listener Implementation

15 messages

Re: Listener Implementation

Reply Threaded

> As you described there is a registerListener(Properties) method that is
> essentially an initialization method. It takes the Properties defined in the
> user's Configuration. The Listener may or may not need those Properties in
> order to initialize itself. So, yes, each Listener would have to know how to
> initialize itself. There is also the terminateListener method that would be
> responsible for cleaning up its resources and finishing any job that it was
> responsible for.

I was suggesting that it be two separate interfaces because there will be use-cases where listeners have no
resources to setup or clean up and forcing every listener to take on
that responsibility seems misplaced.

Alright. Lets forget that any Listener interface or implementation exists. Lets design the next hierarchy and layout the requirements for an even listening framework.

org.architecturerules.api.listener

   EventListener
      .onEvent(Event)

   ConfigurableEventListener
      .initialize(Properties)
      .terminate()

org.architecturerules.api.event

   Event

org.architecturerules.event
   RuleAddedEvent
   RuleRemovedEvent
   RuleViolatedEvent
   WildcardMatchedEvent
   many many more to come....

I don't like the name ConfigurableEventListener. Also, I'd like to split the initialize and terminate up into their own, because, for example, the ReportListener is only concerned with terminate.

   EventListener
      .onEvent(Event)

   InitilizableEventListener
      .initialize(Properties)

   TerminatableEventListener
      .terminate()

Now, since ReportListener didn't get the properties from initialize, they need to be tossed into terminate.

   EventListener
      .onEvent(Event)

   InitilizableEventListener
      .initialize(Properties)

   TerminatableEventListener
      .terminate(Properties)

New issues:

Find a better name for InitilizableEventListener and TerminatableEventListener.
Identity other classes that fall under or over the EventListener.

~ Mike Nereson

--~--~---------~--~----~------------~-------~--~----~
~~ http://architecturerules.googlecode.com/svn/docs/index.html
~~You received this message because you are subscribed to the Google Groups "architecture-rules-dev" group.
~~To post to this group, send email to [hidden email]
~~To unsubscribe from this group, send email to [hidden email]
~~For more options, visit this group at http://groups.google.com/group/architecture-rules-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Chris Dempsey

Re: Listener Implementation

Reply Threaded

Let me take a deep dive into the ReportListener so that I can understand the use-case better.

On Sat, Aug 30, 2008 at 7:32 PM, Mike Nereson <[hidden email]> wrote:

> As you described there is a registerListener(Properties) method that is
> essentially an initialization method. It takes the Properties defined in the
> user's Configuration. The Listener may or may not need those Properties in
> order to initialize itself. So, yes, each Listener would have to know how to
> initialize itself. There is also the terminateListener method that would be
> responsible for cleaning up its resources and finishing any job that it was
> responsible for.

I was suggesting that it be two separate interfaces because there will be use-cases where listeners have no
resources to setup or clean up and forcing every listener to take on
that responsibility seems misplaced.

Alright. Lets forget that any Listener interface or implementation exists. Lets design the next hierarchy and layout the requirements for an even listening framework.

org.architecturerules.api.listener

   EventListener
      .onEvent(Event)

   ConfigurableEventListener
      .initialize(Properties)
      .terminate()

org.architecturerules.api.event

   Event

org.architecturerules.event
   RuleAddedEvent
   RuleRemovedEvent
   RuleViolatedEvent
   WildcardMatchedEvent
   many many more to come....

I don't like the name ConfigurableEventListener. Also, I'd like to split the initialize and terminate up into their own, because, for example, the ReportListener is only concerned with terminate.

   EventListener
      .onEvent(Event)

   InitilizableEventListener
      .initialize(Properties)

   TerminatableEventListener
      .terminate()

Now, since ReportListener didn't get the properties from initialize, they need to be tossed into terminate.

   EventListener
      .onEvent(Event)

   InitilizableEventListener
      .initialize(Properties)

   TerminatableEventListener
      .terminate(Properties)

New issues:

Find a better name for InitilizableEventListener and TerminatableEventListener.

Identity other classes that fall under or over the EventListener.

~ Mike Nereson

--~--~---------~--~----~------------~-------~--~----~
~~ http://architecturerules.googlecode.com/svn/docs/index.html
~~You received this message because you are subscribed to the Google Groups "architecture-rules-dev" group.
~~To post to this group, send email to [hidden email]
~~To unsubscribe from this group, send email to [hidden email]
~~For more options, visit this group at http://groups.google.com/group/architecture-rules-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Chris Dempsey

Re: Listener Implementation

Reply Threaded

Nevermind! ReportListener is empty. lol

I started on a rough implementation to make sure that I wasn't crazy
and I've extended the java.util.EventListener and
java.util.EventObject from the JDK as the basis of the listener code.
Extending those into AbstractEvent and AbstractEventListener seems
okay so far.

I'm guessing we're wanting to expose the configuration and tear down
of the listeners to enable us to control when we grab or clean up
resources that we might be holding on to in the listener at a specific
point in time? Say a database connection or a file handle, for
example? If so we may simply want to call the interfaces Configurable
and Finalizable. If we do that we could re-use the interfaces if we
decided to support custom plug-ins to AR in the future.

On Aug 31, 12:50 pm, "Chris Dempsey" <[hidden email]> wrote:

> Let me take a deep dive into the ReportListener so that I can understand the
> use-case better.
>
>
>
> On Sat, Aug 30, 2008 at 7:32 PM, Mike Nereson <[hidden email]> wrote:
> > > As you described there is a registerListener(Properties) method that is
> >> > essentially an initialization method. It takes the Properties defined in
> >> the
> >> > user's Configuration. The Listener may or may not need those Properties
> >> in
> >> > order to initialize itself. So, yes, each Listener would have to know
> >> how to
> >> > initialize itself. There is also the terminateListener method that would
> >> be
> >> > responsible for cleaning up its resources and finishing any job that it
> >> was
> >> > responsible for.
>
> >> I was suggesting that it be two separate interfaces because there will be
> >> use-cases where listeners have no
> >> resources to setup or clean up and forcing every listener to take on
> >> that responsibility seems misplaced.
>
> > Alright. Lets forget that any Listener interface or implementation exists.
> > Lets design the next hierarchy and layout the requirements for an even
> > listening framework.
>
> > org.architecturerules.api.listener
>
> > EventListener
> > .onEvent(Event)
>
> > ConfigurableEventListener
> > .initialize(Properties)
> > .terminate()
>
> > org.architecturerules.api.event
>
> > Event
>
> > org.architecturerules.event
> > RuleAddedEvent
> > RuleRemovedEvent
> > RuleViolatedEvent
> > WildcardMatchedEvent
> > many many more to come....
>
> > I don't like the name ConfigurableEventListener. Also, I'd like to split
> > the initialize and terminate up into their own, because, for example, the
> > ReportListener is only concerned with terminate.
>
> > EventListener
> > .onEvent(Event)
>
> > InitilizableEventListener
> > .initialize(Properties)
>
> > TerminatableEventListener
> > .terminate()
>
> > Now, since ReportListener didn't get the properties from initialize, they
> > need to be tossed into terminate.
>
> > EventListener
> > .onEvent(Event)
>
> > InitilizableEventListener
> > .initialize(Properties)
>
> > TerminatableEventListener
> > .terminate(Properties)
>
> > New issues:
>
> > - Find a better name for InitilizableEventListener and
> > TerminatableEventListener.
> > - Identity other classes that fall under or over the EventListener.
>
> > ~ Mike Nereson- Hide quoted text -
>
> - Show quoted text -

mikenereson

Re: Listener Implementation

Reply Threaded

Nevermind! ReportListener is empty. lol

I prototyped the output of the XML report here http://code.google.com/p/architecturerules/issues/detail?id=60

That, like anything else, is up for review. If anyone has any comments or questions about it.

I foresee the XML report being used by third parties, as well as being used by our Maven site report and so that is the only use case that I have for the report. Users have asked for an XML output. I don't know if they have plans for the output or not. If we wanted to, we could make a Hudson plugin, which would also read the contents of the XML output. A Hudson plugin would be good for our future. It should help us snag some new users since Hudson is a big hit and pluggable.

I'm guessing we're wanting to expose the configuration and tear down
of the listeners to enable us to control when we grab or clean up
resources that we might be holding on to in the listener at a specific
point in time? Say a database connection or a file handle, for
example?

Yes, ReportListener will output to a File. It could stream the output to the file as the events occur, in which case the file is created and opened in the ReportListener initalization, or it could do one major file write in the terminate method, in which initialize is not needed for the ReportListener. Either one works for me.

If so we may simply want to call the interfaces Configurable
and Finalizable. If we do that we could re-use the interfaces if we
decided to support custom plug-ins to AR in the future.

Thats good for reusability, but make requires the interfaces to be more generic. We need to pass the Properties to both methods.

~ Mike Nereson

On Sun, Aug 31, 2008 at 2:58 PM, cdempsey <[hidden email]> wrote:

Nevermind! ReportListener is empty. lol

I started on a rough implementation to make sure that I wasn't crazy
and I've extended the java.util.EventListener and
java.util.EventObject from the JDK as the basis of the listener code.
Extending those into AbstractEvent and AbstractEventListener seems
okay so far.

I'm guessing we're wanting to expose the configuration and tear down
of the listeners to enable us to control when we grab or clean up
resources that we might be holding on to in the listener at a specific
point in time? Say a database connection or a file handle, for
example? If so we may simply want to call the interfaces Configurable
and Finalizable. If we do that we could re-use the interfaces if we
decided to support custom plug-ins to AR in the future.

On Aug 31, 12:50 pm, "Chris Dempsey" <[hidden email]> wrote:
> Let me take a deep dive into the ReportListener so that I can understand the
> use-case better.
>
>
>

> On Sat, Aug 30, 2008 at 7:32 PM, Mike Nereson <[hidden email]> wrote:
> > > As you described there is a registerListener(Properties) method that is
> >> > essentially an initialization method. It takes the Properties defined in
> >> the
> >> > user's Configuration. The Listener may or may not need those Properties
> >> in
> >> > order to initialize itself. So, yes, each Listener would have to know
> >> how to
> >> > initialize itself. There is also the terminateListener method that would
> >> be
> >> > responsible for cleaning up its resources and finishing any job that it
> >> was
> >> > responsible for.
>
> >> I was suggesting that it be two separate interfaces because there will be
> >> use-cases where listeners have no
> >> resources to setup or clean up and forcing every listener to take on
> >> that responsibility seems misplaced.
>
> > Alright. Lets forget that any Listener interface or implementation exists.
> > Lets design the next hierarchy and layout the requirements for an even
> > listening framework.
>
> > org.architecturerules.api.listener
>
> > EventListener
> > .onEvent(Event)
>
> > ConfigurableEventListener
> > .initialize(Properties)
> > .terminate()
>
> > org.architecturerules.api.event
>
> > Event
>
> > org.architecturerules.event
> > RuleAddedEvent
> > RuleRemovedEvent
> > RuleViolatedEvent
> > WildcardMatchedEvent
> > many many more to come....
>
> > I don't like the name ConfigurableEventListener. Also, I'd like to split
> > the initialize and terminate up into their own, because, for example, the
> > ReportListener is only concerned with terminate.
>
> > EventListener
> > .onEvent(Event)
>
> > InitilizableEventListener
> > .initialize(Properties)
>
> > TerminatableEventListener
> > .terminate()
>
> > Now, since ReportListener didn't get the properties from initialize, they
> > need to be tossed into terminate.
>
> > EventListener
> > .onEvent(Event)
>
> > InitilizableEventListener
> > .initialize(Properties)
>
> > TerminatableEventListener
> > .terminate(Properties)
>
> > New issues:
>
> > - Find a better name for InitilizableEventListener and
> > TerminatableEventListener.
> > - Identity other classes that fall under or over the EventListener.
>

> > ~ Mike Nereson- Hide quoted text -
>
> - Show quoted text -

Chris Dempsey

Re: Listener Implementation

Reply Threaded

I prototyped the output of the XML report here http://code.google.com/p/architecturerules/issues/detail?id=60

That, like anything else, is up for review. If anyone has any comments or questions about it.

I foresee the XML report being used by third parties, as well as being used by our Maven site report and so that is the only use case that I have for the report. Users have asked for an XML output. I don't know if they have plans for the output or not. If we wanted to, we could make a Hudson plugin, which would also read the contents of the XML output. A Hudson plugin would be good for our future. It should help us snag some new users since Hudson is a big hit and pluggable.

Good job! I'll wander over and take a look at it ASAP.

Yes, ReportListener will output to a File. It could stream the output to the file as the events occur, in which case the file is created and opened in the ReportListener initalization, or it could do one major file write in the terminate method, in which initialize is not needed for the ReportListener. Either one works for me.

I think following the principle of least surprise and the general idea that a method does one thing developers wouldn't expect file writes to happen within a "terminate" method. I suppose it would be like waiting to issue SQL statements to the database on a connection.close() call.

Thats good for reusability, but make requires the interfaces to be more generic. We need to pass the Properties to both methods.

We could generify the interfaces (Configurable<T>, Finalizable<T>) and let implementations choose the structure for passing in the configuration / tear down data. Just thinking out loud here but shouldn't the listener implementation know how to clean up after itself (it knows it has files to clean up, for example)? If so, then Finalizable wouldn't need parameters at all. It would just be a hook method we would call from the main AR processing flow to give listeners time to clean up after themselves before we shutdown.

On Sun, Aug 31, 2008 at 2:36 PM, Mike Nereson <[hidden email]> wrote:

Nevermind! ReportListener is empty. lol

I prototyped the output of the XML report here http://code.google.com/p/architecturerules/issues/detail?id=60

That, like anything else, is up for review. If anyone has any comments or questions about it.

I foresee the XML report being used by third parties, as well as being used by our Maven site report and so that is the only use case that I have for the report. Users have asked for an XML output. I don't know if they have plans for the output or not. If we wanted to, we could make a Hudson plugin, which would also read the contents of the XML output. A Hudson plugin would be good for our future. It should help us snag some new users since Hudson is a big hit and pluggable.

I'm guessing we're wanting to expose the configuration and tear down
of the listeners to enable us to control when we grab or clean up
resources that we might be holding on to in the listener at a specific
point in time? Say a database connection or a file handle, for
example?

Yes, ReportListener will output to a File. It could stream the output to the file as the events occur, in which case the file is created and opened in the ReportListener initalization, or it could do one major file write in the terminate method, in which initialize is not needed for the ReportListener. Either one works for me.

If so we may simply want to call the interfaces Configurable
and Finalizable. If we do that we could re-use the interfaces if we
decided to support custom plug-ins to AR in the future.

Thats good for reusability, but make requires the interfaces to be more generic. We need to pass the Properties to both methods.

~ Mike Nereson

On Sun, Aug 31, 2008 at 2:58 PM, cdempsey <[hidden email]> wrote:

Nevermind! ReportListener is empty. lol

I started on a rough implementation to make sure that I wasn't crazy
and I've extended the java.util.EventListener and
java.util.EventObject from the JDK as the basis of the listener code.
Extending those into AbstractEvent and AbstractEventListener seems
okay so far.

I'm guessing we're wanting to expose the configuration and tear down
of the listeners to enable us to control when we grab or clean up
resources that we might be holding on to in the listener at a specific
point in time? Say a database connection or a file handle, for
example? If so we may simply want to call the interfaces Configurable
and Finalizable. If we do that we could re-use the interfaces if we
decided to support custom plug-ins to AR in the future.

On Aug 31, 12:50 pm, "Chris Dempsey" <[hidden email]> wrote:
> Let me take a deep dive into the ReportListener so that I can understand the
> use-case better.
>
>
>

> On Sat, Aug 30, 2008 at 7:32 PM, Mike Nereson <[hidden email]> wrote:
> > > As you described there is a registerListener(Properties) method that is
> >> > essentially an initialization method. It takes the Properties defined in
> >> the
> >> > user's Configuration. The Listener may or may not need those Properties
> >> in
> >> > order to initialize itself. So, yes, each Listener would have to know
> >> how to
> >> > initialize itself. There is also the terminateListener method that would
> >> be
> >> > responsible for cleaning up its resources and finishing any job that it
> >> was
> >> > responsible for.
>
> >> I was suggesting that it be two separate interfaces because there will be
> >> use-cases where listeners have no
> >> resources to setup or clean up and forcing every listener to take on
> >> that responsibility seems misplaced.
>
> > Alright. Lets forget that any Listener interface or implementation exists.
> > Lets design the next hierarchy and layout the requirements for an even
> > listening framework.
>
> > org.architecturerules.api.listener
>
> > EventListener
> > .onEvent(Event)
>
> > ConfigurableEventListener
> > .initialize(Properties)
> > .terminate()
>
> > org.architecturerules.api.event
>
> > Event
>
> > org.architecturerules.event
> > RuleAddedEvent
> > RuleRemovedEvent
> > RuleViolatedEvent
> > WildcardMatchedEvent
> > many many more to come....
>
> > I don't like the name ConfigurableEventListener. Also, I'd like to split
> > the initialize and terminate up into their own, because, for example, the
> > ReportListener is only concerned with terminate.
>
> > EventListener
> > .onEvent(Event)
>
> > InitilizableEventListener
> > .initialize(Properties)
>
> > TerminatableEventListener
> > .terminate()
>
> > Now, since ReportListener didn't get the properties from initialize, they
> > need to be tossed into terminate.
>
> > EventListener
> > .onEvent(Event)
>
> > InitilizableEventListener
> > .initialize(Properties)
>
> > TerminatableEventListener
> > .terminate(Properties)
>
> > New issues:
>
> > - Find a better name for InitilizableEventListener and
> > TerminatableEventListener.
> > - Identity other classes that fall under or over the EventListener.
>
> > ~ Mike Nereson- Hide quoted text -
>
> - Show quoted text -

--~--~---------~--~----~------------~-------~--~----~
~~ http://architecturerules.googlecode.com/svn/docs/index.html
~~You received this message because you are subscribed to the Google Groups "architecture-rules-dev" group.
~~To post to this group, send email to [hidden email]
~~To unsubscribe from this group, send email to [hidden email]
~~For more options, visit this group at http://groups.google.com/group/architecture-rules-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

mikenereson

Re: Listener Implementation

Reply Threaded

Just thinking out loud here but shouldn't the listener implementation know how to clean up after itself (it knows it has files to clean up, for example)? If so, then Finalizable wouldn't need parameters at all. It would just be a hook method we would call from the main AR processing flow to give listeners time to clean up after themselves before we shutdown.

Depends. ReportListener needs to know where to output the report to and what format to output as. That information comes in Properties. So, if finalize writes the file, the initialize doesn't do anything so initialize would not be neccessary. If initialize(Properties) is not used, then ReportListener still needs to get the Properties to know where to output the file too. The other option is to implement initalize(Properties) just to store a reference to the properties.

On the other hand, if the file output is streamed as the events occur, then we will need initialize, and finalize will just close the file.

I think following the principle of least surprise and the general idea that a method does one thing developers wouldn't expect file writes to happen within a "terminate" method. I suppose it would be like waiting to issue SQL statements to the database on a connection.close() call.

I like the idea of streaming the data out to the file. And it sounds like you'd agree?

Chris Dempsey

Re: Listener Implementation

Reply Threaded

I like the idea of streaming the data out to the file. And it sounds like you'd agree?

Yup! I totally agree that is the way to go.

On Sun, Aug 31, 2008 at 3:56 PM, Mike Nereson <[hidden email]> wrote:

Just thinking out loud here but shouldn't the listener implementation know how to clean up after itself (it knows it has files to clean up, for example)? If so, then Finalizable wouldn't need parameters at all. It would just be a hook method we would call from the main AR processing flow to give listeners time to clean up after themselves before we shutdown.

Depends. ReportListener needs to know where to output the report to and what format to output as. That information comes in Properties. So, if finalize writes the file, the initialize doesn't do anything so initialize would not be neccessary. If initialize(Properties) is not used, then ReportListener still needs to get the Properties to know where to output the file too. The other option is to implement initalize(Properties) just to store a reference to the properties.

On the other hand, if the file output is streamed as the events occur, then we will need initialize, and finalize will just close the file.

I think following the principle of least surprise and the general idea that a method does one thing developers wouldn't expect file writes to happen within a "terminate" method. I suppose it would be like waiting to issue SQL statements to the database on a connection.close() call.

I like the idea of streaming the data out to the file. And it sounds like you'd agree?

--~--~---------~--~----~------------~-------~--~----~
~~ http://architecturerules.googlecode.com/svn/docs/index.html
~~You received this message because you are subscribed to the Google Groups "architecture-rules-dev" group.
~~To post to this group, send email to [hidden email]
~~To unsubscribe from this group, send email to [hidden email]
~~For more options, visit this group at http://groups.google.com/group/architecture-rules-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Chris Dempsey

Re: Listener Implementation

Reply Threaded

Is there anything you'd like help on with the listeners, Mike? Or
should I take a look at some of the issues first?

On Aug 31, 5:54 pm, "Chris Dempsey" <[hidden email]> wrote:

> > I like the idea of streaming the data out to the file. And it sounds like
> > you'd agree?
>
> Yup! I totally agree that is the way to go.
>
>
>
> On Sun, Aug 31, 2008 at 3:56 PM, Mike Nereson <[hidden email]> wrote:
> > Just thinking out loud here but shouldn't the listener implementation
> >> know how to clean up after itself (*it knows it has files to clean up,
> >> for example*)? If so, then Finalizable wouldn't need parameters at all.
> >> It would just be a hook method we would call from the main AR processing
> >> flow to give listeners time to clean up after themselves before we shutdown.
>
> > Depends. ReportListener needs to know where to output the report to and
> > what format to output as. That information comes in Properties. So, if
> > finalize writes the file, the initialize doesn't do anything so initialize
> > would not be neccessary. If initialize(Properties) is not used, then
> > ReportListener still needs to get the Properties to know where to output the
> > file too. The other option is to implement initalize(Properties) just to
> > store a reference to the properties.
>
> > On the other hand, if the file output is streamed as the events occur, then
> > we will need initialize, and finalize will just close the file.
>
> > I think following the principle of least surprise<http://en.wikipedia.org/wiki/Principle_of_least_surprise>and the general idea that a method does one thing developers wouldn't expect
> >> file writes to happen within a "terminate" method. I suppose it would be
> >> like waiting to issue SQL statements to the database on a connection.close()
> >> call.
>
> > I like the idea of streaming the data out to the file. And it sounds like
> > you'd agree?- Hide quoted text -
>
> - Show quoted text -

mikenereson

Re: Listener Implementation

Reply Threaded

Chris,

You've invested a good amount of time into reviewing the current listener setup, and clearly have a good idea as to how you'd implement an even better setup. I have already thrown up some code which should demonstrate what I was going for, and you've seen the XML report which is the current end goal of the listeners. I think you are more than well enough equiped with the requirements and experience to implement the even listener.

I have plenty of other tasks that I could be working on and have to particular preference. I think we'd be pretty well off if you took on the even listeners while I hit up one of the other issues or finish up some unfinished tasks (like default-architecture-rules.xml and proper tests for reading properties.)

So yes, if you want to take on the listeners, please have at it.

~ Mike Nereson

On Mon, Sep 1, 2008 at 12:04 PM, cdempsey <[hidden email]> wrote:

Is there anything you'd like help on with the listeners, Mike? Or
should I take a look at some of the issues first?

On Aug 31, 5:54 pm, "Chris Dempsey" <[hidden email]> wrote:
> > I like the idea of streaming the data out to the file. And it sounds like
> > you'd agree?
>
> Yup! I totally agree that is the way to go.
>
>
>

> On Sun, Aug 31, 2008 at 3:56 PM, Mike Nereson <[hidden email]> wrote:
> > Just thinking out loud here but shouldn't the listener implementation
> >> know how to clean up after itself (*it knows it has files to clean up,
> >> for example*)? If so, then Finalizable wouldn't need parameters at all.
> >> It would just be a hook method we would call from the main AR processing
> >> flow to give listeners time to clean up after themselves before we shutdown.
>
> > Depends. ReportListener needs to know where to output the report to and
> > what format to output as. That information comes in Properties. So, if
> > finalize writes the file, the initialize doesn't do anything so initialize
> > would not be neccessary. If initialize(Properties) is not used, then
> > ReportListener still needs to get the Properties to know where to output the
> > file too. The other option is to implement initalize(Properties) just to
> > store a reference to the properties.
>
> > On the other hand, if the file output is streamed as the events occur, then
> > we will need initialize, and finalize will just close the file.
>

> > I think following the principle of least surprise<http://en.wikipedia.org/wiki/Principle_of_least_surprise>and the general idea that a method does one thing developers wouldn't expect

> >> file writes to happen within a "terminate" method. I suppose it would be
> >> like waiting to issue SQL statements to the database on a connection.close()
> >> call.
>
> > I like the idea of streaming the data out to the file. And it sounds like

> > you'd agree?- Hide quoted text -
>
> - Show quoted text -

Chris Dempsey

Re: Listener Implementation

Reply Threaded

Alrighty. I'll start moving on the listeners then. :)

On Mon, Sep 1, 2008 at 1:08 PM, Mike Nereson <[hidden email]> wrote:

Chris,

You've invested a good amount of time into reviewing the current listener setup, and clearly have a good idea as to how you'd implement an even better setup. I have already thrown up some code which should demonstrate what I was going for, and you've seen the XML report which is the current end goal of the listeners. I think you are more than well enough equiped with the requirements and experience to implement the even listener.

I have plenty of other tasks that I could be working on and have to particular preference. I think we'd be pretty well off if you took on the even listeners while I hit up one of the other issues or finish up some unfinished tasks (like default-architecture-rules.xml and proper tests for reading properties.)

So yes, if you want to take on the listeners, please have at it.

~ Mike Nereson

On Mon, Sep 1, 2008 at 12:04 PM, cdempsey <[hidden email]> wrote:

Is there anything you'd like help on with the listeners, Mike? Or
should I take a look at some of the issues first?

On Aug 31, 5:54 pm, "Chris Dempsey" <[hidden email]> wrote:
> > I like the idea of streaming the data out to the file. And it sounds like
> > you'd agree?
>
> Yup! I totally agree that is the way to go.
>
>
>

> On Sun, Aug 31, 2008 at 3:56 PM, Mike Nereson <[hidden email]> wrote:
> > Just thinking out loud here but shouldn't the listener implementation
> >> know how to clean up after itself (*it knows it has files to clean up,
> >> for example*)? If so, then Finalizable wouldn't need parameters at all.
> >> It would just be a hook method we would call from the main AR processing
> >> flow to give listeners time to clean up after themselves before we shutdown.
>
> > Depends. ReportListener needs to know where to output the report to and
> > what format to output as. That information comes in Properties. So, if
> > finalize writes the file, the initialize doesn't do anything so initialize
> > would not be neccessary. If initialize(Properties) is not used, then
> > ReportListener still needs to get the Properties to know where to output the
> > file too. The other option is to implement initalize(Properties) just to
> > store a reference to the properties.
>
> > On the other hand, if the file output is streamed as the events occur, then
> > we will need initialize, and finalize will just close the file.
>
> > I think following the principle of least surprise<http://en.wikipedia.org/wiki/Principle_of_least_surprise>and the general idea that a method does one thing developers wouldn't expect

> >> file writes to happen within a "terminate" method. I suppose it would be
> >> like waiting to issue SQL statements to the database on a connection.close()
> >> call.
>
> > I like the idea of streaming the data out to the file. And it sounds like
> > you'd agree?- Hide quoted text -
>
> - Show quoted text -

mikenereson

Re: Listener Implementation

Reply Threaded

We talked about streaming the xml report. This tool can do just that for us...

http://www.ociweb.com/mark/programming/WAX.html

However, its not hosted in any maven repo, so I'm not sure it is the BEST tool for us.

~ Mike Nereson

On Mon, Sep 1, 2008 at 5:40 PM, Chris Dempsey <[hidden email]> wrote:

Alrighty. I'll start moving on the listeners then. :)

On Mon, Sep 1, 2008 at 1:08 PM, Mike Nereson <[hidden email]> wrote:

Chris,

You've invested a good amount of time into reviewing the current listener setup, and clearly have a good idea as to how you'd implement an even better setup. I have already thrown up some code which should demonstrate what I was going for, and you've seen the XML report which is the current end goal of the listeners. I think you are more than well enough equiped with the requirements and experience to implement the even listener.

I have plenty of other tasks that I could be working on and have to particular preference. I think we'd be pretty well off if you took on the even listeners while I hit up one of the other issues or finish up some unfinished tasks (like default-architecture-rules.xml and proper tests for reading properties.)

So yes, if you want to take on the listeners, please have at it.

~ Mike Nereson

On Mon, Sep 1, 2008 at 12:04 PM, cdempsey <[hidden email]> wrote:

Is there anything you'd like help on with the listeners, Mike? Or
should I take a look at some of the issues first?

On Aug 31, 5:54 pm, "Chris Dempsey" <[hidden email]> wrote:
> > I like the idea of streaming the data out to the file. And it sounds like
> > you'd agree?
>
> Yup! I totally agree that is the way to go.
>
>
>

> On Sun, Aug 31, 2008 at 3:56 PM, Mike Nereson <[hidden email]> wrote:
> > Just thinking out loud here but shouldn't the listener implementation
> >> know how to clean up after itself (*it knows it has files to clean up,
> >> for example*)? If so, then Finalizable wouldn't need parameters at all.
> >> It would just be a hook method we would call from the main AR processing
> >> flow to give listeners time to clean up after themselves before we shutdown.
>
> > Depends. ReportListener needs to know where to output the report to and
> > what format to output as. That information comes in Properties. So, if
> > finalize writes the file, the initialize doesn't do anything so initialize
> > would not be neccessary. If initialize(Properties) is not used, then
> > ReportListener still needs to get the Properties to know where to output the
> > file too. The other option is to implement initalize(Properties) just to
> > store a reference to the properties.
>
> > On the other hand, if the file output is streamed as the events occur, then
> > we will need initialize, and finalize will just close the file.
>
> > I think following the principle of least surprise<http://en.wikipedia.org/wiki/Principle_of_least_surprise>and the general idea that a method does one thing developers wouldn't expect

> >> file writes to happen within a "terminate" method. I suppose it would be
> >> like waiting to issue SQL statements to the database on a connection.close()
> >> call.
>
> > I like the idea of streaming the data out to the file. And it sounds like
> > you'd agree?- Hide quoted text -
>
> - Show quoted text -

Chris Dempsey

Re: Listener Implementation

Reply Threaded

I took a look at WAX. Other than hating the name it looks nice. :) One of the oddities I noticed is the API names. It just seems strange to call "start" instead of "element" or "attr" instead of "attribute". Not a big deal really and certainly not a reason not to use it. I've been kicking around writing something like this for work. Currently, our XML generation is all StringBuilder-based which is fast but way ugly code.

Nice find!

On Wed, Sep 10, 2008 at 9:22 PM, Mike Nereson <[hidden email]> wrote:

We talked about streaming the xml report. This tool can do just that for us...

http://www.ociweb.com/mark/programming/WAX.html

However, its not hosted in any maven repo, so I'm not sure it is the BEST tool for us.

~ Mike Nereson

On Mon, Sep 1, 2008 at 5:40 PM, Chris Dempsey <[hidden email]> wrote:

Alrighty. I'll start moving on the listeners then. :)

On Mon, Sep 1, 2008 at 1:08 PM, Mike Nereson <[hidden email]> wrote:

Chris,

You've invested a good amount of time into reviewing the current listener setup, and clearly have a good idea as to how you'd implement an even better setup. I have already thrown up some code which should demonstrate what I was going for, and you've seen the XML report which is the current end goal of the listeners. I think you are more than well enough equiped with the requirements and experience to implement the even listener.

I have plenty of other tasks that I could be working on and have to particular preference. I think we'd be pretty well off if you took on the even listeners while I hit up one of the other issues or finish up some unfinished tasks (like default-architecture-rules.xml and proper tests for reading properties.)

So yes, if you want to take on the listeners, please have at it.

~ Mike Nereson

On Mon, Sep 1, 2008 at 12:04 PM, cdempsey <[hidden email]> wrote:

Is there anything you'd like help on with the listeners, Mike? Or
should I take a look at some of the issues first?

On Aug 31, 5:54 pm, "Chris Dempsey" <[hidden email]> wrote:
> > I like the idea of streaming the data out to the file. And it sounds like
> > you'd agree?
>
> Yup! I totally agree that is the way to go.
>
>
>

> On Sun, Aug 31, 2008 at 3:56 PM, Mike Nereson <[hidden email]> wrote:
> > Just thinking out loud here but shouldn't the listener implementation
> >> know how to clean up after itself (*it knows it has files to clean up,
> >> for example*)? If so, then Finalizable wouldn't need parameters at all.
> >> It would just be a hook method we would call from the main AR processing
> >> flow to give listeners time to clean up after themselves before we shutdown.
>
> > Depends. ReportListener needs to know where to output the report to and
> > what format to output as. That information comes in Properties. So, if
> > finalize writes the file, the initialize doesn't do anything so initialize
> > would not be neccessary. If initialize(Properties) is not used, then
> > ReportListener still needs to get the Properties to know where to output the
> > file too. The other option is to implement initalize(Properties) just to
> > store a reference to the properties.
>
> > On the other hand, if the file output is streamed as the events occur, then
> > we will need initialize, and finalize will just close the file.
>
> > I think following the principle of least surprise<http://en.wikipedia.org/wiki/Principle_of_least_surprise>and the general idea that a method does one thing developers wouldn't expect

> >> file writes to happen within a "terminate" method. I suppose it would be
> >> like waiting to issue SQL statements to the database on a connection.close()
> >> call.
>
> > I like the idea of streaming the data out to the file. And it sounds like
> > you'd agree?- Hide quoted text -
>
> - Show quoted text -

mikenereson

Re: Listener Implementation

Reply Threaded

I took a look at WAX. Other than hating the name it looks nice. :)

WAX = Writing API for XML. Could be worse, but could be a whole lot better to. I

One of the oddities I noticed is the API names. It just seems strange to call "start" instead of "element" or "attr" instead of "attribute". Not a big deal really and certainly not a reason not to use it.

I looked at their Google code site. They have no wiki, no issues and one revision. I wonder if its just one developer who doesn't have a community around him to help point out proper naming conventions like this.

I've been kicking around writing something like this for work.

If it is just one guy, he could use your help - But we need your help too, so don't go too far ( : The domain of WAX seems like a good area to get into if one is looking to join an open source project .

Currently, our XML generation is all StringBuilder-based which is fast but way ugly code.

I think that's how most people are still doing it. Its either a StringBuilder or a complex heavy-weight XML library.

I am not sure we should use WAX though, because its not hosted in any Maven repository, so our maven users, which hopefuly most are, would not be able to get the dependency directly with maven. Ah, the woes of software development.

~ Mike Nereson

Chris Dempsey

Re: Listener Implementation

Reply Threaded

Well, I'm buttoning up the changes on the internal XML generation code and could reproduce it for AR after I'm done writing all the tests for the listeners/events.

I agree with your concerns surrounding WAX. I had not gotten to the point where I was going to look in a Maven repo for it but was a bit disappointed that I could not browse the source for WAX on-line.

On Fri, Sep 12, 2008 at 8:21 AM, Mike Nereson <[hidden email]> wrote:

I took a look at WAX. Other than hating the name it looks nice. :)

WAX = Writing API for XML. Could be worse, but could be a whole lot better to. I

One of the oddities I noticed is the API names. It just seems strange to call "start" instead of "element" or "attr" instead of "attribute". Not a big deal really and certainly not a reason not to use it.

I looked at their Google code site. They have no wiki, no issues and one revision. I wonder if its just one developer who doesn't have a community around him to help point out proper naming conventions like this.

I've been kicking around writing something like this for work.

If it is just one guy, he could use your help - But we need your help too, so don't go too far ( : The domain of WAX seems like a good area to get into if one is looking to join an open source project .

Currently, our XML generation is all StringBuilder-based which is fast but way ugly code.

I think that's how most people are still doing it. Its either a StringBuilder or a complex heavy-weight XML library.

I am not sure we should use WAX though, because its not hosted in any Maven repository, so our maven users, which hopefuly most are, would not be able to get the dependency directly with maven. Ah, the woes of software development.

~ Mike Nereson

mikenereson

Re: Listener Implementation

Reply Threaded

Same here. I went to browse the source. I assume that a pretty common first step to investigating a new open source project that you have some interest it. The Google code page is completely empty.

I was turned on to WAX by a friend in St Louis who attends the STL Java User Group. I guess this guy is presenting this project there this week or so. Good for him. It should get him some more attention.

~ Mike Nereson

On Fri, Sep 12, 2008 at 9:43 AM, Chris Dempsey <[hidden email]> wrote:

Well, I'm buttoning up the changes on the internal XML generation code and could reproduce it for AR after I'm done writing all the tests for the listeners/events.

I agree with your concerns surrounding WAX. I had not gotten to the point where I was going to look in a Maven repo for it but was a bit disappointed that I could not browse the source for WAX on-line.

On Fri, Sep 12, 2008 at 8:21 AM, Mike Nereson <mikenereson@...> wrote:

I took a look at WAX. Other than hating the name it looks nice. :)

WAX = Writing API for XML. Could be worse, but could be a whole lot better to. I

One of the oddities I noticed is the API names. It just seems strange to call "start" instead of "element" or "attr" instead of "attribute". Not a big deal really and certainly not a reason not to use it.

I looked at their Google code site. They have no wiki, no issues and one revision. I wonder if its just one developer who doesn't have a community around him to help point out proper naming conventions like this.

I've been kicking around writing something like this for work.

If it is just one guy, he could use your help - But we need your help too, so don't go too far ( : The domain of WAX seems like a good area to get into if one is looking to join an open source project .

Currently, our XML generation is all StringBuilder-based which is fast but way ugly code.

I think that's how most people are still doing it. Its either a StringBuilder or a complex heavy-weight XML library.

I am not sure we should use WAX though, because its not hosted in any Maven repository, so our maven users, which hopefuly most are, would not be able to get the dependency directly with maven. Ah, the woes of software development.

~ Mike Nereson