Re: [VOTE] Move our git repo to Apache gitbox

[Jason Porter]

+1

On Mon, Jan 7, 2019 at 12:16 Christian Kaltepoth 
wrote:

> +1
>
> Am Mo., 7. Jan. 2019, 18:18 hat Thomas Andraschko <
> andraschko.tho...@gmail.com> geschrieben:
>
> > +1
> >
> > Am Mo., 7. Jan. 2019 um 18:09 Uhr schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com>:
> >
> > > +1
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 7 janv. 2019 à 18:08, Mark Struberg  >
> > a
> > > écrit :
> > >
> > > > Hi folks!
> > > >
> > > > I've made good experience with gitbox in other ASF projects.
> > > > I'd say we just call it 'deltaspike' as is. We just have one repo, so
> > > that
> > > > would be a 1:1 migration.
> > > > As with everything GIT the sha1 doesn'T change anyway...
> > > >
> > > > Can I pull the trigger?
> > > >
> > > > Here is my +1
> > > >
> > > > The VOTE is open for 72h
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > > > Am 03.01.2019 um 14:19 schrieb Apache Infrastructure Team <
> > > > infrastruct...@apache.org>:
> > > > >
> > > > > Hello, deltaspike folks.
> > > > > As stated earlier in 2018, all git repositories must be migrated
> from
> > > > > the git-wip-us.apache.org URL to gitbox.apache.org, as the old
> > service
> > > > > is being decommissioned. Your project is receiving this email
> because
> > > > > you still have repositories on git-wip-us that needs to be
> migrated.
> > > > >
> > > > > The following repositories on git-wip-us belong to your project:
> > > > > - deltaspike.git
> > > > >
> > > > >
> > > > > We are now entering the mandated (coordinated) move stage of the
> > > roadmap,
> > > > > and you are asked to please coordinate migration with the Apache
> > > > > Infrastructure Team before February 7th. All repositories not
> > migrated
> > > > > on February 7th will be mass migrated without warning, and we'd
> > > > appreciate
> > > > > it if we could work together to avoid a big mess that day :-).
> > > > >
> > > > > Moving to gitbox means you will get full write access on GitHub as
> > > well,
> > > > > and be able to close/merge pull requests and much more.
> > > > >
> > > > > To have your repositories moved, please follow these steps:
> > > > >
> > > > > - Ensure consensus on the move (a link to a lists.apache.org
> thread
> > > will
> > > > >  suffice for us as evidence).
> > > > > - Create a JIRA ticket at
> > https://issues.apache.org/jira/browse/INFRA
> > > > >
> > > > > Your migration should only take a few minutes. If you wish to
> migrate
> > > > > at a specific time of day or date, please do let us know in the
> > ticket.
> > > > >
> > > > > As always, we appreciate your understanding and patience as we move
> > > > > things around and work to provide better services and features for
> > > > > the Apache Family.
> > > > >
> > > > > Should you wish to contact us with feedback or questions, please do
> > so
> > > > > at: us...@infra.apache.org.
> > > > >
> > > > >
> > > > > With regards,
> > > > > Apache Infrastructure
> > > > >
> > > >
> > > >
> > >
> >
>
-- 
Sent from Gmail Mobile

Re: bringing interdyn and invomon to DeltaSpike?

[Jason Porter]

count: 1  net.struberg.myproject.events.
> > > > be.EventRemoteServiceImpl
> > > > > >
> > > > > > 2011-03-19 12:36:27,292 [2046767960@qtp-1243908618-9]  INFO
> > > > > > invomon.InvocationResultLogger Top Method Invocations:
> > > > > >   dur[ms]: 442.48096count: 1
> > > net.struberg.myproject.course.
> > > > > > be.CourseServiceImpl#deleteCourse
> > > > > >   dur[ms]: 349.34717count: 1
> > > net.struberg.myproject.course.
> > > > > > be.CourseServiceImpl#getByFilter
> > > > > >   dur[ms]: 104.53423count: 1
> > > net.struberg.myproject.events.
> > > > > > be.EventRemoteServiceImpl#getEvent
> > > > > >   dur[ms]: 100.43162count: 1
> > > net.struberg.myproject.events.
> > > > > > be.EventServiceImpl#getEvent
> > > > > >   dur[ms]: 24.677048count: 1
> > > net.struberg.myproject.course.
> > > > > > be.LecturerServiceImpl#getEmployeeIdsInvolvedInOrgUnitCourses
> > > > > >   dur[ms]: 1.596834 count: 1
> > net.struberg.myproject.core.
> > > > > > be.persons.PersonRemoteServiceImpl#getByEmployeeIdList
> > > > > >   dur[ms]: 0.892522 count: 51
> >  net.struberg.myproject.core.
> > > > > > be.semester.SemesterRemoteServiceImpl#
> getCorrespondingSemesterCode
> > > > > >   dur[ms]: 0.288455 count: 5
> > net.struberg.myproject.util.
> > > > > > be.config.ConfigServiceImpl#getStringProperty
> > > > > >   dur[ms]: 0.248038 count: 3
> > net.struberg.myproject.core.
> > > > > > be.security.service.SecurityServiceImpl#isGranted
> > > > > >   dur[ms]: 0.203102 count: 18
> >  net.struberg.myproject.core.
> > > > > > be.security.service.SecurityServiceImpl#isAuthenticated
> > > > > >
> > > > > >
> > > > > > The initial version requires an own property file. But of course
> > all
> > > > this
> > > > > > configuration could also be provided via DS-config.
> > > > > >
> > > > > > wdyt?
> > > > > > Worth moving over to DeltaSpike?
> > > > > >
> > > > > > LieGrue,
> > > > > > strub
> > > > > >
> > > > > >
> > > > > >
> > > > > > [1] https://github.com/struberg/interdyn
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>



-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: [VOTE] Apache DeltaSpike 1.8.0 - 2nd take

[Jason Porter (lightguardjp)]

+1


Get Outlook for iOS






On Sun, May 28, 2017 at 4:42 AM -0600, "Mark Struberg" 
 wrote:










Hi!

I just rerolled the release.
release branch and tag again staged at my github account
https://github.com/struberg/deltaspike/tree/release_deltaspike_1.8.0

Staging repo is 
https://repository.apache.org/content/repositories/orgapachedeltaspike-1045/

Source release is
https://repository.apache.org/content/repositories/orgapachedeltaspike-1045/org/apache/deltaspike/deltaspike/1.8.0/

Please VOTE:

[+1] yeah dude, let's ship it!
[+0] meh, don't care
[-1] woah, stop there is a ${showstopper}

The VOTE is open for 72h.

Here is my own +1

d
txs and LieGrue,
strub

Re: [DISCUSS] PR Based Contributor Workflow

[Jason Porter]

+1 PRs are much easier to work with, imo.

On Sun, Jul 24, 2016 at 1:40 AM, Christian Kaltepoth <christ...@kaltepoth.de
> wrote:

> Hey John,
>
> Great work!
>
> +1 ;)
>
> Christian
>
> 2016-07-23 18:14 GMT+02:00 Daniel Cunha <daniels...@gmail.com>:
>
> > Hi John,
> >
> > Greate job. I think that we really need to have that. It's much more easy
> > and cool to work with PR.
> > Easy way to review, easy way to fix changes, the contributor does not
> need
> > to attach a new patch just need to update the PR and we'll have feedbacks
> > more fast with PR Builder Plugin and comments by line on PR.
> >
> > I prefer this way, totally agree with your PR.
> >
> > +1 :)
> >
> > On Sat, Jul 23, 2016 at 1:04 PM, John D. Ament <johndam...@apache.org>
> > wrote:
> >
> > > All,
> > >
> > > I put together a first pass PR on an improved contributor workflow that
> > can
> > > leverage github PRs.  This is in addition to our existing patch
> approach.
> > >
> > > You can find the PR here, with the changes:
> > > https://github.com/apache/deltaspike/pull/61/files
> > >
> > > Using PRs gives us a bit of an advantage:
> > >
> > > - We don't lose the original author in the commit
> > > - We can run automated tests prior to the commit being merged in
> > >
> > > Please take a look, I'm happy to adjust as needed.  I also took the
> > liberty
> > > to replace some of the to-be-retired links (e.g. people.a.o is retiring
> > > soon, mail archives are being moved to pony, ICLA is now PDF based)
> > >
> > > John
> > >
> >
> >
> >
> > --
> > Daniel Cunha
> > https://twitter.com/dvlc_
> > http://www.tomitribe.com
> > http://www.tomitribe.io
> >
>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>



-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: [VOTE] Release of Apache DeltaSpike 1.6.1

[Jason Porter]

+1

On Sat, Apr 23, 2016 at 2:05 PM, Gerhard Petracek <gpetra...@apache.org>
wrote:

