Sorry, I didn't mean we would exclude applications from using the JMS API. There are cases where a Blueprint component isn't concerned what async comms is being used, and there are times when that level of detail is needed. There are many use cases which of course we haven't thought about and that is a reason why we're coming to Apache - to explore that. So the proposal is the initial scope and the project will hopefully grow from there. If you feel strongly about it then we can add something to the proposal.
Thanks, Jeremy 2009/9/10 Peter Peshev <ppes...@gmail.com>: > Hi Jeremy, > > Well, I had some other use cases in mind besides "Message driven > Blueprint components" > > At least in my view JMS API is quite popular and stable so it's not > a rare case to be used from web applications as it is. An interesting > use case would be the resource provisioning. I would expect that > those "deployable units" mentioned in the proposal could bring as > well metainformation about JMS resources (connection factories, > destinations) that are going to be used from the application and I > would expect the Aries would be the glue code between the resource > creation in the JMS broker and the deployment. > > Best regards > Peter > > On Thu, Sep 10, 2009 at 11:59 AM, Jeremy Hughes <hugh...@apache.org> wrote: >> 2009/9/8 Peter Peshev <ppes...@gmail.com>: >>> Hi Jeremy, >>> >>> Since you are asking about potential committers - at least to me a new >>> OSGi project focused on Java EE sounds quite interesting. >>> >>> Btw, when looking at the proposal I would personally suggest even to >>> expand the scope and include other Java enterprise concepts - for >>> example integration with JMS (i.e. ActiveMQ) , JCA resource adapters , >>> or addressing the usecase for integration of non-Apache Java EE >>> components (EclipseLink, etc.). Would you consider these as in scope >>> for the project ? >> >> I think these are in scope. They're just not explicitly called out in >> the proposal. On the asynchronous messaging side, we do call out >> "Message driven Blueprint components" which would (potentially) use >> JMS to achieve that. >> >> Thanks, >> Jeremy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
