Re: [VOTE] Release Apache DeltaSpike-2.0.0

[Christian Kaltepoth]

+1

Am Sa., 30. März 2024 um 09:23 Uhr schrieb Mark Struberg
:

> Hi John!
>
> Good question!
> Honestly, I just took all which had 2.0.0 as target release and copied
> them over.
> Maybe in the future we should remove the 'fixed in' version when we set
> tickets to won't fix?
>
> txs and LieGrue,
> strub
>
> > Am 29.03.2024 um 18:51 schrieb John D. Ament :
> >
> > +1 LGTM
> >
> > Though I always question when release notes mention things that are Won't
> > Do as being included in them, not a problem for the release.
> >
> > On Fri, Mar 29, 2024 at 10:45 AM Mark Struberg  >
> > wrote:
> >
> >> Good afternoon!
> >>
> >> I'd like to call a VOTE on releasing Apache DeltaSpike-2.0.0
> >>
> >> The list of fixed tickets can be found in the release notes
> >>
> >>
> https://github.com/apache/deltaspike/blob/master/deltaspike/readme/ReleaseNotes-2.0.0.txt
> >>
> >> This is the first version to natively target JakartaEE-9 and the
> jakarta.*
> >> namespace.
> >>
> >> The staging repo is available under:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1060/
> >>
> >> The source release zip can be found here
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1060/org/apache/deltaspike/deltaspike/2.0.0/
> >>
> >> the sha512 is
> >>
> >>
> 06a462cd3e66457cc35bc88e8ec0f63f4560fa4bdf4d91cb0983e07001c05fbf4fa7d50d73310a9e52fb420824256e69bf373a1d03750858645f5e83120f5d1e
> >>
> >> Please VOTE
> >>
> >> [+1] let's ship it
> >> [+0] don't care
> >> [-1] stop, there is a ${showstopper}
> >>
> >> The VOTE is open for 72h
> >>
> >>
> >>
> >> txs and LieGrue,
> >> strub
> >>
>
>

Re: DeltaSpike 1.9.2?

[Christian Kaltepoth]

+1

Am Fr., 13. Dez. 2019 um 11:58 Uhr schrieb Gerhard Petracek <
gpetra...@apache.org>:

> +1
>
> regards,
> gerhard
>
>
>
> Am Do., 12. Dez. 2019 um 13:30 Uhr schrieb Thomas Andraschko
> :
> >
> > Hi,
> >
> > i would like to trigger the release process today.
> > Everyone ok with it?
> >
> > Best regards,
> > Thomas
>


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

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

[Christian Kaltepoth]

+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
> > > >
> > >
> > >
> >
>

Re: [VOTE] Release Apache DeltaSpike-1.9.0 (take2)

[Christian Kaltepoth]

+1

Am Mo., 10. Sep. 2018 um 09:21 Uhr schrieb Gerhard Petracek <
gpetra...@apache.org>:

> +1
>
> regards,
> gerhard
>
>
>
> Am Mo., 10. Sep. 2018 um 08:54 Uhr schrieb Mark Struberg
> :
>
> > Good morning!
> >
> > This is the second release attempt for DeltaSpike 1.9.0.
> >
> > John discovered that we missed a license header in the first run.
> > This is fixed now - thanks John for the catch!
> > I've also enabled the apache-rat-plugin to run every time and not only in
> > a dedicated profile.
> >
> >
> > The staging repo can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1049/
> >
> > The source release zip is here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1049/org/apache/deltaspike/deltaspike/1.9.0/
> > sha1
> > <
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1049/org/apache/deltaspike/deltaspike/1.9.0/sha1
> >:
> > 18d39411a60b4cc6a5af2ab261b4f7cde8692096
> >
> > The following tickets got resolved since 1.8.2 (same as in the first
> take):
> >
> > Bug
> >
> > • [DELTASPIKE-900] - ResourceLocalTransactionStrategy not working
> > with multiple EntityManagers
> > • [DELTASPIKE-1198] - BeanManagerProvider.isActive() returns true
> > after container shutdown
> > • [DELTASPIKE-1324] - @Transactional annotation at method level
> > doesn't override the one at class level any more
> > • [DELTASPIKE-1327] - EnvironmentPropertyConfigSource is not
> > scannable?
> > • [DELTASPIKE-1336] - Regression: deltaspike-cdictrl-weld 1.8.0
> > depends on weld-api 1.1.Final
> > • [DELTASPIKE-1344] - deltaspike-cdictrl-owb has a transient
> > runtime dependency on Shrinkwrap and Arquillian
> > • [DELTASPIKE-1349] - isProxyableClass should ignore methods from
> > Object.class
> > • [DELTASPIKE-1351] - Java 10: IllegalArgumentException in
> > ClassReader.
> > • [DELTASPIKE-1353] - null values as arguments in messagebundles
> > lead to exceptions
> > New Feature
> >
> > • [DELTASPIKE-1280] - Automatic support for count* methods in
> > EntityRepository
> > • [DELTASPIKE-1315] - EntityRepository should offer an
> > findOptionalBy
> > • [DELTASPIKE-1321] - Upgrade DeltaSpike to require Java8 as
> > minimum version
> > • [DELTASPIKE-1335] - allow atomic access to n different
> > TypedResolver values
> > Improvement
> >
> > • [DELTASPIKE-1277] - Force refresh of cached config values
> > • [DELTASPIKE-1322] - clean up ConfigResolver
> > • [DELTASPIKE-1326] - Clean up Java 8 support in data module
> > • [DELTASPIKE-1339] - Add support for dynamic interceptor
> binding,
> > added via Extension
> > • [DELTASPIKE-1340] - Delegate to JPA 2.2 getResultStream
> > • [DELTASPIKE-1341] - [perf] QueryProcessorFactory could reuse
> > QueryProcessors
> > • [DELTASPIKE-1342] - Upgrade to ASM 6.1 for Java 10 support
> > • [DELTASPIKE-1346] - ProjectStageProducer should log changed
> > values only if the value changed
> > Task
> >
> > • [DELTASPIKE-1308] - Documentation of user home properties
> > mechanism
> > • [DELTASPIKE-1325] - actively release ConfigSources and
> > ConfigFilters if they implement Autocloseable
> >
> >
> > Please VOTE:
> >
> > [+1] let's ship it!
> > [+0] meh, don't care
> > [-1] stop there is a ${showstopper}
> >
> >
> > The VOTE is open for 72h
> >
> > txs and LieGrue,
> > strub
>


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

Re: Welcome Alex Falb as new Apache DeltaSpike

[Christian Kaltepoth]

Welcome! :-)

Am Di., 7. Aug. 2018 um 09:13 Uhr schrieb Thomas Andraschko <
andraschko.tho...@gmail.com>:

> welcome!
>
> 2018-08-07 8:56 GMT+02:00 Romain Manni-Bucau :
>
> > Welcome!
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <https://www.packtpub.com/application-development/java-
> > ee-8-high-performance>
> >
> >
> > Le mar. 7 août 2018 à 08:53, Gerhard Petracek  a
> > écrit :
> >
> > > welcome!
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > Am Di., 7. Aug. 2018 um 08:09 Uhr schrieb Mark Struberg
> > > :
> > >
> > > > Dear fellow Apache DeltaSpike users and devs.
> > > >
> > > > The Apache DeltaSpike PMC has voted on inviting Alex Falb as a new
> > > > committer to our project and he has accepted our invitation.
> > > >
> > > >
> > > > Welcome Alex!
> > > >
> > > >
> > > > the Apache DeltaSpike PMC
> > >
> >
>


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

Re: [DISCUSS] require Java8 and move to Deltaspike-1.9.x version?

[Christian Kaltepoth]

+1, we will get Java10 really soon, so requiring at least Java8 seems
reasonable.

2018-03-01 7:11 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> +1, even big data libs like apache beam are java 8 based now so if big data
> moved to j8, server techno should have moved already IMHO ;)
>
> Le 1 mars 2018 05:48, "Mark Struberg" <strub...@yahoo.de.invalid> a écrit
> :
>
> > Hi folks!
> >
> > Our build, etc in theory still runs with Java6.
> > As typical with ASF projects we make battle prooven projects for
> > production.
> > That means we take backward compatibility really serious.
> >
> > But I think it's finally time to up the game to Java8.
> > To indicate this I suggest to move from currently 1.8.x to 1.9.x.
> >
> > Note that all the rest will still be backward compatible with older
> > versions!
> > We also might still ship 1.8.2, 1.8.3, etc as Java7 compatible version if
> > there is any necessity.
> >
> > Any objections?
> >
> > LieGrue,
> > strub
>



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

Re: bringing interdyn and invomon to DeltaSpike?

[Christian Kaltepoth]

+1 for integrating interdyn.

Am 09.02.2018 19:15 schrieb "Jason Porter" :