> Hi,
>
> I was running the needed tasks to get the 25th release of Apache DeltaSpike
> out.
> The artifacts are deployed to Nexus [1] (and [2]).
>
> The tag is available at [3] and the release-branch at [4].
> They will get pushed to the ASF repository once the vote passed.
>
> Please take a look at the 1.6.1 artifacts and vote!
>
> Please note:
> This vote is "majority approval" with a minimum of three +1 votes (see
> [5]).
>
> 
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be released, and
> why..
> 
>
> Thanks,
> Gerhard
>
> [1]
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1036/
> [2]
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1036/org/apache/deltaspike/deltaspike/1.6.1/deltaspike-1.6.1-source-release.zip
> [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.6.1
> [4] https://github.com/os890/deltaspike-vote/tree/ds-1.6.1
> [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
>



-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: Awaitility to test async operations?

[Jason Porter]

+0 never used it, can't speak to it.

On Mon, Apr 4, 2016 at 11:35 AM, John D. Ament <johndam...@apache.org>
wrote:

> Hey guys,
>
> Was wondering what others thought about introducing Awaitlity to test some
> of the async code going on?  https://github.com/jayway/awaitility
>
> I've had some good success with it in corporate projects, so I can only
> speak highly of it.
>
> John
>



-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: Where's index.adoc?

[Jason Porter]

Does it have to do with the documentation? I know the docs are all in
asciidoc.

On Sun, Apr 3, 2016 at 6:16 AM, John D. Ament <johndam...@apache.org> wrote:

> Hey guys
>
> Was wondering, does anyone know where index.adoc is?  I noticed that I had
> to update the html file manually.  Is there purposely no equivalent of the
> html file in adoc format?
>
> John
>



-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: 1.6 to be the last release to support Java 1.6?

[Jason Porter]

+1

On Sat, Mar 26, 2016 at 11:36 AM, Harald Wellmann <hwellmann...@gmail.com>
wrote:

> +1
>
> 2016-03-26 17:49 GMT+01:00 Christian Kaltepoth <christ...@kaltepoth.de>:
>
> > +1
> >
> > 2016-03-26 16:50 GMT+01:00 Daniel Cunha <daniels...@gmail.com>:
> >
> > > +1 :)
> > >
> > > On Sat, Mar 26, 2016 at 10:34 AM, John D. Ament <johndam...@apache.org
> >
> > > wrote:
> > >
> > > > All,
> > > >
> > > > Here's the announcement I'm going to post to the site.  Let me know
> if
> > > you
> > > > have any comments on the change.
> > > >
> > > > == End of Support Announcement - Java 6
> > > >
> > > >
> > > > The Apache DeltaSpike team has decided to begin dropping support for
> > > >
> > > > Java 6.  The next release, 1.6.0 is currently planned to be the last
> > > >
> > > > minor release to support Java 6.  Patch fixes on 1.6.x will continue
> > > >
> > > > to support it, but our next minor release (1.7.0) will require
> > > >
> > > > Java 7 at a minimum.
> > > >
> > > >
> > > >
> > > > On Fri, Mar 25, 2016 at 8:17 AM Harald Wellmann <
> > hwellmann...@gmail.com>
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > 2016-03-25 13:09 GMT+01:00 John D. Ament <johndam...@apache.org>:
> > > > >
> > > > > > BTW, if we do agree to drop Java 6, do we create a 1.6
> maintenance
> > > > branch
> > > > > > or just leave the tag, and if need be cut a bug fix release then?
> > > > > >
> > > > > > John
> > > > > >
> > > > > > On Fri, Mar 25, 2016 at 8:06 AM John D. Ament <
> > johndam...@apache.org
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > To me, dropping support for Java 6 doesn't mean rewriting the
> > code
> > > > base
> > > > > > to
> > > > > > > only be compliant with Java 7 and up.
> > > > > > >
> > > > > > > It does allow for some new stuff in our codebase, if we want to
> > go
> > > > back
> > > > > > > and clean it up:
> > > > > > >
> > > > > > > - try-with-resources
> > > > > > > - automatic type inference on generics.
> > > > > > >
> > > > > > > But those are just clean ups, no real new functionality.
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Mar 25, 2016 at 4:24 AM Thomas Andraschko <
> > > > > > > andraschko.tho...@gmail.com> wrote:
> > > > > > >
> > > > > > >> basically +1
> > > > > > >> Most of our customers are using 1.7 since this year.
> > > > > > >>
> > > > > > >> I just wonder whats the benefit for us?
> > > > > > >> I think there are no language features which would improve our
> > > code
> > > > > > base.
> > > > > > >>
> > > > > > >> 2016-03-25 3:25 GMT+01:00 John D. Ament <
> johndam...@apache.org
> > >:
> > > > > > >>
> > > > > > >> > Hey guys,
> > > > > > >> >
> > > > > > >> > I've brought this topic up before without much positive
> > > > response.  I
> > > > > > >> figure
> > > > > > >> > I'll bring it up again.
> > > > > > >> >
> > > > > > >> > I'd like to propose that DeltaSpike 1.6 be the last minor
> > > release
> > > > to
> > > > > > >> > support Java 1.6.  I suspect that most users are already
> using
> > > > Java
> > > > > 7
> > > > > > or
> > > > > > >> > higher.  None of our builds in CI (builds.apache.org)
> > currently
> > > > run
> > > > > > on
> > > > > > >> 1.6
> > > > > > >> > either, so while we can say from a syntax standpoint we're
> 1.6
> > > > > > compliant
> > > > > > >> > I'm not sure we can say from a JDK Library standpoint we
> don't
> > > > rely
> > > > > on
> > > > > > >> > anything from Java 7.
> > > > > > >> >
> > > > > > >> > We're one of the few projects that probably still supports
> > Java
> > > 6
> > > > > as a
> > > > > > >> > mainline development, so I was hoping we could just cut 1.6
> as
> > > 1.6
> > > > > > >> > compliant, if we need to cut patch releases of 1.6 to apply
> > > > patches,
> > > > > > but
> > > > > > >> > with DeltaSpike 1.7 and on, focus on Java 7 and up.
> > > > > > >> >
> > > > > > >> > John
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Daniel Cunha
> > > https://twitter.com/dvlc_
> > > http://www.tomitribe.com
> > > http://www.tomitribe.io
> > >
> >
> >
> >
> > --
> > Christian Kaltepoth
> > Blog: http://blog.kaltepoth.de/
> > Twitter: http://twitter.com/chkal
> > GitHub: https://github.com/chkal
> >
>



-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: first steps for the next release

[Jason Porter]

+1

On Wednesday, March 23, 2016, Romain Manni-Bucau 
wrote:

> +1
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>
>
> 2016-03-23 11:23 GMT+01:00 Gerhard Petracek  >:
> > hi @ all,
> >
> > if there are no objections, i will start with the first steps for the
> next
> > release (v1.6.0) by the end of next week.
> >
> > regards,
> > gerhard
>


-- 
Sent from Gmail Mobile

Re: [VOTE] Release of Apache DeltaSpike 1.5.4

[Jason Porter]

+1

On Thu, Feb 18, 2016 at 1:40 PM, Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> +1
>
> 2016-02-18 21:30 GMT+01:00 Gerhard Petracek <gpetra...@apache.org>:
>
> > Hi,
> >
> > I was running the needed tasks to get the 23rd release of Apache
> DeltaSpike
> > out.
> > The artifacts are deployed to Nexus [1] (and [2]).
> >
> > The tag is available at [3] and the release-branch at [4].
> > They will get pushed to the ASF repository once the vote passed.
> >
> > Please take a look at the 1.5.4 artifacts and vote!
> >
> > Please note:
> > This vote is "majority approval" with a minimum of three +1 votes (see
> > [5]).
> >
> > 
> > [ ] +1 for community members who have reviewed the bits
> > [ ] +0
> > [ ] -1 for fatal flaws that should cause these bits not to be released,
> and
> > why..
> > 
> >
> > Thanks,
> > Gerhard
> >
> > [1]
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1033/
> > [2]
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1033/org/apache/deltaspike/deltaspike/1.5.4/deltaspike-1.5.4-source-release.zip
> > [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.5.4
> > [4] https://github.com/os890/deltaspike-vote/tree/ds-1.5.4
> > [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
> >
>



-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: Hotfix release 1.5.4

[Jason Porter]

Though would this be better as 1.5.3.1?

On Wednesday, February 17, 2016, Jason Porter <lightguard...@gmail.com>
wrote:

> +1
>
> On Wednesday, February 17, 2016, Gerhard Petracek <gpetra...@apache.org
> <javascript:_e(%7B%7D,'cvml','gpetra...@apache.org');>> wrote:
>
>> short addition:
>> i would start with the release in ~24h.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2016-02-17 16:44 GMT+01:00 Thomas Andraschko <andraschko.tho...@gmail.com
>> >:
>>
>> > Hi,
>> >
>> > i already talked to gerhard and i need a hotfix release with
>> > https://issues.apache.org/jira/browse/DELTASPIKE-1078
>> >
>> > it will also contain
>> > https://issues.apache.org/jira/browse/DELTASPIKE-1074
>> >
>> > if anyone would like to fix a issue for this release, please let me
>> know.
>> >
>> > Regards,
>> > Thomas
>> >
>>
>
>
> --
> Sent from Gmail Mobile
>


-- 
Sent from Gmail Mobile

Re: Hotfix release 1.5.4

[Jason Porter]

+1

On Wednesday, February 17, 2016, Gerhard Petracek 
wrote:

> short addition:
> i would start with the release in ~24h.
>
> regards,
> gerhard
>
>
>
> 2016-02-17 16:44 GMT+01:00 Thomas Andraschko  >:
>
> > Hi,
> >
> > i already talked to gerhard and i need a hotfix release with
> > https://issues.apache.org/jira/browse/DELTASPIKE-1078
> >
> > it will also contain
> > https://issues.apache.org/jira/browse/DELTASPIKE-1074
> >
> > if anyone would like to fix a issue for this release, please let me know.
> >
> > Regards,
> > Thomas
> >
>


-- 
Sent from Gmail Mobile

Re: [VOTE] Release of Apache DeltaSpike 1.5.3

[Jason Porter]

+1

On Saturday, February 6, 2016, Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> +1
>
> 2016-02-05 14:01 GMT+01:00 Gerhard Petracek  >:
>
> > Hi,
> >
> > I was running the needed tasks to get the 22th release of Apache
> DeltaSpike
> > out.
> > The artifacts are deployed to Nexus [1] (and [2]).
> >
> > The tag is available at [3] and the release-branch at [4].
> > They will get pushed to the ASF repository once the vote passed.
> >
> > Please take a look at the 1.5.3 artifacts and vote!
> >
> > Please note:
> > This vote is "majority approval" with a minimum of three +1 votes (see
> > [5]).
> >
> > 
> > [ ] +1 for community members who have reviewed the bits
> > [ ] +0
> > [ ] -1 for fatal flaws that should cause these bits not to be released,
> and
> > why..
> > 
> >
> > Thanks,
> > Gerhard
> >
> > [1]
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1032/
> > [2]
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1032/org/apache/deltaspike/deltaspike/1.5.3/deltaspike-1.5.3-source-release.zip
> > [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.5.3
> > [4] https://github.com/os890/deltaspike-vote/tree/ds-1.5.3
> > [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
> >
>


-- 
Sent from Gmail Mobile

Re: [VOTE] Release of Apache DeltaSpike 1.5.2

[Jason Porter]

+1

On Wed, Dec 9, 2015 at 11:57 AM, Gerhard Petracek <gpetra...@apache.org>
wrote:

> +1
>
> regards,
> gerhard
>
>
>
> 2015-12-06 20:54 GMT+01:00 Gerhard Petracek <gpetra...@apache.org>:
>
> > Hi,
> >
> > I was running the needed tasks to get the 21th release of Apache
> > DeltaSpike out.
> > The artifacts are deployed to Nexus [1] (and [2]).
> >
> > The tag is available at [3] and the release-branch at [4].
> > They will get pushed to the ASF repository once the vote passed.
> >
> > Please take a look at the 1.5.2 artifacts and vote!
> >
> > Please note:
> > This vote is "majority approval" with a minimum of three +1 votes (see
> > [5]).
> >
> > 
> > [ ] +1 for community members who have reviewed the bits
> > [ ] +0
> > [ ] -1 for fatal flaws that should cause these bits not to be released,
> > and why..
> > 
> >
> > Thanks,
> > Gerhard
> >
> > [1]
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1031/
> > [2]
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1031/org/apache/deltaspike/deltaspike/1.5.2/deltaspike-1.5.2-source-release.zip
> > [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.5.2
> > [4] https://github.com/os890/deltaspike-vote/tree/ds-1.5.2
> > [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
> >
>



-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: [VOTE] Release of Apache DeltaSpike 1.5.2

[Jason Porter]

Harald, you have tests or an app to verify your statements? If so I'll give
a -1 to the release.

On Monday, December 7, 2015, Harald Wellmann  wrote:

> -1.
>
> This release breaks one of my applications (again) with an exception in
> DeltaSpike Data.
>
> I'll get back with a JIRA ticket once I've identified the cause, which
> will probably be too late for this vote.
>
> The release will go ahead anyway, and I don't really object to that, if
> people are waiting for improvements in other areas, but this feels like a
> déjà vu.
>
> In fact, each of the previous releases broke my applications in one way or
> another, so I think the bottom line is this: There have been too many
> subtle incompatible changes going on in DeltaSpike Data that in theory
> should never happen with a patch release, and apparently there's too little
> test coverage or too much happy path testing, or else these
> incompatibilities would have been noticed sooner.
>
> Looks like we should spend some more time on Data tests before working on
> bugs or new features.
>
> Regards,
> Harald
>
>
> Am 06.12.2015 um 20:54 schrieb Gerhard Petracek:
>
>> Hi,
>>
>> I was running the needed tasks to get the 21th release of Apache
>> DeltaSpike
>> out.
>> The artifacts are deployed to Nexus [1] (and [2]).
>>
>> The tag is available at [3] and the release-branch at [4].
>> They will get pushed to the ASF repository once the vote passed.
>>
>> Please take a look at the 1.5.2 artifacts and vote!
>>
>> Please note:
>> This vote is "majority approval" with a minimum of three +1 votes (see
>> [5]).
>>
>> 
>> [ ] +1 for community members who have reviewed the bits
>> [ ] +0
>> [ ] -1 for fatal flaws that should cause these bits not to be released,
>> and
>> why..
>> 
>>
>> Thanks,
>> Gerhard
>>
>> [1]
>>
>> https://repository.apache.org/content/repositories/orgapachedeltaspike-1031/
>> [2]
>>
>> https://repository.apache.org/content/repositories/orgapachedeltaspike-1031/org/apache/deltaspike/deltaspike/1.5.2/deltaspike-1.5.2-source-release.zip
>> [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.5.2
>> [4] https://github.com/os890/deltaspike-vote/tree/ds-1.5.2
>> [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
>>
>>
>

-- 
Sent from Gmail Mobile

Re: first steps for the next release

[Jason Porter]

+1

On Thursday, November 26, 2015, Gerhard Petracek 
wrote:

> hi @ all,
>
> if there are no objections, i will start with the first steps for the next
> release (v1.5.2) by the end of next week.
>
> regards,
> gerhard
>


-- 
Sent from Gmail Mobile

Re: [VOTE] Release of Apache DeltaSpike 1.5.1

[Jason Porter]

Let's try this again +1

On Saturday, October 24, 2015, Jason Porter <lightguard...@gmail.com> wrote:

> +-
>
> On Saturday, October 24, 2015, Romain Manni-Bucau <rmannibu...@gmail.com
> <javascript:_e(%7B%7D,'cvml','rmannibu...@gmail.com');>> wrote:
>
>> +1
>> Le 24 oct. 2015 17:43, "Gerhard Petracek" <gerhard.petra...@gmail.com> a
>> écrit :
>>
>> > +1
>> >
>> > regards,
>> > gerhard
>> >
>> >
>> >
>> > 2015-10-24 16:39 GMT+02:00 Gerhard Petracek <gerhard.petra...@gmail.com
>> >:
>> >
>> > > Hi,
>> > >
>> > > I was running the needed tasks to get the 20th release of Apache
>> > > DeltaSpike out.
>> > > The artifacts are deployed to Nexus [1] (and [2]).
>> > >
>> > > The tag is available at [3] and the release-branch at [4].
>> > > They will get pushed to the ASF repository once the vote passed.
>> > >
>> > > Please take a look at the 1.5.1 artifacts and vote!
>> > >
>> > > Please note:
>> > > This vote is "majority approval" with a minimum of three +1 votes (see
>> > > [5]).
>> > >
>> > > 
>> > > [ ] +1 for community members who have reviewed the bits
>> > > [ ] +0
>> > > [ ] -1 for fatal flaws that should cause these bits not to be
>> released,
>> > > and why..
>> > > 
>> > >
>> > > Thanks,
>> > > Gerhard
>> > >
>> > > [1]
>> > >
>> >
>> https://repository.apache.org/content/repositories/orgapachedeltaspike-1030/
>> > > [2]
>> > >
>> >
>> https://repository.apache.org/content/repositories/orgapachedeltaspike-1030/org/apache/deltaspike/deltaspike/1.5.1/deltaspike-1.5.1-source-release.zip
>> > > [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.5.1
>> > > [4] https://github.com/os890/deltaspike-vote/tree/ds-1.5.1
>> > > [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
>> > >
>> >
>>
>
>
> --
> Sent from Gmail Mobile
>


-- 
Sent from Gmail Mobile

Re: [VOTE] Release of Apache DeltaSpike 1.5.1

[Jason Porter]

+-

On Saturday, October 24, 2015, Romain Manni-Bucau 
wrote:

> +1
> Le 24 oct. 2015 17:43, "Gerhard Petracek"  > a
> écrit :
>
> > +1
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2015-10-24 16:39 GMT+02:00 Gerhard Petracek  >:
> >
> > > Hi,
> > >
> > > I was running the needed tasks to get the 20th release of Apache
> > > DeltaSpike out.
> > > The artifacts are deployed to Nexus [1] (and [2]).
> > >
> > > The tag is available at [3] and the release-branch at [4].
> > > They will get pushed to the ASF repository once the vote passed.
> > >
> > > Please take a look at the 1.5.1 artifacts and vote!
> > >
> > > Please note:
> > > This vote is "majority approval" with a minimum of three +1 votes (see
> > > [5]).
> > >
> > > 
> > > [ ] +1 for community members who have reviewed the bits
> > > [ ] +0
> > > [ ] -1 for fatal flaws that should cause these bits not to be released,
> > > and why..
> > > 
> > >
> > > Thanks,
> > > Gerhard
> > >
> > > [1]
> > >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1030/
> > > [2]
> > >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1030/org/apache/deltaspike/deltaspike/1.5.1/deltaspike-1.5.1-source-release.zip
> > > [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.5.1
> > > [4] https://github.com/os890/deltaspike-vote/tree/ds-1.5.1
> > > [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
> > >
> >
>


-- 
Sent from Gmail Mobile

Re: first steps for the next release

[Jason Porter]

+1

On Tuesday, July 28, 2015, Daniel Cunha daniels...@gmail.com wrote:

 +1

 On Tue, Jul 28, 2015 at 3:28 PM, Thomas Andraschko 
 andraschko.tho...@gmail.com javascript:; wrote:

  +1
 
  2015-07-28 19:52 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com
 javascript:;:
 
   +1
  
  
   Romain Manni-Bucau
   @rmannibucau https://twitter.com/rmannibucau |  Blog
   http://rmannibucau.wordpress.com | Github 
   https://github.com/rmannibucau |
   LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
   http://www.tomitribe.com
  
   2015-07-28 10:21 GMT-07:00 Gerhard Petracek gpetra...@apache.org
 javascript:;:
  
hi @ all,
   
if there are no objections, i will start with the first steps for the
   next
release (v1.4.3) by the end of next week.
   
regards,
gerhard
   
  
 



 --
 Best regard,
 Daniel Cunha (soro)



-- 
Sent from Gmail Mobile

Re: [VOTE] Release of Apache DeltaSpike 1.4.2

[Jason Porter]

+1

On Monday, July 20, 2015, Harald Wellmann hwellmann...@gmail.com wrote:

 +1 (non-binding)

 Cheers,
 Harald

 2015-07-20 19:40 GMT+02:00 John D. Ament johndam...@apache.org
 javascript:;:

  +1 (binding)
 
  On Sun, Jul 19, 2015 at 1:11 PM Gerhard Petracek gpetra...@apache.org
 javascript:;
  wrote:
 
   Hi,
  
   I was running the needed tasks to get the 18th release of Apache
  DeltaSpike
   out.
   The artifacts are deployed to Nexus [1] (and [2]).
  
   The tag is available at [3] and the release-branch at [4].
   They will get pushed to the ASF repository once the vote passed.
  
   Please take a look at the 1.4.2 artifacts and vote!
  
   Please note:
   This vote is majority approval with a minimum of three +1 votes (see
   [5]).
  
   
   [ ] +1 for community members who have reviewed the bits
   [ ] +0
   [ ] -1 for fatal flaws that should cause these bits not to be released,
  and
   why..
   
  
   Thanks,
   Gerhard
  
   [1]
  
  
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1028/
   [2]
  
  
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1028/org/apache/deltaspike/deltaspike/1.4.2/deltaspike-1.4.2-source-release.zip
   [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.4.2
   [4] https://github.com/os890/deltaspike-vote/tree/ds-1.4.2
   [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
  
 



-- 
Sent from Gmail Mobile

Re: first steps for the next release

[Jason Porter]

+1

On Saturday, May 9, 2015, Christian Kaltepoth christ...@kaltepoth.de
wrote:

 +1

 2015-05-08 18:41 GMT+02:00 Daniel Cunha daniels...@gmail.com
 javascript:;:

  +1
 
  On Fri, May 8, 2015 at 1:36 PM, Rafael Benevides benevi...@redhat.com
 javascript:;
  wrote:
   +1
  
  
   On 5/8/15 09:00, Rudy De Busscher wrote:
  
   +1
  
   Rudy
  
   On 8 May 2015 at 13:40, Thomas Andraschko 
 andraschko.tho...@gmail.com javascript:;
   wrote:
  
   +1
  
   Am Freitag, 8. Mai 2015 schrieb Romain Manni-Bucau :
  
   +1
   Le 8 mai 2015 13:13, Gerhard Petracek gpetra...@apache.org
 javascript:;
   javascript:; a écrit :
  
   hi @ all,
  
   if there are no objections, i will start with the first steps for
 the
  
   next
  
   release (v1.4.0) by the end of next week.
  
   regards,
   gerhard
  
  
 
 
 
  --
  Best regard,
  Daniel Cunha (soro)
 



 --
 Christian Kaltepoth
 Blog: http://blog.kaltepoth.de/
 Twitter: http://twitter.com/chkal
 GitHub: https://github.com/chkal



-- 
Sent from Gmail Mobile

Re: v1.4.0 instead of v1.3.1

[Jason Porter]

Fine by me
+1

On Sat, May 2, 2015 at 4:15 PM, Mark Struberg strub...@yahoo.de wrote:

 +1

 LieGrue,
 strub


  Am 01.05.2015 um 18:51 schrieb Gerhard Petracek 
 gerhard.petra...@gmail.com:
 
  hi @ all,
 
  if there are no objections, i'll change the version number to 1.4.0
  before the next release.
 
  reasons:
  - the release will contain a new module (the proxy-module)
  - we added several new features
 
  regards,
  gerhard




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: v1.4.0 instead of v1.3.1

[Jason Porter]

+1

On Sat, May 2, 2015 at 5:26 PM, Gerhard Petracek gerhard.petra...@gmail.com
 wrote:

 finally this mail arrived twice...
 in the other thread we already have 3x +1 for v1.4.0 - i'll add your
 opinions their once i send the conclusion.

 regards,
 gerhard



 2015-05-02 23:27 GMT+02:00 John D. Ament johndam...@apache.org:

  Agreed looks like a 1.3.1 to me.
 
  On Sat, May 2, 2015, 17:09 Romain Manni-Bucau rmannibu...@gmail.com
  wrote:
 
   Yep didnt see sthg justifying an upgrade for me. What would justify it
  for
   a user - ie not for us.
Le 2 mai 2015 23:03, Gerhard Petracek gerhard.petra...@gmail.com
 a
   écrit :
  
@romain:
see e.g.
   
   
  
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312820version=12327249
   
regards,
gerhard
   
   
   
2015-05-02 22:48 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com
 :
   
 Hi Gerhard, can you highlight some new features? Not sure proxy
  module
   is
 enough by itself so would be +0 ATM for me.
 hi @ all,

 if there are no objections, i'll change the version number to 1.4.0
 before the next release.

 reasons:
  - the release will contain a new module (the proxy-module)
  - we added several new features

 regards,
 gerhard

   
  
 




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: [VOTE] Release Apache DeltaSpike-1.3.0

[Jason Porter]

+1

On Wed, Mar 4, 2015 at 9:35 AM, Rafael Benevides benevi...@redhat.com
wrote:

 +1


 On 3/4/15 04:08, Mark Struberg wrote:

 Hi!

 I’d like to call a VOTE for the release of DeltasSpike-1.3.0

 The staging repo is:
 https://repository.apache.org/content/repositories/
 orgapachedeltaspike-1020/

 The tag is available here:
 https://github.com/struberg/deltaspike/tree/deltaspike-root-1.3.0
 This will get pushed to the ASF repo once the VOTE succeeded.

 The source release is available here:
 https://repository.apache.org/content/repositories/
 orgapachedeltaspike-1020/org/apache/deltaspike/deltaspike-
 root/1.3.0/deltaspike-root-1.3.0-source-release.zip
 sha1: 62a9a425c7314811b56f55e3586ff66ce7fe383c

 You can find my key in GIT.

 Guide to testing:
 Add the following to your ~/.m2/settings.xml:

  profile
idstaging/id
repositories
  repository
idapache_staging/id
urlhttps://repository.apache.org/content/repositories/
 orgapachedeltaspike-1020//url
releasesenabledtrue/enabled/releases
snapshotsenabledfalse/enabled/snapshots
  /repository
/repositories
  /profile

 Then upgrade your project to 1.3.0 and build with mvn -Pstaging.


 Please VOTE:
 [+1] ship it
 [+0] meh, don’t care
 [-1] stop, there is a problem, ${errorcause}

 The VOTE is open for 72h.



 LieGrue,
 your Apache DeltaSpike Team





-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: first steps for the next release

[Jason Porter]

+1

On Mon, Dec 15, 2014 at 3:36 PM, Gerhard Petracek 
gerhard.petra...@gmail.com wrote:

 hi @ all,

 if there are no objections, i will start with the first steps for the next
 release (v1.2.1) by the end of the week.

 regards,
 gerhard



-- 
Jason Porter
http://en.gravatar.com/lightguardjp

[jira] [Commented] (DELTASPIKE-400) BeanBuilder should set the bean of the InjectionPoints

[Jason Porter (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14246957#comment-14246957
 ] 

Jason Porter commented on DELTASPIKE-400:
-

Which code path are we talking about here? {{readFromType}} should already have 
that data. If you're specifying {{InjectionPoints}} via {{injectionPoints}} 
then I can see it. We can either add some checks and error out, or we could try 
and create new {{InjectionPoints}} but there's no guarantee you'll have a Bean 
already ready. Maybe the exception is best if you send {{InjectionPoints}} 
without a {{Bean}}?

 BeanBuilder should set the bean of the InjectionPoints
 --

 Key: DELTASPIKE-400
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-400
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Affects Versions: 0.4
Reporter: Mark Struberg
Assignee: Mark Struberg

 BeanBuilder creates Beans which have InjetionPoints without a bean set. Means 
 getBean() will return null for them.
 This creates issues in some containers.
 What we can do is to set this info if it's null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Deltaspike Data with Arquillian - problem

[Jason Porter]

.
 ContainerDeployController.deployManaged(ContainerDeployController.java:79)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at org.jboss.arquillian.core.impl.ObserverImpl.invoke(
 ObserverImpl.java:94)
 at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(
 EventContextImpl.java:99)
 at org.jboss.arquillian.core.impl.EventContextImpl.proceed(
 EventContextImpl.java:81)
 at org.jboss.arquillian.core.impl.ManagerImpl.fire(
 ManagerImpl.java:145)
 at org.jboss.arquillian.core.impl.ManagerImpl.fire(
 ManagerImpl.java:116)
 at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
 at org.jboss.arquillian.container.test.impl.client.
 ContainerEventController.execute(ContainerEventController.java:101)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at org.jboss.arquillian.core.impl.ObserverImpl.invoke(
 ObserverImpl.java:94)
 at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(
 EventContextImpl.java:99)
 at org.jboss.arquillian.core.impl.EventContextImpl.proceed(
 EventContextImpl.java:81)
 at org.jboss.arquillian.test.impl.TestContextHandler.
 createClassContext(TestContextHandler.java:84)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at org.jboss.arquillian.core.impl.ObserverImpl.invoke(
 ObserverImpl.java:94)
 at org.jboss.arquillian.core.impl.EventContextImpl.proceed(
 EventContextImpl.java:88)
 at org.jboss.arquillian.test.impl.TestContextHandler.
 createSuiteContext(TestContextHandler.java:65)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at org.jboss.arquillian.core.impl.ObserverImpl.invoke(
 ObserverImpl.java:94)
 at org.jboss.arquillian.core.impl.EventContextImpl.proceed(
 EventContextImpl.java:88)
 at org.jboss.arquillian.core.impl.ManagerImpl.fire(
 ManagerImpl.java:145)
 at org.jboss.arquillian.core.impl.ManagerImpl.fire(
 ManagerImpl.java:116)
 at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(
 EventTestRunnerAdaptor.java:80)
 at org.jboss.arquillian.junit.Arquillian$2.evaluate(
 Arquillian.java:190)
 at org.jboss.arquillian.junit.Arquillian.multiExecute(
 Arquillian.java:345)
 at org.jboss.arquillian.junit.Arquillian.access$200(
 Arquillian.java:49)
 at org.jboss.arquillian.junit.Arquillian$3.evaluate(
 Arquillian.java:207)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
 at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155)
 at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(
 JUnit4TestReference.java:50)
 at org.eclipse.jdt.internal.junit.runner.TestExecution.
 run(TestExecution.java:38)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
 runTests(RemoteTestRunner.java:467)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
 runTests(RemoteTestRunner.java:683)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
 run(RemoteTestRunner.java:390)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
 main(RemoteTestRunner.java:197).

 i browsed through the net and didn't find a solution or an explaination.
 Has anyone expirienced the same or has anyone a working example of using
 deltaspike with arquillian for unit testing?

 Thank you
 Niki



-- 
Jason Porter
http://en.gravatar.com/lightguardjp

[jira] [Resolved] (DELTASPIKE-400) BeanBuilder should set the bean of the InjectionPoints

[Jason Porter (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Porter resolved DELTASPIKE-400.
-
   Resolution: Fixed
Fix Version/s: 1.3.0
   1.2.1

Fixed in commit ae145f3

 BeanBuilder should set the bean of the InjectionPoints
 --

 Key: DELTASPIKE-400
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-400
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Affects Versions: 0.4
Reporter: Mark Struberg
Assignee: Jason Porter
 Fix For: 1.2.1, 1.3.0


 BeanBuilder creates Beans which have InjetionPoints without a bean set. Means 
 getBean() will return null for them.
 This creates issues in some containers.
 What we can do is to set this info if it's null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release of Apache DeltaSpike 1.2.0

[Jason Porter]

+1
On Sun, Nov 30, 2014 at 14:03 Rafael Benevides benevi...@redhat.com wrote:

 +1

 On 11/30/14 15:23, Gerhard Petracek wrote:
  Hi,
 
  I was running the needed tasks to get the 13th release of Apache
 DeltaSpike
  out.
  The artifacts are deployed to Nexus [1] (and [2]).
 
  The tag is available at [3] and will get pushed to the ASF repository
 once
  the vote passed.
 
  Please take a look at the 1.2.0 artifacts and vote!
 
  Please note:
  This vote is majority approval with a minimum of three +1 votes (see
 [4]).
 
  
  [ ] +1 for community members who have reviewed the bits
  [ ] +0
  [ ] -1 for fatal flaws that should cause these bits not to be released,
 and
  why..
  
 
  Thanks,
  Gerhard
 
  [1]
  https://repository.apache.org/content/repositories/
 orgapachedeltaspike-1016
  [2]
  https://repository.apache.org/content/repositories/
 orgapachedeltaspike-1016/org/apache/deltaspike/deltaspike-
 project/1.2.0/deltaspike-project-1.2.0-source-release.zip
  [3] https://github.com/os890/deltaspike-vote/tree/
 deltaspike-project-1.2.0
  [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
 

Re: first steps for the next release

[Jason Porter]

+1
On Mon, Nov 17, 2014 at 12:10 Rafael Benevides benevi...@redhat.com wrote:

 +1 for 1.2.0


 On 11/17/14 16:54, Gerhard Petracek wrote:
  hi @ all,
 
  if there are no objections, i will start with the first steps for the
 next
  release (v1.2.0) by the end of next week.
 
  @ v1.2.0 instead of v1.1.1:
  we have some new features (esp. optional cdi 1.1+ support - e.g. the
  optional delegation to CDI.current().getBeanManager()).
 
  regards,
  gerhard
 

[jira] [Updated] (DELTASPIKE-739) BeanBuilder#readFromType should respect @Typed

[Jason Porter (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Porter updated DELTASPIKE-739:

Assignee: Rafael Benevides  (was: Jason Porter)

 BeanBuilder#readFromType should respect @Typed
 --

 Key: DELTASPIKE-739
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-739
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.3
Reporter: Ron Smeral
Assignee: Rafael Benevides
 Attachments: ds-beanbuilder-typed-reproducer.zip


 {{BeanBuilder#readFromType}} currently includes all superclasses of a type in 
 the set of bean types and it does not respect the {{@Typed}} annotation.
 This currently also causes a problem with PartialBeans which use {{@Typed}}.
 Example:
 {code}
 public interface Rules {}
 {code}
 {code}
 public class BaseRules implements Rules {}
 {code}
 {code}
 @SomePartialBeanBinding
 @Typed(AdminRules.class)
 public abstract class AdminRules implements Rules {}
 {code}
 {code}
 public class Controller {
 @Inject private Rules rules;
 }
 {code}
 This causes a deployment exception - ambiguous dependencies. The expected 
 behaviour would be, that {{AdminRules}} is not resolvable as {{Rules}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release of Apache DeltaSpike 1.0.3

[Jason Porter]

+1

On Mon, Sep 22, 2014 at 1:47 AM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:

 +1
 Le 22 sept. 2014 00:59, John D. Ament john.d.am...@gmail.com a écrit :

  +1 release looks good.
 
  I've also put together this page [1] which I'll use to pass around
 various
  parts of the internet.. (once vote is done, I'll finalize the page).
 
  [1]:
  http://deltaspike.staging.apache.org/documentation/deltaspike_1.0.3.html
 
  On Sun, Sep 21, 2014 at 2:07 PM, Gerhard Petracek gpetra...@apache.org
  wrote:
 
   Hi,
  
   I was running the needed tasks to get the 11th release of Apache
  DeltaSpike
   out.
   The artifacts are deployed to Nexus [1] (and [2]).
  
   The tag is available at [3] and will get pushed to the ASF repository
  once
   the vote passed.
  
   Please take a look at the 1.0.3 artifacts and vote!
  
   Please note:
   This vote is majority approval with a minimum of three +1 votes (see
   [4]).
  
   
   [ ] +1 for community members who have reviewed the bits
   [ ] +0
   [ ] -1 for fatal flaws that should cause these bits not to be released,
  and
   why..
   
  
   Thanks,
   Gerhard
  
   [1]
  
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1014
   [2]
  
  
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1014/org/apache/deltaspike/deltaspike-project/1.0.3/deltaspike-project-1.0.3-source-release.zip
   [3]
  https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.0.3
   [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
  
 




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: first steps for the next release

[Jason Porter]

+1

On Tue, Sep 16, 2014 at 4:49 PM, Gerhard Petracek 
gerhard.petra...@gmail.com wrote:

 hi @ all,

 if there are no objections, i will start with the first steps for the next
 release (v1.0.3) by the end of the week.

 regards,
 gerhard




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

[jira] [Commented] (DELTASPIKE-690) Documentation donation from RedHat

[Jason Porter (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14134970#comment-14134970
 ] 

Jason Porter commented on DELTASPIKE-690:
-

There was good documentation up on JDF, but it looks like we've lost it in the 
new JBoss.org, I'll create a ticket for that. In the mean time, feel free to 
use https://github.com/seam/migration/blob/develop/open18_migration.asciidoc

 Documentation donation from RedHat
 --

 Key: DELTASPIKE-690
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-690
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Documentation
Reporter: John D. Ament
Assignee: Rafael Benevides

 DeltaSpike Doc Reorg Proposal
 Summary of task
 Develop better structure of docs so users can find required info
 https://issues.apache.org/jira/browse/DELTASPIKE-642
 Areas identified for improvement
 1. Presentation
 The Documentation page of the DeltaSpike site provides a long linked table of 
 contents. The links in the table of contents take users to the relevant 
 section of the document lower down the page but for a number of these 
 sections the user then needs to click another link to get to the actual 
 content (e.g., Core).
 Examples are listed as the very last item of the Documentation page (and also 
 listed on the Home page).
 Migration information appears to be linked from the menu bar only.
 Recommendations
 Change the landing Documentation page to solely provide a list of categorized 
 (and linked) titles, keeping the actual content on separate pages. [For 
 example, http://aerogear.org/docs/guides/]
 Arrange the titles under four categories as follows:
 Getting Started
 Overview of DeltaSpike
 Installing and Configuring DeltaSpike
 Migrating to DeltaSpike
 Examples and Tutorials
 Using Individual Modules
 Link for each module page
 Reference
 Build DeltaSpike from Source
 API
 SPI
 More Resources
 Blogs and Articles
 Add-ons
 External Examples
 2. Organization
 Lots of sections contain solely a link to another section or the sole link to 
 another page. An example of the latter is the Project Configuration without 
 Maven page, in which the in-text hyperlinked ‘build’ provides the only link 
 to the Building DeltaSpike from Source page. This kind of organization means 
 that users can get easily lost navigating the documentation and makes it 
 harder for users to understand quickly how concepts and components fit 
 together.
 Recommendations
 Implement the presentation changes recommended in item 1, which links every 
 page from the Documentation page and provides a logical structure to the 
 content.
 Within each page, structure the content as outlined in the page tables at the 
 end of this document.
 3. Examples and Tutorials
 The existing Examples page is low on detail.
 There is one (internal) DeltaSpike example listed (artifact-id: 
 deltaspike-jse-owb-example) but no details on how to obtain or build it. A 
 number of examples are distributed as part of source.zip but their existence 
 is not advertised on the website. The distributed examples do not have README 
 files to inform users what the examples are or how to use them. Several 
 project templates in GitHub are linked from the Documentation page but no 
 information is provided about them. These project templates do not have 
 README files to inform users what the templates are or how to use them.
 The list of external DeltaSpike examples is minimal and the user has to open 
 every link to find out more about each. Further, some of the examples linked 
 here contain no README file to instruct users what the example is or how to 
 build it.
 There are no quickstart tutorials. It difficult for a user to quickly 
 understand or experience adding DeltaSpike to a sample project or their own 
 project and assess whether they want to learn more about DeltaSpike.
 Recommendations
 Expand the information provided on the currently listed internal example, 
 including information on what the example demonstrates and how to build it.
 Add 2-3 sentences about each of the examples distributed in source.zip, 
 specifying that the examples source is available in source.zip.
 Add a README file to the source code for each distributed example in 
 source.zip.
 Add 2-3 sentences about each of the project templates.
 Add a README file to the source code for each project template in GitHub.
 Provide one sentence about each of the external project links - what the 
 project is a demonstration of, why/when would the user find the example 
 helpful.
 Put together a simple tutorial either:
  a) demonstrating how to add (for example) the DeltaSpike Core module to a 
 maven project and make use of one of the main module features in the project.
 b) pulling apart the code of one of the project templates

Re: Release Notes pages

[Jason Porter]

I like this, the whole thing. +1 from me.

On Mon, Sep 8, 2014 at 12:04 PM, John D. Ament john.d.am...@gmail.com
wrote:

 Agreed, I was about to post something on reddit for ds and noticed there
 was no release page.

 On Mon, Sep 8, 2014 at 6:04 AM, Pete Muir pm...@redhat.com wrote:

  +1 this is something I’ve heard a lot of people ask for, and will make
  getting the word out about DS much easier.
 
  On 7 Sep 2014, at 16:06, John D. Ament john.d.am...@gmail.com wrote:
 
   Hi all
  
   I was looking at other apache projects and noted that many of them
  include
   dedicated pages for each release, with some summary information about
  what
   went in.  In DeltaSpike we're currently putting a short blurb, I was
   wondering if it makes sense to include something similar, and perhaps
  even
   merge with the generated release notes that make it into the SCM.
  
   Here's a prototype page: [1].
  
  
  
 http://deltaspike.staging.apache.org/documentation/deltaspike_1.0.2.html
 
 




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: Feedback on CMS with Github and Asciidoctor

[Jason Porter]

Great work!


On Thu, Aug 28, 2014 at 11:03 AM, Rafael Benevides benevi...@redhat.com
wrote:

 I believe that the work for the asciidoc documentation is ready!

 Please, check this generated asciidcotor page:
 http://deltaspike.apache.org/documentation/container-control-test.html

 The branch with the source code is here: https://github.com/rafabene/
 deltaspike/tree/documentation/documentation


 Em 8/27/14, 18:14, Rafael Benevides escreveu:

  Yeap. I have to agree with you.

 So I've changed my strategy...

 I've taken your PoC and made some minor modifications and place it on my
 branch: https://github.com/rafabene/deltaspike/tree/documentation/
 documentation

 Note that I'm using the agreed path for documentation folder and that I
 also included a Readme.md that instructs how to setup the credentials on
 ~/.m2/settings.xml and what maven command that should be used to deploy.

 The result was published here: http://deltaspike.apache.org/
 documentation/container-control-test.html

 What is missing now is the generated html template/styles.


 Em 8/27/14, 17:23, John D. Ament escreveu:

 IMHO, the current approach is a bit safer and more testable.  running
 mvn site will generate the asciidoc.  That would be a bit harder to do if
 we need to support running it as a part of a staging pull.


 On Wed, Aug 27, 2014 at 4:14 PM, Rafael Benevides benevi...@redhat.com
 mailto:benevi...@redhat.com wrote:

 I was trying to avoid two steps to deploy:

 1 - mvn site-deploy on git repo to copy it to the CMS staging are
 2 - CMS deploy to publish it

 But I think that should not be a problem, Right?

 So what I'll do now, based on your PoC is to make the templates of
 the generated html to be close to deltaspike site style.

 Em 8/27/14, 17:10, John D. Ament escreveu:

 Rafael,

 This shouldn't be needed any longer.  Based on what I did, we can
 now do a mvn site-deploy to copy everything into the CMS staging
 area.  Once verified go into CMS and do a publish.

 John


 On Wed, Aug 27, 2014 at 3:57 PM, Rafael Benevides
 benevi...@redhat.com mailto:benevi...@redhat.com wrote:

 Hi all,

 This email is just to give a feedback about making CMS to
 work with Github and Asciidoc.

 Finally  I was able to understand enough how CMS works and
 probably I'm stopped where John Ament was.

 What I'm doing now is writing a GitUtil Perl Module that will
 be hosted at
 http://svn.apache.org/repos/asf/deltaspike/site/trunk/lib/
 that will be responsible for cloning the documentation (on
 deltaspike git repo) and then another module will run the
 build (asciidoc to html) just for [git_root/documentation/].

 The idea is that the final documentation gets hosted at
 deltaspike.apache.org/documentation/
 http://deltaspike.apache.org/documentation/ (note the sub
 folder).

 Further steps: Prepare a template so asciidoc generated html
 uses the same style of deltaspike.apache.org
 http://deltaspike.apache.org.

 Well, the idea here is to make everyone aware about this and
 also say that if is there anybody if Perl knowledge, you're
 welcome to give some hints!

 Thanks


 --
 *Rafael Benevides | Senior Software Engineer*
 JBoss Developer
 M: +55-61-9269-6576 tel:%2B55-61-9269-6576

 Red Hat

 Better technology. Faster innovation. Powered by community
 collaboration.
 See how it works at www.redhat.com http://www.redhat.com/

 LinkedIn http://www.linkedin.com/company/3258288 Youtube
 https://www.youtube.com/redhatlatam










-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: [VOTE] Release of Apache DeltaSpike 1.0.2

[Jason Porter]

+1—
Sent from Mailbox

On Sun, Aug 17, 2014 at 7:16 AM, Gerhard Petracek gpetra...@apache.org
wrote:

 Hi,
 I was running the needed tasks to get the 10th release of Apache DeltaSpike
 out.
 The artifacts are deployed to Nexus [1] (and [2]).
 The tag is available at [3] and will get pushed to the ASF repository once
 the vote passed.
 Please take a look at the 1.0.2 artifacts and vote!
 Please note:
 This vote is majority approval with a minimum of three +1 votes (see [4]).
 
 [ ] +1 for community members who have reviewed the bits
 [ ] +0
 [ ] -1 for fatal flaws that should cause these bits not to be released, and
 why..
 
 Thanks,
 Gerhard
 [1]
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1013
 [2]
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1013/org/apache/deltaspike/deltaspike-project/1.0.2/deltaspike-project-1.0.2-source-release.zip
 [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.0.2
 [4] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: DeltaSpike docs plan

[Jason Porter]

+1 from me. —
Sent from Mailbox

On Mon, Aug 11, 2014 at 9:54 AM, Rafael Benevides benevi...@redhat.com
wrote:

 I ran the PoC and I do really thing that it works for DeltaSpike 
 (considering that there's no restriction on CMS).
 Can I give a green sign to Michelle start the docs refactoring (as 
 planned) using Asciidoctor? I think that she and her team can work on 
 its own repository and them move it in one big shot once that we have 
 all requirements setup. Wdyt ?
 Em 8/11/14, 8:17, John D. Ament escreveu:
 @mark

 That's what I based it on actually.


 On Mon, Aug 11, 2014 at 12:44 AM, Mark Struberg strub...@yahoo.de wrote:

 You can look at batchee.

 Romain configured offline doc (with markdown, but could also be asciidoc)
 and mvn scm-publish

 LieGrue,
 strub


 
 On Sat, 9/8/14, John D. Ament john.d.am...@gmail.com wrote:

   Subject: Re: DeltaSpike docs plan
   To: deltaspike dev@deltaspike.apache.org
   Date: Saturday, 9 August, 2014, 15:54

   Actually, from digging
   around their code, might have an easier solution, so
   long as everyone agrees.

   I have a small POC setup here:

 https://github.com/johnament/deltaspike/commit/402becc0e450e551570107a1661d39e9eb6a43cb

   I setup a local VM w/ a SVN
   repo to test it out.  Basically, we can
   generate the asciidoc locally using mvn site,
   then run mvn site-deploy to
   move the
   rendered files to staging.  Once done, login to CMS and
   promote to
   prod.

   The only change would be to get infra to switch
   our script to use the shell
   option.  It
   does put the rendering process on whoever is writing the
   docs,
   but since it's using the java
   plugin and jruby, nothing should need to be
   downloaded separately to machines.


   On Fri, Aug 8, 2014 at 1:55
   PM, Rafael Benevides benevi...@redhat.com
   wrote:

I
   remember that someone said that CMS already supports
   remote
repositories. Can't we start
   by having this documents moved soon while we
discuss about the asciidoc rendering ?
   
Em 8/8/14, 10:53,
   Gerhard Petracek escreveu:
   
 @john:
the
   infra team is usually not the blocking part (if there is
   no
significant
technical issue and they don't get
   a new heavy part to maintain).
   
regards,
   
   gerhard
   
   
   
2014-08-08
   15:37 GMT+02:00 John D. Ament john.d.am...@gmail.com:
   
 I think we
   need to convince infra@ that these are all must needed
features.
  From looking at the
   code behind CMS, it would appear that it's the one
calling markdown based on the
   imports in our files.  Unless we want to do
something crazy like render
   asciidoc in markdown format, then hand that
over for rendering..
   
Still
   would need to convince that pulling from git over the svn
   site is
ideal as well.
   
   
   John
   
   
On
   Fri, Aug 8, 2014 at 9:03 AM, Rafael Benevides benevi...@redhat.com
wrote:
   
 Em
   8/8/14, 6:49, Pete Muir escreveu:
   
  On 7 Aug 2014, at
   18:47, Rafael Benevides benevi...@redhat.com
wrote:
   
  Before we
   have a deal with Michelle's team about these content
changes,
   
I think we should
   close the two other definitions:
   
- docs location: move
   to deltaspike sources, create a new repository,
other?
   
 +1 to move to
   sources
   
 +1 to move to sources
   
   and
   
-docs format: markdown
   or asciidoc
   
 +1 for asciidoc.
   
 +1 for asciidoc
   
   
 However I believe we also
   need agree on:
   
* add support for asciidoc
   to Apache CMS
* add
   support for importing external repo to Apache CMS
   
so that the docs can still
   be build as part of the website.
   
  From what
   people have said in the past, both are possible, if
   someone
(e.g. Rafael
   ;-) can spend a couple of days doing it.
   
 Definitely I would like
   to help/handle that. I believe that both
   
   
   (asciidoc
   
support + importing external
   repo) will bring open doors to
documentation
contribution.
   
   
   I believe that we should
   propose a vote to decided this, otherwise it
   
can become an endless
   discussion. Wdyt ?
   
   
   
Em 8/4/14, 17:28,
   Gerhard Petracek escreveu:
   
 @suggested content
   changes:
+1
   
regards,
gerhard
   
   
   
2014-08-01 18:46
   GMT+02:00 Rafael Benevides benevi...@redhat.com
mailto:benevi...@redhat.com:
   
 Hi all,
   
 As you may
   known, Red Hat docs team was called to help on
 DeltaSpike
   docs. After a long period, they have analyzed the
   
   documentation and bring us an awesome plan that is
   available
   
   here:
   
   https://docs.google.com/document/d/186f_
   
   amQ9XuREq8FcO7orxvOjQZtvEEYa7WPj1e8p8bM/edit#heading=h.4sqhyz68wgg2
   
 The
   document is opened for comments.
   
 Something
   

Re: first steps for the next release

[Jason Porter]

+1


On Tue, Aug 5, 2014 at 10:55 PM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:

 +1
 Le 6 août 2014 05:30, Christian Kaltepoth christ...@kaltepoth.de a
 écrit :

  +1
 
 
  2014-08-06 4:27 GMT+02:00 John D. Ament john.d.am...@gmail.com:
 
   +1
  
  
   On Tue, Aug 5, 2014 at 5:24 PM, Gerhard Petracek 
   gerhard.petra...@gmail.com
wrote:
  
hi @ all,
   
if there are no objections, i will start with the first steps for the
   next
release (v1.0.2) by the end of next week.
   
regards,
gerhard
   
  
 
 
 
  --
  Christian Kaltepoth
  Blog: http://blog.kaltepoth.de/
  Twitter: http://twitter.com/chkal
  GitHub: https://github.com/chkal
 




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: DeltaSpike docs plan

[Jason Porter]

Wow, looks like a lot of work was spent on the analysis of the
documentation! Thanks Michelle!

+1 from me for all the suggestions.


On Fri, Aug 1, 2014 at 10:46 AM, Rafael Benevides benevi...@redhat.com
wrote:

  Hi all,

 As you may known, Red Hat docs team was called to help on DeltaSpike docs.
 After a long period, they have analyzed the documentation and bring us an
 awesome plan that is available here:
 https://docs.google.com/document/d/186f_amQ9XuREq8FcO7orxvOjQZtvEEYa7WPj1e8p8bM/edit#heading=h.4sqhyz68wgg2

 The document is opened for comments.

 Something that was also discussed not only inside Red Hat but with some
 community members is about the format and source of the documentation. I
 strongly believe that we should have the documentation somewhere else but
 the DS site source. It could improve the ease to the community to
 contribute with it. Having said that, it's also suggested that we should
 use asciidoc as documentation format.

 So what we have until now ?

 - The documentation plan to be reviewed and approved by the DS community.
 Then we can talk about the plans to make it happen.
 - The documentation location: Recommendation to be out of the site source.
 - The documentation format: Suggested to use asciidoc.

 Please, read the plan and lets discuss about these 3 topics individually.

 Michelle Murray (whose team provided the plan and she is copied on this
 Thread) can follow the feedback.
 --

 *Rafael Benevides | Senior Software Engineer*
 JBoss Developer
 M: +55-61-9269-6576

 [image: Red Hat]

 Better technology. Faster innovation. Powered by community collaboration.
 See how it works at www.redhat.com

 [image: LinkedIn] http://www.linkedin.com/company/3258288 [image:
 Youtube] https://www.youtube.com/redhatlatam




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: [VOTE] Release of Apache DeltaSpike 1.0.1

[Jason Porter]

+1


On Mon, Jul 14, 2014 at 6:32 AM, Rafael Benevides benevi...@redhat.com
wrote:

 +1

 Em 7/14/14, 6:13, Christian Kaltepoth escreveu:

  +1


 2014-07-14 9:52 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:

  +1


 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau


 2014-07-14 9:27 GMT+02:00 Thomas Andraschko andraschko.tho...@gmail.com
 :

 +1


 2014-07-13 16:12 GMT+02:00 Gerhard Petracek gerhard.petra...@gmail.com
 :

  +1

 regards,
 gerhard



 2014-07-13 16:11 GMT+02:00 Gerhard Petracek gpetra...@apache.org:

  Hi,

 I was running the needed tasks to get the 9th release of Apache

 DeltaSpike

 out.
 The artifacts are deployed to Nexus [1] (and [2]).

 The tag is available at [3] and will get pushed to the ASF repository

 once

 the vote passed.

 Please take a look at the 1.0.1 artifacts and vote!

 Please note:
 This vote is majority approval with a minimum of three +1 votes (see
 [4]).

 
 [ ] +1 for community members who have reviewed the bits
 [ ] +0
 [ ] -1 for fatal flaws that should cause these bits not to be

 released,

 and why..
 

 Thanks,
 Gerhard

 [1]

  https://repository.apache.org/content/repositories/
 orgapachedeltaspike-1012

 [2]

  https://repository.apache.org/content/repositories/
 orgapachedeltaspike-1012/org/apache/deltaspike/deltaspike-
 project/1.0.1/deltaspike-project-1.0.1-source-release.zip

 [3]

 https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.0.1

   [4] http://www.apache.org/foundation/voting.html#ReleaseVotes







-- 
Jason Porter
http://en.gravatar.com/lightguardjp

DELTASPIKE-638 and DELTASPIKE-636

[Jason Porter]

Do we have tests for 636? If we don't have a test we need to create one so I 
understand how we can best fix this problem. —
Sent from Mailbox

Re: [DISCUSS] supporting different spec versions

[Jason Porter]

I think #1 is really the only way we can realistically continue forward. We
should communicate though that those matrices which use earlier versions of
the spec(s) probably will not receive as much attention, probably just bug
fixes, unless we can refactor to a base for those modules and then add new
things in base where appropriate.


On Sat, Jun 28, 2014 at 5:17 PM, John D. Ament john.d.am...@gmail.com
wrote:

 I'd agree to #1.  I was actually thinking recently about how to
 re-implement core using CDI 1.1 features.  I'll send out a separate
 email RE that.

 On Sat, Jun 28, 2014 at 6:51 PM, Romain Manni-Bucau
 rmannibu...@gmail.com wrote:
  ok, so I'd say 1.
 
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
  2014-06-29 0:46 GMT+02:00 Gerhard Petracek gerhard.petra...@gmail.com:
  no - i contacted esp. one server team months ago and they promised to
 fix
  it.
  however, the latest release contains fixes for several issues i reported
  except this one.
  (and afaik there won't be any new ee6 release any time soon and an ee7
  release might take some time as well.)
 
  since we might see similar issues with ee8+, we need a nice approach.
 
  regards,
  gerhard
 
 
 
  2014-06-29 0:09 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
 
  +0 for 1
  -1 for 2 (otherwise a single branch will be maintained in practise)
  are we able to fix them? for 3
 
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
  2014-06-29 0:03 GMT+02:00 Gerhard Petracek gerhard.petra...@gmail.com
 :
   hi @ all,
  
   as we have seen e.g. as7 logs exceptions during the startup due to
 our
   optional classes (needed for jsf 2.2+).
   since we really need at least some of them (otherwise we would break
 jsf
   2.2+ applications), we said that users should ignore those log
 entries
   (there is no impact later on).
   however, there are other servers which don't ignore it and the
 deployment
   fails.
  
   we have different options here - e.g.:
   #1 special modules once they are needed
   #2 one branch per java ee version
   #3 keep it as it is (and ignore those servers)
  
   regards,
   gerhard
 




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: [VOTE] logo-color

[Jason Porter]

+1 for blue


On Tue, Jun 17, 2014 at 8:39 AM, Bruno Leonardo Gonçalves 
brunol...@gmail.com wrote:

 +1 for blue


 2014-06-14 15:55 GMT-03:00 Gerhard Petracek gerhard.petra...@gmail.com:

  hi @ all,
 
  this second vote is about the color and therefore the final logo.
 
  i've uploaded the candidates provided by jim at [1]-[4].
  please send a +1 for one of them.
 
  regards,
  gerhard
 
  [1] http://s.apache.org/DS_LOGO_BLUE_VOTE2
  [2] http://s.apache.org/DS_LOGO_ORANGE_VOTE2
  [3] http://s.apache.org/DS_LOGO_PURPLE_VOTE2
  [4] http://s.apache.org/DS_LOGO_RED_VOTE2
 




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: [DISCUSS] next release version? 0.6 or 1.0?

[Jason Porter]

Probably because we've become busy with some other projects and priorities :(—
Sent from Mailbox for iPhone

On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim oranh...@gmail.com wrote:

 The commit graph shows too few committers.. and I appreciate your work! 
 I also notice too few Redhat/JBoss Weld/Seam committers left on the project. 
 How come?
 /ove
 On 16. feb. 2014, at 22:10, Gerhard Petracek gerhard.petra...@gmail.com 
 wrote:
 hi ove,
 
 i was only talking about the commits.
 
 regards,
 gerhard
 
 http://www.irian.at
 
 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 
 2014-02-16 22:07 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com:
 
 +1 Ove
 We are really late for an 0.6. I would release 0.6 this/next month and
 after that, lets finish 1.0.
 We should fix all open issues and finish the documentation!
 

Re: Optimizing the integration tests

[Jason Porter]

 a
 testDatabase configuration for tomee. So, we could have just one
 arquillian.xml file somewhere in the testsuite root, copy it over
 using
 resources-plugin, and override it only when necessary.
 One minor problem is -- and this is for the container unpacking

 too

 --

  that to point to the testsuite root, every pom would need to keep

 a

  relative reference to it (e.g. testsuite.root../../../
 testsuite.root),
 which is ugly, but doable.


 On 3.1.2014 06:26, Christian Kaltepoth wrote:

Hey Ron,

  yeah, there are differences between arquillian.xml files. But

 why?

 I

  don't
 see any reason for having different arquillian.xml files between
 modules.
 Actually the integration test Maven profiles are also located in

 a

  single
 parent pom and not in each individual module pom. IMHO we should
 treat
 arquillian.xml the same way. Unless there is a good reason for

 having

  multiple ones.

 I agree that we should unpack the container only once. I'm not

 sure I

  like
 to use java.io.tmpdir though. It would be nice to have it in the
 top-level
 target directory or something like that. That would ensure that
 running
 mvn clean would also remove the unpacked container.

 Christian


 2014/1/2 Ron Smeral rsme...@redhat.com

 On 2.1.2014 17:55, Christian Kaltepoth wrote:

  Hey all,

   there are two things I would like to address regarding our

 integration
 test
 suite.

 1. Currently each module has its own arquillian.xml file. IMHO

 this

  doesn't
 make sense. What about using a single arquillian.xml and

 placing

   it in
 the
 test-utils module?

 +0, there are minor differences among them currently
 (though

 not

  sure

   if

 necessary), and it would make it more difficult to make an
 individual
 modification if there was single arquillian.xml.


 2. We have both managed and remote profiles for some
 containers.
 But

   the managed profiles (especially Wildfly + Glassfish)
 require

 you to
 manually download and setup the corresponding container which I
 would
 like
 to avoid. I think it would be nicer if the managed profiles
 could do
 this
 automatically. This would simplify the process of running the

 tests

  locally
 before committing and it would also be easier to create CI jobs

 for

  them.
 See [1] for an example of a profile which sets up the container
 automatically and therefore runs out of the box even in

 transient

   CI
 environments like Travis [2].

 There already is such profile at least for JBoss AS7

   (jbossas-build-managed-7) and at this very moment I'm adding

 such

  profile
 for WildFly. However, currently there is a minor drawback to the
 current
 approach -- the container is unpacked for every module and so
 almost 5
 GB
 of diskspace is required to run the whole testsuite, which is

 quite

  impractical. It would be nice to have the container unpacked to

 a

  shared
 location, e.g. ${java.io.tmpdir}, just as in the ocpsoft rewrite

 pom

  you
 linked. I'll try that in the AS7 and WF8 profiles.



 Thoughts?

   [1]

 https://github.com/ocpsoft/rewrite/blob/master/pom.xml#L706

   [2] https://travis-ci.org/ocpsoft/rewrite/builds/16192940

 Christian


  --

Ron Smeral

  JBoss Quality Engineer
 Brno



--

  Ron Smeral

 JBoss Quality Engineer
 Brno



   --

 Ron Smeral
 JBoss Quality Engineer
 Brno



  --
 Ron Smeral
 JBoss Quality Engineer
 Brno



 --
 Christian Kaltepoth
 Blog: http://blog.kaltepoth.de/
 Twitter: http://twitter.com/chkal
 GitHub: https://github.com/chkal



 --
 Christian Kaltepoth
 Blog: http://blog.kaltepoth.de/
 Twitter: http://twitter.com/chkal
 GitHub: https://github.com/chkal




 --
 Ron Smeral
 JBoss Quality Engineer
 Brno




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

[Jason Porter]

I'd like to engage the Pivotal Team (anyone have contacts?) to see if we
can get some of there help as well to create a really good integration.


On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek 
gerhard.petra...@gmail.com wrote:

 hi @ all,

 i would like to continue with this discussion.

 [1] describes a two-way bridge which is already based on deltaspike.
 it offers a simple spi which allows more advanced add-ons like it is
 mentioned in [2].

 regards,
 gerhard

 [1]
 http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html
 [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html



 2013/2/19 Matt Benson gudnabr...@gmail.com

 Okay, I spent some time with Sam on IRC hashing this out.  Assuming that
 Seam-Spring is covered under the SG(s?) Red Hat has filed for deltaspike,
 his view is that it's not terribly important who does the initial code
 import, though it would be best for a so-authorized Red Hatter to be the
 one to change the file headers.  I will be out of pocket for the rest of
 the week beyond today, so if you, Marius, are able to work on the import
 end of this week/early next then that's in any event as soon as I would
 have been able to get to it anyway.  Otherwise, anyone can do that, with
 someone still employed by RH finally applying the change that modifies the
 headers--which, I suppose, could be prepared by anyone else and simply
 shared among our private git repos.

 Matt


 On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici 
 marius.bogoev...@gmail.com wrote:

  I still am a participant on this thread, but doing more reading than
  writing as of late :)
 
  So, yes, I've been strapped for time with the job and the transition,
 but
  I'd be happy to help out with this at the end of the week or early next.
 
  With my CLA on file, and the code being granted already, I'm not sure
 what
  else needs to be done. I'm happy for the code to live in DeltaSpike,
 fwiw.
 
  On 2013-02-18, at 6:50 PM, Matt Benson gudnabr...@gmail.com wrote:
 
   Seems Marius's prior participation on this thread was via a gmail
  address.
   With him no longer at Red Hat we definitely want to make sure we take
 the
   necessary precautions wrt IP.
  
   Matt
  
  
   On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter 
 lightguard...@gmail.com
  wrote:
  
   I'm pretty sure we've granted Seam Spring to Apache. I'll need to
 check
  to
   see if Marius has subscribed to this list on a personal email as he
 has
   embarked on a new adventure outside of Red Hat.
  
  
   On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson gudnabr...@gmail.com
  wrote:
  
   Let me refine my plan to say that it would be *best* if Marius does
 the
   commit since AIUI this is mostly code he personally authored, but as
  long
   as RH intends for Seam-Spring to be donated to Apache deltaspike,
  probably
   no irreparable *harm* would be caused by another Red Hatter pulling
 the
   trigger.
  
   Matt
  
  
   On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson gudnabr...@gmail.com
   wrote:
  
   I think this received enough +1 votes (I'll add mine now) to
 proceed.
   If
   a Red Hatter (Marius?) would do the simplest repackaging possible
 and
   commit that then others could join in the quest to modularize the
 hell
   out
   of it.  :)  Presumably we'd do this on a branch until considered
  baked
   enough to merge to master.
  
   Let's go!
  
   Matt
  
  
   On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg 
   arne.limb...@openknowledge.de wrote:
  
   Hi,
  
   Some ideas from my side, too ([1] and [2]). Unfortunately it is in
   german.
   But everyone of you can read the code. We used an advanced
 version of
   that
   code to build a Spring-CDI-Bridge in a large project.
 Unfortunately
   meanwhile the project is completely migrated to CDI and the code
 is
   lost
   in subversion. Will see, if I find the final version and can
 donate
  it.
  
   Cheers,
   Arne
  
   [1]
  
  
  
 
 http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe
   r-eine-cdi-extension-erster-teil.html
  
 
 http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-erster-teil.html
  
   [2]
  
  
  
 
 http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe
   r-eine-cdi-extension-zweiter-teil.html
  
 
 http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-zweiter-teil.html
  
  
  
  
   Am 15.10.12 17:16 schrieb Jason Porter unter 
   lightguard...@gmail.com:
  
   You have my +1 Marius. If we can rouse the CDISource guys (mostly
   Rick)
   they may have some ideas as well.
  
   On Mon, Oct 15, 2012 at 1:53 AM, Antoine Sabot-Durand 
   anto...@sabot-durand.net wrote:
  
   +1 it would definitively improve Java EE and CDI adoption.
  
   Antoine SABOT-DURAND
  
  
  
   Le 15 oct. 2012 à 09:41, Romain Manni-Bucau 
 rmannibu...@gmail.com
  
   a
   écrit :
  
   +1 (since DS manages spring context lifecycle

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

[Jason Porter]

Do we just want to take what we had in Seam 3 and move it over?


On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek 
gerhard.petra...@gmail.com wrote:

 hi jason,

 the bridge doesn't introduce an api and the spi just provides a simple
 contract for starting the container as well as a bean-filter.
 - if needed, we could improve the implementation at any time.
 imo we should add it before the release of v0.6 (since a lot of users
 requested such a bridge).

 regards,
 gerhard



 2014/1/22 Jason Porter lightguard...@gmail.com

  I'd like to engage the Pivotal Team (anyone have contacts?) to see if we
  can get some of there help as well to create a really good integration.
 
 
  On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek 
  gerhard.petra...@gmail.com wrote:
 
  hi @ all,
 
  i would like to continue with this discussion.
 
  [1] describes a two-way bridge which is already based on deltaspike.
  it offers a simple spi which allows more advanced add-ons like it is
  mentioned in [2].
 
  regards,
  gerhard
 
  [1]
 
 http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html
  [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html
 
 
 
  2013/2/19 Matt Benson gudnabr...@gmail.com
 
  Okay, I spent some time with Sam on IRC hashing this out.  Assuming
 that
  Seam-Spring is covered under the SG(s?) Red Hat has filed for
 deltaspike,
  his view is that it's not terribly important who does the initial code
  import, though it would be best for a so-authorized Red Hatter to be
 the
  one to change the file headers.  I will be out of pocket for the rest
 of
  the week beyond today, so if you, Marius, are able to work on the
 import
  end of this week/early next then that's in any event as soon as I would
  have been able to get to it anyway.  Otherwise, anyone can do that,
 with
  someone still employed by RH finally applying the change that modifies
  the
  headers--which, I suppose, could be prepared by anyone else and simply
  shared among our private git repos.
 
  Matt
 
 
  On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici 
  marius.bogoev...@gmail.com wrote:
 
   I still am a participant on this thread, but doing more reading than
   writing as of late :)
  
   So, yes, I've been strapped for time with the job and the transition,
  but
   I'd be happy to help out with this at the end of the week or early
  next.
  
   With my CLA on file, and the code being granted already, I'm not sure
  what
   else needs to be done. I'm happy for the code to live in DeltaSpike,
  fwiw.
  
   On 2013-02-18, at 6:50 PM, Matt Benson gudnabr...@gmail.com wrote:
  
Seems Marius's prior participation on this thread was via a gmail
   address.
With him no longer at Red Hat we definitely want to make sure we
  take the
necessary precautions wrt IP.
   
Matt
   
   
On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter 
  lightguard...@gmail.com
   wrote:
   
I'm pretty sure we've granted Seam Spring to Apache. I'll need to
  check
   to
see if Marius has subscribed to this list on a personal email as
 he
  has
embarked on a new adventure outside of Red Hat.
   
   
On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson 
 gudnabr...@gmail.com
   wrote:
   
Let me refine my plan to say that it would be *best* if Marius
  does the
commit since AIUI this is mostly code he personally authored, but
  as
   long
as RH intends for Seam-Spring to be donated to Apache deltaspike,
   probably
no irreparable *harm* would be caused by another Red Hatter
  pulling the
trigger.
   
Matt
   
   
On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson 
 gudnabr...@gmail.com
  
wrote:
   
I think this received enough +1 votes (I'll add mine now) to
  proceed.
If
a Red Hatter (Marius?) would do the simplest repackaging
 possible
  and
commit that then others could join in the quest to modularize
 the
  hell
out
of it.  :)  Presumably we'd do this on a branch until considered
   baked
enough to merge to master.
   
Let's go!
   
Matt
   
   
On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg 
arne.limb...@openknowledge.de wrote:
   
Hi,
   
Some ideas from my side, too ([1] and [2]). Unfortunately it is
  in
german.
But everyone of you can read the code. We used an advanced
  version of
that
code to build a Spring-CDI-Bridge in a large project.
  Unfortunately
meanwhile the project is completely migrated to CDI and the
 code
  is
lost
in subversion. Will see, if I find the final version and can
  donate
   it.
   
Cheers,
Arne
   
[1]
   
   
   
  
 
 http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe
r-eine-cdi-extension-erster-teil.html
   
  
 
 http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-erster-teil.html
   
[2]
   
   
   
  
 
 http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

[Jason Porter]

+1 for adding the Spring integration


On Wed, Jan 22, 2014 at 11:21 AM, John D. Ament john.d.am...@gmail.comwrote:

 +1 to Romain
 I'd like to see something like this for a 1.0 release.  It would be a
 real game changer.

 On Wed, Jan 22, 2014 at 12:03 PM, Romain Manni-Bucau
 rmannibu...@gmail.com wrote:
  I'd release 0.6 before having it, it will surely create discussion
  once we'll get something and it is easy to do something totally
  brokenn in particular when we'll want to get something clever in a web
  context
 
  btw we shouldn't do it without pivotal IMO
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
 
  2014/1/22 Jason Porter lightguard...@gmail.com:
  Do we just want to take what we had in Seam 3 and move it over?
 
 
  On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek 
  gerhard.petra...@gmail.com wrote:
 
  hi jason,
 
  the bridge doesn't introduce an api and the spi just provides a simple
  contract for starting the container as well as a bean-filter.
  - if needed, we could improve the implementation at any time.
  imo we should add it before the release of v0.6 (since a lot of users
  requested such a bridge).
 
  regards,
  gerhard
 
 
 
  2014/1/22 Jason Porter lightguard...@gmail.com
 
   I'd like to engage the Pivotal Team (anyone have contacts?) to see
 if we
   can get some of there help as well to create a really good
 integration.
  
  
   On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek 
   gerhard.petra...@gmail.com wrote:
  
   hi @ all,
  
   i would like to continue with this discussion.
  
   [1] describes a two-way bridge which is already based on deltaspike.
   it offers a simple spi which allows more advanced add-ons like it is
   mentioned in [2].
  
   regards,
   gerhard
  
   [1]
  
 
 http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html
   [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html
  
  
  
   2013/2/19 Matt Benson gudnabr...@gmail.com
  
   Okay, I spent some time with Sam on IRC hashing this out.  Assuming
  that
   Seam-Spring is covered under the SG(s?) Red Hat has filed for
  deltaspike,
   his view is that it's not terribly important who does the initial
 code
   import, though it would be best for a so-authorized Red Hatter to
 be
  the
   one to change the file headers.  I will be out of pocket for the
 rest
  of
   the week beyond today, so if you, Marius, are able to work on the
  import
   end of this week/early next then that's in any event as soon as I
 would
   have been able to get to it anyway.  Otherwise, anyone can do that,
  with
   someone still employed by RH finally applying the change that
 modifies
   the
   headers--which, I suppose, could be prepared by anyone else and
 simply
   shared among our private git repos.
  
   Matt
  
  
   On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici 
   marius.bogoev...@gmail.com wrote:
  
I still am a participant on this thread, but doing more reading
 than
writing as of late :)
   
So, yes, I've been strapped for time with the job and the
 transition,
   but
I'd be happy to help out with this at the end of the week or
 early
   next.
   
With my CLA on file, and the code being granted already, I'm not
 sure
   what
else needs to be done. I'm happy for the code to live in
 DeltaSpike,
   fwiw.
   
On 2013-02-18, at 6:50 PM, Matt Benson gudnabr...@gmail.com
 wrote:
   
 Seems Marius's prior participation on this thread was via a
 gmail
address.
 With him no longer at Red Hat we definitely want to make sure
 we
   take the
 necessary precautions wrt IP.

 Matt


 On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter 
   lightguard...@gmail.com
wrote:

 I'm pretty sure we've granted Seam Spring to Apache. I'll
 need to
   check
to
 see if Marius has subscribed to this list on a personal email
 as
  he
   has
 embarked on a new adventure outside of Red Hat.


 On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson 
  gudnabr...@gmail.com
wrote:

 Let me refine my plan to say that it would be *best* if
 Marius
   does the
 commit since AIUI this is mostly code he personally
 authored, but
   as
long
 as RH intends for Seam-Spring to be donated to Apache
 deltaspike,
probably
 no irreparable *harm* would be caused by another Red Hatter
   pulling the
 trigger.

 Matt


 On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson 
  gudnabr...@gmail.com
   
 wrote:

 I think this received enough +1 votes (I'll add mine now) to
   proceed.
 If
 a Red Hatter (Marius?) would do the simplest repackaging
  possible
   and
 commit that then others could join in the quest to
 modularize
  the
   hell
 out
 of it.  :)  Presumably we'd do this on a branch until
 considered
baked

[jira] [Commented] (DELTASPIKE-510) PersistenceException not handled by @Handles @FacesRequest ExceptionEventjavax.persistence.PersistenceException

[Jason Porter (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879186#comment-13879186
 ] 

Jason Porter commented on DELTASPIKE-510:
-

This is working exactly as it should, and exactly as it is documented. Take a 
look at http://deltaspike.apache.org/core.html#exception-handler-annotations, 
the last example. In both the example and the code in your project the 
exception handlers are being qualified, exactly the same way qualifiers in base 
CDI.

Without seeing where this exception is coming from (is the exception qualified 
when it's sent to exception handling?) the best I can surmise is that the 
exception when it is sent for exception handling is not receiving the 
{{@FacesRequest}} qualifier, therefore none of the handlers in your code will 
pick it up.

 PersistenceException not handled by @Handles @FacesRequest 
 ExceptionEventjavax.persistence.PersistenceException
 -

 Key: DELTASPIKE-510
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-510
 Project: DeltaSpike
  Issue Type: Bug
  Components: ExceptionControl-Module
Affects Versions: 0.5
 Environment: JBoss AS 7.1
Reporter: Esteve
  Labels: exception-handling

 Hi,
 I have defined a @ExceptionHandler  like this:
 @ExceptionHandler
 public class FacesExceptionHandler {
   @Inject
   private Logger log;
   
   public void handlePersistenceException(@Handles @FacesRequest 
 ExceptionEventjavax.persistence.PersistenceException evt, FacesContext 
 facesContext) {
   log.debug( JSF Exception handler.  Handling 
 javax.persistence.PersistenceException: , evt);
   facesContext.addMessage(null, new 
 FacesMessage(FacesMessage.SEVERITY_ERROR, S'ha produït un error al 
 emmagatzemar les dades a la base de dades: 
 +evt.getException().getLocalizedMessage() , ));
   evt.handledAndContinue();
   }
   public void handleOptimisticLockException(@Handles @FacesRequest 
 ExceptionEventOptimisticLockException evt, FacesContext facesContext) {
   log.debug( JSF Exception handler.  Handling 
 OptimisticLockException: , evt);
   facesContext.addMessage(null, new 
 FacesMessage(FacesMessage.SEVERITY_ERROR, El registre ha estat modificat a 
 la base de dades per un altre procés. Les dades no s'han guardat., ));
   evt.handled();
   }
   public void showFacesMessage(@Handles @FacesRequest 
 ExceptionEventThrowable evt, FacesContext facesContext) {
   log.debug( JSF Exception handler.  Handling Throwable: , evt);
   facesContext.addMessage(null, new 
 FacesMessage(FacesMessage.SEVERITY_ERROR, evt.getException().getMessage(), 
 ));
   evt.handledAndContinue();
   }
   
   
 }
 But javax.persistence.PersistenceException is not handled:
 (http-localhost-127.0.0.1-8080-4) Error processing Update: : 
 javax.persistence.PersistenceException: 
 org.hibernate.exception.ConstraintViolationException: Unique index or primary 
 key violation: CONSTRAINT_INDEX_4 ON 
 PUBLIC.UNITAT_NEGOCI_CANAL_VENDA(UNITAT_NEGOCI_ID, CANAL_VENDA_ID); SQL 
 statement:
 update UNITAT_NEGOCI_CANAL_VENDA set CODI_USUARI_ULTIMA_MODIFICACIO=?, 
 DATAHORA_CREACIO=?, DATAHORA_ULTIMA_MODIFICACIO=?, DATAHORA_ALTA=?, 
 DATAHORA_BAIXA=?, CANAL_VENDA_ID=?, UNITAT_NEGOCI_ID=?, VERSION=? where ID=? 
 and VERSION=? [23505-161]
   at 
 org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
  [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
   at 
 org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
  [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
   at 
 org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
  [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
   at 
 org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:976)
  [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
   at 
 org.jboss.as.jpa.container.AbstractEntityManager.flush(AbstractEntityManager.java:439)
  [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
   at 
 cat.tmb.tdo.ocicommerce.view.UnitatNegociCanalVendaBean.update(UnitatNegociCanalVendaBean.java:157)
  [classes:]
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
 [rt.jar:1.7.0_51]
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
 [rt.jar:1.7.0_51]
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  [rt.jar:1.7.0_51]
   at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51

Re: Test-Control injects in test class object only

[Jason Porter]

Right, injection through arquillian happens after all the @Before and
@BeforeClass hooks.


On Mon, Jan 6, 2014 at 2:50 PM, Dirk Weil dirk.w...@web.de wrote:

 I digged into my problem a bit further: It is not the case – as I though
 earlier -, that only some injections are resolved. But:



 Within @Before methods all injections are still null. When entering the
 tests itself, the injected field are filled.

 My test class is no cdi bean (src/test/META-INF/beans.xml declares
 bean-discovery-mode=annotated), but if I make it a cdi bean, there is no
 difference.



 Regards

 Dirk









 *Von:* Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
 *Gesendet:* Freitag, 3. Januar 2014 12:00
 *An:* dev@deltaspike.apache.org
 *Betreff:* Re: Test-Control injects in test class object only



 short addition:



 i've added a test for it and it looks fine here (see [1]).



 fyi - basically there are two modes:

 #1 the test-class is a cdi-bean as well
 (src/test/resources/META-INF/beans.xml is needed)

 #2 the test-class isn't a cdi-bean (due to a missing beans.xml or @Typed()
 or @Exclude,...) - BeanProvider#injectFields is used as fallback



 regards,

 gerhard



 [1]
 https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commit;h=4939550ed208c4e6be98ee12e6019ebe7d271afd







 2014/1/3 Gerhard Petracek gerhard.petra...@gmail.com

 hi dirk,



 deltaspike just delegates the injection to the cdi-container.



 regards,

 gerhard







 2014/1/3 Dirk Weil dirk.w...@web.de

 Hi!



 I've just come around Test-Control - great module, simplifies in-container
 testing a lot. But I discovered one thing and I'm not sure if it's intended
 or a bug:



 @Inject is resolved for fields of the test class object itself only, not
 for
 fields of base classes. As a workaround I use
 BeanProvider.injectFields(this), but I would expect injections to be
 resolved automatically for the test class object as a whole, not just for
 the derived class part.



 Regards, Dirk








-- 
Jason Porter
http://en.gravatar.com/lightguardjp

[jira] [Commented] (DELTASPIKE-449) ExceptionHandler not invoked for AccessDeniedException

[Jason Porter (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841317#comment-13841317
 ] 

Jason Porter commented on DELTASPIKE-449:
-

Rainer: This is great! Would you be okay contributing this up to DeltaSpike? Do 
you have a CLA on file with Apache?

 ExceptionHandler not invoked for AccessDeniedException
 --

 Key: DELTASPIKE-449
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-449
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Security-Module
Affects Versions: 0.5
 Environment: Glassfish 4 / Weld 2.0.4
Reporter: John Schneider
Assignee: Jason Porter

 When an 
 org.apache.deltaspike.security.api.authorization.AccessDeniedException is 
 thrown, a valid ExceptionHandler method is not invoked.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: [data] getSingleResult exceptions

[Jason Porter]

Okay. If we're exposing it up through the stack then people can decide on
their own how they'd like to handle things.


On Fri, Nov 22, 2013 at 11:17 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 I was written it in my previous mail then thought nobody will use it. Too
 low level IMO
 Le 22 nov. 2013 19:15, Jason Porter lightguard...@gmail.com a écrit :

  Do we want to / should we have exceptioncontrol integration here?
 
 
  On Fri, Nov 22, 2013 at 10:20 AM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
   Looks good!
   Le 22 nov. 2013 18:05, Thomas Hug thomas@ctp.com a écrit :
  
Digged out some other crappy exception handling on the delegates.
   Proposals
for 1) and 2) pushed at
https://github.com/thomashug/DeltaSpike-Mirror/commits/master
   
   
   
On Fri, Nov 22, 2013 at 5:11 PM, Thomas Hug thomas@ctp.com
  wrote:
   
 Oops, good catch, that one sneaked in.

 -Original Message-
 From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
 Sent: Freitag, 22. November 2013 16:13
 To: dev@deltaspike.apache.org
 Subject: Re: [data] getSingleResult exceptions

 +1

 I'd remove both line btw:

 e.printStackTrace();
 log.log(Level.SEVERE, Query execution error, e);

 i'd keep the log in FINEST level


 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2013/11/22 Thomas Hug thomas@gmail.com:
  Here we go. Would that work?
 
   https://github.com/thomashug/DeltaSpike-Mirror/commit/6177a9581b669457
  0d3279d5d694d45ddb6e7ac1
 
 
 
  On Fri, Nov 22, 2013 at 12:15 PM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
  sounds great, thks!
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
 
  2013/11/22 Thomas Hug thomas@gmail.com:
   Hi Romain
   1) relates to DELTASPIKE-421. Started to prototype something
  there
   and
  will
   push a proposal soon.
   2) Agree there should be something in the API. And for JPA
   exceptions, I guess we should just rethrow them.
  
  
   On Fri, Nov 22, 2013 at 11:01 AM, Romain Manni-Bucau
   rmannibu...@gmail.comwrote:
  
   Hi,
  
   playing further with data module I realized we get an
 exception
   is
   we do a X findYyyy(bbb); and X doesn't exist.
  
   - The first thing is: can't we get null instead of an
  exception
   (adding a param in @Query or adding a
  @SingleQuery(throwException
   = false))?
  
   The other point (and more embarassaing) is: why is it a
   QueryInvocationException? If we don't want null but an
  exception
   to be aligned on the jpa spec we should be able to catch the
   exception. ATM we can only do it if we add in compile scope
   data-impl which doesn't seem to be the idea. Do we add an
   exception
 for that purpose?
  
   To summarize:
   1) do we allow to configure though an annotation the fact
  single
   result query return null if the entity is not ofund?
   2) do we add in the data-api an exception when 1) throws an
   exception to be able to catch it?
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
 

   
  
 
 
 
  --
  Jason Porter
  http://en.gravatar.com/lightguardjp
 




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: [data] getSingleResult exceptions

[Jason Porter]

I think it only makes sense to integrate our own features.


On Fri, Nov 22, 2013 at 11:26 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 Then the question is the same as for @transactional/@repo: do we integrate
 all our features together (im +1)
 Le 22 nov. 2013 19:22, Jason Porter lightguard...@gmail.com a écrit :

  Okay. If we're exposing it up through the stack then people can decide on
  their own how they'd like to handle things.
 
 
  On Fri, Nov 22, 2013 at 11:17 AM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
   I was written it in my previous mail then thought nobody will use it.
 Too
   low level IMO
   Le 22 nov. 2013 19:15, Jason Porter lightguard...@gmail.com a
 écrit
  :
  
Do we want to / should we have exceptioncontrol integration here?
   
   
On Fri, Nov 22, 2013 at 10:20 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
   
 Looks good!
 Le 22 nov. 2013 18:05, Thomas Hug thomas@ctp.com a écrit :

  Digged out some other crappy exception handling on the delegates.
 Proposals
  for 1) and 2) pushed at
  https://github.com/thomashug/DeltaSpike-Mirror/commits/master
 
 
 
  On Fri, Nov 22, 2013 at 5:11 PM, Thomas Hug thomas@ctp.com
wrote:
 
   Oops, good catch, that one sneaked in.
  
   -Original Message-
   From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
   Sent: Freitag, 22. November 2013 16:13
   To: dev@deltaspike.apache.org
   Subject: Re: [data] getSingleResult exceptions
  
   +1
  
   I'd remove both line btw:
  
   e.printStackTrace();
   log.log(Level.SEVERE, Query execution error, e);
  
   i'd keep the log in FINEST level
  
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
  
   2013/11/22 Thomas Hug thomas@gmail.com:
Here we go. Would that work?
   

  https://github.com/thomashug/DeltaSpike-Mirror/commit/6177a9581b669457
0d3279d5d694d45ddb6e7ac1
   
   
   
On Fri, Nov 22, 2013 at 12:15 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
   
sounds great, thks!
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
   
   
   
2013/11/22 Thomas Hug thomas@gmail.com:
 Hi Romain
 1) relates to DELTASPIKE-421. Started to prototype
 something
there
 and
will
 push a proposal soon.
 2) Agree there should be something in the API. And for JPA
 exceptions, I guess we should just rethrow them.


 On Fri, Nov 22, 2013 at 11:01 AM, Romain Manni-Bucau
 rmannibu...@gmail.comwrote:

 Hi,

 playing further with data module I realized we get an
   exception
 is
 we do a X findYyyy(bbb); and X doesn't exist.

 - The first thing is: can't we get null instead of an
exception
 (adding a param in @Query or adding a
@SingleQuery(throwException
 = false))?

 The other point (and more embarassaing) is: why is it a
 QueryInvocationException? If we don't want null but an
exception
 to be aligned on the jpa spec we should be able to catch
  the
 exception. ATM we can only do it if we add in compile
 scope
 data-impl which doesn't seem to be the idea. Do we add an
 exception
   for that purpose?

 To summarize:
 1) do we allow to configure though an annotation the fact
single
 result query return null if the entity is not ofund?
 2) do we add in the data-api an exception when 1) throws
 an
 exception to be able to catch it?

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau

   
  
 

   
   
   
--
Jason Porter
http://en.gravatar.com/lightguardjp
   
  
 
 
 
  --
  Jason Porter
  http://en.gravatar.com/lightguardjp
 




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

[jira] [Commented] (DELTASPIKE-334) CDI + Blueprint integration

[Jason Porter (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806863#comment-13806863
 ] 

Jason Porter commented on DELTASPIKE-334:
-

I believe part (or maybe all of this?) is being done with PAX CDI. Anyone 
working on that here?

 CDI + Blueprint integration
 ---

 Key: DELTASPIKE-334
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-334
 Project: DeltaSpike
  Issue Type: New Feature
Reporter: Charles Moulliard
Assignee: Charles Moulliard
Priority: Minor

 Description should be enriched by authors (Jason, ...)
 {code}
 From:Nodet Guillaume gno...@redhat.com
 Such a xml is in the META-INF/beans.xml, right ? So that you can override the 
 behaviour of annotations ?
 I'm not sure how / where we could use it, and that does not seem really 
 critical to me anyway.
 I think we'd better come to an understanding of the use case we'd want to 
 cover.
 I'm thinking about:
  * #1 create beans using the CDI container
  * #2 inject CDI beans into blueprint beans using the blueprint xml
  * #3 inject blueprint beans into CDI beans using @Inject
  * #4 support CDI annotations on blueprint beans (@PostConstruct, 
 @PreDestroy, @Inject)
 #1 is obviously needed, it could be done from the blueprint xml using a 
 simple tag, eventually pointing to the beans.xml config file, or inline it 
 (though inlining is not really worth the pain now imho)
  cdi:container xmlns=…
  cdi:beans url=… /
  /cdi:container
 #2 means being able to use one of the bean created from the CDI container and 
 inject it using the xml blueprint syntax, something like
  bean ….
cdiroperty name=service… /
 /bean
 Not sure what exactly we'd need in the cdiroperty/ element, but the idea is 
 to use the bean setters to inject a bean created inside the CDI container
 #3 means that we'd need to be able to inject a bean created by the blueprint 
 container using bean/ into a @Inject annotated property of a CDI bean 
 created by the CDI container.  In blueprint, beans are referred to by name 
 though, so it may require a custom annotation maybe ?
 #4 means mixing CDI annotations with blueprint beans.  It's the most 
 complicated case I think, as it needs an even closer cooperation of both 
 containers.
 This needs to be triggered either globally or an individual bean using a flag 
 such an xml attribute such as cdirocess=true that could be set on a bean/ 
 element or a default attribute on the cdi:container/ element.
 Cheers,
 Guillaume Nodet
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (DELTASPIKE-341) Provide Integration between Faces Exceptions and Exception Handling

[Jason Porter (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806980#comment-13806980
 ] 

Jason Porter commented on DELTASPIKE-341:
-

Cody, if you have a working example with the Deactivatable code, that would be 
a great addition to add to some documentation.

 Provide Integration between Faces Exceptions and Exception Handling
 ---

 Key: DELTASPIKE-341
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-341
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: Cody Lerum
Assignee: Jason Porter
 Fix For: 0.6


 Just an ExceptionHandlerFactory and ExceptionHandlerWrapper which fire and 
 remove events so that DS core exceptional handling can intercept.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Data Module

[Jason Porter]

Was this my action item?

Sent from my iPhone

 On Oct 1, 2013, at 7:43, Romain Manni-Bucau rmannibu...@gmail.com wrote:
 
 Hi
 
 any news on it?
 
 @ResultMapper was good to me
 
 *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/7/12 Jason Porter lightguard...@gmail.com
 
 On Fri, Jul 12, 2013 at 12:13 AM, Romain Manni-Bucau
 rmannibu...@gmail.comwrote:
 
 Ps: you can make a cdi bean an ejb from cdi extension
 
 
 No, the bootstrapping for each container do not communicate to my
 knowledge.
 
 
 Le 12 juil. 2013 08:12, Romain Manni-Bucau rmannibu...@gmail.com a
 écrit :
 
 Hi
 
 Depending the case DTO are not an option.
 
 I agree in rest app i wouldnt it but if not possible (maybe through
 another Bean) it would kill this module for half of the usages i see
 since
 i'd need to add this layer.
 Le 12 juil. 2013 06:55, hantsy han...@yahoo.com.cn a écrit :
 
 No DTO please, data module for data access, why we care about DTO.
 
 A question about the data, the difference for EJB and none EJB
 environment.
 
 if possible in a EJB envoriment, proxy the Repository and add
 @Stateless
 and transaction declaration to Repository automatically at runtime.
 
 Regards
 
 Hantsy
 On 7/10/2013 23:23, Thomas Hug wrote:
 I wouldn't label the feature with DTO but rather as some general
 result
 transformation - might also be useful for e.g. native queries. Going
 back
 to the API suggestion, from that perspective such an annotation
 should
 probably also work on method level, so I'd keep the forEntity out
 there.
 
 
 On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament 
 john.d.am...@gmail.com
 wrote:
 
 Personally, I don't like this idea.
 
 A DAO should do DAO stuff.
 A DTO should do DTO stuff.
 
 The transformation of your entities into some other POJO shouldn't
 be
 inside your DAO.
 
 Right now, I use google guava to do DTO work on entities going back
 and
 forth over a REST API.  Works well IMHO.
 
 John
 
 
 On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
 rmannibu...@gmail.comwrote:
 
 globally my answer meant if forEntity is sometimes mandatory,
 sometimes
 not this is maybe not the right place
 
 i thought to add it to mapper config
 
 *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/7/10 Thomas Hug thomas@gmail.com
 
 Making forEntity non-optional would then be redundant for the
 regular
 cases
 using the base interface, so I wouldn't. But I see that it should
 be
 clearly documented then as things might get confusing...
 
 
 On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
 rmannibu...@gmail.comwrote:
 
 do you mean you force forEntity = Person.class?
 
 looks ok for me since the only constraint is to add the dto
 types
 somewhere
 :)
 
 *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/7/10 Thomas Hug thomas@gmail.com
 
 Hmm and I assumed DTOs are dead and buried :-)
 
 Packing this in the base interface feels kind of clunky to me -
 also
 considering that there are repositories without the need to
 extend
 the
 base
 interface. What about something like
 
 @Repository(forEntity = Person.class)
 @ResultMapper(entityMapper = MapperX.class, keyMapper =
 MapperY.class)
 public interface PersonRepository extends
 EntityRepositoryPersonDto,
 DtoPk { ... }
 
 Having the Entity on @Repository takes precedence and the type
 parameters
 are in this case just for convenience.
 
 
 
 On Wed, Jul 10, 2013 at 2:35 PM, Romain Manni-Bucau
 rmannibu...@gmail.comwrote:
 
 +1
 
 just to complete this thread the main issue is not the
 implementation
 but
 the exposed API:
 
 public interface EntityRepositoryE, PK extends Serializable
 
 would become
 
 public interface EntityDtoRepositoryE, PK extends
 Serializable,
 Dto,
 DtoPk
 
 *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/7/10 Jean-Louis MONTEIRO jeano...@gmail.com
 
 Hello guys,
 
 Just used DS Data module yesturday, and I was wondering if we
 could
 add a
 feature allowing on-the-fly conversion to DTO.
 For example, we could use modelmapper (or similar to convert
 DAO
 return
 values to DTO objects).
 
 Adding a mapper interface to delegate to would also allow
 people
 to
 plug
 their own implementation

[jira] [Commented] (DELTASPIKE-414) HttpServletRequest (and others) injection not working in servlet filters from web.xml

[Jason Porter (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13783102#comment-13783102
 ] 

Jason Porter commented on DELTASPIKE-414:
-

I'll add my +1 to doing this with a Listener instead of a filter, unless for 
some reason a container doesn't support CDI in Listeners (which it should)

 HttpServletRequest (and others) injection not working in servlet filters from 
 web.xml
 -

 Key: DELTASPIKE-414
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-414
 Project: DeltaSpike
  Issue Type: Bug
  Components: Servlet-Module
Affects Versions: 0.5
Reporter: Emond Papegaaij

 DeltaSpike uses a filter to record the request and response objects for 
 injection in that thread. This filter is configured in web-fragment.xml, 
 which is loaded before other web-fragments, but not before web.xml. Filters 
 from web.xml will be first in the chain, breaking request and response 
 injection into these filters with Attempt to access the request/response 
 without an active HTTP request (RequestResponseHolder:85).
 We are moving from Solder, where the request and response objects were 
 recorded in a ServletRequestListener, which is always fired first, regardless 
 of it's position in the web.xml/web-fragment.xml. I think DeltaSpike should 
 use the same approach.
 For now, a workaround is to copy the configuration of 
 RequestResponseHolderFilter to your web.xml and put it before all other 
 filters.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: ConfigSource using ThreadLocal

[Jason Porter]

In that particular example, in the test, Arquillian knows the URL of the
server, so the port should already be there, right? Maybe I'm missing
something.


On Wed, Sep 25, 2013 at 10:51 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 It would be a contextual config so in the case of arquillian you'd set it
 in the beginning of your  test method.

 The point is not if it works but if we can/should support it.

 typically how to configure a webservice client url when the port is random?

 *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/9/25 Jason Porter lightguard...@gmail.com

  I'm not sure what good a ThreadLocal is going to give you. Unless you're
  using @InSequence in your tests you're not guaranteed when the tests will
  run and if that ThreadLocal variable will be set. Simply having
 Arquillian
  inject the URL should be fine. Also if depending on the forking parameter
  with JUnit it may not work anyway.
 
 
  On Wed, Sep 25, 2013 at 5:01 AM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
   Hi,
  
   I have the following use case: a config is dynamic (typically the url
 of
   the server using arquillian - @ArquillianResource URL url). I need this
  url
   in a config. In prod i use apache-deltaspike.properties or a custom
   ConfigSource. I see an easy solution being a ThreadLocal (or a global
  Map)
   backing a TestConfigSource.
  
   The question now: do we provide a default impl answering this need?
  (maybe
   an in memory configuration == map/properties updatable through a static
   method)
  
   wdyt?
  
  
   *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*
  
 
 
 
  --
  Jason Porter
  http://en.gravatar.com/lightguardjp
 




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

[jira] [Created] (DELTASPIKE-413) Add the ability to create Seam 2 like Factories

[Jason Porter (JIRA)]

Jason Porter created DELTASPIKE-413:
---

 Summary: Add the ability to create Seam 2 like Factories
 Key: DELTASPIKE-413
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-413
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Affects Versions: 0.5
Reporter: Jason Porter


For more information see 
http://stackoverflow.com/questions/18774025/how-can-i-update-a-collection-that-is-produces-applicationscoped
 and 
http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Data-module-full-replacement-for-Seam-Factories-td4655749.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: DeltaSpike @ JavaOne?

[Jason Porter]

Ah, missed that one. Be good to see you again.


On Mon, Sep 16, 2013 at 9:26 AM, John D. Ament john.d.am...@gmail.comwrote:

 Yeah, I'm on the JMS2 BOF.

 On Mon, Sep 16, 2013 at 11:21 AM, Jason Porter lightguard...@gmail.com
 wrote:
  Good question. You're not presenting anything, are you John?
 
  For those in Europe I'll also be at Devoxx this year.
 
 
  On Sun, Sep 15, 2013 at 7:51 AM, John D. Ament john.d.am...@gmail.com
 wrote:
 
  Hi
 
  I know Jason's going, and I'll be there.  Anyone else going to be at
  JavaOne this year?
 
  John
 
 
 
 
  --
  Jason Porter
  http://en.gravatar.com/lightguardjp




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: DeltaSpike @ JavaOne?

[Jason Porter]

Good question. You're not presenting anything, are you John?

For those in Europe I'll also be at Devoxx this year.


On Sun, Sep 15, 2013 at 7:51 AM, John D. Ament john.d.am...@gmail.comwrote:

 Hi

 I know Jason's going, and I'll be there.  Anyone else going to be at
 JavaOne this year?

 John




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Data module, full replacement for Seam Factories?

[Jason Porter]

I was looking at
http://stackoverflow.com/questions/18774025/how-can-i-update-a-collection-that-is-produces-applicationscoped
and
the data module came to my mind. I just did a quick glance through the code
I thought was applicable, but I'm still doubtful it'll actually do what I
want. Can someone correct me if the data module will actually do this?

If not, it sure sounds like a killer feature to implement. We'd need to
create events, probably add some more metadata to it, and possibly create
some beans so there's a concrete class, or perhaps some InvocationHandlers.

-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: [VOTE] Release Apache DeltaSpike-0.5

[Jason Porter]

+1

Thanks Cody for checking on Windows


On Wed, Sep 11, 2013 at 9:15 AM, Cody Lerum cody.le...@gmail.com wrote:

 +1

 Builds and tests locally with Weld and OWB profiles (Win8.1 x64, Java 7u25)

 No issues on an initial spin in my primary project moving form 0.4 to 0.5
 (core,jpa,jsf,security)


 On Wed, Sep 11, 2013 at 7:18 AM, Mark Struberg strub...@yahoo.de wrote:

 
 
   Hi!
 
  I'd like to call a VOTE for the release of DeltasSpike-0.4.
 
  The staging repo is:
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-029/
 
  The tag is available here:
  https://github.com/struberg/deltaspike/tree/deltaspike-project-0.5
  This will get pushed to the ASF repo and merged into the upstream master
  branch once the VOTE succeeded.
 
  The source release is available here:
 
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-029//org/apache/deltaspike/deltaspike-project/0.5/deltaspike-project-0.5-source-release.zip
 
 
  Release Notes:
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312820version=12320947
 
  Guide to testing:
  Add the following to your ~/.m2/settings.xml:
 
  profile
idstaging/id
repositories
  repository
idapache_staging/id
url
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-029/
  /url
releasesenabledtrue/enabled/releases
snapshotsenabledfalse/enabled/snapshots
  /repository
/repositories
  /profile
 
  Then upgrade your project to 0.5 and build with mvn -Pstaging.
 
  LieGrue,
  your Apache DeltaSpike Team
 




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: General Converter

[Jason Porter]

The problem with a generic JSF converter is that it has to be very dumb, or you 
have to use a certain kind of object. 


  


The Seam 3 converter went as generic as possible, it also kept things in 
the conversion (and should work fine in the request as a conversation is at 
least as long as a request). Depending on what state you're storing in the 
converter, you probably wouldn't want anything longer than the conversation due 
to memory issues. 


  


If memory serves correctly, the Seam 2 converter really only worked if you 
were using the EntityHome classes.


  


If you were to do anything similar to the Seam 2 converter you'd need to 
create some sort of object hierarchy the user would need to use, or try to 
perform some sort of generic magic with the criteria API, which is not the 
easiest of things to do. 


  


All that being said, I'd be happy to talk ideas out anyone may have. 

—
Sent from Mailbox for iPhone

On Sat, Aug 17, 2013 at 7:51 PM, hantsy han...@yahoo.com.cn wrote:

 I have posted some content on JBoss.org forum beforethe Seam3 faces
 object converter does not work well as the Seam 2 one.
 The Seam 3 only works in a conversation(the view is a conversation), and
 it also does not support @ManytoMany.
 The Seam2 version works perfectlyit works in request, conversation
 and other scopes...the better is when I used multi check box...it can
 deal with the Hibernate/JPA @ManyToMany relation correctly with any
 codes in the backend codes when I selected or unselected an option.
 Hantsy
 On 8/18/2013 05:42, Adrian Gonzalez wrote:
 Hi, 

 In the meantime, if you're looking for a JSF converter, you can take a look 
 at Omnifaces SelectItemsConverter [1].

 Regards,
 Adrian

 [1] http://showcase.omnifaces.org/converters/SelectItemsConverter


 
 De : Mark Struberg strub...@yahoo.de
 À : dev@deltaspike.apache.org dev@deltaspike.apache.org 
 Envoyé le : Vendredi 16 août 2013 12h39
 Objet : Re: General Converter


 Hi Florian!

 Not yet on our list. We are currently working on getting 0.5 out of the door 
 (code reviews and testing against many containers)


 Please file a feature request in JIRA describing what this Seam2 feature is 
 about and why you like it.


 txs and LieGrue,
 strub



 - Original Message -
 From: i...@softwareentwicklung-hell.de i...@softwareentwicklung-hell.de
 To: dev@deltaspike.apache.org
 Cc: 
 Sent: Tuesday, 13 August 2013, 14:35
 Subject: General Converter

 Hi all,

 is there a plan to implement Seam like general Converter like the Seam  
 Faces Object converter? I know it is not really a cdi topic, but there  
 is still a big gap between what Seam was providing and what DeltaSpike  
 does.

 Thanks and Regards
 Florian

Re: ViewConfig + Rewrite

[Jason Porter]

Is there a lot of user feedback in this area, or is this more of a nice to have?
—
Sent from Mailbox for iPhone

On Thu, Aug 1, 2013 at 12:34 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:

 +0
 regards,
 gerhard
 2013/8/1 Thomas Andraschko andraschko.tho...@gmail.com
 Hi,

 what about:

 @View @Rewrite(/item/#{item}/)
 class Item implements ViewConfig { }

 Just an simple solution, similiar to Seam.

 Regards,
 Thomas


 2013/6/18 Thomas Andraschko andraschko.tho...@gmail.com

  Hi Gerhard,
 
  great! i will create a sample syntax this weekend!
 
  Regards,
  Thomas
 
 
  2013/6/17 Gerhard Petracek gerhard.petra...@gmail.com
 
  hi thomas,
 
  you are welcome to suggest a possible syntax for it.
 
  regards,
  gerhard
 
 
 
  2013/6/17 Thomas Andraschko andraschko.tho...@gmail.com
 
   Hi,
  
   are there any plans integrate Rewrite within DS ViewConfig?
  
   Regards,
   Thomas
  
 
 
 

Re: ViewConfig + Rewrite

[Jason Porter]

Hard to turn away contributions like that :)
—
Sent from Mailbox for iPhone

On Thu, Aug 1, 2013 at 2:29 PM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:

 I think it's more a nice to have and there are other features with more
 prio.
 But i would implement it + provide a pull request, so there should be not
 much effort for you guys :)
 2013/8/1 Jason Porter lightguard...@gmail.com
 Is there a lot of user feedback in this area, or is this more of a nice to
 have?
 —
 Sent from Mailbox for iPhone

 On Thu, Aug 1, 2013 at 12:34 PM, Gerhard Petracek
 gerhard.petra...@gmail.com wrote:

  +0
  regards,
  gerhard
  2013/8/1 Thomas Andraschko andraschko.tho...@gmail.com
  Hi,
 
  what about:
 
  @View @Rewrite(/item/#{item}/)
  class Item implements ViewConfig { }
 
  Just an simple solution, similiar to Seam.
 
  Regards,
  Thomas
 
 
  2013/6/18 Thomas Andraschko andraschko.tho...@gmail.com
 
   Hi Gerhard,
  
   great! i will create a sample syntax this weekend!
  
   Regards,
   Thomas
  
  
   2013/6/17 Gerhard Petracek gerhard.petra...@gmail.com
  
   hi thomas,
  
   you are welcome to suggest a possible syntax for it.
  
   regards,
   gerhard
  
  
  
   2013/6/17 Thomas Andraschko andraschko.tho...@gmail.com
  
Hi,
   
are there any plans integrate Rewrite within DS ViewConfig?
   
Regards,
Thomas
   
  
  
  
 

Re: Data Module

[Jason Porter]

 tonight.
  
  
   On Mon, Jul 1, 2013 at 2:42 AM, John D. Ament 
   john.d.am...@gmail.com
   wrote:
   Hi
  
   Whoever brought in the data module, can you double check
   your
   tests
   and
   license headers?
  
   I think it's just your tests, but it's failing during a rat
   check
  
  
  
 
 https://builds.apache.org/job/DeltaSpike%20RAT-Check/org.apache.deltaspike.modules$deltaspike-data-module-impl/558/testReport/org.apache.deltaspike.data.impl/QueryResultTest/org_apache_deltaspike_data_impl_QueryResultTest/
   John
  
  
  
   --
   Jean-Louis
  
 
 




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

[jira] [Commented] (DELTASPIKE-391) Memory Leak in Data Module

[Jason Porter (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702049#comment-13702049
 ] 

Jason Porter commented on DELTASPIKE-391:
-

Singleton won't do any good, in weld, and I believe in OWB, singleton behaves 
the same way as Application. Honestly you're better off to go with dependent or 
request scoped, possibly session if you want things to last even longer.

 Memory Leak in Data Module
 --

 Key: DELTASPIKE-391
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-391
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 0.5
Reporter: Thomas Hug
Assignee: Thomas Hug
Priority: Critical

 Might be a side effect from moving QueryHandler to application scope. Several 
 beans injected over Instance are not cleaned up properly (probably handled 
 as dependent). Will do some further analysis.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Time to cut 0.5?

[Jason Porter]

I must have been sleeping or something for 0.5, I didn't think that much
work had been done. If that much work had been done, why are there only
nine closed issues in 0.5 in JIRA?


On Sat, Jul 6, 2013 at 6:09 PM, John D. Ament john.d.am...@gmail.comwrote:

 Errr, 3 new modules.


 On Sat, Jul 6, 2013 at 8:03 PM, John D. Ament john.d.am...@gmail.com
 wrote:

  We're a couple weeks late, but is anyone else interested in seeing 0.5
  cut?  Seems like we have a slew of bug fixes and two new modules in the
  hangar waiting to take off.
 




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: Time to cut 0.5?

[Jason Porter]

Yep, saw the deluge of emails come in.


On Sat, Jul 6, 2013 at 6:18 PM, John D. Ament john.d.am...@gmail.comwrote:

 0.5 was intended to be a small release, per [1]

 Note, I just moved the config module ones per your note in the top level
 issue.

 [1]:
 http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201306.mbox/browser


 On Sat, Jul 6, 2013 at 8:15 PM, Jason Porter lightguard...@gmail.com
 wrote:

  I must have been sleeping or something for 0.5, I didn't think that much
  work had been done. If that much work had been done, why are there only
  nine closed issues in 0.5 in JIRA?
 
 
  On Sat, Jul 6, 2013 at 6:09 PM, John D. Ament john.d.am...@gmail.com
  wrote:
 
   Errr, 3 new modules.
  
  
   On Sat, Jul 6, 2013 at 8:03 PM, John D. Ament john.d.am...@gmail.com
   wrote:
  
We're a couple weeks late, but is anyone else interested in seeing
 0.5
cut?  Seems like we have a slew of bug fixes and two new modules in
 the
hangar waiting to take off.
   
  
 
 
 
  --
  Jason Porter
  http://en.gravatar.com/lightguardjp
 




-- 
Jason Porter
http://en.gravatar.com/lightguardjp

Re: Build failed in Jenkins: DeltaSpike RAT-Check #550

[Jason Porter]

The problem at the very end says Too many unapproved licenses: 16 not sure 
what we've added, but we have some license fixes to make it seems. 
—
Sent from Mailbox for iPhone

On Mon, Jun 24, 2013 at 6:14 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:

 See https://builds.apache.org/job/DeltaSpike%20RAT-Check/550/changes
 Changes:
 [john.d.ament] DELTASPIKE-387 Created new name for the module.
 [john.d.ament] DELTASPIKE-387 Renamed package.
 [john.d.ament] DELTASPIKE-387 Changed test package name.
 [christian] Minor javadoc cleanup in servlet module
 --
 [...truncated 2105 lines...]
 INFO - Enterprise application 
 https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/classpath.ear;
  loaded.
 INFO - Creating TransactionManager(id=Default Transaction Manager)
 INFO - Creating SecurityService(id=Default Security Service)
 INFO - Using 
 'java.security.auth.login.config=jar:file:/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/openejb/openejb-core/4.5.1/openejb-core-4.5.1.jar!/login.config'
 INFO - Creating Container(id=Default Managed Container)
 INFO - Using directory /tmp for stateful session passivation
 INFO - Assembling app: 
 https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/classpath.ear
 INFO - Existing thread singleton service in SystemInstance() 
 org.apache.openejb.cdi.ThreadSingletonServiceImpl@d6a05e
 INFO - OpenWebBeans Container is starting...
 INFO - Adding OpenWebBeansPlugin : [CdiPlugin]
 INFO - All injection points are validated successfully.
 INFO - OpenWebBeans Container has started, it took 11 ms.
 INFO - Deployed 
 Application(path=https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/classpath.ear)
 INFO - Destroying container system
 INFO - Undeploying app: 
 https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/classpath.ear
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.82 sec
 Results :
 Tests run: 6, Failures: 0, Errors: 0, Skipped: 0
 [JENKINS] Recording test results
 [INFO] [INFO] Building jar: 
 https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/target/deltaspike-cdictrl-openejb-0.5-SNAPSHOT.jar
 [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ 
 deltaspike-cdictrl-openejb ---
 [INFO] 
 [INFO] --- maven-site-plugin:3.1:attach-descriptor (attach-descriptor) @ 
 deltaspike-cdictrl-openejb ---
 [INFO] [INFO] Exclude: .idea/**/*
 [INFO] Exclude: readme/**/*
 [INFO] Exclude: **/*.log
 [INFO] --- apache-rat-plugin:0.8:check (default) @ deltaspike-cdictrl-openejb 
 ---
 [INFO] 
 [INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (versions) @ 
 deltaspike-cdictrl-openejb ---
 [INFO] [WARNING] Parameter tasks is deprecated, use target instead
 [INFO] Executing tasks
 main:
 [INFO] Executed tasks
 [INFO] --- maven-antrun-plugin:1.6:run (javadoc.resources) @ 
 deltaspike-cdictrl-openejb ---
 [INFO] [INFO] Configured Artifact: 
 org.apache.deltaspike.cdictrl:deltaspike-cdictrl-owb:0.5-SNAPSHOT:jar
 [INFO] Unpacking 
 https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-owb/target/deltaspike-cdictrl-owb-0.5-SNAPSHOT.jar
  to 
 https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/target/classes
  with includes  and excludes 
 **\/META-INF\/**,**\/OpenWebBeansContainerControl.class
 [INFO] --- maven-dependency-plugin:2.4:unpack (unpack-context) @ 
 deltaspike-cdictrl-openejb ---
 Jun 25, 2013 12:12:21 AM hudson.maven.ExecutedMojo init
 WARNING: Failed to getClass for org.apache.maven.plugin.source.SourceJarMojo
 [INFO] [INFO] META-INF already added, skipping
 [INFO] META-INF/NOTICE already added, skipping
 [INFO] META-INF/LICENSE already added, skipping
 [INFO] META-INF/DISCLAIMER already added, skipping
 [INFO] META-INF/DEPENDENCIES already added, skipping
 [INFO] META-INF already added, skipping
 [INFO] META-INF already added, skipping
 [INFO] META-INF/NOTICE already added, skipping
 [INFO] META-INF/LICENSE already added, skipping
 [INFO] META-INF/DISCLAIMER already added, skipping
 [INFO] META-INF/DEPENDENCIES already added, skipping
 [INFO] META-INF already added, skipping
 [INFO] META-INF/NOTICE already added, skipping
 [INFO] META-INF/LICENSE already added, skipping
 [INFO] META-INF/DISCLAIMER already added, skipping
 [INFO] META-INF/DEPENDENCIES already added, skipping
 [INFO] Building jar: 
 https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/target/deltaspike-cdictrl-openejb-0.5-SNAPSHOT-sources.jar
 [INFO] --- maven-source-plugin:2.1.2:jar (attach-sources) @ 
 deltaspike-cdictrl-openejb ---
 [INFO] META-INF already added, skipping
 [INFO] META-INF/NOTICE already added, skipping
 [INFO] META-INF/LICENSE already added, skipping
 [INFO] META-INF/DISCLAIMER already added, skipping
 [INFO] META-INF/DEPENDENCIES already added, 

[jira] [Commented] (DELTASPIKE-386) PropertyFileUtils.getResourceBundle() fails in EAR

[Jason Porter (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13690495#comment-13690495
 ] 

Jason Porter commented on DELTASPIKE-386:
-

Larger patches require an iCLA to be on file, but with small patches we should 
be okay w/o one.

 PropertyFileUtils.getResourceBundle() fails in EAR
 --

 Key: DELTASPIKE-386
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-386
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Affects Versions: 0.4
 Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1)
Reporter: Richard DiCroce

 The method PropertyFileUtils.getResourceBundle(String bundleName, Locale 
 locale) doesn't work correctly in an EAR.
 I have the DS core JARs in the EAR /lib and I'm trying to use the JsfMessage 
 feature in one of my WARs. Because getResourceBundle() calls 
 ResourceBundle.getBundle(String bundleName, Locale locale), Java attempts to 
 load the resource bundle using the classloader that was used to load 
 PropertyFileUtils, which is the EAR's classloader. The property files are in 
 the WAR, so Java can't find them.
 Changing
 return ResourceBundle.getBundle(bundleName, locale);
 to
 return ResourceBundle.getBundle(bundleName, locale, 
 Thread.currentThread().getContextClassLoader());
 fixes the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DELTASPIKE-259) @Transactional should support binding qualifier members

[Jason Porter (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13686262#comment-13686262
 ] 

Jason Porter commented on DELTASPIKE-259:
-

Since EE7 has come out now, I'm guessing we should align this with the new 
functionality from the JTA 1.2 revision

 @Transactional should support binding qualifier members
 ---

 Key: DELTASPIKE-259
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-259
 Project: DeltaSpike
  Issue Type: Improvement
  Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Gerhard Petracek
Assignee: Mark Struberg
 Fix For: 0.5


 right now qualifiers are stored via Class? extends Annotation - the usage 
 of qualifiers is restricted to @Q1, @Q2,... - @Q(1) and @Q(2) isn't 
 supported currently.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DELTASPIKE-118) custom port for jbossas-build-managed-7

[Jason Porter (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13686264#comment-13686264
 ] 

Jason Porter commented on DELTASPIKE-118:
-

When we add support for Wildfly we should be okay with jvm options: 
https://issues.jboss.org/browse/WFLY-330

 custom port for jbossas-build-managed-7
 ---

 Key: DELTASPIKE-118
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-118
 Project: DeltaSpike
  Issue Type: Task
  Components: Tests
Affects Versions: 0.1-incubating
Reporter: Gerhard Petracek
Assignee: Mark Struberg
 Fix For: 0.5


 we need a custom port to run in on jenkins.
 ( blocked by https://issues.jboss.org/browse/AS7-1036 )
 we could replace standalone.xml after the unpack process (in 
 process-test-classes)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Updating site docs

[Jason Porter]

Great! Glad to hear. 
—
Sent from Mailbox for iPhone

On Sun, Jun 9, 2013 at 5:04 PM, John D. Ament john.d.am...@gmail.com
wrote:

 We appear to
 to verify
 Type in http://incubator.apache.org/deltaspike/news.html
 Expected result: get redirected to http://deltaspike.apache.org/news.html
 Outcome: success.
 On Sun, Jun 9, 2013 at 6:59 PM, Jason Porter lightguard...@gmail.comwrote:
 I was also wondering if we have some rewrite rules in place to redirect
 users going to the old URLS.
 —
 Sent from Mailbox for iPhone

 On Sun, Jun 9, 2013 at 4:54 PM, John D. Ament john.d.am...@gmail.com
 wrote:

  Well, I'm assuming the SVN url is:
  http://svn.apache.org/repos/asf/deltaspike/site/trunk/ which gives me an
  access denied.  Should all committers have access?
  I was going to commit the following change
  Index: documentation.mdtext
  ===
  --- documentation.mdtext (revision 1491309)
  +++ documentation.mdtext (working copy)
  @@ -56,9 +56,15 @@
   In the listings below replace the placeholders for the version with the
  version of your choice or use:
   properties
  -deltaspike.version0.4-incubating-SNAPSHOT/deltaspike.version
  +deltaspike.version0.4/deltaspike.version
   /properties
  +Or if you want to very bleeding edge, point to our current snapshot.
  +
  +properties
  +deltaspike.version0.5-SNAPSHOT/deltaspike.version
  +/properties
  +
   ### Configuration of DeltaSpike Core
   dependency
  Index: news.mdtext
  ===
  --- news.mdtext (revision 1491309)
  +++ news.mdtext (working copy)
  @@ -16,6 +16,16 @@
  specific language governing permissions and limitations
  under the License.
  +## 4th Release (0.4) (31.05.2013)
  +
  +The Apache DeltaSpike team is pleased to announce the fourth release
  (v0.4).  This is our first release as a top level project!
  +
  +The [release notes][14] contains a large list of bug fixes and new
  features.
  +
  +## Graduation (28.05.2013)
  +
  +The Apache DeltaSpike team is pleased to announce that we have complete
  graduation as a top level project.
  +
   ## 3rd Release (0.3 incubating) (22.08.2012)
   The Apache DeltaSpike team is pleased to announce the second release
  (v0.3-incubating).
  @@ -164,4 +174,5 @@
 [10]: http://s.apache.org/cTt
 [11]: http://s.apache.org/DeltaSpike_01incubating
 [12]: http://s.apache.org/DeltaSpike_02incubating
  -  [13]: http://s.apache.org/DeltaSpike_03incubating
  \ No newline at end of file
  +  [13]: http://s.apache.org/DeltaSpike_03incubating
  +  [14]: http://s.apache.org/DS-0.4-RNotes
  On Sun, Jun 9, 2013 at 6:36 PM, John D. Ament john.d.am...@gmail.com
 wrote:
  Hi Mark
 
  Yay tons of builds today.
 
  Anyways, I was wondering if there were any docs out there on how to
 update
  the site's documentation? Is there an SVN repo we check out to do this
 (I'm
  assuming infra doesn't support git for the sites).  Do we do anything
 after
  committing?
 
  John