streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Franklin <m.ben.frank...@gmail.com>
Subject Re: ApacheCon Recap & Next Steps
Date Thu, 14 Mar 2013 14:45:02 GMT
On Thu, Mar 14, 2013 at 10:42 AM, Chris Geer <chris@cxtsoftware.com> wrote:
> On Thu, Mar 14, 2013 at 6:52 AM, Matt Franklin <m.ben.franklin@gmail.com>wrote:
>
>> On Wed, Mar 13, 2013 at 3:20 PM, Chris Geer <chris@cxtsoftware.com> wrote:
>> > On Wed, Mar 13, 2013 at 8:41 AM, Matt Franklin <m.ben.franklin@gmail.com
>> >wrote:
>> >
>> >> For all of you who missed it, Craig gave a nice intro into what we are
>> >> trying to accomplish with Streams at Apachecon [1].  At the conference
>> >> there was a fair bit of interest and what seemed to me like potential
>> >> alignment; however, there are some serious issues to discuss and work
>> >> to resolution.  The issues I heard are as follows:
>> >>
>> >> 1) Everyone is interested, few are engaged.
>> >>     There are quite a few people who could use this software, but
>> >> aside from Jason, we really haven't seen much activity in development
>> >> or architecture.
>> >>
>> >
>> > I'm one of the interested but not engaged yet. But I am interested in
>> > engaging if I can make it fit for our project.
>> >
>> >>
>> >> 2) The current code is not easy to engage with
>> >>     We need to lay out tutorials on how to get started and discuss
>> >> general architecture and package structure
>> >>
>> >> 3) We need processing pipelines for incoming and outgoing activities
>> >>     How these pipelines are created, managed (workflow?), parallelized
>> >> and augmented by custom components needs to be discussed
>> >>
>> >
>> > We do a lot of work with dynamically creating camel routes which could be
>> > used here potentially.
>> >
>> >>
>> >> 4) We need to support some kind of persistence
>> >>    Most people want to do ad-hoc querying rather than direct
>> >> subscription notification (though both should be supported IMO), but
>> >> we need persistence, indexes & a whole lot of thought to make this a
>> >> reality
>> >>
>> >> 5) Dependencies need help
>> >>    Someone brought up that all of our dependencies are versions old
>> >> and need to be upgraded
>> >>
>> >
>> > I think I might have made that comment. I believe this is because the
>> > current deployment is tied to ServiceMix which isn't updated very often.
>> > It's picking up the pace again but ServiceMix is a big beast with lots of
>> > dependencies so it's slow to catch up with all the latest libraries.
>> > ServiceMix 4.5 was just released which is using newer libraries which
>> will
>> > help.
>> >
>> > ** I just saw Jason's follow-up where he seemed to be suggesting getting
>> > rid of OSGI support, so if that is the case the stuff below isn't
>> important
>> > **
>> >
>> > 6) Code structure to support various deployments
>> >     Right now I understand that there is a desire to deploy either inside
>> > an OSGI container or standalone as a WAR file in any servlet container.
>> > That is a great goal but I'm not sure the code is structured in the best
>> > way to take advantage of both scenarios to it's fullest. I have a couple
>> > thoughts of some simple changes that would allow the project to be
>> deployed
>> > in both places and still be able to take advantage of OSGI features in
>> that
>> > environment.
>> >  - Split the API from the implementation in separate bundles. This can be
>> > done two ways, either each capability has two bundles (-api, -impl) or
>> you
>> > have one API bundle that includes all the API code for the whole project.
>> > This decouples the implementation from the API so the implementation can
>> be
>> > updated without affecting all the bundles that use it. The downside of
>> not
>> > doing it is that every time a bundle with an API class in it is updated
>> you
>> > have to reload all the bundles that use that class definition.
>> >  - Try to make the API/Implementations pure POJOs. There shouldn't be any
>> > common reason why you need to depend directly on OSGI classes if you use
>> > Blueprint for wiring (replace spring-osgi with blueprint). Having pure
>> > POJOs, with no OSGI or Spring dependencies, allows implementors to wire
>> > things up using the technology they see fit. (Might want to consider a
>> > profile here as well so that spring context file can be stripped.
>> Otherwise
>> > you wind up with multiple instances of the same beans being created in
>> OSGI)
>> >  - For WAR files (if needed) there would probably need to be a profile
>> > setup to build either OSGI or non-OSGI. In the OSGI mode it wouldn't
>> embed
>> > all the libraries inside the WEB-INF/lib folder, instead it would use
>> OSGI
>> > imports to get those dependencies. It can also lookup services to use
>> > instead of creating new versions of the beans.
>> >  - For configuration parameters, in the Blueprint file use configuration
>> > properties. You can provide the default in the blueprint file but it will
>> > publish that item to the OSGI Config Admin service so it can be updated
>> > with either config files or directly through the API/web console.
>>
>> These suggestions seem very reasonable to me.  Any chance we can
>> convince you to implement them? :)
>>
>
> If the desire is to support both WAR and native OSGI deployments then I'd
> be glad to take a stab at it.

IMHO, it would be nice to have both; but, only if we can clearly and
cleanly define how to build for each case.  Your proposed enhancements
appear to me to move further down that path.  Any one else have
thoughts?

>
>>
>> >
>> > On a different note, there seems to be a lot of NOTICES/DISCLAIMERS... in
>> > the project. Are those required in every module? I believe those can be
>> > removed from any module that is a <package>pom</package> type since
that
>> > package structure doesn't generate a jar or use the src folder anyway.
>>
>> We should be able to pull these in during the build process so that
>> they show up in the zip that gets released.
>>
>> >
>> >>
>> >> Anyone have any thoughts on these issues and how we as a community can
>> >> move past them?  Did anyone else have other issues to add to the list?
>> >>
>> >> -Matt
>> >>
>> >> [1]:
>> >>
>> http://archive.apachecon.com/na2013/presentations/26-Tuesday/Tapping_The_Stream/11:15-Apache%20Streams:%20Enterprise%20Social%20Integration.pdf
>> >>
>>

Mime
View raw message