deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: DISCUSS DeltaSpike-324
Date Mon, 25 Mar 2013 22:09:16 GMT
well, a roadmap always depends on how much one can spend. 
The roadmap for 0.4 originally have been JSF support. This is still the case.
But with only Gerhard and me doing 80% of the commits it's obvious that we are not that fast.


So please just help with the features as well!

@Pete: it's pretty easy: 0.4 basic JSF support and basic JPA support, 0.5 even more JSF support
and JPA support.
 
And then 1.0 is just around the corner.

LieGrue,
strub




----- Original Message -----
> From: Cody Lerum <cody.lerum@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: 
> Sent: Monday, March 25, 2013 3:07 PM
> Subject: Re: DISCUSS DeltaSpike-324
> 
> +1
> On Mar 25, 2013 8:04 AM, "Nicklas Karlsson" <nickarls@gmail.com> 
> wrote:
> 
>>  I'm currently in the process of porting an application from Seam3 to
>>  DeltaSpike, with a clear roadmap I might be able to spend some work hours
>>  in getting stuff forward.
>> 
>> 
>>  On Mon, Mar 25, 2013 at 3:58 PM, Pete Muir <pmuir@redhat.com> wrote:
>> 
>>  > Hi all,
>>  >
>>  > At the moment it's really hard for Red Hat to fund more people to 
> work on
>>  > DeltaSpike. Without a clear roadmap, and a regular release schedule 
> (e.g.
>>  > time boxed) it's really hard for us to justify more people for 
> DeltaSpike
>>  > as we can't see how many people we should offer to get to the 
> features
>>  our
>>  > customers need, nor can we see when those features will be available 
> for
>>  > customers to start using.
>>  >
>>  > Last time we asked to agree on a roadmap, this group decided it 
> wasn't
>>  > something that it wanted to do. If we are now able to agree on a 
> roadmap
>>  > with some sort of regular release schedule (even just having approx 
> dates
>>  > for a release is good enough) then I can see how I can reprioritise 
> our
>>  > current work, and get some more help for DeltaSpike, and hopefully get 
> us
>>  > closer to 1.0, which is really what I think we are all after (I'm 
> not
>>  sure
>>  > if I will succeed, but right now it's not really worth me even 
> trying).
>>  >
>>  > Pete
>>  >
>>  > On 24 Mar 2013, at 18:33, Romain Manni-Bucau 
> <rmannibucau@gmail.com>
>>  > wrote:
>>  >
>>  > > I did a JUG this week with a part on DS and was the main question 
> asked
>>  > > with those words "when will it be usable?"...kind of 
> sad. Releasing
>>  even
>>  > in
>>  > > alpha/beta is better IMO.
>>  > > Le 24 mars 2013 19:29, "Jason Porter" 
> <lightguard.jp@gmail.com> a
>>  écrit
>>  > :
>>  > >
>>  > >> +1 glad I'm not the only one asking for a roadmap now.
>>  > >> —
>>  > >> Sent from Mailbox for iPhone
>>  > >>
>>  > >> On Sun, Mar 24, 2013 at 11:54 AM, Romain Manni-Bucau
>>  > >> <rmannibucau@gmail.com> wrote:
>>  > >>
>>  > >>> Do we already have a roadmap? I think we should define 
> one by
>>  iteration
>>  > >>> (+handle a backlog if we want).
>>  > >>> I can help on cdi query part if needed (jsf is still a 
> bit too new
>>  for
>>  > >> me).
>>  > >>> Le 24 mars 2013 18:49, "Gerhard Petracek" <
>>  gerhard.petracek@gmail.com>
>>  > a
>>  > >>> écrit :
>>  > >>>> hi john,
>>  > >>>>
>>  > >>>> we can't keep it currently (i'm also unhappy 
> about it), because if
>>  > only
>>  > >> 2-3
>>  > >>>> people help on a >regular< basis [1], you have 
> to wait until they
>>  have
>>  > >>>> time.
>>  > >>>> it isn't only about unassigned issues. e.g. not 
> that many help with
>>  > >> writing
>>  > >>>> tests and examples, writing/reviewing javadoc and 
> documentation.
>>  > >>>>
>>  > >>>> even the graduation process takes (very) long.
>>  > >>>> that might be a big blocker for some users.
>>  > >>>> at least codi had several users way before v1 (and 
> for sure even
>>  more
>>  > >> after
>>  > >>>> v1).
>>  > >>>> however, we would lose more users, if we release v1 
> which isn't
>>  ready.
>>  > >>>>
>>  > >>>>> imo< our goal for v1 should be >at 
> least< everything (which we know
>>  > >>>> already) we need for improving the java-ee 
> web-profile as well as a
>>  > >> stable
>>  > >>>> api and spi.
>>  > >>>>
>>  > >>>> regards,
>>  > >>>> gerhard
>>  > >>>>
>>  > >>>> [1] 
> https://github.com/apache/incubator-deltaspike/contributors
>>  > >>>>
>>  > >>>>
>>  > >>>>
>>  > >>>> 2013/3/24 Romain Manni-Bucau 
> <rmannibucau@gmail.com>
>>  > >>>>
>>  > >>>>> I get you and think we agree behund words. My 
> main issue is our 0.4
>>  > is
>>  > >>>> not
>>  > >>>>> ready to be released and still doesnt contain 
> what users are
>>  waiting
>>  > >>>> for...
>>  > >>>>>
>>  > >>>>> When i spoke about > 1.0 just understand when 
> last release answer
>>  > >> basic
>>  > >>>>> needs
>>  > >>>>> Le 24 mars 2013 16:49, "John D. Ament" 
> <john.d.ament@gmail.com> a
>>  > >> écrit
>>  > >>>> :
>>  > >>>>>
>>  > >>>>>> Romain,
>>  > >>>>>>
>>  > >>>>>> I'm not sure what to tell you.  One of 
> our founding statements was
>>  > >>>>> release
>>  > >>>>>> early and often.  I'm not sure why we 
> haven't stuck to that.
>>  > >>>>> Personally, I
>>  > >>>>>> think we have failed to do that.  We probably 
> have too many
>>  features
>>  > >>>> in a
>>  > >>>>>> single release/ not much release 
> planning/attempt to release
>>  > >> everything
>>  > >>>>> as
>>  > >>>>>> one big release rather than more modular in 
> nature.  Those are
>>  just
>>  > >>>>>> thoughts.
>>  > >>>>>>
>>  > >>>>>> As I already stated, I don't want this in 
> 0.4.  But I don't think
>>  > >> it's
>>  > >>>>>> appropriate to stick this in after 1.0, who 
> knows when that will
>>  > >> be.  I
>>  > >>>>>> would love to see this in 0.5, already have 
> prototypes working.
>>   My
>>  > >>>>> biggest
>>  > >>>>>> issue, as I was trying to raise in the other 
> thread, is that when
>>  > >>>> people
>>  > >>>>>> look at the issue list out there, generally 
> the candidates to work
>>  > >> on
>>  > >>>> are
>>  > >>>>>> the unassigned issues.  If 80% of what we 
> have out there is
>>  > >> assigned,
>>  > >>>>> then
>>  > >>>>>> it's assumed someone's work on it.  
> If it's assigned to someone
>>  and
>>  > >>>>> they're
>>  > >>>>>> not working on it, that's probably an 
> issue that needs to be
>>  > >> addressed.
>>  > >>>>> As
>>  > >>>>>> far as I can tell, of the 10 unassigned 
> issues out there, none of
>>  > >> them
>>  > >>>>> are
>>  > >>>>>> comprehensible enough (other than the one I 
> already worked on) to
>>  be
>>  > >>>>> worked
>>  > >>>>>> through.  So I'm not sure, maybe it's 
> an issue of perception, but
>>  I
>>  > >>>> don't
>>  > >>>>>> think we have a large pile of open work for 
> future releases.
>>  > >>>>>>
>>  > >>>>>> John
>>  > >>>>>>
>>  > >>>>>>
>>  > >>>>>> On Sun, Mar 24, 2013 at 11:19 AM, Romain 
> Manni-Bucau
>>  > >>>>>> <rmannibucau@gmail.com>wrote:
>>  > >>>>>>
>>  > >>>>>>> Sure but we cant start everything, 
> finishing nothing...our rare
>>  > >>>>> releases
>>  > >>>>>>> are already a pain for users.
>>  > >>>>>>>
>>  > >>>>>>> We need jsf + if possible cdi query for 
> 0.4 IMO then i agree rest
>>  > >>>>> helpers
>>  > >>>>>>> are a must have (some tools around jaxrs 
> client part can be
>>  great)
>>  > >>>>> etc...
>>  > >>>>>>> Le 24 mars 2013 16:13, "John D. 
> Ament" <john.d.ament@gmail.com>
>>  a
>>  > >>>>> écrit
>>  > >>>>>> :
>>  > >>>>>>>
>>  > >>>>>>>> Romain,
>>  > >>>>>>>>
>>  > >>>>>>>> My only issue with this is that I 
> don't think we've mapped out
>>  > >> what
>>  > >>>>> the
>>  > >>>>>>>> common use cases are (at least based 
> on the email I sent out).
>>  > >> If
>>  > >>>>>> we're
>>  > >>>>>>>> favoring JSF, we're neglecting 
> the growing population of REST
>>  > >> APIs
>>  > >>>>> for
>>  > >>>>>>> rich
>>  > >>>>>>>> javascript clients (from UI).
>>  > >>>>>>>>
>>  > >>>>>>>>
>>  > >>>>>>>> On Sat, Mar 23, 2013 at 6:04 PM, 
> Romain Manni-Bucau
>>  > >>>>>>>> <rmannibucau@gmail.com>wrote:
>>  > >>>>>>>>
>>  > >>>>>>>>> yes but JMS is clearly not the 
> most used
>>  > >>>>>>>>>
>>  > >>>>>>>>> can't we push it for the > 
> 1.0?
>>  > >>>>>>>>>
>>  > >>>>>>>>> users really wait the first 1.0 
> to use DS and adding JMS now
>>  > >>>> simply
>>  > >>>>>>> looks
>>  > >>>>>>>>> like forgetting more common use 
> cases
>>  > >>>>>>>>>
>>  > >>>>>>>>> *Romain Manni-Bucau*
>>  > >>>>>>>>> *Twitter: @rmannibucau 
> <https://twitter.com/rmannibucau>*
>>  > >>>>>>>>> *Blog: 
> **http://rmannibucau.wordpress.com/*<
>>  > >>>>>>>>> 
> http://rmannibucau.wordpress.com/>
>>  > >>>>>>>>> *LinkedIn: 
> **http://fr.linkedin.com/in/rmannibucau*
>>  > >>>>>>>>> *Github: 
> https://github.com/rmannibucau*
>>  > >>>>>>>>>
>>  > >>>>>>>>>
>>  > >>>>>>>>>
>>  > >>>>>>>>> 2013/3/23 Gerhard Petracek 
> <gerhard.petracek@gmail.com>
>>  > >>>>>>>>>
>>  > >>>>>>>>>> hi @ all,
>>  > >>>>>>>>>>
>>  > >>>>>>>>>> imo it's more a basic 
> question.
>>  > >>>>>>>>>> if we do it for jms 2, we 
> also have to (/should) do it for
>>  > >>>> other
>>  > >>>>>>>>>> specifications like bv 1.1
>>  > >>>>>>>>>>
>>  > >>>>>>>>>> regards,
>>  > >>>>>>>>>> gerhard
>>  > >>>>>>>>>>
>>  > >>>>>>>>>>
>>  > >>>>>>>>>>
>>  > >>>>>>>>>> 2013/3/21 Romain Manni-Bucau 
> <rmannibucau@gmail.com>
>>  > >>>>>>>>>>
>>  > >>>>>>>>>>> Ill rephrase a bit. I m 
> rather -0 about it and -1 since a
>>  > >> lot
>>  > >>>>> of
>>  > >>>>>>>> others
>>  > >>>>>>>>>>> stuff are needed before.
>>  > >>>>>>>>>>> Le 21 mars 2013 22:50, 
> "Arne Limburg" <
>>  > >>>>>>> arne.limburg@openknowledge.de
>>  > >>>>>>>>>
>>  > >>>>>>>>> a
>>  > >>>>>>>>>>> écrit :
>>  > >>>>>>>>>>>
>>  > >>>>>>>>>>>> We should find out if 
> one can simply use a JMS 2.0
>>  > >>>>>> implementation
>>  > >>>>>>>> and
>>  > >>>>>>>>>> put
>>  > >>>>>>>>>>>> it into an 
> deployment. If that will be possible, we
>>  > >> would
>>  > >>>> not
>>  > >>>>>>> need
>>  > >>>>>>>> to
>>  > >>>>>>>>>>>> implement it.
>>  > >>>>>>>>>>>>
>>  > >>>>>>>>>>>> Cheers,
>>  > >>>>>>>>>>>> Arne
>>  > >>>>>>>>>>>>
>>  > >>>>>>>>>>>> Am 21.03.13 22:34 
> schrieb "Mark Struberg" unter <
>>  > >>>>>>> struberg@yahoo.de
>>  > >>>>>>>>> :
>>  > >>>>>>>>>>>>
>>  > >>>>>>>>>>>>> I tend to lean 
> towards +1 simply because EE-7
>>  > >> containers
>>  > >>>>> will
>>  > >>>>>>> take
>>  > >>>>>>>>>>>>> another year (or 
> 2) to become used in projects.
>>  > >>>>>>>>>>>>>
>>  > >>>>>>>>>>>>> I just think we 
> should first close a few tasks before
>>  > >> we
>>  > >>>>> open
>>  > >>>>>>> new
>>  > >>>>>>>>>> ones.
>>  > >>>>>>>>>>>>>
>>  > >>>>>>>>>>>>> LieGrue,
>>  > >>>>>>>>>>>>> strub
>>  > >>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>
>>  > >>>>>>>>>>>>> ----- Original 
> Message -----
>>  > >>>>>>>>>>>>>> From: John D. 
> Ament <john.d.ament@gmail.com>
>>  > >>>>>>>>>>>>>> To: 
> deltaspike-dev@incubator.apache.org
>>  > >>>>>>>>>>>>>> Cc:
>>  > >>>>>>>>>>>>>> Sent: 
> Thursday, March 21, 2013 6:09 PM
>>  > >>>>>>>>>>>>>> Subject: Re: 
> DISCUSS DeltaSpike-324
>>  > >>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>> Romain,
>>  > >>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>> Generally, 
> I'm mixed about these.  However I think
>>  > >>>> there's
>>  > >>>>>>> some
>>  > >>>>>>>>>> pretty
>>  > >>>>>>>>>>>>>> good
>>  > >>>>>>>>>>>>>> benefits.  
> For an application developer, maybe none
>>  > >> of
>>  > >>>> the
>>  > >>>>>>> other
>>  > >>>>>>>>>> JMS 2
>>  > >>>>>>>>>>>>>> features are 
> useful to you (the bulk of the feature
>>  > >> went
>>  > >>>>>> into
>>  > >>>>>>>> CDI
>>  > >>>>>>>>>>>>>> support,
>>  > >>>>>>>>>>>>>> app server 
> integration, and documentation clean up).
>>  > >>>> You
>>  > >>>>>>> don't
>>  > >>>>>>>>> want
>>  > >>>>>>>>>>> to
>>  > >>>>>>>>>>>>>> move off of 
> TomEE 1.5.x to TomEE Y (which could
>>  > >> support
>>  > >>>>> Java
>>  > >>>>>>> EE
>>  > >>>>>>>> 7
>>  > >>>>>>>>>> Web
>>  > >>>>>>>>>>>>>> Profile) due 
> to downtime in your application.
>>  > >> There's
>>  > >>>>> also
>>  > >>>>>>> lead
>>  > >>>>>>>>>> time
>>  > >>>>>>>>>>>>>> required to 
> impelement JMS 2/Java EE 7 features in
>>  > >> your
>>  > >>>>>>>>> application
>>  > >>>>>>>>>>>>>> server,
>>  > >>>>>>>>>>>>>> but perhaps 
> you don't want to or need to wait for the
>>  > >>>>> whole
>>  > >>>>>>>> thing.
>>  > >>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>> This solution 
> would be DS oriented, I believe
>>  > >> requires
>>  > >>>>>>>>>>> TransactionScoped
>>  > >>>>>>>>>>>>>> (which could 
> require the transaction classes be moved
>>  > >>>> away
>>  > >>>>>>> from
>>  > >>>>>>>>>>>>>> persistence) 
> to operate properly.
>>  > >>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>> There's 
> also the case of using DeltaSpike as your
>>  > >>>> CDI-JMS
>>  > >>>>>>>>>>>>>> 
> implementation if
>>  > >>>>>>>>>>>>>> you were a 
> JMS implementer.  I haven't reached out to
>>  > >>>>>>>> communities
>>  > >>>>>>>>>> such
>>  > >>>>>>>>>>>>>> as
>>  > >>>>>>>>>>>>>> Apache 
> ActiveMQ or HornetQ to see input here; I know
>>  > >> the
>>  > >>>>>>> current
>>  > >>>>>>>>>>>>>> GlassFish
>>  > >>>>>>>>>>>>>> 
> implementation calls their lower level directly (and
>>  > >> not
>>  > >>>>> by
>>  > >>>>>>>>> wrapping
>>  > >>>>>>>>>>> the
>>  > >>>>>>>>>>>>>> JMS APIs).
>>  > >>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>> John
>>  > >>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>> On Thu, Mar 
> 21, 2013 at 12:30 PM, Romain Manni-Bucau
>>  > >>>>>>>>>>>>>> 
> <rmannibucau@gmail.com>wrote:
>>  > >>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>> Hi
>>  > >>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>> i'm 
> globally -1 for redoing something which will
>>  > >> exist
>>  > >>>>>>>> somewhere
>>  > >>>>>>>>>>> else
>>  > >>>>>>>>>>>>>>> 
> (basically if somebody wants JavaEE just let him
>>  > >> use
>>  > >>>>>> JavaEE,
>>  > >>>>>>>> CDI
>>  > >>>>>>>>>>>>>> doesn't
>>  > >>>>>>>>>>>>>>> need the 
> full stack IMO). Was my point for JPA,
>>  > >> more
>>  > >>>>> again
>>  > >>>>>>> on
>>  > >>>>>>>>> JMS.
>>  > >>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>> It is 
> great to add feature before the specs not
>>  > >> once
>>  > >>>> it
>>  > >>>>> is
>>  > >>>>>>> (or
>>  > >>>>>>>>>>> almost)
>>  > >>>>>>>>>>>>>>> done.
>>  > >>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>> Maybe i 
> didnt fully get what you want to do so
>>  > >> maybe
>>  > >>>>> share
>>  > >>>>>>>> some
>>  > >>>>>>>>>>>>>>> pastebin 
> to
>>  > >>>>>>>>>>>>>>> be sure 
> we speak about the same stuff.
>>  > >>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>> *Romain 
> Manni-Bucau*
>>  > >>>>>>>>>>>>>>> *Twitter: 
> @rmannibucau <
>>  > >>>> https://twitter.com/rmannibucau
>>  > >>>>>> *
>>  > >>>>>>>>>>>>>>> *Blog: 
> **http://rmannibucau.wordpress.com/*<
>>  > >>>>>>>>>>>>>>> 
> http://rmannibucau.wordpress.com/>
>>  > >>>>>>>>>>>>>>> 
> *LinkedIn: **
>>  > >> http://fr.linkedin.com/in/rmannibucau*
>>  > >>>>>>>>>>>>>>> *Github: 
> https://github.com/rmannibucau*
>>  > >>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>> 2013/3/21 
> John D. Ament <john.d.ament@gmail.com>
>>  > >>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>>> All,
>>  > >>>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>>> 
> I'd like to open the floor to discussion for
>>  > >> porting
>>  > >>>>>> JMS 2
>>  > >>>>>>>>>>>>>> features to
>>  > >>>>>>>>>>>>>>>> 
> DeltaSpike, specifically the features that added
>>  > >>>> some
>>  > >>>>>> CDI
>>  > >>>>>>>>>>>>>>> 
> capabilities
>>  > >>>>>>>>>>>>>> to
>>  > >>>>>>>>>>>>>>>> JMS.
>>  > >>>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>>> 
> Details of my rough proposal are here:
>>  > >>>>>>>>>>>>>>>>
>>  > >>>> https://issues.apache.org/jira/browse/DELTASPIKE-324
>>  > >>>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>>> 
> Importing these features start to deprecate
>>  > >>>>>> functionality
>>  > >>>>>>> in
>>  > >>>>>>>>>> Seam
>>  > >>>>>>>>>>>>>>> JMS
>>  > >>>>>>>>>>>>>>>> 
> (ideal).  These features would give access to an
>>  > >> API
>>  > >>>>>> very
>>  > >>>>>>>>>> similar
>>  > >>>>>>>>>>>>>>> to
>>  > >>>>>>>>>>>>>> the
>>  > >>>>>>>>>>>>>>>> JMS2 
> API around CDI injection.
>>  > >>>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>>> Some 
> limitations:
>>  > >>>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>>> - 
> This would not be a JMS implementation, simply
>>  > >> an
>>  > >>>>>>> inspired
>>  > >>>>>>>>>>>>>>> interface
>>  > >>>>>>>>>>>>>>> for
>>  > >>>>>>>>>>>>>>>> use 
> in Java EE 6/JMS 1.x that leveraged CDI
>>  > >>>> injection
>>  > >>>>>>> based
>>  > >>>>>>>> on
>>  > >>>>>>>>>> the
>>  > >>>>>>>>>>>>>> rules
>>  > >>>>>>>>>>>>>>>> for 
> CDI injection of these interfaces.  We would
>>  > >>>> bring
>>  > >>>>>> in
>>  > >>>>>>>> very
>>  > >>>>>>>>>>>>>>> similar
>>  > >>>>>>>>>>>>>>>> 
> annotations that supported the injection of the
>>  > >>>> three
>>  > >>>>>>> target
>>  > >>>>>>>>>>> types.
>>  > >>>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>>> - 
> Cannot use the exact interface, since the
>>  > >>>> interface
>>  > >>>>>>>>> implements
>>  > >>>>>>>>>>>>>>>> 
> AutoCloseable which is a Java SE 7 interface.
>>  > >>>>>> DeltaSpike
>>  > >>>>>>>> uses
>>  > >>>>>>>>>>> Java
>>  > >>>>>>>>>>>>>>> SE
>>  > >>>>>>>>>>>>>> 6
>>  > >>>>>>>>>>>>>>>> for a 
> compiler.
>>  > >>>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>>> - 
> Internally these would have to use the current
>>  > >> JMS
>>  > >>>>>>>>> interfaces
>>  > >>>>>>>>>> of
>>  > >>>>>>>>>>>>>>>> 
> connection, session.
>>  > >>>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>>> - 
> Testing would be feasible but require a full
>>  > >> Java
>>  > >>>> EE
>>  > >>>>>>>>> container
>>  > >>>>>>>>>>>>>>> (e.g.
>>  > >>>>>>>>>>>>>> no
>>  > >>>>>>>>>>>>>>>> 
> testing in Weld/OWB directly) that supported
>>  > >>>>> deployment
>>  > >>>>>> of
>>  > >>>>>>>>>>>>>> destinations
>>  > >>>>>>>>>>>>>>> at
>>  > >>>>>>>>>>>>>>>> 
> runtime.  Since this doesn't touch MDBs we can
>>  > >>>>> manually
>>  > >>>>>>> read
>>  > >>>>>>>>>> from
>>  > >>>>>>>>>>>>>> the
>>  > >>>>>>>>>>>>>>>> 
> destination.
>>  > >>>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>>> John
>>  > >>>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>>>
>>  > >>>>>>>>>>>>
>>  > >>>>>>>>>>>>
>>  > >>>>>>>>>>>
>>  > >>>>>>>>>>
>>  > >>>>>>>>>
>>  > >>>>>>>>
>>  > >>>>>>>
>>  > >>>>>>
>>  > >>>>>
>>  > >>>>
>>  >
>>  >
>> 
>> 
>>  --
>>  Nicklas Karlsson, +358 40 5062266
>>  Vaakunatie 10 as 7, 20780 Kaarina
>> 
> 

Mime
View raw message