> +1 for adding them
>
> On Fri, Feb 9, 2018 at 4:09 AM, Rudy De Busscher 
> wrote:
>
> > +1 for adding them.
> >
> > I use the  interdyn   project regularly
> >
> > Rudy
> >
> > On 9 February 2018 at 11:58, Gerhard Petracek 
> > wrote:
> >
> > > imo the config should be based on the ds-config-api -> with that the
> > > config-format isn't limited.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2018-02-09 11:48 GMT+01:00 Thomas Andraschko <
> > andraschko.tho...@gmail.com
> > > >:
> > >
> > > > Also suggested dynamic interceptors some years ago - so +1. Just not
> > sure
> > > > if properties is the best way.
> > > > Maybe we should think about if we should someday introduce something
> > > like a
> > > > deltaspike xml config. Not sure.
> > > >
> > > > 2018-02-09 11:34 GMT+01:00 Gerhard Petracek :
> > > >
> > > > > basically +1 for adding such modules (independent of the details,
> > since
> > > > we
> > > > > can improve parts once it's needed).
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > >
> > > > >
> > > > > 2018-02-09 10:51 GMT+01:00 Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > > > >
> > > > > > Hi Mark
> > > > > >
> > > > > > I like interdync and it is a generic fit but invomon is a bit
> > limited
> > > > in
> > > > > > current flavor and I would be tempted to say we can just inherit
> > from
> > > > the
> > > > > > related sirona part of code if we want to go this way.
> > > > > >
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau  |  Blog
> > > > > >  | Old Blog
> > > > > >  | Github  > > > > > rmannibucau> |
> > > > > > LinkedIn  | Book
> > > > > >  > > > > > ee-8-high-performance>
> > > > > >
> > > > > > 2018-02-09 10:49 GMT+01:00 Mark Struberg
>  > > >:
> > > > > >
> > > > > > > Hi folks!
> > > > > > >
> > > > > > > Some of you might know my interdyn + invomon projects [1].
> > > > > > >
> > > > > > > For the others, what are they about?
> > > > > > >
> > > > > > > interdyn is a dynamic interceptor binding Extension.
> > > > > > > It allows to declare a regexp pattern and a class name of an
> > > > > Interceptor
> > > > > > > annotation.
> > > > > > > It then applies this annotation to all the classes which map
> the
> > > > > regexp.
> > > > > > > Of course you can define multiple rules.
> > > > > > >
> > > > > > > rule.1.match=.*ServiceImpl
> > > > > > > rule.1.interceptor=net.struberg.devtools.cdi.invomon.
> > > > > InvocationMonitored
> > > > > > >
> > > > > > > The other part is exactly that @InvocationMonitored
> interceptor.
> > > > > > >
> > > > > > > It logs the most expensive methods and classes after each
> > request.
> > > > > > > The output looks like the following:
> > > > > > >
> > > > > > > 2011-03-19 12:36:27,291 [2046767960@qtp-1243908618-9]  INFO
> > > > > > > invomon.InvocationResultLogger Top Class Invocations:
> > > > > > >   count: 51 net.struberg.myproject.core.be.semester.
> > > > > > > SemesterRemoteServiceImpl
> > > > > > >   count: 21 net.struberg.myproject.core.
> be.security.service.
> > > > > > > SecurityServiceImpl
> > > > > > >   count: 5  net.struberg.myproject.util.
> > > > > be.config.ConfigServiceImpl
> > > > > > >   count: 2  net.struberg.myproject.course.
> > be.CourseServiceImpl
> > > > > > >   count: 1  net.struberg.myproject.events.
> > be.EventServiceImpl
> > > > > > >   count: 1  net.struberg.myproject.core.be.persons.
> > > > > > > PersonRemoteServiceImpl
> > > > > > >   count: 1  net.struberg.myproject.course.
> > > be.LecturerServiceImpl
> > > > > > >   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.
> > 

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

[Christian Kaltepoth]

+1

Am 29.05.2017 02:53 schrieb "John D. Ament" :

> +1
>
> On Sun, May 28, 2017 at 6:42 AM 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: [VOTE] Release Apache DeltaSpike-1.8.0

[Christian Kaltepoth]

+1, thanks Mark!

2017-05-26 17:41 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:

> Here is my own +1
>
> LieGrue,
> strub
>
>
> > Am 26.05.2017 um 01:16 schrieb Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> >
> > Looks good, +1
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-05-24 16:48 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:
> >
> >> Hi folks!
> >>
> >> I'd like to call a VOTE on releasing Apache DeltaSpike-1.8.0
> >>
> >> There have been lots of improvements and bug fixes:
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> >> projectId=12312820=12338003
> >>
> >>
> >> The staging repository is
> >> https://repository.apache.org/content/repositories/
> >> orgapachedeltaspike-1043/
> >>
> >> I've pushed the build branch to my github repo.
> >> https://github.com/struberg/deltaspike/tree/release_deltaspike_1.8.0
> >> the tag is https://github.com/struberg/deltaspike/tree/deltaspike-1.8.0
> >>
> >> This will get merge and pushed to ASF master once the VOTE succeeds.
> >>
> >> The source release is here
> >> https://repository.apache.org/content/repositories/
> >> orgapachedeltaspike-1043/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.
> >>
> >> txs and LieGrue,
> >> strub
> >>
> >>
> >>
>
>


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

Re: [DISCUSS] PR Based Contributor Workflow

[Christian Kaltepoth]

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

Re: 1.7.1 Release

[Christian Kaltepoth]

+1

2016-07-16 19:40 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:

> +1
>
> LieGrue,
> strub
>
>
> > Am 15.07.2016 um 03:12 schrieb John D. Ament <johndam...@apache.org>:
> >
> > All,
> >
> > So we had some last minute issues pop up but I think its still important
> we
> > aim to get a 1.7.1 out with the bug fixes included.
> >
> > Proposed release notes can be found here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312820=12335497
> >
> > As a result, I'd like to plan to cut the release Sunday evening, starting
> > the vote either then or Monday morning.
> >
> > John
>
>


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

Re: [DISCUSS] GitHub PR Builder

[Christian Kaltepoth]

I think such build jobs are very valuable. So +1 for them.



2016-07-06 4:06 GMT+02:00 John D. Ament <johndam...@apache.org>:

> Hey guys
>
> We've been getting a few more PRs over github.  Its IMHO easier to merge
> those instead of patches in JIRA tickets.
>
> I went ahead and created a PR build job.  When someone raises a PR against
> us in github, it will trigger a build.  Right now that build only runs OWB
> 1.6.x, but I think it would be good to get more tests in there.  Say one
> embedded container and one full container?
>
> What do others think? Useful? Not useful?
>
> John
>



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

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

[Christian Kaltepoth]

+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

Re: Java EE 6 support

[Christian Kaltepoth]

I also think that we should keep to support Java EE 6 for some time.

But +1 for dropping Java SE 6 support

2016-03-25 14:00 GMT+01:00 Rudy De Busscher <rdebussc...@gmail.com>:

> All,
>
> Most of my clients still work with Java EE 6 (on Java SE 7), so I think it
> is too early to abandon that version.
>
> +1 for setting compile version to SE 7.
>
> Regards
> Rudy
>
>
> On 25 March 2016 at 13:48, Gerhard Petracek <gpetra...@apache.org> wrote:
>
> > hi @ all,
> >
> > imo the benefit is too limited.
> > cdi 1.1 added some nice parts, but mainly for users.
> > we would just drop the bv-module as well as some parts of the servlet
> > module.
> > the jsf-module already contains optional ee7 support (-> we would just
> get
> > rid of one small workaround).
> > for the rest the benefit is minimal as well (or there won't be a change
> at
> > all).
> > ee7 is great for users and therefore we support it already, however,
> > internally the benefit is too limited and ee6 servers will be around the
> > next few years.
> >
> > -> imo v2 should be based on cdi 2.0 (-> ee8).
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2016-03-25 13:29 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> > > Se 8 is surely too early (~1 year I think). +1 to drop ee6 from master.
> > > Le 25 mars 2016 13:27, "Harald Wellmann" <hwellmann...@gmail.com> a
> > écrit
> > > :
> > >
> > > > Since John raised the question about Java SE 6 support, what about
> Java
> > > EE
> > > > 6?
> > > >
> > > > Dropping support for Java EE 6/CDI 1.0 would simplify the code base
> > > > significantly (a lot more so than moving from Java 1.6 to Java 1.7).
> > > >
> > > > How about starting a new release line DeltaSpike 2.x targeting Java
> EE
> > 7+
> > > > and Java SE 8+, with continued support for Java EE 6 on the 1.x
> branch
> > > for
> > > > as long as people are willing to work on backward compatibility?
> > > >
> > > > Regards,
> > > > Harald
> > > >
> > >
> >
>



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

Re: first steps for the next release

[Christian Kaltepoth]

+1

2016-03-23 14:33 GMT+01:00 Jason Porter <lightguard...@gmail.com>:

> +1
>
> On Wednesday, March 23, 2016, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > +1
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >
> >
> > 2016-03-23 11:23 GMT+01:00 Gerhard Petracek <gerhard.petra...@gmail.com
> > <javascript:;>>:
> > > 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
>



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

Re: Hotfix release 1.5.4

[Christian Kaltepoth]

+1 for 1.5.4

2016-02-17 20:29 GMT+01:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> not sure - both 1.5.4 and 1.5.3.1 are just bugfix versions.
>
> 2016-02-17 20:24 GMT+01:00 Jason Porter <lightguard...@gmail.com>:
>
> > 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
> >
>



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

Re: [VOTE] Release of Apache DeltaSpike 1.5.3

[Christian Kaltepoth]

+1

2016-02-06 16:19 GMT+01:00 Jason Porter <lightguard...@gmail.com>:

> +1
>
> On Saturday, February 6, 2016, Thomas Andraschko <
> andraschko.tho...@gmail.com> wrote:
>
> > +1
> >
> > 2016-02-05 14:01 GMT+01:00 Gerhard Petracek <gpetra...@apache.org
> > <javascript:;>>:
> >
> > > 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
>



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

Re: [VOTE] Release of Apache DeltaSpike 1.5.2

[Christian Kaltepoth]

+1

2015-12-06 21:01 GMT+01:00 John D. Ament <johndam...@apache.org>:

> +1
> On Dec 6, 2015 14:54, "Gerhard Petracek" <gpetra...@apache.org> wrote:
>
> > 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
> >
>



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

Re: first steps for the next release

[Christian Kaltepoth]

+1

2015-11-26 11:37 GMT+01:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> +1
>
> 2015-11-26 11:31 GMT+01:00 Gerhard Petracek <gerhard.petra...@gmail.com>:
>
> > 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
> >
>



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

Re: [VOTE] Release of Apache DeltaSpike 1.5.1

[Christian Kaltepoth]

+1

2015-10-26 15:16 GMT+01:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> +1
>
> 2015-10-25 2:17 GMT+02:00 Daniel Cunha <daniels...@gmail.com>:
>
> > +1
> >
> > On Sat, Oct 24, 2015 at 9:10 PM, Jason Porter <lightguard...@gmail.com>
> > wrote:
> >
> > > 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
> > >
> >
> >
> >
> > --
> > Daniel Cunha (soro)
> > https://twitter.com/dvlc_
> > http://www.tomitribe.com
> >
>



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

Re: first steps for the next release

[Christian Kaltepoth]

+1

2015-10-14 9:41 GMT+02:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> +1
>
> 2015-10-14 9:38 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > +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-10-14 9:37 GMT+02:00 Gerhard Petracek <gpetra...@apache.org>:
> >
> > > hi @ all,
> > >
> > > if there are no objections, i will start with the first steps for the
> > next
> > > release (v1.5.1) 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

Re: Deactivation and redeployment

[Christian Kaltepoth]

+1 for disabling the cache if the project stage is not "production".

2015-10-10 23:46 GMT+02:00 John D. Ament <johndam...@apache.org>:

> Glad we agree ;-)
>
> https://issues.apache.org/jira/browse/DELTASPIKE-1001
>
> If no one raises any objections by tomorrow evening eastern I'll push up
> the change and update the docs.
>
> John
>
> On Sat, Oct 10, 2015 at 5:33 PM Gerhard Petracek <
> gerhard.petra...@gmail.com>
> wrote:
>
> > +1 to skip caching in case of ProjectStage.UnitTest (and
> > maybe ProjectStage.Development)
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2015-10-10 23:22 GMT+02:00 John D. Ament <johndam...@apache.org>:
> >
> > > Gerhard,
> > >
> > > I think it has more to do with making sure the test is doing the bare
> > > minimum possible.
> > >
> > > Another way to think about it is to specify on start up that
> > > ClassDeactivation shouldn't cache, rather than exposing a "reset"
> > function
> > > in the code base.  Like maybe if project stage == Development, don't
> even
> > > cache.
> > >
> > > Feasible? Sensible? Agreeable?
> > >
> > > On Sat, Oct 10, 2015 at 12:22 PM Gerhard Petracek <
> > > gerhard.petra...@gmail.com> wrote:
> > >
> > > > hi john,
> > > >
> > > > please provide a bit more information about the concrete use-case
> (and
> > > why
> > > > you need different configurations for the same application).
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2015-10-10 2:28 GMT+02:00 John D. Ament <johndam...@apache.org>:
> > > >
> > > > > Sorry, linked to the wrong line
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/util/ClassDeactivationUtils.java#L54
> > > > >
> > > > > John
> > > > >
> > > > > On Fri, Oct 9, 2015 at 8:24 PM John D. Ament <
> johndam...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Hey,
> > > > > >
> > > > > > I ran into a weird issue today.  I have two tests based on
> > > Arquillian,
> > > > > and
> > > > > > both have some DeltaSpike dependencies in them.
> > > > > >
> > > > > > The test I'm running is against Weld EE embedded, it's not
> spawning
> > > new
> > > > > > JVMs or anything, but each test has its own deployment.  The
> weird
> > > part
> > > > > > about the two deployments is that they had different class
> > > > > deactivators.  I
> > > > > > ran into an issue in that TestA ran before TestB.  During TestB's
> > > > > > execution, I was seeing deacitvation behavior based on the
> > > > configuration
> > > > > of
> > > > > > TestA.
> > > > > >
> > > > > > I realized much later that the cause is that the class
> deactivation
> > > > > result
> > > > > > is computed and cached, which is fine for production code but for
> > > unit
> > > > > > tests I would hope that it behaves more idempotent.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/util/ClassDeactivationUtils.java#L47
> > > > > >
> > > > > > I'm wondering if it's possible to expose a method to allow devs
> to
> > > > reset
> > > > > > the deacitvation cache between test runs.
> > > > > >
> > > > > > WDYT?
> > > > > >
> > > > > > John
> > > > > >
> > > > >
> > > >
> > >
> >
>



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

Re: [VOTE] Release of Apache DeltaSpike 1.5.0

[Christian Kaltepoth]

+1

2015-08-10 4:35 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:

 +1
 Le 9 août 2015 19:03, Gerhard Petracek gpetra...@apache.org a écrit :

  +1
 
  regards,
  gerhard
 
 
 
  2015-08-10 4:02 GMT+02:00 Gerhard Petracek gpetra...@apache.org:
 
   Hi,
  
   I was running the needed tasks to get the 19th 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.0 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-1029/
   [2]
  
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1029/org/apache/deltaspike/deltaspike/1.5.0/deltaspike-1.5.0-source-release.zip
   [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.5.0
   [4] https://github.com/os890/deltaspike-vote/tree/ds-1.5.0
   [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
  
 




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

Re: v1.5.0 instead of v1.4.3

[Christian Kaltepoth]

+0

2015-08-03 23:38 GMT+02:00 Daniel Cunha daniels...@gmail.com:

 +1

 On Mon, Aug 3, 2015 at 6:33 PM, Romain Manni-Bucau rmannibu...@gmail.com
 wrote:

  +1
  Le 3 août 2015 22:44, John D. Ament johndam...@apache.org a écrit :
 
   +0
   These are all bug fixes, no major api changes that i can tell.
  
   On Mon, Aug 3, 2015 at 4:24 PM Gerhard Petracek gpetra...@apache.org
   wrote:
  
hi @ all,
   
if there are no objections, i'll change the version number to 1.5.0
before the next release.
   
reasons:
 - security fix
 - changes for window-handling
   
regards,
gerhard
   
  
 



 --
 Best regard,
 Daniel Cunha (soro)




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

Re: [VOTE] Release of Apache DeltaSpike 1.4.2

[Christian Kaltepoth]

+1

2015-07-20 14:24 GMT+02:00 Rafael Benevides benevi...@redhat.com:

 +1 for me.

 - Mensagem original -
 De: Gerhard Petracek gpetra...@apache.org
 Para: dev@deltaspike.apache.org
 Enviadas: Domingo, 19 de julho de 2015 14:11:10
 Assunto: [VOTE] Release of Apache DeltaSpike 1.4.2

 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




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

[jira] [Created] (DELTASPIKE-950) RequestResponseHolderListener fails if requestInitialized() is called more than once

[Christian Kaltepoth (JIRA)]

Christian Kaltepoth created DELTASPIKE-950:
--

 Summary: RequestResponseHolderListener fails if 
requestInitialized() is called more than once
 Key: DELTASPIKE-950
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-950
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Servlet-Module
Affects Versions: 1.4.1
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth


Tomcat seems to call RequestResponseHolderListener.requestInitialized() more 
than once in some situations. I'm not sure if this is spec compliant.

Currently RequestResponseHolderListener fails with There is already an 
instance bound to this thread in this situation.

The implementation should be more robust and handle this case correctly.

See:
http://mail-archives.apache.org/mod_mbox/deltaspike-users/201507.mbox/%3C559E1F24.40408%40senat.fr%3E



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

[jira] [Resolved] (DELTASPIKE-950) RequestResponseHolderListener fails if requestInitialized() is called more than once

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth resolved DELTASPIKE-950.

   Resolution: Fixed
Fix Version/s: 1.4.2

 RequestResponseHolderListener fails if requestInitialized() is called more 
 than once
 

 Key: DELTASPIKE-950
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-950
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Servlet-Module
Affects Versions: 1.4.1
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
 Fix For: 1.4.2


 Tomcat seems to call RequestResponseHolderListener.requestInitialized() more 
 than once in some situations. I'm not sure if this is spec compliant.
 Currently RequestResponseHolderListener fails with There is already an 
 instance bound to this thread in this situation.
 The implementation should be more robust and handle this case correctly.
 See:
 http://mail-archives.apache.org/mod_mbox/deltaspike-users/201507.mbox/%3C559E1F24.40408%40senat.fr%3E



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

[jira] [Resolved] (DELTASPIKE-949) RequestResponseHolderListener should be deactivatable

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth resolved DELTASPIKE-949.

   Resolution: Fixed
Fix Version/s: 1.4.2

 RequestResponseHolderListener should be deactivatable
 -

 Key: DELTASPIKE-949
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-949
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Servlet-Module
Affects Versions: 1.4.1
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
 Fix For: 1.4.2


 I would be useful if users could deactivate RequestResponseHolderListener. 
 Especially because the listener is called multiple times for forwarded 
 requests in some scenarios. 



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

[jira] [Created] (DELTASPIKE-949) RequestResponseHolderListener should be deactivatable

[Christian Kaltepoth (JIRA)]

Christian Kaltepoth created DELTASPIKE-949:
--

 Summary: RequestResponseHolderListener should be deactivatable
 Key: DELTASPIKE-949
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-949
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Servlet-Module
Affects Versions: 1.4.1
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth


I would be useful if users could deactivate RequestResponseHolderListener. 
Especially because the listener is called multiple times for forwarded requests 
in some scenarios. 



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

Re: [VOTE] Release of Apache DeltaSpike 1.4.1

[Christian Kaltepoth]

+1

2015-06-13 12:19 GMT+02:00 Daniel Cunha daniels...@gmail.com:

 +1

 On Sat, Jun 13, 2015 at 6:45 AM, Romain Manni-Bucau rmannibu...@gmail.com
 
 wrote:

  +1
  Le 13 juin 2015 10:56, Harald Wellmann hwellmann...@gmail.com a
 écrit
  :
 
   +1
  
   Regards,
   Harald
  
   Am 12.06.2015 um 23:23 schrieb Gerhard Petracek:
  
   Hi,
  
   I was running the needed tasks to get the 17th 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.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-1027/
   [2]
  
  
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1027/org/apache/deltaspike/deltaspike/1.4.1/deltaspike-1.4.1-source-release.zip
   [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.4.1
   [4] https://github.com/os890/deltaspike-vote/tree/ds-1.4.1
   [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
  
  
  
 



 --
 Best regard,
 Daniel Cunha (soro)




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

[jira] [Created] (DELTASPIKE-913) QuartzScheduler uses BeanProvider.getContextualReference() for dependent scoped bean

[Christian Kaltepoth (JIRA)]

Christian Kaltepoth created DELTASPIKE-913:
--

 Summary: QuartzScheduler uses 
BeanProvider.getContextualReference() for dependent scoped bean
 Key: DELTASPIKE-913
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-913
 Project: DeltaSpike
  Issue Type: Bug
  Components: Scheduler
Affects Versions: 1.4.0
Reporter: Christian Kaltepoth


The scheduler module logs a warning for each invocation of a job:

{code}
28-May-2015 09:12:35.001 WARNING [DefaultQuartzScheduler_Worker-2] 
org.apache.deltaspike.core.api.provider.BeanProvider.logWarningIfDependent 
BeanProvider shall not be used to create @Dependent scoped beans. Bean: Managed 
Bean [class org.apache.deltaspike.cdise.weld.WeldContextControl] with 
qualifiers [@Any @Default]
{code}

This is caused by {{JobListenerContext}} which uses 
{{BeanProvider.getContextualReference}} to get an instance of 
{{ContextControl}}.



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

[jira] [Commented] (DELTASPIKE-913) QuartzScheduler uses BeanProvider.getContextualReference() for dependent scoped bean

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth commented on DELTASPIKE-913:


I created a first version of a fix for this:

https://github.com/chkal/deltaspike/commit/e5b436922e61046ca33390e85f2f64c9171a8fc1

I would like to hear your opinion on this. Any thoughts?

 QuartzScheduler uses BeanProvider.getContextualReference() for dependent 
 scoped bean
 

 Key: DELTASPIKE-913
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-913
 Project: DeltaSpike
  Issue Type: Bug
  Components: Scheduler
Affects Versions: 1.4.0
Reporter: Christian Kaltepoth

 The scheduler module logs a warning for each invocation of a job:
 {code}
 28-May-2015 09:12:35.001 WARNING [DefaultQuartzScheduler_Worker-2] 
 org.apache.deltaspike.core.api.provider.BeanProvider.logWarningIfDependent 
 BeanProvider shall not be used to create @Dependent scoped beans. Bean: 
 Managed Bean [class org.apache.deltaspike.cdise.weld.WeldContextControl] with 
 qualifiers [@Any @Default]
 {code}
 This is caused by {{JobListenerContext}} which uses 
 {{BeanProvider.getContextualReference}} to get an instance of 
 {{ContextControl}}.



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

Re: first steps for the next release

[Christian Kaltepoth]

+1

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

 +1

 On Fri, May 8, 2015 at 1:36 PM, Rafael Benevides benevi...@redhat.com
 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
  wrote:
 
  +1
 
  Am Freitag, 8. Mai 2015 schrieb Romain Manni-Bucau :
 
  +1
  Le 8 mai 2015 13:13, Gerhard Petracek gpetra...@apache.org
  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

Re: v1.4.0 instead of v1.3.1

[Christian Kaltepoth]

+1 for 1.4.0

2015-05-04 22:05 GMT+02:00 Rafael Benevides benevi...@redhat.com:

 I though more about it and considering that we had some APIs change I'm
 doing a

 +1 to 1.4.0



 On 5/4/15 12:37, Rafael Benevides wrote:

 I'm ok with either 1.3.1 or 1.4.0.


 On 5/4/15 12:14, Jason Porter wrote:

 +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








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

Re: [COMMUNITY] DeltaSpike += Ron Smeral

[Christian Kaltepoth]

Welcome. :)

2015-04-17 19:28 GMT+02:00 John D. Ament johndam...@apache.org:

 Welcome aboard Ron!

 On Fri, Apr 17, 2015 at 9:10 AM Gerhard Petracek gpetra...@apache.org
 wrote:

  The DeltaSpike PMC is proud to announce a new addition to our community.
 
  Please welcome Ron Smeral as the newest DeltaSpike committer!
 
  @Ron:
  Please add yourself to the developers section (in
  deltaspike/parent/pom.xml).
 
  Welcome  regards,
  Gerhard
 




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

[jira] [Commented] (DELTASPIKE-838) SchedulerExtension: Multiple Job-Classes found with name

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth commented on DELTASPIKE-838:


[~mkouba]: Awesome! Thank you!

 SchedulerExtension: Multiple Job-Classes found with name
 

 Key: DELTASPIKE-838
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-838
 Project: DeltaSpike
  Issue Type: Bug
  Components: Scheduler
Affects Versions: 1.2.1
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
 Fix For: 1.2.2

 Attachments: 
 0001-DELTASPIKE-838-Ensure-job-classes-are-processed-only.patch


 I just had a weird issue today. After adding a single {{@Scheduled}} to one 
 of my beans, the application failed with this error during startup:
 {code}
 IllegalStateException: Multiple Job-Classes found with name MyBean
 {code}
 I debugged this a bit. It looks like Weld is sending multiple 
 {{ProcessAnnotatedType}} events for the same type. I guess this is caused by 
 the fact that the application I'm working on has two beans.xml files. One in 
 {{src/main/resources/META-INF}} and one in {{src/main/webapp/WEB-INF}}. I 
 know this setup is not portable according to the spec. However,  the 
 application is working absolutely fine. Just the {{SchedulerExtension}} fails.
 We could work around such issues simply by changing the type of the 
 {{foundManagedJobClasses}} field from {{List}} to {{Set}}. I think this 
 should be fine and prevents errors in such scenarios.
 Thoughts?



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

[jira] [Created] (DELTASPIKE-838) SchedulerExtension: Multiple Job-Classes found with name

[Christian Kaltepoth (JIRA)]

Christian Kaltepoth created DELTASPIKE-838:
--

 Summary: SchedulerExtension: Multiple Job-Classes found with name
 Key: DELTASPIKE-838
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-838
 Project: DeltaSpike
  Issue Type: Bug
  Components: Scheduler
Affects Versions: 1.2.1
Reporter: Christian Kaltepoth


I just had a weird issue today. After adding a single {{@Scheduled}} to one of 
my beans, the application failed with this error during startup:

{code}
IllegalStateException: Multiple Job-Classes found with name MyBean
{code}

I debugged this a bit. It looks like Weld is sending multiple 
{{ProcessAnnotatedType}} events for the same type. I guess this is caused by 
the fact that the application I'm working on has two beans.xml files. One in 
{{src/main/resources/META-INF}} and one in {{src/main/webapp/WEB-INF}}. I know 
this setup is not portable according to the spec. However,  the application 
is working absolutely fine. Just the {{SchedulerExtension}} fails.

We could work around such issues simply by changing the type of the 
{{foundManagedJobClasses}} field from {{List}} to {{Set}}. I think this should 
be fine and prevents errors in such scenarios.

Thoughts?



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

[jira] [Updated] (DELTASPIKE-838) SchedulerExtension: Multiple Job-Classes found with name

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth updated DELTASPIKE-838:
---
Attachment: 0001-DELTASPIKE-838-Ensure-job-classes-are-processed-only.patch

Proposed patch. Let me know your thoughts on this.

 SchedulerExtension: Multiple Job-Classes found with name
 

 Key: DELTASPIKE-838
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-838
 Project: DeltaSpike
  Issue Type: Bug
  Components: Scheduler
Affects Versions: 1.2.1
Reporter: Christian Kaltepoth
 Attachments: 
 0001-DELTASPIKE-838-Ensure-job-classes-are-processed-only.patch


 I just had a weird issue today. After adding a single {{@Scheduled}} to one 
 of my beans, the application failed with this error during startup:
 {code}
 IllegalStateException: Multiple Job-Classes found with name MyBean
 {code}
 I debugged this a bit. It looks like Weld is sending multiple 
 {{ProcessAnnotatedType}} events for the same type. I guess this is caused by 
 the fact that the application I'm working on has two beans.xml files. One in 
 {{src/main/resources/META-INF}} and one in {{src/main/webapp/WEB-INF}}. I 
 know this setup is not portable according to the spec. However,  the 
 application is working absolutely fine. Just the {{SchedulerExtension}} fails.
 We could work around such issues simply by changing the type of the 
 {{foundManagedJobClasses}} field from {{List}} to {{Set}}. I think this 
 should be fine and prevents errors in such scenarios.
 Thoughts?



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

[jira] [Commented] (DELTASPIKE-838) SchedulerExtension: Multiple Job-Classes found with name

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth commented on DELTASPIKE-838:


[~mkouba]: Weld Servlet 2.2.8.Final deployed to Tomcat 8.0.15. It works fine 
with only a beans.xml in WEB-INF. But having two beans.xml files (WEB-INF + 
WEB-INF/classes/META-INF) breaks it.

 SchedulerExtension: Multiple Job-Classes found with name
 

 Key: DELTASPIKE-838
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-838
 Project: DeltaSpike
  Issue Type: Bug
  Components: Scheduler
Affects Versions: 1.2.1
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
 Fix For: 1.2.2

 Attachments: 
 0001-DELTASPIKE-838-Ensure-job-classes-are-processed-only.patch


 I just had a weird issue today. After adding a single {{@Scheduled}} to one 
 of my beans, the application failed with this error during startup:
 {code}
 IllegalStateException: Multiple Job-Classes found with name MyBean
 {code}
 I debugged this a bit. It looks like Weld is sending multiple 
 {{ProcessAnnotatedType}} events for the same type. I guess this is caused by 
 the fact that the application I'm working on has two beans.xml files. One in 
 {{src/main/resources/META-INF}} and one in {{src/main/webapp/WEB-INF}}. I 
 know this setup is not portable according to the spec. However,  the 
 application is working absolutely fine. Just the {{SchedulerExtension}} fails.
 We could work around such issues simply by changing the type of the 
 {{foundManagedJobClasses}} field from {{List}} to {{Set}}. I think this 
 should be fine and prevents errors in such scenarios.
 Thoughts?



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

[jira] [Resolved] (DELTASPIKE-838) SchedulerExtension: Multiple Job-Classes found with name

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth resolved DELTASPIKE-838.

Resolution: Fixed

Thanks for reviewing. I just committed the patch.

 SchedulerExtension: Multiple Job-Classes found with name
 

 Key: DELTASPIKE-838
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-838
 Project: DeltaSpike
  Issue Type: Bug
  Components: Scheduler
Affects Versions: 1.2.1
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
 Fix For: 1.2.2

 Attachments: 
 0001-DELTASPIKE-838-Ensure-job-classes-are-processed-only.patch


 I just had a weird issue today. After adding a single {{@Scheduled}} to one 
 of my beans, the application failed with this error during startup:
 {code}
 IllegalStateException: Multiple Job-Classes found with name MyBean
 {code}
 I debugged this a bit. It looks like Weld is sending multiple 
 {{ProcessAnnotatedType}} events for the same type. I guess this is caused by 
 the fact that the application I'm working on has two beans.xml files. One in 
 {{src/main/resources/META-INF}} and one in {{src/main/webapp/WEB-INF}}. I 
 know this setup is not portable according to the spec. However,  the 
 application is working absolutely fine. Just the {{SchedulerExtension}} fails.
 We could work around such issues simply by changing the type of the 
 {{foundManagedJobClasses}} field from {{List}} to {{Set}}. I think this 
 should be fine and prevents errors in such scenarios.
 Thoughts?



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

Re: [VOTE] Release of Apache DeltaSpike 1.2.0

[Christian Kaltepoth]

+1

2014-12-01 3:37 GMT+01:00 Jason Porter lightguard...@gmail.com:

 +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
  
 
 




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

Re: first steps for the next release

[Christian Kaltepoth]

+1 for 1.2.0

2014-11-17 20:38 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com:

 +0 (i dont like all the noise around BeanManagerProvider but seems alone so
 dont want to block)
 Le 17 nov. 2014 20:20, Jason Porter lightguard...@gmail.com a écrit :

  +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
   
  
  
 




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

Re: [VOTE] Release of Apache DeltaSpike 1.1.0

[Christian Kaltepoth]

+1

2014-11-03 10:59 GMT+01:00 Mark Struberg strub...@yahoo.de:

 +1

 LieGrue,
 strub





  On Saturday, 1 November 2014, 21:47, Gerhard Petracek 
 gpetra...@apache.org wrote:
   Hi,
 
  I was running the needed tasks to get the 12th 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.1.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-1015
  [2]
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1015/org/apache/deltaspike/deltaspike-project/1.1.0/deltaspike-project-1.1.0-source-release.zip
  [3]
 https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.1.0
  [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
 




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

[jira] [Resolved] (DELTASPIKE-732) Servlet API module needs beans.xml

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth resolved DELTASPIKE-732.

   Resolution: Fixed
Fix Version/s: 1.0.4

Fixed. Thanks for bringing this up.

 Servlet API module needs beans.xml
 --

 Key: DELTASPIKE-732
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-732
 Project: DeltaSpike
  Issue Type: Bug
  Components: Servlet-Module
Affects Versions: 1.0.3
Reporter: Ron Smeral
Assignee: Christian Kaltepoth
 Fix For: 1.0.4


 The servlet api module misses the beans.xml file.
 It contains the WebResourceProvider, which is an ApplicationScoped bean, 
 resolved in InjectableResourceProducer through BeanProvider. 
 Also, the WebResourceProviderTest needs to be corrected. It didn't catch this 
 issue, because the WebResourceProvider is explicitly added to the test 
 archive through addClass. That statement should be removed.



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

Re: first steps for the next release

[Christian Kaltepoth]

@Ron  @Gerhard:

Yeah, I'll fix this issue today. Sorry for the delay.

I would also like to get this one into the release which was reported on
the Rewrite forums:

https://issues.apache.org/jira/browse/DELTASPIKE-753

Christian

2014-10-26 21:29 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com:

 hi ron,

 yes - christian will check it within the next days.
 it should be in since the change itself is trivial.

 regards,
 gerhard



 2014-10-26 21:10 GMT+01:00 Ron Smeral rsme...@redhat.com:

  Hi,
 
  could we also squeeze this one in for 1.0.4? https://issues.apache.org/
  jira/browse/DELTASPIKE-732.
  It needs a trivial fix, yet it completely prevents a feature from working
  (missing beans.xml = web resource injection doesn't work).
 
  Thanks,
 
  R.
 
 
  On 25.10.2014 12:32, Gerhard Petracek wrote:
 
  hi @ all,
 
  if there are no objections, i will start with the first steps for the
 next
  release (v1.0.4) by the end of next week.
 
  regards,
  gerhard
 
 
  --
  Ron Smeral
  JBoss Quality Engineer
  Brno
 
 




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

Re: [VOTE] Release of Apache DeltaSpike 1.0.3

[Christian Kaltepoth]

+1

2014-09-23 7:51 GMT+02:00 Mark Struberg strub...@yahoo.de:

 +1

 LieGrue,
 strub




  On Sunday, 21 September 2014, 20:07, 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
 




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

[jira] [Commented] (DELTASPIKE-706) Multiple CDI API versions on classpath in JSF module tests (Weld)

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth commented on DELTASPIKE-706:


Looks good to me. I think you can push it.

 Multiple CDI API versions on classpath in JSF module tests (Weld)
 -

 Key: DELTASPIKE-706
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-706
 Project: DeltaSpike
  Issue Type: Bug
  Components: JSF-Module
Affects Versions: 1.0.2
Reporter: Jozef Hartinger
Assignee: Jozef Hartinger
 Fix For: 1.0.3


 When running JSF module tests against Weld 2.2, both geronimo CDI 1.0 and CDI 
 1.2 API classes are on classpath.



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

Re: first steps for the next release

[Christian Kaltepoth]

+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

Re: [VOTE] Release of Apache DeltaSpike 1.0.1

[Christian Kaltepoth]

+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
  
 




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

Re: first steps for the next release

[Christian Kaltepoth]

+1


2014-07-06 14:32 GMT+02:00 Mark Struberg strub...@yahoo.de:

 +1

 LieGrue,
 strub


 On Sunday, 6 July 2014, 12:01, Thomas Andraschko 
 andraschko.tho...@gmail.com wrote:


 
 
 +1
 
 
 
 2014-07-05 15:41 GMT+02:00 Gerhard Petracek gerhard.petra...@gmail.com:
 
  hi @ all,
 
  if there are no objections, i will start with the first steps for the
 next
  release (v1.0.1) 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

Re: [VOTE] logo-color

[Christian Kaltepoth]

+1 for red


2014-06-16 13:41 GMT+02:00 Rafael Benevides benevi...@redhat.com:

 +1 for red

 Em 14/06/14 14:55, Gerhard Petracek escreveu:

  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





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

Re: [COMMUNITY] DeltaSpike += Rafael Benevides

[Christian Kaltepoth]

Congratulations! :)




2014-05-20 13:53 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:

 Congrats!



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


 2014-05-20 13:44 GMT+02:00 Jean-Louis MONTEIRO jeano...@gmail.com:

  Congrats.
 
 
  2014-05-20 4:26 GMT-07:00 Gerhard Petracek gpetra...@apache.org:
 
   The DeltaSpike PMC is proud to announce a new addition to our
 community.
  
   Please welcome Rafael Benevides as the newest DeltaSpike committer!
  
   @Rafael:
   Please add yourself to the developers section (in
   deltaspike/parent/pom.xml).
  
   Welcome  regards,
   Gerhard
  
 
 
 
  --
  Jean-Louis
 




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

Re: [DISCUSS] next release as 1.0?

[Christian Kaltepoth]

+1


2014-05-19 11:34 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-05-19 11:13 GMT+02:00 Mark Struberg strub...@yahoo.de:

  Hi!
 
  Is there ANYTHING which holds us back from moving our version to 1.0?
 
  We are long overdue and there are SOOO many companies using DeltaSpike in
  production since years now...
 
  LieGrue,
  strub
 




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

Re: [VOTE] Release of Apache DeltaSpike 0.7

[Christian Kaltepoth]

+1

Looks good!


2014-05-01 23:56 GMT+02:00 John D. Ament john.d.am...@gmail.com:

 +1


 On Thu, May 1, 2014 at 5:51 PM, Jean-Louis MONTEIRO jeano...@gmail.com
 wrote:

  Looks good guys.
  +1
 
  JLouis
 
 
  2014-05-01 23:06 GMT+02:00 Mark Struberg strub...@yahoo.de:
 
   +1
  
   LieGrue,
   strub
  
  
  
  
  
On Thursday, 1 May 2014, 17:12, Cody Lerum cody.le...@gmail.com
  wrote:
 +1
   
builds and tests weld and owb fine on win 8.1 x64 7u51
   
   
On Wed, Apr 30, 2014 at 2:22 PM, Gerhard Petracek 
  gpetra...@apache.org
wrote:
 Hi,
   
 I was running the needed tasks to get the 7th 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 0.7 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-1003/
 [2]
   
   
  
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1003/org/apache/deltaspike/deltaspike-project/0.7/deltaspike-project-0.7-source-release.zip
 [3]
   https://github.com/os890/deltaspike-vote/tree/deltaspike-project-0.7
 [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
   
  
 
 
 
  --
  Jean-Louis
 




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

Re: [DISCUSS] releases

[Christian Kaltepoth]

+1


2014-04-03 14:44 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-04-03 14:42 GMT+02:00 Gerhard Petracek gerhard.petra...@gmail.com:
  hi @ all,
 
  initially we agreed on releasing early and often.
  so far the average was ~3 releases per year. imo it should be more like
 1-2
  releases every quarter (for sure depending on the resolved tickets).
 
  if there are no objections, we could do the next release in about a
 month.
 
  regards,
  gerhard




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

Re: [VOTE] #2 Release of Apache DeltaSpike 0.6

[Christian Kaltepoth]

+1


2014-03-16 23:00 GMT+01:00 Ove Ranheim oranh...@gmail.com:

 +1

 Sent from my iPhone

  On 16. mars 2014, at 20:50, Thomas Andraschko 
 andraschko.tho...@gmail.com wrote:
 
  +1
 
 
  2014-03-16 20:19 GMT+01: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-03-16 18:36 GMT+01:00 John D. Ament john.d.am...@gmail.com:
  +1.
 
  Don't forget to cancel the prior vote.
 
  On Sun, Mar 16, 2014 at 1:31 PM, Gerhard Petracek 
 gpetra...@apache.org
  wrote:
  Hi,
 
  I was running the needed tasks to get the 6th 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 0.6 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-1001/
  [2]
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1001/org/apache/deltaspike/deltaspike-project/0.6/deltaspike-project-0.6-source-release.zip
  [3]
  https://github.com/os890/deltaspike-vote/tree/deltaspike-project-0.6
  [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
 




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

Re: first steps for the next release

[Christian Kaltepoth]

+1


2014-03-12 11:26 GMT+01: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-03-12 11:19 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com
 :
  +1
  thanks gerhard
 
 
  2014-03-12 11:14 GMT+01:00 Gerhard Petracek gpetra...@apache.org:
 
  hi @ all,
 
  if there are no objections, i will start with the first steps for the
 next
  release (v0.6) by the end of this week.
 
  regards,
  gerhard
 




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

[jira] [Updated] (DELTASPIKE-481) Use unique archive names in Servlet module integration tests

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth updated DELTASPIKE-481:
---

Fix Version/s: 0.6

 Use unique archive names in Servlet module integration tests
 

 Key: DELTASPIKE-481
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-481
 Project: DeltaSpike
  Issue Type: Task
  Components: Servlet-Module
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
Priority: Minor
 Fix For: 0.6


 As pointed out by [~gpetracek] in DELTASPIKE-399, integration test archives 
 should have unique names to prevent problems with Arquillian's 
 deploymentExportPath.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth resolved DELTASPIKE-414.


   Resolution: Fixed
Fix Version/s: 0.6

I just committed a fix for this issue. I added a ServletRequestListener that 
binds the request to the thread which will happen immediately after the request 
is created. There is also an integration test that verifies that the scenario 
you described now works as expected.

 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
Assignee: Christian Kaltepoth
 Fix For: 0.6


 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.2#6252)

[jira] [Updated] (DELTASPIKE-492) Create ExternalResourceProvider for the Servlet Module

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth updated DELTASPIKE-492:
---

Fix Version/s: 0.6

 Create ExternalResourceProvider for the Servlet Module 
 ---

 Key: DELTASPIKE-492
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-492
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Servlet-Module
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
 Fix For: 0.6


 There should be an ExternalResourceProvider that uses 
 ServletContext.getResource() for loading resources.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (DELTASPIKE-496) Merge arquillian.xml files into a single one

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth updated DELTASPIKE-496:
---

Fix Version/s: 0.6

 Merge arquillian.xml files into a single one
 

 Key: DELTASPIKE-496
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-496
 Project: DeltaSpike
  Issue Type: Task
  Components: Tests
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
Priority: Minor
 Fix For: 0.6


 Currently we have 9 different arquillian.xml files. We should merge them into 
 a single one and put it into the test-utils module. 
 Discussion: 
 http://s.apache.org/40D



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [DISCUSS] move @Initialized and @Destroyed

[Christian Kaltepoth]

+1


2014-02-18 14:29 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com:

 sounds good!


 2014-02-18 14:19 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com:

  @ thomas:
 
  @Observes @BeforeJsfRequest FacesContext
  @Observes @AfterJsfRequest FacesContext
  -
  @Observes @Initialized FacesContext
  @Observes @Destroyed FacesContext
 
  the implementation of @AfterJsfRequest fits to @Destroyed, but for
  @Initialized we might have to move the logic (to get a real
 initialization
  event).
  if we would move it to DeltaSpikeFacesContextFactory the benefit is
  minimal, but there would be an overhead for resource-request and there is
  no active client-window at that point.
 
  regards,
  gerhard
 
 
 
  2014-02-18 13:44 GMT+01:00 Mark Struberg strub...@yahoo.de:
 
   +1
  
   LieGrue,
   strub
  
  
  
  
  
   On Tuesday, 18 February 2014, 13:27, Thomas Andraschko 
   andraschko.tho...@gmail.com wrote:
  
   +1
   I like such minor improvements and finalize such stuff :)
   
   Whats the replacements for @After/BeforeJsfRequest then?
   
   
   
   
   2014-02-18 13:23 GMT+01:00 Gerhard Petracek 
 gerhard.petra...@gmail.com
  :
   
hi @ all,
   
if we would move @Initialized and @Destroyed to ds-core, we could
 use
   them
for other parts as well (e.g. instead of @BeforeJsfRequest and
@AfterJsfRequest).
   
regards,
gerhard
   
   
   
   
  
 




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

Re: Optimizing the integration tests

[Christian Kaltepoth]

Hey Ron,

thanks for sharing these details. I created a separate arquillian.xml file
for AS7 and JBoss.

https://github.com/apache/deltaspike/commit/ce875fde3fe5421c6d12bd43019fedaee8af5923

I guess this setup should work fine now.

Christian



2014-02-04 10:18 GMT+01:00 Ron Smeral rsme...@redhat.com:

 Christian,

 I just found out, that adding protocol type=Servlet 3.0 / to the
 container element in arquillian.xml only configures (does not select) an
 already selected protocol. If no protocol is selected using
 defaultProtocol, then the container's default is used. And the default
 for AS7 is, sadly, jmx-as7, which is intended for internal testing of the
 container and makes tests unstable.

 What could be done, is to create arquillian-owb.xml in test-utils, and add
 arquillian.xmlarquillian-owb.xml/arquillian.xml to the
 systemProperties in OWB profile. Or the other way around for JBoss.

 Ron


 On 3.2.2014 17:23, Christian Kaltepoth wrote:

 @Ron

 I just tried that. The result is this:

 java.lang.IllegalArgumentException: No
 org.jboss.arquillian.container.spi.client.protocol.metadata.HTTPContext
 found in
 org.jboss.arquillian.container.spi.client.protocol.
 metadata.ProtocolMetaData.
 Servlet protocol can not be used
  at
 org.jboss.arquillian.protocol.servlet.BaseServletProtocol.getExecutor(
 BaseServletProtocol.java:64)
  at
 org.jboss.arquillian.protocol.servlet.BaseServletProtocol.getExecutor(
 BaseServletProtocol.java:35)
  at
 org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.
 getContainerMethodExecutor(RemoteTestExecuter.java:136)
  at
 org.jboss.arquillian.container.test.impl.execution.
 RemoteTestExecuter.execute(RemoteTestExecuter.java:119)

 What if we just add *protocol type=Servlet 3.0 /* to all the AS7 and

 Wildfly profiles? Wouldn't this fix all our problems?

 Christian




 2014-02-03 Ron Smeral rsme...@redhat.com:

  Hi Christian,

 the reason for this could be, that in parent/code/pom.xml, the
 'org.jboss.arquillian.protocol:arquillian-protocol-servlet' dependency
 is
 not declared for any non-JBoss profile (OWB, tomee, glassfish, ..).
 Could you try it with the dependency declared?

 Ron


 On 3.2.2014 10:51, Christian Kaltepoth wrote:

  @gerhard:

 I was getting this when running the build:

 Caused by: java.lang.IllegalStateException: Defined default protocol
 Servlet 3.0 can not be found on classpath
   at
 org.jboss.arquillian.container.test.impl.client.protocol.
 ProtocolRegistryCreator.createRegistry(ProtocolRegistryCreator.java:61)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method)
   at
 sun.reflect.NativeMethodAccessorImpl.invoke(
 NativeMethodAccessorImpl.java:57)
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(
 DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at
 org.jboss.arquillian.core.impl.ObserverImpl.invoke(
 ObserverImpl.java:94)
   at
 org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(
 EventContextImpl.java:99)

 The weird thing is that Maven simply doesn't run the tests in this case
 which leads to a successful build.

  Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

 Full log of running mvn clean -POWB -Dowb.version=1.1.8 on core-impl
 with
 the default protocol entry:

 http://pastebin.com/raw.php?i=1hk9nxmZ


 Christian




 2014-02-02 Gerhard Petracek gerhard.petra...@gmail.com:

   @christian:

 locally i've tested the owb-, weld- and some build-managed-profiles
 with
 the defaultProtocol you removed and everything is working on my
 machine.
 - please provide further details.

 regards,
 gerhard



 2014-02-01 Christian Kaltepoth christ...@kaltepoth.de:

   @Ron  @Jason

 The defaultProtocol was only used in a single arquillian.xml file of
 the

  8

  different ones we had before. I had to remove it because the plain
 Weld
 +
 OWB integration tests started to fail with it (at least for me) for
 some
 reason.

 Christian



 2014-01-31 Jason Porter lightguard...@gmail.com:

   The JMX protocol for Wildfly / AS is horrible and for any sort of

 application or framework the servlet adaptor should be used. Yes,
 it's

  a
 little slower, but it will give you the full environment you're used
 to

 using when you develop.


 On Fri, Jan 31, 2014 at 1:59 PM, Ron Smeral rsme...@redhat.com

  wrote:
 Hi Christian,

 I see you recently removed defaultProtocol from arquillian.xml. Is

  there
 any reason not to have it there? The now default JMX protocol seems
 to

 be

  causing test stability issues, I can't succesfully run for example
 the

 Data

 module tests. I'm not sure why this happens. Have you maybe

  encountered

 this too?

 Also, just FYI, we now have a job 'DeltaSpike-wildfly-daily' at
 hudson.jboss.org which tests the wildfly-build-managed profile. It

  will
 be sending mails to commits@deltaspike.

 Ron


 On 25.1.2014 08:36, Christian Kaltepoth wrote

Re: Optimizing the integration tests

[Christian Kaltepoth]

@Ron  @Jason

The defaultProtocol was only used in a single arquillian.xml file of the 8
different ones we had before. I had to remove it because the plain Weld +
OWB integration tests started to fail with it (at least for me) for some
reason.

Christian



2014-01-31 Jason Porter lightguard...@gmail.com:

 The JMX protocol for Wildfly / AS is horrible and for any sort of
 application or framework the servlet adaptor should be used. Yes, it's a
 little slower, but it will give you the full environment you're used to
 using when you develop.


 On Fri, Jan 31, 2014 at 1:59 PM, Ron Smeral rsme...@redhat.com wrote:

  Hi Christian,
 
  I see you recently removed defaultProtocol from arquillian.xml. Is there
  any reason not to have it there? The now default JMX protocol seems to be
  causing test stability issues, I can't succesfully run for example the
 Data
  module tests. I'm not sure why this happens. Have you maybe encountered
  this too?
 
  Also, just FYI, we now have a job 'DeltaSpike-wildfly-daily' at
  hudson.jboss.org which tests the wildfly-build-managed profile. It will
  be sending mails to commits@deltaspike.
 
  Ron
 
 
  On 25.1.2014 08:36, Christian Kaltepoth wrote:
 
  Hey Gerhard,
 
  yeah, I wasn't aware that the Glassfish jobs have already been added.
 But
  Wildfly is still missing.
 
  Christian
 
 
 
  2014/1/24 Gerhard Petracek gerhard.petra...@gmail.com
 
   hi christian,
 
  the jenkins-jobs should be in place already.
 
  regards,
  gerhard
 
 
 
  2014/1/24 Christian Kaltepoth christ...@kaltepoth.de
 
   Hey all,
 
  I pushed out all the changes of the build-managed integration test
 
  Maven
 
  profiles which I suggested.
 
  You can now run the integration test suite against the different
 
  containers
 
  like this:
 
  $ mvn clean install -Ptomee-build-managed
  $ mvn clean install -Pjbossas-build-managed-7
  $ mvn clean install -Pwildfly-build-managed
  $ mvn clean install -Pglassfish-build-managed-3
  $ mvn clean install -Pglassfish-build-managed-4
 
  Each profiles will automatically download, unpack and configure the
  corresponding container. All TCP ports are changed so that they differ
 
  from
 
  this default ones. This way we should be able to run them on the CI
 
  server
 
  without any problems.
 
  Could anyone with the required permissions add corresponding jobs in
  Jenkins?
 
  Christian
 
 
 
 
  2014/1/11 Christian Kaltepoth christ...@kaltepoth.de
 
   Hey Ron,
 
  yeah, I also thought about using user.dir, but this could point to
 
  some
 
  weird locations depending on from where you start the build. So let's
 
  go
 
  with java.io.tmpdir for now.
 
  Christian
 
 
  2014/1/8 Ron Smeral rsme...@redhat.com
 
   Hey Christian,
 
  you're right, I haven't realized that. Also, if some module needed a
  custom arquillian conf, Arquillian reads a system property named
  arquillian.xml which defines the name of the configuration file.
 
  The last thing I can think of for the testsuite root is the Maven
  property user.dir - the working directory from which mvn was
 
  executed.
 
  Ron
 
 
  On 7.1.2014 17:20, Christian Kaltepoth wrote:
 
   Hey Ron,
 
  I don't think unpacking is necessary. If arquillian.xml is located
 in
  deltaspike/test-utils/src/main/resources, it will be on the
  classpath
  for
  all integration tests. That's basically the setup we are using for
  Rewrite
  since quite some time and it is working fine. See [1].
 
  I guess you are right regarding the merging of poms and that
 
  ${basedir}
 
   won't work because of this. Too bad. So perhaps we should use
  java.io.tmpdir for now until we find a better way (if there is
 any).
 
  Christian
 
  [1]
  https://github.com/ocpsoft/rewrite/blob/master/test-
  harness/src/main/resources/arquillian.xml
 
 
  2014/1/7 Ron Smeral rsme...@redhat.com
 
Hi Christian,
 
  the test-utils is in the parent/code/pom.xml as a dependency, but
 
  then
 
   still, to get to the arquillian.xml file in the test-utils.jar, it
 
  would
 
   need to be unpacked using e.g. dependency:unpack plugin goal.
 
  Regarding basedir, because POMs are merged in Maven to form the
  Effective
  POM, the basedir property always points to the current project,
  regardless
  of the POM in which you reference it.
  For example, if -- as you suggest -- there's project P and C,
 where
 
  P
 
  is
 
   parent of C, and P contains root${basedir}/root, then for C, the
  ${root} will contain the base dir of C anyway, not that of P.
  The least hacky (but still ugly) way that comes to mind is to pass
 
  the
 
   property an absolute path from the shell, as in mvn clean test
  -Droot=$(pwd). The root property could have a default value of
  ${java.io.tmpdir}.
 
  Ron
 
 
  On 7.1.2014 07:51, Christian Kaltepoth wrote:
 
Hey Ron,
 
  I don't think we will have to copy arquillian.xml using the
  resources-plugin. If we add it to src/main/resources of the
 
  test-utils
 
   module, it will be on the test classpath for all

[jira] [Resolved] (DELTASPIKE-513) Transactional interceptor throws NPE for missing EntityManager

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth resolved DELTASPIKE-513.


Resolution: Fixed

 Transactional interceptor throws NPE for missing EntityManager
 --

 Key: DELTASPIKE-513
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-513
 Project: DeltaSpike
  Issue Type: Bug
  Components: JPA-Module
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
Priority: Minor
 Fix For: 0.6


 The {{@Transactional}} interceptor currently fails with a 
 {{NullPointerException}} if no {{EntityManager}} can be found for the 
 requested qualifier.
 {code}
 java.lang.NullPointerException
   at 
 org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.getTransaction(ResourceLocalTransactionStrategy.java:296)
   at 
 org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.rollbackAllTransactions(ResourceLocalTransactionStrategy.java:262)
   at 
 org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.execute(ResourceLocalTransactionStrategy.java:141)
   at 
 org.apache.deltaspike.jpa.impl.transaction.TransactionalInterceptor.executeInTransaction(TransactionalInterceptor.java:57)
 {code}
 Instead there should be an exception telling the user what exactly is wrong 
 so that it is easier to fix such an issue.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Optimizing the integration tests

[Christian Kaltepoth]

Hey Gerhard,

yeah, I wasn't aware that the Glassfish jobs have already been added. But
Wildfly is still missing.

Christian



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

 hi christian,

 the jenkins-jobs should be in place already.

 regards,
 gerhard



 2014/1/24 Christian Kaltepoth christ...@kaltepoth.de

  Hey all,
 
  I pushed out all the changes of the build-managed integration test
 Maven
  profiles which I suggested.
 
  You can now run the integration test suite against the different
 containers
  like this:
 
  $ mvn clean install -Ptomee-build-managed
  $ mvn clean install -Pjbossas-build-managed-7
  $ mvn clean install -Pwildfly-build-managed
  $ mvn clean install -Pglassfish-build-managed-3
  $ mvn clean install -Pglassfish-build-managed-4
 
  Each profiles will automatically download, unpack and configure the
  corresponding container. All TCP ports are changed so that they differ
 from
  this default ones. This way we should be able to run them on the CI
 server
  without any problems.
 
  Could anyone with the required permissions add corresponding jobs in
  Jenkins?
 
  Christian
 
 
 
 
  2014/1/11 Christian Kaltepoth christ...@kaltepoth.de
 
   Hey Ron,
  
   yeah, I also thought about using user.dir, but this could point to
 some
   weird locations depending on from where you start the build. So let's
 go
   with java.io.tmpdir for now.
  
   Christian
  
  
   2014/1/8 Ron Smeral rsme...@redhat.com
  
   Hey Christian,
  
   you're right, I haven't realized that. Also, if some module needed a
   custom arquillian conf, Arquillian reads a system property named
   arquillian.xml which defines the name of the configuration file.
  
   The last thing I can think of for the testsuite root is the Maven
   property user.dir - the working directory from which mvn was
 executed.
  
   Ron
  
  
   On 7.1.2014 17:20, Christian Kaltepoth wrote:
  
   Hey Ron,
  
   I don't think unpacking is necessary. If arquillian.xml is located in
   deltaspike/test-utils/src/main/resources, it will be on the classpath
   for
   all integration tests. That's basically the setup we are using for
   Rewrite
   since quite some time and it is working fine. See [1].
  
   I guess you are right regarding the merging of poms and that
 ${basedir}
   won't work because of this. Too bad. So perhaps we should use
   java.io.tmpdir for now until we find a better way (if there is any).
  
   Christian
  
   [1]
   https://github.com/ocpsoft/rewrite/blob/master/test-
   harness/src/main/resources/arquillian.xml
  
  
   2014/1/7 Ron Smeral rsme...@redhat.com
  
Hi Christian,
  
   the test-utils is in the parent/code/pom.xml as a dependency, but
 then
   still, to get to the arquillian.xml file in the test-utils.jar, it
  would
   need to be unpacked using e.g. dependency:unpack plugin goal.
  
   Regarding basedir, because POMs are merged in Maven to form the
   Effective
   POM, the basedir property always points to the current project,
   regardless
   of the POM in which you reference it.
   For example, if -- as you suggest -- there's project P and C, where
 P
  is
   parent of C, and P contains root${basedir}/root, then for C, the
   ${root} will contain the base dir of C anyway, not that of P.
   The least hacky (but still ugly) way that comes to mind is to pass
 the
   property an absolute path from the shell, as in mvn clean test
   -Droot=$(pwd). The root property could have a default value of
   ${java.io.tmpdir}.
  
   Ron
  
  
   On 7.1.2014 07:51, Christian Kaltepoth wrote:
  
Hey Ron,
  
   I don't think we will have to copy arquillian.xml using the
   resources-plugin. If we add it to src/main/resources of the
  test-utils
   module, it will be on the test classpath for all other modules. I
  think
   this should work fine.
  
   Regarding the testsuite root directory. I think we could use
 Maven's
   ${basedir} in the parent pom and store it in a system property.
   Thoughts?
  
   Christian
  
  
   2014/1/3 Ron Smeral rsme...@redhat.com
  
 Hi Christian,
  
   looking at the arquillian.xml files, they are 99% the same, the
 only
   one
   that actually differs (other than whitespace, comments and missing
   cdicontainer.version property) is the one in the data module,
   containing
   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

Re: Optimizing the integration tests

[Christian Kaltepoth]

Hey all,

I pushed out all the changes of the build-managed integration test Maven
profiles which I suggested.

You can now run the integration test suite against the different containers
like this:

$ mvn clean install -Ptomee-build-managed
$ mvn clean install -Pjbossas-build-managed-7
$ mvn clean install -Pwildfly-build-managed
$ mvn clean install -Pglassfish-build-managed-3
$ mvn clean install -Pglassfish-build-managed-4

Each profiles will automatically download, unpack and configure the
corresponding container. All TCP ports are changed so that they differ from
this default ones. This way we should be able to run them on the CI server
without any problems.

Could anyone with the required permissions add corresponding jobs in
Jenkins?

Christian




2014/1/11 Christian Kaltepoth christ...@kaltepoth.de

 Hey Ron,

 yeah, I also thought about using user.dir, but this could point to some
 weird locations depending on from where you start the build. So let's go
 with java.io.tmpdir for now.

 Christian


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

 Hey Christian,

 you're right, I haven't realized that. Also, if some module needed a
 custom arquillian conf, Arquillian reads a system property named
 arquillian.xml which defines the name of the configuration file.

 The last thing I can think of for the testsuite root is the Maven
 property user.dir - the working directory from which mvn was executed.

 Ron


 On 7.1.2014 17:20, Christian Kaltepoth wrote:

 Hey Ron,

 I don't think unpacking is necessary. If arquillian.xml is located in
 deltaspike/test-utils/src/main/resources, it will be on the classpath
 for
 all integration tests. That's basically the setup we are using for
 Rewrite
 since quite some time and it is working fine. See [1].

 I guess you are right regarding the merging of poms and that ${basedir}
 won't work because of this. Too bad. So perhaps we should use
 java.io.tmpdir for now until we find a better way (if there is any).

 Christian

 [1]
 https://github.com/ocpsoft/rewrite/blob/master/test-
 harness/src/main/resources/arquillian.xml


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

  Hi Christian,

 the test-utils is in the parent/code/pom.xml as a dependency, but then
 still, to get to the arquillian.xml file in the test-utils.jar, it would
 need to be unpacked using e.g. dependency:unpack plugin goal.

 Regarding basedir, because POMs are merged in Maven to form the
 Effective
 POM, the basedir property always points to the current project,
 regardless
 of the POM in which you reference it.
 For example, if -- as you suggest -- there's project P and C, where P is
 parent of C, and P contains root${basedir}/root, then for C, the
 ${root} will contain the base dir of C anyway, not that of P.
 The least hacky (but still ugly) way that comes to mind is to pass the
 property an absolute path from the shell, as in mvn clean test
 -Droot=$(pwd). The root property could have a default value of
 ${java.io.tmpdir}.

 Ron


 On 7.1.2014 07:51, Christian Kaltepoth wrote:

  Hey Ron,

 I don't think we will have to copy arquillian.xml using the
 resources-plugin. If we add it to src/main/resources of the test-utils
 module, it will be on the test classpath for all other modules. I think
 this should work fine.

 Regarding the testsuite root directory. I think we could use Maven's
 ${basedir} in the parent pom and store it in a system property.
 Thoughts?

 Christian


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

   Hi Christian,

 looking at the arquillian.xml files, they are 99% the same, the only
 one
 that actually differs (other than whitespace, comments and missing
 cdicontainer.version property) is the one in the data module,
 containing
 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

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

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth resolved DELTASPIKE-118.


Resolution: Fixed

Works fine. AS7 now uses an offset of 4 (HTTP - 48080), Wildfly uses an 
offset of 5 (HTTP - 58080). Of cause all other ports are also affected by 
this offset. So there should be no problem when running the build-managed 
profiles on Jenkins.

 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: Christian Kaltepoth
 Fix For: 0.6


 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 was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (DELTASPIKE-497) Create build-managed test profiles for Glassfish

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth resolved DELTASPIKE-497.


   Resolution: Fixed
Fix Version/s: 0.6

 Create build-managed test profiles for Glassfish
 

 Key: DELTASPIKE-497
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-497
 Project: DeltaSpike
  Issue Type: Task
  Components: Tests
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
Priority: Minor
 Fix For: 0.6


 We should create build-managed profiles for Glassfish 3.1 and 4.0



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth reassigned DELTASPIKE-118:
--

Assignee: Christian Kaltepoth  (was: Mark Struberg)

We could use the {{jboss.socket.binding.port-offset}} system property for this. 
I'll give it a try.

 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: Christian Kaltepoth
 Fix For: 0.6


 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 was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (DELTASPIKE-498) Deltaspike 0.6-SNAPSHOT failing on JBoss 7 and Wildfly

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth commented on DELTASPIKE-498:


Looks like there is some other problem with your deployment:

{code}
Caused by: [...] JBAS018037: Failed to process WEB-INF/lib: 
[...]/geniidm.war/WEB-INF/lib/deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar
{code}

And further down the stacktrace:

{code}
Caused by: java.util.zip.ZipException: error in opening zip file 
at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.7.0_45] 
at java.util.zip.ZipFile.init(ZipFile.java:215) [rt.jar:1.7.0_45] 
{code}

Maybe the file is damaged? Try to delete it and download it again.

 Deltaspike 0.6-SNAPSHOT failing on JBoss 7 and Wildfly
 --

 Key: DELTASPIKE-498
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-498
 Project: DeltaSpike
  Issue Type: Bug
  Components: Build
Affects Versions: 0.6
 Environment: Ubuntu , Eclipse IDE(Kepler) , Java 7 
Reporter: Paa Kojo Konduah Amos

 I set out to try the Data Module of Deltaspike. So i have the following for 
 example;
 @Repository
 public interface SomeInterface extends EntityRepositorySomeEntity, Long{}
 Now according to the online documentation, it reads ,The implementation of 
 the method is done automatically by the CDI extension.
 So, i try to inject this SomeInterface into a controller, thinking the 
 implementation is done automatically. Eclipse warns that (No bean is eligible 
 for injection to the injection point [JSR-299 §5.2.1]).
 So i migrate from 0.5 to 0.6 thinking that would be resolved. Still i get 
 that and when i try to deploy in JBoss 7 or Wild fly, please find below the 
 error stack.
 05:33:18,226 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) 
 JBAS015876: Starting deployment of geniidm.war
 05:33:18,685 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) 
 MSC1: Failed to start service 
 jboss.deployment.unit.geniidm.war.STRUCTURE: 
 org.jboss.msc.service.StartException in service 
 jboss.deployment.unit.geniidm.war.STRUCTURE: Failed to process phase 
 STRUCTURE of deployment geniidm.war
   at 
 org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119)
  [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
   at 
 org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
  [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
   at 
 org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
  [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  [rt.jar:1.7.0_45]
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  [rt.jar:1.7.0_45]
   at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
 Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: 
 org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: 
 Failed to process WEB-INF/lib: /home/pkkamos/Application 
 Servers/Brontes-Master/standalone/deployments/geniidm.war/WEB-INF/lib/deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar
   at 
 org.jboss.as.web.deployment.WarStructureDeploymentProcessor.deploy(WarStructureDeploymentProcessor.java:120)
   at 
 org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113)
  [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
   ... 5 more
 Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: 
 JBAS018037: Failed to process WEB-INF/lib: /home/pkkamos/Application 
 Servers/Brontes-Master/standalone/deployments/geniidm.war/WEB-INF/lib/deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar
   at 
 org.jboss.as.web.deployment.WarStructureDeploymentProcessor.createWebInfLibResources(WarStructureDeploymentProcessor.java:175)
   at 
 org.jboss.as.web.deployment.WarStructureDeploymentProcessor.createResourceRoots(WarStructureDeploymentProcessor.java:153)
   at 
 org.jboss.as.web.deployment.WarStructureDeploymentProcessor.deploy(WarStructureDeploymentProcessor.java:114)
   ... 6 more
 Caused by: java.util.zip.ZipException: error in opening zip file
   at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.7.0_45]
   at java.util.zip.ZipFile.init(ZipFile.java:215) [rt.jar:1.7.0_45]
   at java.util.zip.ZipFile.init(ZipFile.java:145) [rt.jar:1.7.0_45]
   at java.util.jar.JarFile.init(JarFile.java:153) [rt.jar:1.7.0_45]
   at java.util.jar.JarFile.init(JarFile.java:117) [rt.jar:1.7.0_45]
   at org.jboss.vfs.spi.JavaZipFileSystem.init(JavaZipFileSystem.java:97)
   at org.jboss.vfs.spi.JavaZipFileSystem.init

Re: [VOTE] Get rid of @Web in the servlet module

[Christian Kaltepoth]

-1
I think we should use a qualifier for producers of types that aren't ours
to prevent conflicts.

Christian


2014/1/8 Mark Struberg strub...@yahoo.de

 -1 (non blocking of course).
 Because there are already other producers for some of the resources in
 question and the vetoing is really an ugly and error prone workaround.

 LieGrue,
 strub





 
  From: Gerhard Petracek gerhard.petra...@gmail.com
 To: dev@deltaspike.apache.org
 Sent: Wednesday, 8 January 2014, 0:30
 Subject: Re: [VOTE] Get rid of @Web in the servlet module
 
 
 +1 since we haven't seen a technical reason which would block this
 simplification
 
 regards,
 gerhard
 
 
 
 
 2014/1/7 Romain Manni-Bucau rmannibu...@gmail.com
 
  +0
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
 
  2014/1/7 Thomas Andraschko andraschko.tho...@gmail.com:
   Hi all,
  
   based on the discusstion in Servlet Module - Do we really need
 @Web? so
   far, I'd like to call a vote.
  
   +1 get rid of @Web
   +0 no opinion
   -1 keep it
  
   Please vote.
  
   Regards,
   Thomas
 
 
 
 




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

[jira] [Resolved] (DELTASPIKE-496) Merge arquillian.xml files into a single one

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth resolved DELTASPIKE-496.


Resolution: Fixed

 Merge arquillian.xml files into a single one
 

 Key: DELTASPIKE-496
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-496
 Project: DeltaSpike
  Issue Type: Task
  Components: Tests
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
Priority: Minor

 Currently we have 9 different arquillian.xml files. We should merge them into 
 a single one and put it into the test-utils module. 
 Discussion: 
 http://s.apache.org/40D



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Optimizing the integration tests

[Christian Kaltepoth]

Hey Ron,

I don't think unpacking is necessary. If arquillian.xml is located in
deltaspike/test-utils/src/main/resources, it will be on the classpath for
all integration tests. That's basically the setup we are using for Rewrite
since quite some time and it is working fine. See [1].

I guess you are right regarding the merging of poms and that ${basedir}
won't work because of this. Too bad. So perhaps we should use
java.io.tmpdir for now until we find a better way (if there is any).

Christian

[1]
https://github.com/ocpsoft/rewrite/blob/master/test-harness/src/main/resources/arquillian.xml


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

 Hi Christian,

 the test-utils is in the parent/code/pom.xml as a dependency, but then
 still, to get to the arquillian.xml file in the test-utils.jar, it would
 need to be unpacked using e.g. dependency:unpack plugin goal.

 Regarding basedir, because POMs are merged in Maven to form the Effective
 POM, the basedir property always points to the current project, regardless
 of the POM in which you reference it.
 For example, if -- as you suggest -- there's project P and C, where P is
 parent of C, and P contains root${basedir}/root, then for C, the
 ${root} will contain the base dir of C anyway, not that of P.
 The least hacky (but still ugly) way that comes to mind is to pass the
 property an absolute path from the shell, as in mvn clean test
 -Droot=$(pwd). The root property could have a default value of
 ${java.io.tmpdir}.

 Ron


 On 7.1.2014 07:51, Christian Kaltepoth wrote:

 Hey Ron,

 I don't think we will have to copy arquillian.xml using the
 resources-plugin. If we add it to src/main/resources of the test-utils
 module, it will be on the test classpath for all other modules. I think
 this should work fine.

 Regarding the testsuite root directory. I think we could use Maven's
 ${basedir} in the parent pom and store it in a system property. Thoughts?

 Christian


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

  Hi Christian,

 looking at the arquillian.xml files, they are 99% the same, the only one
 that actually differs (other than whitespace, comments and missing
 cdicontainer.version property) is the one in the data module, containing
 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

Re: Parent vs BOM

[Christian Kaltepoth]

Hey John,

thanks for the clarification. I just was a little bit confused. :)

In this case +1 for moving the bom up. I'm not sure if it will be used a
lot by end users but it doesn't harm to have it and it will reduce the size
of our parent pom.

Christian



2014/1/6 John D. Ament john.d.am...@gmail.com

 Christian,

 Sorry missed your reply!

 Yes, you're technically right, what's here is actually the BOM based
 on standard def:
 https://github.com/apache/deltaspike/blob/master/deltaspike/dist/pom.xml
 so really what's in the bom folder right now isn't useful.

 So basically, restating what I said previously but pointing to this pom
 file.

 John

 On Tue, Dec 24, 2013 at 3:50 AM, Christian Kaltepoth
 christ...@kaltepoth.de wrote:
  Hey John,
 
  just to clear up the situation a bit. AFAIK the bom artifact
  (deltaspike/dist/bom/pom.xml) isn't actually a real bom as it defines all
  the modules as direct dependencies which is more a depchain. The real
 pom
  is the parent (deltaspike/dist/pom.xml) as it defines the versions of the
  modules in a dependencyManagement section, correct?
 
  Christian
 
 
 
  2013/12/23 John D. Ament john.d.am...@gmail.com
 
  Romain,
 
  Right.  My hope is that internally we can list the cross module
  dependencies in one place.  If we're going to prep docs on how a new
  dev can bring deltaspike to their project, using a bom is a simple
  tool.
 
  On Mon, Dec 23, 2013 at 1:06 AM, Romain Manni-Bucau
  rmannibu...@gmail.com wrote:
   +-0 while deltaspike doesnt use itself the bom (they lead too often to
  dep
   issues in practise)
   Le 23 déc. 2013 02:09, John D. Ament john.d.am...@gmail.com a
 écrit
  :
  
   Hi all
  
   Recently for the binary distribution task, I added a bom.  I added
   this because the parent pom includes our dependencies, as well as our
   developer list.  For someone importing the project to build against,
 I
   figured this was a bad idea (we would show as developers in that
   imported pom).  However, this ended up adding some double entry.
  
   So I'd like to propose moving this bom up a few directories, and
 leave
   this up as the only place to have the modules listed.  Importing this
   one into our parent.
  
   WDYT?
  
   John
  
 
 
 
 
  --
  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

Re: Optimizing the integration tests

[Christian Kaltepoth]

Hey Ron,

I don't think we will have to copy arquillian.xml using the
resources-plugin. If we add it to src/main/resources of the test-utils
module, it will be on the test classpath for all other modules. I think
this should work fine.

Regarding the testsuite root directory. I think we could use Maven's
${basedir} in the parent pom and store it in a system property. Thoughts?

Christian


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

 Hi Christian,

 looking at the arquillian.xml files, they are 99% the same, the only one
 that actually differs (other than whitespace, comments and missing
 cdicontainer.version property) is the one in the data module, containing 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




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

[jira] [Created] (DELTASPIKE-496) Merge arquillian.xml files into a single one

[Christian Kaltepoth (JIRA)]

Christian Kaltepoth created DELTASPIKE-496:
--

 Summary: Merge arquillian.xml files into a single one
 Key: DELTASPIKE-496
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-496
 Project: DeltaSpike
  Issue Type: Task
  Components: Tests
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Priority: Minor


Currently we have 9 different arquillian.xml files. We should merge them into a 
single one and put it into the test-utils module. 

Discussion: 
http://s.apache.org/40D



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (DELTASPIKE-481) Use unique archive names in Servlet module integration tests

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth resolved DELTASPIKE-481.


Resolution: Fixed

 Use unique archive names in Servlet module integration tests
 

 Key: DELTASPIKE-481
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-481
 Project: DeltaSpike
  Issue Type: Task
  Components: Servlet-Module
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
Priority: Minor

 As pointed out by [~gpetracek] in DELTASPIKE-399, integration test archives 
 should have unique names to prevent problems with Arquillian's 
 deploymentExportPath.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (DELTASPIKE-481) Use unique archive names in Servlet module integration tests

[Christian Kaltepoth (JIRA)]

Christian Kaltepoth created DELTASPIKE-481:
--

 Summary: Use unique archive names in Servlet module integration 
tests
 Key: DELTASPIKE-481
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-481
 Project: DeltaSpike
  Issue Type: Task
  Components: Servlet-Module
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
Priority: Minor


As pointed out by [~gpetracek] in DELTASPIKE-399, integration test archives 
should have unique names to prevent problems with Arquillian's 
{{deploymentExportPath}}.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (DELTASPIKE-399) Incorporate Solder's ResourceLoader features into DeltaSpike

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth commented on DELTASPIKE-399:


@ [~struberg]: I agree with John that injecting a Properties object is _not_ 
the main usecase of this feature. The idea is to be able to inject all kind of 
stuff like XML documents, images, other binary data, etc. But I agree that 
injecting an InputStream may be problematic. Either we tell users to inject 
InstanceInputStream instead or we create some class that allows to open the 
InputStream several times.

 Incorporate Solder's ResourceLoader features into DeltaSpike
 

 Key: DELTASPIKE-399
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-399
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Core
Affects Versions: 0.4
Reporter: Aaron Siri
Assignee: John D. Ament
Priority: Minor
 Fix For: 0.6

 Attachments: DELTASPIKE-399_ambiguous_file_check.patch, 
 DELTASPIKE-399_merged_interface.patch


 Seam 3's Solder module had some nice resource loading functionality within 
 the org.jboss.solder.resourceLoader packages.  With it you could do the 
 following:
 // Load a properties file
 @Inject @Resource(app.properties)
 private Properties appProperties;
 or:
 @Inject
 private ResourceProvider resourceProvider
 public Properties getHostProperties() {
String hostname = java.net.InetAddress.getLocalHost().getHostName();
return resourceProvider.loadPropertiesBundle(hostname + .properties);
 }



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (DELTASPIKE-479) add tests with simple ear-packaging

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth commented on DELTASPIKE-479:


@ [~gpetracek]:

I totally agree with you that we need more tests that verify behavior in EAR 
packaging scenarios.

But I think that your EAR test doesn't cover the most interesting case. You are 
basically just adding the WAR from the standard test into an EAR file. I think 
it would be more useful to test the skinny WAR packaging scenario which means 
that all the libraries aren't in {{/WEB-INF/lib}} but in the EAR's {{lib}} 
directory. There seem to be some class loading related problems in this case. 
See DELTASPIKE-362, DELTASPIKE-386, etc. for examples.

Perhaps we could look for a way to simplify creating tests that run both 
packaging scenarios? Perhaps we could automatically create an EAR with a skinny 
WAR from a Shrinkwrap WebArchive? It would be great to have a very simply way 
to create such tests without the need to create three classes and manually 
repackaging.

Thoughts?

 add tests with simple ear-packaging
 ---

 Key: DELTASPIKE-479
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-479
 Project: DeltaSpike
  Issue Type: Test
  Components: Tests
Affects Versions: 0.5
Reporter: Gerhard Petracek
 Fix For: 0.6


 for all tests with war-file deployments, we should also add a test which 
 packages the war-file into an ear-file. that's the minimum we should 
 safeguard with our tests.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (DELTASPIKE-399) Incorporate Solder's ResourceLoader features into DeltaSpike

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth commented on DELTASPIKE-399:


@ [~johnament]: 

A) Regarding the Servlet module: I think it would make sense to provide an 
{{ExternalResourceProvider}} that uses {{ServletContext.getResource()}}. This 
is very useful if you want to load resources that are packed in a WAR. Say you 
want to load {{web.xml}} for whatever reason. You could just use:

{code}
@ExternalResource(storage=web, name=WEB-INF/web.xml) 
{code}

B) I like Gerhard's idea of simply inferring the format of a Properties 
resource from the file name. IMHO {{.properties}} should be the default as most 
people are using this format. So we could simply use 
{{Properties.loadFromXML()}} only if the name of the resource ends with 
{{.xml}}. I think this is a nice example for using convention over 
configuration.

C) I agree with John that using a simple string as an location identifier is 
fine:

{code}
@ExternalResource(storage=classpath, name=myapp.properties) 
{code}

This way uses can provide custom {{ExternalResourceProvider}} implementations 
very easily. But we could provider some constants for the storage types we 
provide out of the box:

{code}
@ExternalResource(storage=StorageType.CLASSPATH, name=myapp.properties) 
{code}


 Incorporate Solder's ResourceLoader features into DeltaSpike
 

 Key: DELTASPIKE-399
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-399
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Core
Affects Versions: 0.4
Reporter: Aaron Siri
Assignee: John D. Ament
Priority: Minor
 Fix For: 0.6


 Seam 3's Solder module had some nice resource loading functionality within 
 the org.jboss.solder.resourceLoader packages.  With it you could do the 
 following:
 // Load a properties file
 @Inject @Resource(app.properties)
 private Properties appProperties;
 or:
 @Inject
 private ResourceProvider resourceProvider
 public Properties getHostProperties() {
String hostname = java.net.InetAddress.getLocalHost().getHostName();
return resourceProvider.loadPropertiesBundle(hostname + .properties);
 }



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (DELTASPIKE-453) Provide @Eager for ApplicationScoped beans

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth commented on DELTASPIKE-453:


@ [~gpetracek]: I don't see a way to backport @Initialized without OWB/Weld 
specific code which may be problematic I think.

 Provide @Eager for ApplicationScoped beans
 --

 Key: DELTASPIKE-453
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-453
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Core
Reporter: Thomas Andraschko
 Attachments: 453.patch






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Literal package

[Christian Kaltepoth]

Hey John,

basically I agree with you. Placing literals in the same package as the
qualifier makes things much more clear.

However, up to now we followed the literal sub-package pattern everywhere
(AFAIK). I also used it in the Servlet module [1] because I saw that other
modules did it this way. So I would prefer to be consistent and keep using
the literal package like we do it in other places.

Christian


[1]
https://github.com/apache/deltaspike/tree/master/deltaspike/modules/servlet/api/src/main/java/org/apache/deltaspike/servlet/api



2013/12/18 John D. Ament john.d.am...@gmail.com

 Hi all,

 Any reason we have a package just for literals?

 I guess it makes sense for the repackaged core CDI literals, but for
 literals for our own qualifiers, why not just package them in the same
 package as the qualifier?  IMHO it makes it easier to understand where
 they came from.

 John




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

[jira] [Commented] (DELTASPIKE-399) Incorporate Solder's ResourceLoader features into DeltaSpike

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth commented on DELTASPIKE-399:


Hey John,

first of all, thanks for starting to work on this. I really think this will be 
a very useful feature.

I just had a quick look at the code and want to give some feedback.

#1 Regarding ExternalResourceProviderComparator. As we now have some APIs that 
use some kind of priority/ordinal for ordering, we should think about creating 
an interface for this. This way we could build a single comparator that would 
work for all the classes that implement this interface. I'm thinking about 
something like [1]. Thoughts?

#2 To be honest, I'm not quite happy with the fact that the code currently 
tries all ExternalResourceProviders to find a matching resource. As Gerhard 
already pointed out, this may lead to weird effects if more than one provider 
returns a result. I was thinking if we could instead use some kind of prefix in 
the resource name to identifier which provider to use. Something like:

{code}
@Inject
@ExternalResource(classpath:myconfig.properties)
private InputStream inputStream;
{code}

Spring uses a similar concept. I think this would make sense because the users 
typically know from which place the resource should be loaded. So we should 
allow them to specify it. I think this will be easy to implement if the 
provider API supports this concept. 

#3 We could think about adding an ExternalResourceProvider for web resources 
which uses ServletContext.getResource() and add it to the Servlet module.
 

[1] 
https://github.com/togglz/togglz/blob/master/core/src/main/java/org/togglz/core/util/Weighted.java

 Incorporate Solder's ResourceLoader features into DeltaSpike
 

 Key: DELTASPIKE-399
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-399
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Core
Affects Versions: 0.4
Reporter: Aaron Siri
Assignee: John D. Ament
Priority: Minor
 Fix For: 0.6


 Seam 3's Solder module had some nice resource loading functionality within 
 the org.jboss.solder.resourceLoader packages.  With it you could do the 
 following:
 // Load a properties file
 @Inject @Resource(app.properties)
 private Properties appProperties;
 or:
 @Inject
 private ResourceProvider resourceProvider
 public Properties getHostProperties() {
String hostname = java.net.InetAddress.getLocalHost().getHostName();
return resourceProvider.loadPropertiesBundle(hostname + .properties);
 }



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Re: Binary distribution

[Christian Kaltepoth]

Hey John,

great work! The archive looks good. Seems like it contains everything users
may need. :)

One minor thing: I updated the version of the maven-assembly-plugin to work
around an issue with directory permissions in ZIP archives. See [1] for
details.

Christian

[1] http://jira.codehaus.org/browse/MASSEMBLY-449



2013/12/15 John D. Ament john.d.am...@gmail.com

 Ok, so the new profile is in.  I'm not sure at what point we want to
 change it, but you can now run mvn clean install -Pdistribution to get
 the zip and tar.gz files created.

 I guess you can update Jenkins Mark?

 On Mon, Dec 9, 2013 at 4:44 PM, Mark Struberg strub...@yahoo.de wrote:
 
 
  Hi John!
 
 
  binaries would be cool. We should run them in a profiles.
 
  We can tweak the maven-release-plugin section to activate that profile
 during release.
 
  cdi-ctrl is an own part because it's basically not based on
 deltaspike-core, but something really distinct. The modules are kind of EE
 extensions modules for various specs and features.
 
 
  module.xml is fine for me. This is only a few bytes and does not
 interfere with other containers and features.
 
 
  LieGrue,
  strub
 
 
  From: John D. Ament john.d.am...@gmail.com
 To: dev@deltaspike.apache.org
 Sent: Sunday, 8 December 2013, 22:55
 Subject: Binary distribution
 
 
 Hi all
 
 I added support for zip and tar.gz distributions in DeltaSpike here:
 
 https://github.com/johnament/deltaspike/tree/DELTASPIKE-263/deltaspike/dist
 
 One execution question - when should we generate dist? Should we use a
 distinct profile to execute it so that it's not always running?
 
 A couple other not fully related questions
 
 How come cdi ctrl is *not* a module?  It seems like it should be, but
 it's kind of standalone.
 
 Another question, I'd like to setup DeltaSpike to run as a set of
 JBoss modules.  Any thoughts (plus or minus) to doing this?  If so,
 I'd like to include module.xml file in the distributions.
 
 John
 
 
 




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

[jira] [Resolved] (DELTASPIKE-464) unify naming (Broadcaster vs Emitter)

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth resolved DELTASPIKE-464.


Resolution: Fixed

 unify naming (Broadcaster vs Emitter)
 -

 Key: DELTASPIKE-464
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-464
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Servlet-Module
Affects Versions: 0.5
Reporter: Gerhard Petracek
Assignee: Christian Kaltepoth
 Fix For: 0.6


 currently we have the term Broadcaster in one of our apis and several 
 implementations. however, we also have 
 org.apache.deltaspike.servlet.impl.event.EventEmitter



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Commented] (DELTASPIKE-453) Provide @Eager for ApplicationScoped beans

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth commented on DELTASPIKE-453:


I agree that having @Eager would be _very_ useful in many scenarios. Especially 
in non-Servlet environments.

I think we have three options here:

# Find an alternative way to implement this feature which is spec compliment
# Use {{AfterDeploymentValidation}} as suggested and add a corresponding 
warning which tells the user that this feature _may_ not work as expected in 
some scenarios.
# Don't implement it at all.

Of cause I would prefer option 1, but I would also be fine with 2.

 Provide @Eager for ApplicationScoped beans
 --

 Key: DELTASPIKE-453
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-453
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Core
Reporter: Thomas Andraschko
 Attachments: 453.patch






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

Re: [DISCUSS] unit-test cdi-control

[Christian Kaltepoth]

I really like this. So +1 for adding it. Great work Gerhard. :)

And I agree with Mark that we should also support TestNG later. So the
module name should indicate that it is JUnit specific.

Christian


2013/12/2 Gerhard Petracek gerhard.petra...@gmail.com

 hi @ all,

 please have a look at [1].

 it's just a first (and quick) draft based on major use-cases.
 however, it's working already and the api/spi is minimal - we can think
 about adding it to deltaspike.
 (it's already prepared for additional use-cases, however, for sure we can
 simplify/change/improve any part of it easily.)

 regards,
 gerhard

 [1]
 http://os890.blogspot.com/2013/12/add-on-cdi-tests-with-deltaspike-05.html




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

[jira] [Commented] (DELTASPIKE-453) Provide @Eager for ApplicationScoped beans

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth commented on DELTASPIKE-453:


Yeah, sorry, I forgot that we already discussed this some time ago. 

Here is Mark's statement on this:

http://mail-archives.apache.org/mod_mbox/deltaspike-users/201307.mbox/%3c1373958405.16520.yahoomail...@web28905.mail.ir2.yahoo.com%3E

 Provide @Eager for ApplicationScoped beans
 --

 Key: DELTASPIKE-453
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-453
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Core
Reporter: Thomas Andraschko
 Attachments: 453.patch






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

[jira] [Closed] (DELTASPIKE-389) Create documentation for the servlet module

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth closed DELTASPIKE-389.
--

Resolution: Fixed

A first version of the documentation is finished:

http://deltaspike.staging.apache.org/servlet.html

 Create documentation for the servlet module
 ---

 Key: DELTASPIKE-389
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-389
 Project: DeltaSpike
  Issue Type: Task
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
Priority: Minor
 Fix For: 0.6


 We need some documentation for the features of the servlet module

--
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-399) Incorporate Solder's ResourceLoader features into DeltaSpike

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth commented on DELTASPIKE-399:


I agree with Gerhard that we should avoid name clashes. What about 
@ClasspathResource?

What do you think about extending what Solder provided by supporting injection 
of other types than URL and InputStream? We could provide an SPI to allow users 
to extend the types that are supported.

Imagine this example. A user wants to load a FreeMarker template from the 
classpath. Wouldn't it be nice to be able to do something like this:

@Inject
@ClasspathResource(name=template.ftl, loader=TemplateLoader.class)
private Template myTemplate;

Where TemplateLoader is an implementation of an interface like this:

public interface ResourceLoaderT {
  T load(URL url);
}

Actually I don't think the user will have to explicitly name the loader to use. 
This could be done automatically.

Thoughts?

 Incorporate Solder's ResourceLoader features into DeltaSpike
 

 Key: DELTASPIKE-399
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-399
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Core
Affects Versions: 0.4
Reporter: Aaron Siri
Assignee: John D. Ament
Priority: Minor
 Fix For: 0.6


 Seam 3's Solder module had some nice resource loading functionality within 
 the org.jboss.solder.resourceLoader packages.  With it you could do the 
 following:
 // Load a properties file
 @Inject @Resource(app.properties)
 private Properties appProperties;
 or:
 @Inject
 private ResourceProvider resourceProvider
 public Properties getHostProperties() {
String hostname = java.net.InetAddress.getLocalHost().getHostName();
return resourceProvider.loadPropertiesBundle(hostname + .properties);
 }

--
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] [Closed] (DELTASPIKE-377) Supporting injection of basic servlet objects

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth closed DELTASPIKE-377.
--

Resolution: Fixed

 Supporting injection of basic servlet objects
 -

 Key: DELTASPIKE-377
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-377
 Project: DeltaSpike
  Issue Type: New Feature
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
 Fix For: 0.5


 The servlet module should support injection of the following servlet objects:
 * ServletRequest / HttpServletRequest
 * ServletResponse / HttpServletResponse
 * HttpSession
 * ServletContext
 We must use a special qualifier because CDI 1.1 provides this out of the box.

--
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] [Closed] (DELTASPIKE-376) Propagation of basic servlet events to the CDI event bus

[Christian Kaltepoth (JIRA)]

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

Christian Kaltepoth closed DELTASPIKE-376.
--

Resolution: Fixed

 Propagation of basic servlet events to the CDI event bus
 

 Key: DELTASPIKE-376
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-376
 Project: DeltaSpike
  Issue Type: New Feature
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
 Fix For: 0.5


 The servlet module should send events when the following servlet objects are 
 created and/or destroyed:
 * HttpServletRequest
 * HttpServletResponse
 * HttpSession
 * ServletContext

--
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] [Created] (DELTASPIKE-389) Create documentation for the servlet module

[Christian Kaltepoth (JIRA)]

Christian Kaltepoth created DELTASPIKE-389:
--

 Summary: Create documentation for the servlet module
 Key: DELTASPIKE-389
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-389
 Project: DeltaSpike
  Issue Type: Task
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
Priority: Minor
 Fix For: 0.5


We need some documentation for the features of the servlet module

--
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

Servlet module prototype

[Christian Kaltepoth]

Hey all,

I spent some time working on a first version of the servlet module. All the
basic features are finished now and therefore I think its time to ask for
some feedback.

I pushed the code to the servlet branch on my github repo:

https://github.com/chkal/deltaspike/tree/servlet

The servlet module provides two major features:

 * Injection of servlet various objects
 * Servlet lifecycle events

The producers are using the qualifier @Web to avoid conflicts with CDI 1.1.
We could discuss whether some other name for the qualifier fits better.

See the following classes from the tests to get an idea of what can be
injected:

https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/producer/ServletObjectInjectionBean.java

https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/producer/ServletContextInjectionTest.java

The lifecycle events are fired using the qualifiers @Initialized or
@Destroyed just like in Seam Solder. I also added the @Web qualifier to all
events, but we could discuss whether this is really necessary.

The following classes show which events can be observed:

https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/event/request/RequestResponseEventsObserver.java

https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/event/session/SessionEventsObserver.java

https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/event/context/ServletContextEventsObserver.java

One thing that I'm not quite happy with is the way the ServletContext
injection works. I'm currently using a map that stores the ServletContext
for each context class loader. IMHO this is better than using
HttpServletRequest.getServletContext() as it also works for threads outside
of a request (like schedulers for example). I also wanted to avoid using
the CDI application scope for storing the ServletContext to avoid problems
regarding different implementations of the scope in regard to EAR
packaging. I would be very interested in hearing your thoughts on this. :)

One other thing. As I currently don't use any Servlet 3.0 features, the
module depends on the Servlet 2.5 API. Do you think it makes sense to still
support Servlet 2.5 or should we require at least Servlet 3.0?

Looking forward to your feedback. Especially I would like to know if you
think that the code should be merged into the upstream repository. :)

Christian


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

Re: Servlet module

[Christian Kaltepoth]

Hey John,

I'm almost finished with the stuff I wanted to get in for a first version.
What I got so far is propagation of servlet events for creation/destruction
of request, response, session and servlet context. And also injection of
request, response and session. What I'm currently finishing is the
injection of the servlet context, which is a bit tricky.

I think I'll be able to finish it in 3-4 days and push it out to github so
everyone cat give feedback.

I'll create a few JIRA issues for the stuff that is already implemented.
Feel free to add anything you think that is missing.

Christian


2013/6/1 John D. Ament john.d.am...@gmail.com

 Hey Christian,

 Just wondering how far you got with this.  Since 0.5 is now starting up
 maybe we can start entering JIRAs for the features?


 On Tue, May 14, 2013 at 4:05 AM, Christian Kaltepoth 
 christ...@kaltepoth.de
  wrote:

  Sure, as I already wrote I would start in a separate branch on github and
  merge later after 0.4 is out.
 
 
  2013/5/14 Mark Struberg strub...@yahoo.de
 
   +1. Could you please start working on it in a branch?
   I really like to release 0.4 sonish (maybe end of this week?)
   After that we could go for it in master.
  
   LieGrue,
   strub
  
  
  
  
   - Original Message -
From: Jason Porter lightguard...@gmail.com
To: deltaspike-...@incubator.apache.org 
   deltaspike-...@incubator.apache.org
Cc:
Sent: Monday, 13 May 2013, 18:35
Subject: Re: Servlet module
   
I see no reason not to. Just keep rebasing (if you're working in a
   separate
module there shouldn't be any conflicts) until we're able to start
 work
on
0.5.
   
   
On Mon, May 13, 2013 at 10:16 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
   
 Since the module is light +1
 Le 13 mai 2013 18:11, John D. Ament
john.d.am...@gmail.com a écrit :
   
  +1.  This is actually one thing I need to finish porting an app
  from
 seam3
  to DS.  If you want help doing it let me know.
 
 
  On Mon, May 13, 2013 at 12:03 PM, Christian Kaltepoth 
  christ...@kaltepoth.de wrote:
 
   Hey all,
  
   as I already discussed with Mark and Arne two weeks ago, I'm
really
   interested in working on the servlet module for DeltaSpike.
 This
topic
  was
   discussed several times on the list (see [1], [2]) and I think
there
 was
  an
   agreement to target this for 0.5. Although 0.4 hasn't been
released
 yet,
  I
   would love to spend some time hacking on this. :)
  
   In my opinion the most important features for the module would
be:
  
  - Producers for servlet objects like the HttpServletRequest,
  ServletContext, etc. As this will be part of CDI 1.1, the
producer
   should
  use a custom qualifier.
  - Bridging of the servlet lifecycle events to the CDI event
bus.
  
   I think these are the most important features which are
 required
for
 many
   real world applications.
  
   I'll start working on this on a separate branch on my GitHub
repo. This
  way
   I can prototype the module and then ask for your feedback
 before
 merging
  it
   at a later point in time.
  
   WDYT? Any comments or ideas? :)
  
   Christian
  
  
   [1]
  
  
 
   
   
  
 
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/seam-servlet-stuff-to-deltaspike-td4653869.html
   [2]
  
  
 
   
   
  
 
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Servlet-module-td4654725.html
  
   --
   Christian Kaltepoth
   Blog: http://blog.kaltepoth.de/
   Twitter: http://twitter.com/chkal
   GitHub: https://github.com/chkal
  
 
   
   
   
   
--
Jason Porter
http://en.gravatar.com/lightguardjp
   
  
 
 
 
  --
  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

[jira] [Created] (DELTASPIKE-376) Propagation of basic servlet events to the CDI event bus

[Christian Kaltepoth (JIRA)]

Christian Kaltepoth created DELTASPIKE-376:
--

 Summary: Propagation of basic servlet events to the CDI event bus
 Key: DELTASPIKE-376
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-376
 Project: DeltaSpike
  Issue Type: New Feature
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
 Fix For: 0.5


The servlet module should send events when the following servlet objects are 
created and/or destroyed:

* HttpServletRequest
* HttpServletResponse
* HttpSession
* ServletContext

--
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: Determining when to port functionality

[Christian Kaltepoth]

Just a small note regarding Deactivatable. AFAIK you can use it for any
class by manually implementing checks like this:

if( ClassDeactivationUtils.isActivated( this.getClass() ) ) {
  // do whatever the class is responsible for
}




2013/6/2 John D. Ament john.d.am...@gmail.com

 Mark,

 I think Deactivatable only works if you're using some kind of CDI extension
 (e.g. check whether or not the extension should install or not).  For
 something like bean val, you need to replace the constraint validator
 factory w/ a custom CDI enabled one; so it becomes simply configuring
 validator to point to a custom one.  So while Deactivatable is preferred, I
 don't think we can require it being used in all cases.

 John


 On Sun, Jun 2, 2013 at 11:06 AM, Mark Struberg strub...@yahoo.de wrote:

  For deactivating features we have the Deactivatable interface + config.
 
 
  LieGrue,
  strub
 
 
 
 
  - Original Message -
   From: John D. Ament john.d.am...@gmail.com
   To: dev@deltaspike.apache.org
   Cc:
   Sent: Sunday, 2 June 2013, 17:02
   Subject: Determining when to port functionality
  
   All
  
   Based on the bean validation thread, I figured I'd start this one off
 so
  we
   can determine when it makes sense to port functionality included in
 later
   EE specs to be added to DeltaSpike.
  
   For one, I think we should only consider this when it's functionality
  that
   has been added to a spec, not for functionality that might be added to
 a
   spec.  I also think that it must be a must have that this functionality
  be
   optional - whether it's a separate module or requires activation; so
 that
   if someone is using the new spec they don't get burdened with the DS
   implementation being in the middle.
  
   Second, I think we need to consider whether CODI or Seam3 provided this
   functionality.  Ultimately we want to get people off of these stacks
 and
  on
   to DeltaSpike, It's easier to drop in a replacement library than it is
 to
   drop in a replacement EE spec.
  
   Third, we need to look at the complexity to implement.  Is it easy or
 is
  it
   hard to do?
  
   Fourth that I can think of is how strong of a use case is it.  Is this
  some
   brand new programming model that will look odd to someone seeing it for
  the
   first time? Is it simply some extra methods that can be used?
  
   Let's build out this list.
  
   John
  
 




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