Re: [VOTE] Release Apache DeltaSpike-0.4

[Ove Ranheim]

+1

I have testet and verified the build.

Thanks to the dev team for making DS !

Br, Ove

Re: [VOTE] [RESULT] Release Apache DeltaSpike-0.4

[Ove Ranheim]

0.4 release is out! :-)

Sent from my iPhone

On 31. mai 2013, at 17:02, Mark Struberg  wrote:

> Hi!
> 
> The VOTE has passed with the following 
> 
> 
> +1: John Ament, Cody Lerum  Mark Struberg, Florian Hell (nb), Romain 
> Manni-Bucau, Shane Bryzak, Nicklas Karlsson (nb), Christian Kaltepoth, Ove 
> Ranheim (nb) Ken Finnigan, Arne Limburg, Gerhard Petracek
> 
> +0: none
> 
> -1: none
> 
> txs all 4 voting!
> 
> 
> Gonna propagate the artifacts and write the announce once they did hit the 
> maven.central repo.
> 
> 
> LieGrue,
> strub
> 
> 
> 
> - Original Message -
>> From: Mark Struberg 
>> To: deltaspike 
>> Cc: 
>> Sent: Tuesday, 28 May 2013, 15:40
>> Subject: [VOTE] Release Apache DeltaSpike-0.4
>> 
>> Hi!
>> 
>> I'd like to call a VOTE for the release of DeltasSpike-0.4.
>> 
>> The staging repo is:
>> https://repository.apache.org/content/repositories/orgapachedeltaspike-011/
>> 
>> The tag is available here:
>> https://github.com/struberg/incubator-deltaspike/tree/deltaspike-project-0.4
>> This will get pushed to the ASF repo once the VOTE succeeded.
>> 
>> The source release is available here:
>> https://repository.apache.org/content/repositories/orgapachedeltaspike-011/org/apache/deltaspike/deltaspike-project/0.4/deltaspike-project-0.4-source-release.zip
>> sha1: 261897829b42f003ad43a157c607ed931686c482
>> 
>> 
>> Guide to testing:
>> Add the following to your ~/.m2/settings.xml:
>> 
>> 
>>   staging
>>   
>> 
>>   apache_staging
>>   
>> https://repository.apache.org/content/repositories/orgapachedeltaspike-011/
>>   true
>>   
>> false
>> 
>>   
>> 
>> 
>> Then upgrade your project to 0.4 and build with mvn -Pstaging.
>> 
>> LieGrue,
>> your Apache DeltaSpike Team
>> 

Re: Servlet module prototype

[Ove Ranheim]

My experience with seam servlet observers is that it causes performance cost 
when use ajax. When there are many browser callbacks per page (including jsf 
resources), there is a noticeable cost.

I suggest a @IncludePath filter to be added so only specific context paths 
would trigger an event to be fired. Or opposed an @ExcludePath filter.

On Jun 7, 2013, at 8:22 AM, Christian Kaltepoth  wrote:

> I think Nicklas and John fear that firing events for each request/response
> could lead to performance issues!?!
> 
> But I'm not sure if there will be a noticeable performance impact if there
> are no observers for the events. I don't think that firing an event that
> nobody observes is expensive.
> 
> And I also think that Solder didn't provide any way to disable these events
> (correct me if I'm wrong). Or has there been any reports regarding Solder's
> performance?
> 
> 
> 2013/6/7 Romain Manni-Bucau 
> 
>> Hi
>> 
>> in fact i don't get why you would like to be able to deactivate it.
>> Basically it is a web *module* so if it is here it is either needed by a
>> dep or you explicitely imported it so you want it. So basically a
>> configurable (through ConfigResolver) ServletContainerInitializer is just
>> what we need to be able to deactivate not needed listeners. Other config
>> can break modules relying on it so it could prevent lib to use this module.
>> 
>> *Romain Manni-Bucau*
>> *Twitter: @rmannibucau *
>> *Blog: **http://rmannibucau.wordpress.com/*<
>> http://rmannibucau.wordpress.com/>
>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>> *Github: https://github.com/rmannibucau*
>> 
>> 
>> 
>> 2013/6/7 Christian Kaltepoth 
>> 
>>> The servlet module doesn't work at all without the filter and the
>>> listeners. So I think it absolutely makes sense to include them in a
>>> web-fragment.xml inside the servlet-impl module. If something like
>>> filter/listener ordering is an issue for users, they can still set
>>> "metadata-complete" and manually add the required entries into their own
>>> web.xml. Or they could use .
>>> 
>>> But I agree that it should be possible to disable the events (all events
>> or
>>> perhaps just the request/response events?). The question is which way the
>>> user should use to configure this. Of cause we could also use a servlet
>>> context parameter. Something like:
>>> 
>>>  
>>>org.apache.deltaspike.DISABLE_SERVLET_EVENTS
>>>true
>>>  
>>> 
>>> But DeltaSpike already provides a mechanism for disabling features which
>> is
>>> part of the core module and is already used in various other places. If
>> we
>>> allow users to deactivate features, we should be consistent in how users
>>> can do it.
>>> 
>>> Is it correct that there is currently no implementation of
>> ClassDeactivator
>>> in DeltaSpike at all? What about adding an implementation that uses
>> servlet
>>> context parameters to the servlet module? Wouldn't this be a nice
>>> enhancement? This way users could either use "simple" servlet context
>>> parameters or they could use some other more flexible way if they want
>> to.
>>> 
>>> Christian
>>> 
>>> 
>>> 
>>> 
>>> 2013/6/6 John D. Ament 
>>> 
 What if the web-fragment.xml were in a separate JAR?
 Deactivatable is a custom solution, I'd love to avoid using it.
 
 
 On Thu, Jun 6, 2013 at 11:03 AM, Christian Kaltepoth <
 christ...@kaltepoth.de
> wrote:
 
> @John, @Nicklas:
> 
> I agree that it should be possible to disable the servlet events.
>> But I
> think we should automatically register the filter and the listeners
>>> using
> web-fragment.xml because they are required for the injection to work
> correctly.
> 
> Isn't this a perfect use case for Deactivatable? We could simply
>>> define a
> dummy implementation of Deactivatable which can be used to disable
>> just
 the
> events. We already do something with GlobalAlternative:
> 
> 
> 
 
>>> 
>> https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/exclude/GlobalAlternative.java#L26
> 
> 
> 
 
>>> 
>> https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/exclude/extension/ExcludeExtension.java#L91
> 
> What about this:
> 
>  public interface ServletEventBridge implements Deactivatable { }
> 
> Thoughts?
> 
> Christian
> 
> 
> 
> 2013/6/6 John D. Ament 
> 
>> I'd prefer if we simply didn't include the web-fragment.xml and
>>> instead
>> provided instructions on the wiki on how to enable them.
>> 
>> 
>> On Thu, Jun 6, 2013 at 4:37 AM, Nicklas Karlsson <
>> nicka...@gmail.com
 
>> wrote:
>> 
>>> I would also drop the @Web-annotation, I think. BTW, can the
>>> request/reponse lifecycle events be disabled? I would assume that
 there
>> is
>>>

Re: CDI Query import

[Ove Ranheim]

Hi Mark,

In what timeframe would CDI Query be imported as a module to Deltaspike?

Is the final name elected to be Data?

Ove

On Jun 16, 2013, at 8:39 AM, Mark Struberg  wrote:

> Hi Thomas, great stuff. 
> 
> Give us plz a few days to review and do the necessary preparations for the 
> import. 
> I've seen you have an ASF iCLA on file already, so this part should be fine ;)
> 
> LieGrue,
> strub
> 
> 
> 
> 
> - Original Message -
>> From: Thomas Hug 
>> To: "dev@deltaspike.apache.org" 
>> Cc: 
>> Sent: Friday, 14 June 2013, 11:55
>> Subject: CDI Query import
>> 
>> Hey all
>> 
>> Any suggestions on how to proceed with the CDI Query import? So far we have
>> - a proposal on the API [1]
>> - a cleaned out branch depending on DS core and PartialBeans, running on
>> the JBoss, TomEE and Glassfish profiles [2]
>> - a reasonable amount of documentation [3]
>> So what'd be next, anything still to adapt/missing?
>> 
>> [1] https://cwiki.apache.org/DeltaSpike/repository-drafts.html
>> [2] https://github.com/ctpconsulting/query/tree/dsimport
>> [3] https://github.com/ctpconsulting/query/tree/dsimport#readme
>> 

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

[Ove Ranheim]

Dear DS team!

Two months ago the team discussed a 0.6 release. What is your plan? There are 
many new great features since 0.5, so what is stopping the DS-team to provide a 
new release?

Looking through the JIRA there are 30 open issues, many of them regards JSF and 
Tests. I don’t use JSF anymore, so it hurts to be held back by stack-releases.

6 out of 30 are Improvements.
7 are New Features. 
1 is a Wish of porting Seam Mail. Cody has discontinued development of Seam 
Mail, so this issue could probably be Resolved/Won’t fix. 

If you constrain the release window to only bug fixing it looks like 14 issues 
should be moved to 0.7.
16 issues are real issues that needs to be decided upon.

Would it make sense to elect on some big tickets to get 0.6 out?

15 months ago DS was proposed to be incubated. IMHO, if DS is going to be a 
success, regular releases is a key factor.

It’s been five months since last 0.5 release.

regards,
ove


On 12. nov. 2013, at 16:28, Mark Struberg  wrote:

> yea, but what are the alternatives?
> If you have a better idea, then tell us :)
> 
> The problem is that it's not only about the JSF module but about all other 
> modules as well. 
> 
> LieGrue,
> strub
> 
> 
> 
> 
> - Original Message -
>> From: Gerhard Petracek 
>> To: dev@deltaspike.apache.org
>> Cc: 
>> Sent: Tuesday, 12 November 2013, 16:18
>> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0?
>> 
>> @mark:
>> i never said that we should do #2.
>> 
>> regards,
>> gerhard
>> 
>> 
>> 
>> 
>> 2013/11/12 Mark Struberg 
>> 
>>> Pete, Gerhard
>>> 
>>> The Problem here is that there are only 2 ways to handle the situation:
>>> 
>>> 1.) all modules share the same version but have different maturity grades
>>> 
>>> 2.) each module has it's very own version. A 0.x reflects instability, 
>> 1.x
>>> reflects maturity. But you know what happened with exactly this approach in
>>> Seam3? The problem is that users do not know which version of ds-jsf-api
>>> works together with which version of ds-core-impl for example. It gets much
>>> more complicated with later modules.
>>> 
>>> Thus I prefer 1.).
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
>>> 
 
 From: Pete Muir 
 To: dev@deltaspike.apache.org
 Sent: Tuesday, 12 November 2013, 14:35
 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0?
 
 
 +1 to Gerhard’s point (I am looking to try to find someone to help with
>>> docs, but the person I had in mind just left Red Hat :-(. Also +1 to going
>>> to 1.0 soon (i.e. making docs and stability a priority!).
 
 
 On 11 Nov 2013, at 23:09, Gerhard Petracek 
>> 
>>> wrote:
 
> if we move to v1 soon, we need an useful versioning strategy, 
>> better
>>> docs
> and examples + the api and spi need to be stable for some time (in 
>> the
>>> best
> case until v2+).
> 
> regards,
> gerhard
> 
> 
> 
> 2013/11/11 Mark Struberg 
> 
>> 
>> 
>> how should that work?
>> 
>> Please note that we will have some not perfectly finished 
>> modules very
>> often. Basically whenever we add a new module...
>> There is just no way to avoid this other than making those 
>> modules own
>> releases. But this does not work out neither (as seen on a few 
>> other
>> projects I don't like to name).
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>> 
>> 
>>> 
>>> From: Romain Manni-Bucau 
>>> To: Mark Struberg ; 
>> dev@deltaspike.apache.org
>>> Sent: Monday, 11 November 2013, 20:54
>>> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0?
>>> 
>>> 
>>> 
>>> Well if code is released it should be stable or 
>> explicitely in
>> alpha/beta..maybe we should do subreleases for unstables 
>> modules
>>> Le 11 nov. 2013 18:43, "Mark Struberg" 
>>  a écrit :
>>> 
>>> Oki folks, txs 4 the feedback, all!
 
 
 I'd say we should create the 
>> module-maturity-matrix.md first and
>>> then
>> we might do the version bump.
 Maybe something like green/blue/orange/red for mature 
>> / ready but
>>> still
>> needs a few features / ready but might change it's api 
>> still / work in
>> progress
 
 
 LieGrue,
 strub
 
 
 
 
 - Original Message -
> From: Charles Moulliard 
> To: dev@deltaspike.apache.org
> Cc: Mark Struberg 
> Sent: Monday, 11 November 2013, 18:25
> Subject: Re: [DISCUSS] next release version? 0.6 
>> or 1.0?
> 
> +1 to move to 1.0. We have done the same thing 
>> with Apache Aries
>>> moving
> Blueprint from 0.5 to 1.0 release
> 
> 
> 
> On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament
> wrote:
> 
>> Yep, agreed.  Users care about the version #.  
>> I 

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

[Ove Ranheim]

Mark, when do you plan to get the 1.0 release out? Time is important. Since 
there’s a lot of documentation required, wouldn’t this cause further delays? 
Are we talking about a shippable product in May timeframe, or would we see a 
release in Feb, possibly in March?

I’m a user of DS, but in order to trust CDI/DS and not move towards Spring. 
This is a big question for me, and I’m sure for many others (and potential) 
users too. IMO, it’s a mistake not keep a tight e.g 12 weekly shippable 
release. Being Agile is key to success. The project has been running for 25+ 
months now. Reading through sources and looking at the commit-graph from 
Gerhard. I think you guys deserve to see an uptake of DS. But, binaries needs 
to be pushed to central.

I’d say: -1 for 1.0 && +1 for 0.6.

br, ove

On 16. feb. 2014, at 16:39, Mark Struberg  wrote:

> I'd be +1 for 1.0
> 
> LieGrue,
> strub
> 
> 
> 
> 
> 
> On Sunday, 16 February 2014, 14:52, Nicklas Karlsson  
> wrote:
> 
> (the rumors of my demise is somewhat exaggerated ;-)
>> 
>> After migrating some applications from Seam 2 to Seam 3 (and then have Seam
>> 3 "run out of steam"), I recommended migrating to DeltaSpike so I have some
>> interest in DeltaSpike not end up the same way, that would be...
>> professionally embarrassing ;-)
>> 
>> Although I'm not obsessed with version numbers, I know several people who
>> are and a 1.0 would certainly attract attention (and hopefully
>> contributors). OTOH, one must be careful not to destroy the reputation of
>> the framework by releasing too early and give a crappy first impression.
>> Even if there are not that many fancy features, if the existing ones are
>> well documented and accompanied by examples, people are usually more
>> forgiving.
>> 
>> Having said that, I might be able to contribute some company time on e.g.
>> the JSF module (since we are using that, too).
>> 
>> regards,
>>   - Nik
>> 
>> 
>> 
>> On Sun, Feb 16, 2014 at 1:40 PM, Ove Ranheim  wrote:
>> 
>>> Dear DS team!
>>> 
>>> Two months ago the team discussed a 0.6 release. What is your plan? There
>>> are many new great features since 0.5, so what is stopping the DS-team to
>>> provide a new release?
>>> 
>>> Looking through the JIRA there are 30 open issues, many of them regards
>>> JSF and Tests. I don't use JSF anymore, so it hurts to be held back by
>>> stack-releases.
>>> 
>>> 6 out of 30 are Improvements.
>>> 7 are New Features.
>>> 1 is a Wish of porting Seam Mail. Cody has discontinued development of
>>> Seam Mail, so this issue could probably be Resolved/Won't fix.
>>> 
>>> If you constrain the release window to only bug fixing it looks like 14
>>> issues should be moved to 0.7.
>>> 16 issues are real issues that needs to be decided upon.
>>> 
>>> Would it make sense to elect on some big tickets to get 0.6 out?
>>> 
>>> 15 months ago DS was proposed to be incubated. IMHO, if DS is going to be
>>> a success, regular releases is a key factor.
>>> 
>>> It's been five months since last 0.5 release.
>>> 
>>> regards,
>>> ove
>>> 
>>> 
>>> On 12. nov. 2013, at 16:28, Mark Struberg  wrote:
>>> 
>>>> yea, but what are the alternatives?
>>>> If you have a better idea, then tell us :)
>>>> 
>>>> The problem is that it's not only about the JSF module but about all
>>> other modules as well.
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>> 
>>>> 
>>>> 
>>>> - Original Message -
>>>>> From: Gerhard Petracek 
>>>>> To: dev@deltaspike.apache.org
>>>>> Cc:
>>>>> Sent: Tuesday, 12 November 2013, 16:18
>>>>> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0?
>>>>> 
>>>>> @mark:
>>>>> i never said that we should do #2.
>>>>> 
>>>>> regards,
>>>>> gerhard
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 2013/11/12 Mark Struberg 
>>>>> 
>>>>>> Pete, Gerhard
>>>>>> 
>>>>>> The Problem here is that there are only 2 ways to handle the situation:
>>>>>> 
>>>>>> 1.) all modules share the same version but have different maturity
>>> grades
>>>

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

[Ove Ranheim]

Hi Gerhard,

Was your point the commit graph or the professional support?

I would recognize Apache Software to be an Open Source Foundation. My intent 
was not identify myself as a customer to shop commercial product support, on 
something not completed, but to urge the importance of getting sources, 
compiled binaries (read: i can do that myself), out the door. Not, the 
professional part of it.

I used to be one of the JBoss-ers evangelists (external) and wishes to see the 
joint efforts agreed on 2+ years ago to become the success on top of CDI, that 
DS really deserves to become.

Cheers,
Ove

On 16. feb. 2014, at 21:54, Gerhard Petracek  wrote:

> hi ove,
> 
> fyi:
> i just sent the link for our site.
> for code+site you can have a look at [1].
> 
> regards,
> gerhard
> 
> [1] http://s.apache.org/Pov
> 
> http://www.irian.at
> 
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 
> 
> 2014-02-16 21:27 GMT+01:00 Ove Ranheim :
> 
>> Mark, when do you plan to get the 1.0 release out? Time is important.
>> Since there's a lot of documentation required, wouldn't this cause further
>> delays? Are we talking about a shippable product in May timeframe, or would
>> we see a release in Feb, possibly in March?
>> 
>> I'm a user of DS, but in order to trust CDI/DS and not move towards
>> Spring. This is a big question for me, and I'm sure for many others (and
>> potential) users too. IMO, it's a mistake not keep a tight e.g 12 weekly
>> shippable release. Being Agile is key to success. The project has been
>> running for 25+ months now. Reading through sources and looking at the
>> commit-graph from Gerhard. I think you guys deserve to see an uptake of DS.
>> But, binaries needs to be pushed to central.
>> 
>> I'd say: -1 for 1.0 && +1 for 0.6.
>> 
>> br, ove
>> 
>> On 16. feb. 2014, at 16:39, Mark Struberg  wrote:
>> 
>>> I'd be +1 for 1.0
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Sunday, 16 February 2014, 14:52, Nicklas Karlsson 
>> wrote:
>>> 
>>> (the rumors of my demise is somewhat exaggerated ;-)
>>>> 
>>>> After migrating some applications from Seam 2 to Seam 3 (and then have
>> Seam
>>>> 3 "run out of steam"), I recommended migrating to DeltaSpike so I have
>> some
>>>> interest in DeltaSpike not end up the same way, that would be...
>>>> professionally embarrassing ;-)
>>>> 
>>>> Although I'm not obsessed with version numbers, I know several people
>> who
>>>> are and a 1.0 would certainly attract attention (and hopefully
>>>> contributors). OTOH, one must be careful not to destroy the reputation
>> of
>>>> the framework by releasing too early and give a crappy first impression.
>>>> Even if there are not that many fancy features, if the existing ones are
>>>> well documented and accompanied by examples, people are usually more
>>>> forgiving.
>>>> 
>>>> Having said that, I might be able to contribute some company time on
>> e.g.
>>>> the JSF module (since we are using that, too).
>>>> 
>>>> regards,
>>>>  - Nik
>>>> 
>>>> 
>>>> 
>>>> On Sun, Feb 16, 2014 at 1:40 PM, Ove Ranheim 
>> wrote:
>>>> 
>>>>> Dear DS team!
>>>>> 
>>>>> Two months ago the team discussed a 0.6 release. What is your plan?
>> There
>>>>> are many new great features since 0.5, so what is stopping the DS-team
>> to
>>>>> provide a new release?
>>>>> 
>>>>> Looking through the JIRA there are 30 open issues, many of them regards
>>>>> JSF and Tests. I don't use JSF anymore, so it hurts to be held back by
>>>>> stack-releases.
>>>>> 
>>>>> 6 out of 30 are Improvements.
>>>>> 7 are New Features.
>>>>> 1 is a Wish of porting Seam Mail. Cody has discontinued development of
>>>>> Seam Mail, so this issue could probably be Resolved/Won't fix.
>>>>> 
>>>>> If you constrain the release window to only bug fixing it looks like 14
>>>>> issues should be moved to 0.7.
>>>>> 16 issues are real issues that needs to be decided upon.
>>>>> 
>>

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

[Ove Ranheim]

The commit graph shows too few committers.. and I appreciate your work! 

I also notice too few Redhat/JBoss Weld/Seam committers left on the project. 
How come?

/ove

On 16. feb. 2014, at 22:10, Gerhard Petracek  wrote:

> hi ove,
> 
> i was only talking about the commits.
> 
> regards,
> gerhard
> 
> http://www.irian.at
> 
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 
> 
> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko :
> 
>> +1 Ove
>> We are really late for an 0.6. I would release 0.6 this/next month and
>> after that, lets finish 1.0.
>> We should fix all open issues and finish the documentation!
>> 

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

[Ove Ranheim]

That’s reasonable enough.

On 16. feb. 2014, at 23:02, Jason Porter  wrote:

> Probably because we've become busy with some other projects and priorities :(—
> Sent from Mailbox for iPhone
> 
> On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim  wrote:
> 
>> The commit graph shows too few committers.. and I appreciate your work! 
>> I also notice too few Redhat/JBoss Weld/Seam committers left on the project. 
>> How come?
>> /ove
>> On 16. feb. 2014, at 22:10, Gerhard Petracek  
>> wrote:
>>> hi ove,
>>> 
>>> i was only talking about the commits.
>>> 
>>> regards,
>>> gerhard
>>> 
>>> http://www.irian.at
>>> 
>>> Your JSF/JavaEE powerhouse -
>>> JavaEE Consulting, Development and
>>> Courses in English and German
>>> 
>>> Professional Support for Apache MyFaces
>>> 
>>> 
>>> 
>>> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko :
>>> 
>>>> +1 Ove
>>>> We are really late for an 0.6. I would release 0.6 this/next month and
>>>> after that, lets finish 1.0.
>>>> We should fix all open issues and finish the documentation!

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

[Ove Ranheim]

+1 for this :)


2014-02-17 10:10 GMT+01:00 Mark Struberg :

> Oki, I can help a bit with ViewAccessScoped. Romain and Thomas, please fix
> the Tx stuff.
>
> In that case I'd say we gonna ship a 0.6 and then in 3 weeks move to 1.0.
>
> wdyt?
>
>
> LieGrue,
> strub
>
>
>
>
>
> On Monday, 17 February 2014, 10:06, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
> Hi
> >
> >
> >can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx
> >stuff? Basically I'm waiting after it for months and this is blocker
> >to be used ATM.
> >Romain Manni-Bucau
> >Twitter: @rmannibucau
> >Blog: http://rmannibucau.wordpress.com/
> >LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >Github: https://github.com/rmannibucau
> >
> >
> >
> >
> >2014-02-17 9:57 GMT+01:00 Mark Struberg :
> >> back 2 the topic, please!
> >>
> >> I'd say we should approach 1.0 NOW.
> >>
> >> DeltaSpike core and a few other modules is really rock solid already
> since a year or so. It is also used heavily in production already.
> >> There will always be some modules which are not so perfectly mature at
> times. E.g. if we will add a new module.
> >>
> >> Thus I already did propose a methology which would fix this shortcoming:
> >> We might introduce an 'ample page' which contains the status of each
> project - stable / ready /in progress
> >>
> >> You know, the traffic light thingy where green means the module (e.g.
> deltaspike-core) is stable and the API will not change or we will at least
> be backward compatible unless we do a major new version.
> >> Orange means that the module has been tested and looks good. Whereas
> red means that the api might change still.
> >>
> >> What road blockers do we have before 1.0?
> >> Please note that there is always something one can do better - but this
> should not hinder us from releasing until something is really broken.
> >> Also the documentation is *not* a show stopper - it is perfectly fine
> to ship this later as our CMS is completely asynchronous.
> >>
> >>
> >> So what BLOCKERS do you see before I go and press the release button?
> >> Like to do that on Wednesday...
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >> On Sunday, 16 February 2014, 23:14, Ove Ranheim 
> wrote:
> >>
> >> That's reasonable enough.
> >>>
> >>>
> >>>On 16. feb. 2014, at 23:02, Jason Porter 
> wrote:
> >>>
> >>>> Probably because we've become busy with some other projects and
> priorities :(--
> >>>> Sent from Mailbox for iPhone
> >>>>
> >>>> On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim 
> wrote:
> >>>>
> >>>>> The commit graph shows too few committers.. and I appreciate your
> work!
> >>>>> I also notice too few Redhat/JBoss Weld/Seam committers left on the
> project. How come?
> >>>>> /ove
> >>>>> On 16. feb. 2014, at 22:10, Gerhard Petracek <
> gerhard.petra...@gmail.com> wrote:
> >>>>>> hi ove,
> >>>>>>
> >>>>>> i was only talking about the commits.
> >>>>>>
> >>>>>> regards,
> >>>>>> gerhard
> >>>>>>
> >>>>>> http://www.irian.at
> >>>>>>
> >>>>>> Your JSF/JavaEE powerhouse -
> >>>>>> JavaEE Consulting, Development and
> >>>>>> Courses in English and German
> >>>>>>
> >>>>>> Professional Support for Apache MyFaces
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko <
> andraschko.tho...@gmail.com>:
> >>>>>>
> >>>>>>> +1 Ove
> >>>>>>> We are really late for an 0.6. I would release 0.6 this/next month
> and
> >>>>>>> after that, lets finish 1.0.
> >>>>>>> We should fix all open issues and finish the documentation!
> >>>
> >>>
> >>>
> >
> >
> >
>

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

[Ove Ranheim]

Hi Antoine, it's good to hear that more red hat committers are on its way :)

On 17 Feb 2014, at 16:22, Antoine Sabot-Durand  wrote:

> Yes Ove, too few Red Hat committers. But they’re will be one more when CDI 
> 1.2 will be out and work for preparing CDI 2.0 will be on track.
> 
> Antoine Sabot-Durand
> ———
> Twitter : @antoine_sd
> CDI co-spec lead & eco-system development
> Agorava tech lead
> 
> 
> Le 16 févr. 2014 à 22:38, Ove Ranheim  a écrit :
> 
>> The commit graph shows too few committers.. and I appreciate your work! 
>> 
>> I also notice too few Redhat/JBoss Weld/Seam committers left on the project. 
>> How come?
>> 
>> /ove
>> 
>> On 16. feb. 2014, at 22:10, Gerhard Petracek  
>> wrote:
>> 
>>> hi ove,
>>> 
>>> i was only talking about the commits.
>>> 
>>> regards,
>>> gerhard
>>> 
>>> http://www.irian.at
>>> 
>>> Your JSF/JavaEE powerhouse -
>>> JavaEE Consulting, Development and
>>> Courses in English and German
>>> 
>>> Professional Support for Apache MyFaces
>>> 
>>> 
>>> 
>>> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko :
>>> 
>>>> +1 Ove
>>>> We are really late for an 0.6. I would release 0.6 this/next month and
>>>> after that, lets finish 1.0.
>>>> We should fix all open issues and finish the documentation!
>>>> 
>> 
> 
> 
> 

Wled 2.1.2: Could not find beans for Type=class org.apache.deltaspike.core.impl.scope.window.WindowBeanHolder and qualifiers:[]

[Ove Ranheim]

I getting an exception when using Weld 2.1.2 with DS 0.6-SNAPSHOT.

The exception message is: Could not find beans for Type=class 
org.apache.deltaspike.core.impl.scope.window.WindowBeanHolder and qualifiers:[]

Is DS compatible with Weld 2.1.2?

Br, Ove

Feb 20, 2014 9:01:50 AM org.jboss.weld.bootstrap.WeldStartup 
INFO: WELD-000900: 2.1.2 (Final)
Feb 20, 2014 9:01:51 AM org.jboss.weld.event.ExtensionObserverMethodImpl 
checkRequiredTypeAnnotations
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] protected 
org.apache.deltaspike.core.impl.exclude.extension.ExcludeExtension.vetoBeans(@Observes
 ProcessAnnotatedType, BeanManager) receives events for all annotated 
types. Consider restricting events using @WithAnnotations or a generic type 
with bounds.
Feb 20, 2014 9:01:51 AM org.jboss.weld.event.ExtensionObserverMethodImpl 
checkRequiredTypeAnnotations
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] protected 
org.apache.deltaspike.core.impl.message.MessageBundleExtension.detectInterfaces(@Observes
 ProcessAnnotatedType) receives events for all annotated types. 
Consider restricting events using @WithAnnotations or a generic type with 
bounds.
Feb 20, 2014 9:01:51 AM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: org.apache.deltaspike.core.impl.config.ConfigurationExtension 
activated=true
Feb 20, 2014 9:01:51 AM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: 
org.apache.deltaspike.core.impl.exception.control.extension.ExceptionControlExtension
 activated=true
Feb 20, 2014 9:01:51 AM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: org.apache.deltaspike.core.impl.message.MessageBundleExtension 
activated=true
Feb 20, 2014 9:01:51 AM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: org.apache.deltaspike.core.impl.exclude.extension.ExcludeExtension 
activated=true
Feb 20, 2014 9:01:51 AM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: 
org.apache.deltaspike.core.impl.exclude.CustomProjectStageBeanFilter 
activated=true
Feb 20, 2014 9:01:51 AM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: org.apache.deltaspike.core.impl.exclude.GlobalAlternative 
activated=true
Feb 20, 2014 9:01:51 AM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: org.apache.deltaspike.core.impl.jmx.MBeanExtension activated=true
Feb 20, 2014 9:01:51 AM org.apache.deltaspike.core.util.ProjectStageProducer 
initProjectStage
INFO: Computed the following DeltaSpike ProjectStage: UnitTest
Running com.parts.test.WeldTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec <<< 
FAILURE!

Results :

Tests in error: 
  com.parts.test.WeldTest: Exception List with 1 exceptions:(..)


---
Test set: com.parts.test.WeldTest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec <<< 
FAILURE!
com.parts.test.WeldTest  Time elapsed: 0.003 sec  <<< ERROR!
org.jboss.weld.exceptions.DeploymentException: Exception List with 1 exceptions:
Exception 0 :
java.lang.IllegalStateException: Could not find beans for Type=class 
org.apache.deltaspike.core.impl.scope.window.WindowBeanHolder and qualifiers:[]
at 
org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:150)
at 
org.apache.deltaspike.core.impl.scope.DeltaSpikeContextExtension.initializeDeltaSpikeContexts(DeltaSpikeContextExtension.java:59)
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.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)
at 
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:266)
at 
org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125)
at 
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253)
at 
org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:232)
at 
org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:169)
at 
org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:128)
at 
org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:102)
at 
org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:63)
at 
org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerE

Re: Wled 2.1.2: Could not find beans for Type=class org.apache.deltaspike.core.impl.scope.window.WindowBeanHolder and qualifiers:[]

[Ove Ranheim]

The test case is successful in Jenkins. I checkout latest sources from
GitHub and re-run my test.

I still get the same error. Is GitHub in sync with Apache Git?

Re: Wled 2.1.2: Could not find beans for Type=class org.apache.deltaspike.core.impl.scope.window.WindowBeanHolder and qualifiers:[]

[Ove Ranheim]

Hi Gerhard,

I did run the test suite in DS and all test cases runs fine with -PWeld 
-Dweld.version=2.1.2.Final !

However, when I run my (simple) test case, it fails. So in order to nail out 
the problem, I made a test case. Would you be able to have a look at: 
https://github.com/oranheim/ds-weld-test

I also compared the dependency graph for my own test project with 
"core/impl"-module and they are 100% equal.

Cheers,
Ove


On 20 Feb 2014, at 12:45, Gerhard Petracek  wrote:

> hi ove,
> 
> please have a look at [1].
> 
> regards,
> gerhard
> 
> [1] http://deltaspike.apache.org/source.html#scm-repository
> 
> http://www.irian.at
> 
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 
> 
> 2014-02-20 11:51 GMT+01:00 Ove Ranheim :
> 
>> The test case is successful in Jenkins. I checkout latest sources from
>> GitHub and re-run my test.
>> 
>> I still get the same error. Is GitHub in sync with Apache Git?
>> 

Re: Wled 2.1.2: Could not find beans for Type=class org.apache.deltaspike.core.impl.scope.window.WindowBeanHolder and qualifiers:[]

[Ove Ranheim]

I've double checked my configuration in poms over again and cannot find
anything wrong.

If I disable DS-dependencies for deltaspike-core-api
and deltaspike-core-impl (ds-weld-test-helloworld pom), it works like a
charm. When they are enabled, the error re-occurs. If something is wrong
with my arquillian configuration, I suppose the weld-profile wouldn't work
at all. But it does using weld-only.

Do you have some more leads for me that I could go after?

Btw, I posted this message on the Arquillian forum:
https://community.jboss.org/thread/237358



2014-02-21 10:59 GMT+01:00 Gerhard Petracek :

> hi ove,
>
> the project you provided shows an arquillian config-issue.
> please check the setup again and/or contact the arquillian community.
>
> regards,
> gerhard
>
>
>
> 2014-02-20 23:01 GMT+01:00 Ove Ranheim :
>
> > Hi Gerhard,
> >
> > I did run the test suite in DS and all test cases runs fine with -PWeld
> > -Dweld.version=2.1.2.Final !
> >
> > However, when I run my (simple) test case, it fails. So in order to nail
> > out the problem, I made a test case. Would you be able to have a look at:
> > https://github.com/oranheim/ds-weld-test
> >
> > I also compared the dependency graph for my own test project with
> > "core/impl"-module and they are 100% equal.
> >
> > Cheers,
> > Ove
> >
> >
> > On 20 Feb 2014, at 12:45, Gerhard Petracek 
> > wrote:
> >
> > > hi ove,
> > >
> > > please have a look at [1].
> > >
> > > regards,
> > > gerhard
> > >
> > > [1] http://deltaspike.apache.org/source.html#scm-repository
> > >
> > > http://www.irian.at
> > >
> > > Your JSF/JavaEE powerhouse -
> > > JavaEE Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> > >
> > >
> > > 2014-02-20 11:51 GMT+01:00 Ove Ranheim :
> > >
> > >> The test case is successful in Jenkins. I checkout latest sources from
> > >> GitHub and re-run my test.
> > >>
> > >> I still get the same error. Is GitHub in sync with Apache Git?
> > >>
> >
> >
>

Re: Wled 2.1.2: Could not find beans for Type=class org.apache.deltaspike.core.impl.scope.window.WindowBeanHolder and qualifiers:[]

[Ove Ranheim]

Another finding. When I copy the test case sources from
ds-weld-test/helloworld/src/test/java to deltaspike/core/impl/src/test/java
and issue:

mvn clean test -PWeld -Dweld.version=2.1.2.Final (-Dtest=WeldTest)

all test cases works as expected, except for the [1] WeldTest. Is something
wrong with the anatomy of this test case?

regards,
Ove

[1]
https://github.com/oranheim/ds-weld-test/blob/master/helloworld/src/test/java/com/acme/test/WeldTest.java



2014-02-21 13:16 GMT+01:00 Ove Ranheim :

> I've double checked my configuration in poms over again and cannot find
> anything wrong.
>
> If I disable DS-dependencies for deltaspike-core-api
> and deltaspike-core-impl (ds-weld-test-helloworld pom), it works like a
> charm. When they are enabled, the error re-occurs. If something is wrong
> with my arquillian configuration, I suppose the weld-profile wouldn't work
> at all. But it does using weld-only.
>
> Do you have some more leads for me that I could go after?
>
> Btw, I posted this message on the Arquillian forum:
> https://community.jboss.org/thread/237358
>
>
>
> 2014-02-21 10:59 GMT+01:00 Gerhard Petracek :
>
> hi ove,
>>
>> the project you provided shows an arquillian config-issue.
>> please check the setup again and/or contact the arquillian community.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2014-02-20 23:01 GMT+01:00 Ove Ranheim :
>>
>> > Hi Gerhard,
>> >
>> > I did run the test suite in DS and all test cases runs fine with -PWeld
>> > -Dweld.version=2.1.2.Final !
>> >
>> > However, when I run my (simple) test case, it fails. So in order to nail
>> > out the problem, I made a test case. Would you be able to have a look
>> at:
>> > https://github.com/oranheim/ds-weld-test
>> >
>> > I also compared the dependency graph for my own test project with
>> > "core/impl"-module and they are 100% equal.
>> >
>> > Cheers,
>> > Ove
>> >
>> >
>> > On 20 Feb 2014, at 12:45, Gerhard Petracek 
>> > wrote:
>> >
>> > > hi ove,
>> > >
>> > > please have a look at [1].
>> > >
>> > > regards,
>> > > gerhard
>> > >
>> > > [1] http://deltaspike.apache.org/source.html#scm-repository
>> > >
>> > > http://www.irian.at
>> > >
>> > > Your JSF/JavaEE powerhouse -
>> > > JavaEE Consulting, Development and
>> > > Courses in English and German
>> > >
>> > > Professional Support for Apache MyFaces
>> > >
>> > >
>> > >
>> > > 2014-02-20 11:51 GMT+01:00 Ove Ranheim :
>> > >
>> > >> The test case is successful in Jenkins. I checkout latest sources
>> from
>> > >> GitHub and re-run my test.
>> > >>
>> > >> I still get the same error. Is GitHub in sync with Apache Git?
>> > >>
>> >
>> >
>>
>
>

Re: Wled 2.1.2: Could not find beans for Type=class org.apache.deltaspike.core.impl.scope.window.WindowBeanHolder and qualifiers:[]

[Ove Ranheim]

hi gerhard!

thanks for clarifying my mistake.

adding jars solves my problem.. :-)

ove

On 21 Feb 2014, at 13:37, Gerhard Petracek  wrote:

> hi ove,
> 
> you are not adding deltaspike to your deployment.
> please have a look at our arquillian >tests<.
> 
> regards,
> gerhard
> 
> http://www.irian.at
> 
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 
> 
> 2014-02-21 13:16 GMT+01:00 Ove Ranheim :
> 
>> I've double checked my configuration in poms over again and cannot find
>> anything wrong.
>> 
>> If I disable DS-dependencies for deltaspike-core-api
>> and deltaspike-core-impl (ds-weld-test-helloworld pom), it works like a
>> charm. When they are enabled, the error re-occurs. If something is wrong
>> with my arquillian configuration, I suppose the weld-profile wouldn't work
>> at all. But it does using weld-only.
>> 
>> Do you have some more leads for me that I could go after?
>> 
>> Btw, I posted this message on the Arquillian forum:
>> https://community.jboss.org/thread/237358
>> 
>> 
>> 
>> 2014-02-21 10:59 GMT+01:00 Gerhard Petracek :
>> 
>>> hi ove,
>>> 
>>> the project you provided shows an arquillian config-issue.
>>> please check the setup again and/or contact the arquillian community.
>>> 
>>> regards,
>>> gerhard
>>> 
>>> 
>>> 
>>> 2014-02-20 23:01 GMT+01:00 Ove Ranheim :
>>> 
>>>> Hi Gerhard,
>>>> 
>>>> I did run the test suite in DS and all test cases runs fine with -PWeld
>>>> -Dweld.version=2.1.2.Final !
>>>> 
>>>> However, when I run my (simple) test case, it fails. So in order to
>> nail
>>>> out the problem, I made a test case. Would you be able to have a look
>> at:
>>>> https://github.com/oranheim/ds-weld-test
>>>> 
>>>> I also compared the dependency graph for my own test project with
>>>> "core/impl"-module and they are 100% equal.
>>>> 
>>>> Cheers,
>>>> Ove
>>>> 
>>>> 
>>>> On 20 Feb 2014, at 12:45, Gerhard Petracek >> 
>>>> wrote:
>>>> 
>>>>> hi ove,
>>>>> 
>>>>> please have a look at [1].
>>>>> 
>>>>> regards,
>>>>> gerhard
>>>>> 
>>>>> [1] http://deltaspike.apache.org/source.html#scm-repository
>>>>> 
>>>>> http://www.irian.at
>>>>> 
>>>>> Your JSF/JavaEE powerhouse -
>>>>> JavaEE Consulting, Development and
>>>>> Courses in English and German
>>>>> 
>>>>> Professional Support for Apache MyFaces
>>>>> 
>>>>> 
>>>>> 
>>>>> 2014-02-20 11:51 GMT+01:00 Ove Ranheim :
>>>>> 
>>>>>> The test case is successful in Jenkins. I checkout latest sources
>> from
>>>>>> GitHub and re-run my test.
>>>>>> 
>>>>>> I still get the same error. Is GitHub in sync with Apache Git?
>>>>>> 
>>>> 
>>>> 
>>> 
>> 

Observer method [BackedAnnotatedMethod] receives events for all annotated types (Weld 2.1.2)

[Ove Ranheim]

Hi,

I'm using DS, Weld and Tomcat and in the log I found these messages.

20:41:31.199 [Thread-1] INFO  org.jboss.weld.Version - WELD-000900: 2.1.2 
(Final)
20:41:31.608 [Thread-1] INFO  org.jboss.weld.Bootstrap - WELD-000101: 
Transactional services not available. Injection of @Inject UserTransaction not 
available. Transactional observers will be invoked synchronously.
20:41:31.870 [Thread-1] WARN  org.jboss.weld.Event - WELD-000411: Observer 
method [BackedAnnotatedMethod] protected 
org.apache.deltaspike.core.impl.message.MessageBundleExtension.detectInterfaces(@Observes
 ProcessAnnotatedType) receives events for all annotated types. 
Consider restricting events using @WithAnnotations or a generic type with 
bounds.
20:41:31.888 [Thread-1] WARN  org.jboss.weld.Event - WELD-000411: Observer 
method [BackedAnnotatedMethod] protected 
org.apache.deltaspike.core.impl.message.MessageBundleExtension.detectInterfaces(@Observes
 ProcessAnnotatedType) receives events for all annotated types. 
Consider restricting events using @WithAnnotations or a generic type with 
bounds.
20:41:31.902 [Thread-1] WARN  org.jboss.weld.Event - WELD-000411: Observer 
method [BackedAnnotatedMethod] protected 
org.apache.deltaspike.core.impl.exclude.extension.ExcludeExtension.vetoBeans(@Observes
 ProcessAnnotatedType, BeanManager) receives events for all annotated 
types. Consider restricting events using @WithAnnotations or a generic type 
with bounds.
20:41:31.904 [Thread-1] WARN  org.jboss.weld.Event - WELD-000411: Observer 
method [BackedAnnotatedMethod] protected 
org.apache.deltaspike.core.impl.exclude.extension.ExcludeExtension.vetoBeans(@Observes
 ProcessAnnotatedType, BeanManager) receives events for all annotated 
types. Consider restricting events using @WithAnnotations or a generic type 
with bounds.

Is this normal and excepted behaviour?

Ove

JPA PersistenceUnit - persistence.xml not being picked up

[Ove Ranheim]

Hi,

I'm trying out DeltaSpike JPA, but my persistence.xml is not being picked up. I 
tried to place persistene.xml under META-INF and WEB-INF/classes/META-INF/.

TransactionalInterceptor is configured in beans.xml. 

Here are my files.

war-listing:

    
   210031  03-06-14 18:35   WEB-INF/lib/deltaspike-core-api-0.6-SNAPSHOT.jar
   116683  03-06-14 18:35   WEB-INF/lib/hibernate-jpa-2.1-api-1.0.0.Final.jar
   714186  03-06-14 18:35   WEB-INF/lib/javassist-3.18.1-GA.jar
0  03-06-14 18:35   WEB-INF/lib/
40784  03-06-14 18:35   
WEB-INF/lib/deltaspike-jpa-module-impl-0.6-SNAPSHOT.jar
0  03-06-14 18:35   WEB-INF/classes/com/parts/persistence/test/
15648  03-06-14 18:35   
WEB-INF/lib/deltaspike-jpa-module-api-0.6-SNAPSHOT.jar
0  03-06-14 18:35   WEB-INF/classes/com/parts/persistence/model/
0  03-06-14 18:35   WEB-INF/classes/com/parts/persistence/
0  03-06-14 18:35   WEB-INF/classes/
   121490  03-06-14 18:35   WEB-INF/lib/deltaspike-core-impl-0.6-SNAPSHOT.jar
   314186  03-06-14 18:35   WEB-INF/lib/dom4j-1.6.1.jar
0  03-06-14 18:35   WEB-INF/classes/com/parts/
0  03-06-14 18:35   
WEB-INF/classes/com/parts/persistence/test/repository/
58109  03-06-14 18:35   WEB-INF/lib/jboss-logging-3.1.3.GA.jar
   109768  03-06-14 18:35   WEB-INF/lib/xml-apis-1.0.b2.jar
0  03-06-14 18:35   WEB-INF/
  437  03-06-14 18:35   META-INF/beans.xml
  912  03-06-14 18:35   
WEB-INF/classes/com/parts/persistence/model/TestEntity.class
  1644906  03-06-14 18:35   WEB-INF/lib/h2-1.3.175.jar
 4022  03-06-14 18:35   
WEB-INF/classes/com/parts/persistence/test/repository/PartsRepositoryTest.class
  527  03-06-14 18:35   
WEB-INF/classes/com/parts/persistence/producer/PartsRepository.class
0  03-06-14 18:35   WEB-INF/classes/com/parts/persistence/producer/
 1113  03-06-14 18:35   META-INF/persistence.xml
0  03-06-14 18:35   WEB-INF/classes/com/
76575  03-06-14 18:35   
WEB-INF/lib/hibernate-commons-annotations-4.0.4.Final.jar
28291  03-06-14 18:35   
WEB-INF/lib/jboss-transaction-api_1.2_spec-1.0.0.Final.jar
12022  03-06-14 18:35   
WEB-INF/lib/jboss-logging-annotations-1.2.0.Beta1.jar
   445514  03-06-14 18:35   WEB-INF/lib/antlr-2.7.7.jar
77445  03-06-14 18:35   WEB-INF/lib/jandex-1.1.0.Final.jar
0  03-06-14 18:35   META-INF/
 1306  03-06-14 18:35   
WEB-INF/classes/com/parts/persistence/producer/PartsRepositoryProducer.class
  5282694  03-06-14 18:35   WEB-INF/lib/hibernate-core-4.3.4.Final.jar


Persistence.xml:


http://xmlns.jcp.org/xml/ns/persistence"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence 
http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd";>
  
ENABLE_SELECTIVE
partsds

  
  
  
  
  
  
  
  

  


EntityProducer:

@ApplicationScoped
public class PartsRepositoryProducer {

//or manual bootstrapping
@PersistenceUnit
private EntityManagerFactory entityManagerFactory;

@Produces
@PartsRepository
@RequestScoped
protected EntityManager createEntityManager() {
return this.entityManagerFactory.createEntityManager();
}

protected void closeEntityManager(@Disposes @PartsRepository EntityManager 
entityManager) {
if (entityManager.isOpen()) {
entityManager.close();
}
}
}

Test case:

@Inject
@PartsRepository
private EntityManager em;

@Test
public void testEm() throws Exception {
assertNotNull(em);
TestEntity m = new TestEntity();
m.setId("1");
m.setName("foo");
em.getTransaction().begin();
em.persist(m);
em.flush();
em.getTransaction().commit();
}

The assertNotNull passes but the Exception occurs on em.getTransaction().

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.139 sec <<< 
FAILURE! - in com.parts.persistence.test.repository.PartsRepositoryTest
testMe(com.parts.persistence.test.repository.PartsRepositoryTest)  Time 
elapsed: 0.072 sec  <<< ERROR!
java.lang.NullPointerException: null
at 
org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44)
at 
org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53)
at org.jboss.weld.util.Beans.injectEEFields(Beans.java:331)
at 
org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:59)
at 
org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
at 
org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
at 
org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
at 
org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.j

Re: JPA PersistenceUnit - persistence.xml not being picked up

[Ove Ranheim]

This is standalone with arquillian-weld-ee-embedded-1.1.

The arquillian war file is listed below.

On 06 Mar 2014, at 19:11, John D. Ament  wrote:

> Looks like your issue is more JBoss related.  Is this WildFly?
> 
> Can you show the output of your WAR file in your test?
> 
> On Thu, Mar 6, 2014 at 1:02 PM, Ove Ranheim  wrote:
>> Hi,
>> 
>> I'm trying out DeltaSpike JPA, but my persistence.xml is not being picked 
>> up. I tried to place persistene.xml under META-INF and 
>> WEB-INF/classes/META-INF/.
>> 
>> TransactionalInterceptor is configured in beans.xml.
>> 
>> Here are my files.
>> 
>> war-listing:
>> 
>>    
>>   210031  03-06-14 18:35   WEB-INF/lib/deltaspike-core-api-0.6-SNAPSHOT.jar
>>   116683  03-06-14 18:35   WEB-INF/lib/hibernate-jpa-2.1-api-1.0.0.Final.jar
>>   714186  03-06-14 18:35   WEB-INF/lib/javassist-3.18.1-GA.jar
>>0  03-06-14 18:35   WEB-INF/lib/
>>40784  03-06-14 18:35   
>> WEB-INF/lib/deltaspike-jpa-module-impl-0.6-SNAPSHOT.jar
>>0  03-06-14 18:35   WEB-INF/classes/com/parts/persistence/test/
>>15648  03-06-14 18:35   
>> WEB-INF/lib/deltaspike-jpa-module-api-0.6-SNAPSHOT.jar
>>0  03-06-14 18:35   WEB-INF/classes/com/parts/persistence/model/
>>0  03-06-14 18:35   WEB-INF/classes/com/parts/persistence/
>>0  03-06-14 18:35   WEB-INF/classes/
>>   121490  03-06-14 18:35   WEB-INF/lib/deltaspike-core-impl-0.6-SNAPSHOT.jar
>>   314186  03-06-14 18:35   WEB-INF/lib/dom4j-1.6.1.jar
>>0  03-06-14 18:35   WEB-INF/classes/com/parts/
>>0  03-06-14 18:35   
>> WEB-INF/classes/com/parts/persistence/test/repository/
>>58109  03-06-14 18:35   WEB-INF/lib/jboss-logging-3.1.3.GA.jar
>>   109768  03-06-14 18:35   WEB-INF/lib/xml-apis-1.0.b2.jar
>>0  03-06-14 18:35   WEB-INF/
>>  437  03-06-14 18:35   META-INF/beans.xml
>>  912  03-06-14 18:35   
>> WEB-INF/classes/com/parts/persistence/model/TestEntity.class
>>  1644906  03-06-14 18:35   WEB-INF/lib/h2-1.3.175.jar
>> 4022  03-06-14 18:35   
>> WEB-INF/classes/com/parts/persistence/test/repository/PartsRepositoryTest.class
>>  527  03-06-14 18:35   
>> WEB-INF/classes/com/parts/persistence/producer/PartsRepository.class
>>0  03-06-14 18:35   WEB-INF/classes/com/parts/persistence/producer/
>> 1113  03-06-14 18:35   META-INF/persistence.xml
>>0  03-06-14 18:35   WEB-INF/classes/com/
>>76575  03-06-14 18:35   
>> WEB-INF/lib/hibernate-commons-annotations-4.0.4.Final.jar
>>28291  03-06-14 18:35   
>> WEB-INF/lib/jboss-transaction-api_1.2_spec-1.0.0.Final.jar
>>12022  03-06-14 18:35   
>> WEB-INF/lib/jboss-logging-annotations-1.2.0.Beta1.jar
>>   445514  03-06-14 18:35   WEB-INF/lib/antlr-2.7.7.jar
>>77445  03-06-14 18:35   WEB-INF/lib/jandex-1.1.0.Final.jar
>>0  03-06-14 18:35   META-INF/
>> 1306  03-06-14 18:35   
>> WEB-INF/classes/com/parts/persistence/producer/PartsRepositoryProducer.class
>>  5282694  03-06-14 18:35   WEB-INF/lib/hibernate-core-4.3.4.Final.jar
>> 
>> 
>> Persistence.xml:
>> 
>> 
>> http://xmlns.jcp.org/xml/ns/persistence"; 
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
>> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence 
>> http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd";>
>>  
>>ENABLE_SELECTIVE
>>partsds
>>
>>  > value="jdbc:hsqldb:mem:partsdb;shutdown=false"/>
>>  
>>  
>>  > value="org.hibernate.dialect.H2Dialect"/>
>>  
>>  
>>  
>>  
>>
>>  
>> 
>> 
>> EntityProducer:
>> 
>> @ApplicationScoped
>> public class PartsRepositoryProducer {
>> 
>>//or manual bootstrapping
>>@PersistenceUnit
>>private EntityManagerFactory entityManagerFactory;
>> 
>>@Produces
>>@PartsRepository
>>@RequestScoped
>>protected EntityManager createEntityManager() {
>>return this.entityManagerFactory.createEntityManager();
>>}
>> 
>>protected void closeEntityManager(@Disposes @PartsRepository 
>> EntityManager entityManager) {
>>if (entityManager.isOpen()) {
>>entityManager.close();
>>}
>>}
>> }
>> 
>> Test case:
>> 
>>@Inject
>>@PartsRepository
>>private En

Re: JPA PersistenceUnit - persistence.xml not being picked up

[Ove Ranheim]

Thanks John!

I guess this a good start: Persistence.createEntityManagerFactory("primary");

I usually use Wildfly, so bootstrapping is not something i do very often. Sorry 
for the silly question.

On 06 Mar 2014, at 20:14, John D. Ament  wrote:

> Well, I mean, @PersistenceContext/@PersistenceUnit are only enabled in
> EJB spec.  You'll need to bootstrap in an SE type env, AFAIK.
> 
> On Thu, Mar 6, 2014 at 1:15 PM, Ove Ranheim  wrote:
>> This is standalone with arquillian-weld-ee-embedded-1.1.
>> 
>> The arquillian war file is listed below.
>> 
>> On 06 Mar 2014, at 19:11, John D. Ament  wrote:
>> 
>>> Looks like your issue is more JBoss related.  Is this WildFly?
>>> 
>>> Can you show the output of your WAR file in your test?
>>> 
>>> On Thu, Mar 6, 2014 at 1:02 PM, Ove Ranheim  wrote:
>>>> Hi,
>>>> 
>>>> I'm trying out DeltaSpike JPA, but my persistence.xml is not being picked 
>>>> up. I tried to place persistene.xml under META-INF and 
>>>> WEB-INF/classes/META-INF/.
>>>> 
>>>> TransactionalInterceptor is configured in beans.xml.
>>>> 
>>>> Here are my files.
>>>> 
>>>> war-listing:
>>>> 
>>>>    
>>>>  210031  03-06-14 18:35   WEB-INF/lib/deltaspike-core-api-0.6-SNAPSHOT.jar
>>>>  116683  03-06-14 18:35   WEB-INF/lib/hibernate-jpa-2.1-api-1.0.0.Final.jar
>>>>  714186  03-06-14 18:35   WEB-INF/lib/javassist-3.18.1-GA.jar
>>>>   0  03-06-14 18:35   WEB-INF/lib/
>>>>   40784  03-06-14 18:35   
>>>> WEB-INF/lib/deltaspike-jpa-module-impl-0.6-SNAPSHOT.jar
>>>>   0  03-06-14 18:35   WEB-INF/classes/com/parts/persistence/test/
>>>>   15648  03-06-14 18:35   
>>>> WEB-INF/lib/deltaspike-jpa-module-api-0.6-SNAPSHOT.jar
>>>>   0  03-06-14 18:35   WEB-INF/classes/com/parts/persistence/model/
>>>>   0  03-06-14 18:35   WEB-INF/classes/com/parts/persistence/
>>>>   0  03-06-14 18:35   WEB-INF/classes/
>>>>  121490  03-06-14 18:35   WEB-INF/lib/deltaspike-core-impl-0.6-SNAPSHOT.jar
>>>>  314186  03-06-14 18:35   WEB-INF/lib/dom4j-1.6.1.jar
>>>>   0  03-06-14 18:35   WEB-INF/classes/com/parts/
>>>>   0  03-06-14 18:35   
>>>> WEB-INF/classes/com/parts/persistence/test/repository/
>>>>   58109  03-06-14 18:35   WEB-INF/lib/jboss-logging-3.1.3.GA.jar
>>>>  109768  03-06-14 18:35   WEB-INF/lib/xml-apis-1.0.b2.jar
>>>>   0  03-06-14 18:35   WEB-INF/
>>>> 437  03-06-14 18:35   META-INF/beans.xml
>>>> 912  03-06-14 18:35   
>>>> WEB-INF/classes/com/parts/persistence/model/TestEntity.class
>>>> 1644906  03-06-14 18:35   WEB-INF/lib/h2-1.3.175.jar
>>>>4022  03-06-14 18:35   
>>>> WEB-INF/classes/com/parts/persistence/test/repository/PartsRepositoryTest.class
>>>> 527  03-06-14 18:35   
>>>> WEB-INF/classes/com/parts/persistence/producer/PartsRepository.class
>>>>   0  03-06-14 18:35   WEB-INF/classes/com/parts/persistence/producer/
>>>>1113  03-06-14 18:35   META-INF/persistence.xml
>>>>   0  03-06-14 18:35   WEB-INF/classes/com/
>>>>   76575  03-06-14 18:35   
>>>> WEB-INF/lib/hibernate-commons-annotations-4.0.4.Final.jar
>>>>   28291  03-06-14 18:35   
>>>> WEB-INF/lib/jboss-transaction-api_1.2_spec-1.0.0.Final.jar
>>>>   12022  03-06-14 18:35   
>>>> WEB-INF/lib/jboss-logging-annotations-1.2.0.Beta1.jar
>>>>  445514  03-06-14 18:35   WEB-INF/lib/antlr-2.7.7.jar
>>>>   77445  03-06-14 18:35   WEB-INF/lib/jandex-1.1.0.Final.jar
>>>>   0  03-06-14 18:35   META-INF/
>>>>1306  03-06-14 18:35   
>>>> WEB-INF/classes/com/parts/persistence/producer/PartsRepositoryProducer.class
>>>> 5282694  03-06-14 18:35   WEB-INF/lib/hibernate-core-4.3.4.Final.jar
>>>> 
>>>> 
>>>> Persistence.xml:
>>>> 
>>>> 
>>>> http://xmlns.jcp.org/xml/ns/persistence"; 
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
>>>> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence 
>>>> http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd";>
>>>> 
>>>>   ENABLE_SELECTIVE
>>>>   partsds
>>>>   
>>>> >>> value="jdbc:hsqldb:mem:partsdb;shutdown=false"/>

How can TransactionScoped be started with weld-embedded-1.1

[Ove Ranheim]

Hi,

I'm not able to start the TransactionScoped in due time. I'm doing an 
experiment on using ds-jpa together with JTA-and-Hibernate 
(https://github.com/jbosstm/quickstart/tree/master/jta-and-hibernate). 

The persistence.xml uses JTA and binds to a JdbcDataSource bound to JNDI. If I 
use the TransactionManager directly, it all works. However, when I use the 
BeanManagedUserTransactionStrategy it fails. I'd like to make use of the 
@Transactional and @TransactionScope.

Here are some code snippets.

public static void bindNamingAndTransactionService() throws Exception {
if(txInitialized) return;
// Start JNDI server
NAMING_BEAN.start();

// Bind JTA implementation with default names
JNDIManager.bindJTAImplementation();

// Bind JTA implementation with JBoss names. Needed for JTA 1.2 
implementation.
// See https://issues.jboss.org/browse/JBTM-2054
// resolve naming parse container for comp and bind
NAMING_BEAN.getNamingInstance().createSubcontext(new 
NamingParser().parse("jboss"));

jtaPropertyManager.getJTAEnvironmentBean().setTransactionManagerJNDIContext("java:/jboss/TransactionManager");
jtaPropertyManager.getJTAEnvironmentBean()

.setTransactionSynchronizationRegistryJNDIContext("java:/jboss/TransactionSynchronizationRegistry");
JNDIManager.bindJTAImplementation();

JdbcDataSource dataSource = new JdbcDataSource();
dataSource.setURL("jdbc:h2:~/partsdb;MVCC=TRUE");
dataSource.setUser("sa");
dataSource.setPassword("");

InitialContext context = new InitialContext();
context.bind("java:/jboss/primaryDS", dataSource);
txInitialized = true;
}

EntityManagerProducer:

@Produces
@PartsRepository
@TransactionScoped
protected EntityManager createEntityManager() {
return entityManagerFactory.createEntityManager();
}

@Produces
public EntityManagerFactory entityManagerFactory() {
if (entityManagerFactory == null) {
try {
if (!txInitialized) bindNamingAndTransactionService();
} catch (Exception e) {
throw new RuntimeException(e);
}
return Persistence.createEntityManagerFactory("primary");
}
throw new UnsupportedOperationException();
};

Arquillian Weld-Embedded-1.1 test:

@BeforeClass
public static void beforeClazz() throws Exception {

BeanProvider.getContextualReference(ContextControl.class).startContext(TransactionScoped.class);
}

@Test
@Transactional
public void testMe() throws Exception {
   // do something with TransactionScoped EntityManager
}

If I move startContext to @Before method, the same error occurs.


Exception:

testMe(com.parts.persistence.test.repository.PartsRepositoryTest)  Time 
elapsed: 0.063 sec  <<< ERROR!
org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active 
contexts for scope type 
org.apache.deltaspike.jpa.api.transaction.TransactionScoped
at 
org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:680)
at 
org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:79)
at 
org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99)
at 
org.jboss.weld.proxies.EntityManager$893098196$Proxy$_$$_WeldClientProxy.persist(Unknown
 Source)
at 
com.parts.persistence.test.repository.PartsRepositoryTest.testMe(PartsRepositoryTest.java:130)

ideas?

Cheers,
Ove

Re: How can TransactionScoped be started with weld-embedded-1.1

[Ove Ranheim]

Hi Gerhard,

Thanks for your prompt response.

I use shrinkwrap desc:

.getOrCreateInterceptors().clazz(TransactionalInterceptor.class.getName())

.clazz(com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorMandatory.class.getName())

.clazz(com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorNever.class.getName())

.clazz(com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorNotSupported.class.getName())

.clazz(com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.class.getName())

.clazz(com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequiresNew.class.getName())

.clazz(com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorSupports.class.getName()).up()
.getOrCreateAlternatives().clazz(BeanManagedUserTransactionStrategy.class.getName()).up()

According to #2: anything missing?

Roger #1. If I use RequestScoped instead, I get this error:

testMe(com.parts.persistence.test.repository.PartsRepositoryTest)  Time 
elapsed: 0.071 sec  <<< ERROR!
java.lang.NullPointerException: null
at 
org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44)
at 
org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53)
at org.jboss.weld.util.Beans.injectEEFields(Beans.java:331)
at 
org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:59)
at 
org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
at 
org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
at 
org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
at 
org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:150)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
at 
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:733)
at 
org.jboss.weld.injection.producer.AbstractMemberProducer.getReceiver(AbstractMemberProducer.java:128)
at 
org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:148)
at 
org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:183)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
at 
org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98)
at 
org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99)
at 
org.jboss.weld.proxies.EntityManager$893098196$Proxy$_$$_WeldClientProxy.persist(Unknown
 Source)
at 
com.parts.persistence.test.repository.PartsRepositoryTest.testMe(PartsRepositoryTest.java:137)

Appreciate you help!

Cheers,
ove

On 07 Mar 2014, at 19:47, Gerhard Petracek  wrote:

> hi ove,
> 
> #1 currently only std. scopes are supported by ContextControl.
> #2 it will work once TransactionalInterceptor gets called
> 
> regards,
> gerhard
> 
> http://www.irian.at
> 
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 
> 
> 2014-03-07 19:12 GMT+01:00 Ove Ranheim :
> 
>> Hi,
>> 
>> I'm not able to start the TransactionScoped in due time. I'm doing an
>> experiment on using ds-jpa together with JTA-and-Hibernate (
>> https://github.com/jbosstm/quickstart/tree/master/jta-and-hibernate).
>> 
>> The persistence.xml uses JTA and binds to a JdbcDataSource bound to JNDI.
>> If I use the TransactionManager directly, it all works. However, when I use
>> the BeanManagedUserTransactionStrategy it fails. I'd like to make use of
>> the @Transactional and @TransactionScope.
>> 
>> Here are some code snippets.
>> 
>>public static void bindNamingAndTransactionService() throws Exception {
>>if(txInitialized) return;
>>// Start JNDI server
>>NAMING_BEAN.start();
>> 
>>// Bind JTA implementation with default names
>>JNDIManager.bindJTAImplementation();
>> 
>>// Bind JTA implementation with JBoss names. Needed for JTA 1.2
>> implementation.
>>// See https://issues.jboss.org/browse/JBTM-2054
>>// resolve naming parse container for comp and bind
>>NAMING_BEAN.getNamingInstance().createSubcontext(new
>> NamingParser().parse("jboss"));
>> 
>> jtaPropertyManager.getJTAEnvironmentBean().setTransactionManagerJNDIContext("java:/jboss/TransactionManager");
>>jtaPropertyManager.getJTAEnvironme

Re: How can TransactionScoped be started with weld-embedded-1.1

[Ove Ranheim]

public class TestBean {

@Inject
@PartsRepository
private EntityManager em;

@Transactional
public void transaction(TestEntity entity) {
em.persist(entity);
}
}

and in test-case:

@Inject
private TestBean testBean;

@Test
public void testMe() throws Exception {
testBean.transaction(m); // <== exception message below
}

stacktrace:

java.lang.NullPointerException: null
at 
org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44)
at 
org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53)
at org.jboss.weld.util.Beans.injectEEFields(Beans.java:331)
at 
org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:59)
at 
org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
at 
org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
at 
org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
at 
org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:150)
at 
org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
at 
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:733)
at 
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:789)
at 
org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
at 
org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
at 
org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
at 
org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
at 
org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
at 
org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
at 
org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:150)
at 
org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
at 
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:733)
at 
org.jboss.weld.bean.interceptor.CdiInterceptorFactory.create(CdiInterceptorFactory.java:45)
at 
org.jboss.weld.interceptor.proxy.InterceptionContext.initInterceptorInstanceMap(InterceptionContext.java:93)
at 
org.jboss.weld.interceptor.proxy.InterceptionContext.of(InterceptionContext.java:68)
at 
org.jboss.weld.interceptor.proxy.InterceptionContext.forNonConstructorInterception(InterceptionContext.java:63)
at 
org.jboss.weld.injection.producer.InterceptorApplyingInstantiator.newInstance(InterceptorApplyingInstantiator.java:53)
at 
org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:85)
at 
org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:183)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:149)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
at 
org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98)
at 
org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78)
at 
com.parts.persistence.test.repository.TestBean$Proxy$_$$_WeldClientProxy.transaction(Unknown
 Source)
at 
com.parts.persistence.test.repository.PartsRepositoryTest.testMe(PartsRepositoryTest.java:141)


This stacktrace doesn't provide me much lead to what's wrong. Is there a way to 
unwrap what's going on behind the scene:

at 
com.parts.persistence.test.repository.TestBean$Proxy$_$$_WeldClientProxy.transaction(Unknown
 Source)
at 
com.parts.persistence.test.repository.PartsRepositoryTest.testMe(PartsRepositoryTest.java:141)


Cheers,
Ove

On 07 Mar 2014, at 20:11, Gerhard Petracek  wrote:

> you can use a separated class and annotate it (or its methods) with
> @Transactional -> inject it in your test and delegate to it.
> 
> regards,
> gerhard
> 
> http://www.irian.at
> 
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 
> 
> 2014-03-07 19:56 GMT+01:00 Ove Ranheim :
> 
>> Hi Gerhard,
>> 
>> Thanks for your prompt response.
>> 
>> I use shrinkw

Re: How can TransactionScoped be started with weld-embedded-1.1

[Ove Ranheim]

Thanks Gerhard! Will do. Have a nice evening :)

Ove

Sent from my iPhone

> On 7. mars 2014, at 21:46, Gerhard Petracek  
> wrote:
> 
> hi ove,
> 
> please provide a link to a demo-app which illustrates the issue.
> 
> regards,
> gerhard
> 
> http://www.irian.at
> 
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 
> 
> 2014-03-07 21:27 GMT+01:00 Ove Ranheim :
> 
>> public class TestBean {
>> 
>>@Inject
>>@PartsRepository
>>private EntityManager em;
>> 
>>@Transactional
>>public void transaction(TestEntity entity) {
>>em.persist(entity);
>>}
>> }
>> 
>> and in test-case:
>> 
>>@Inject
>>private TestBean testBean;
>> 
>>@Test
>>public void testMe() throws Exception {
>>testBean.transaction(m); // <== exception message below
>>}
>> 
>> stacktrace:
>> 
>> java.lang.NullPointerException: null
>>at
>> org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44)
>>at
>> org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53)
>>at org.jboss.weld.util.Beans.injectEEFields(Beans.java:331)
>>at
>> org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:59)
>>at
>> org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
>>at
>> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
>>at
>> org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
>>at
>> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
>>at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:150)
>>at
>> org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
>>at
>> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:733)
>>at
>> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:789)
>>at
>> org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
>>at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
>>at
>> org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
>>at
>> org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
>>at
>> org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
>>at
>> org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
>>at
>> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
>>at
>> org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
>>at
>> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
>>at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:150)
>>at
>> org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
>>at
>> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:733)
>>at
>> org.jboss.weld.bean.interceptor.CdiInterceptorFactory.create(CdiInterceptorFactory.java:45)
>>at
>> org.jboss.weld.interceptor.proxy.InterceptionContext.initInterceptorInstanceMap(InterceptionContext.java:93)
>>at
>> org.jboss.weld.interceptor.proxy.InterceptionContext.of(InterceptionContext.java:68)
>>at
>> org.jboss.weld.interceptor.proxy.InterceptionContext.forNonConstructorInterception(InterceptionContext.java:63)
>>at
>> org.jboss.weld.injection.producer.InterceptorApplyingInstantiator.newInstance(InterceptorApplyingInstantiator.java:53)
>>at
>> org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:85)
>>at
>> org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:183)
>>at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:149)
>>at
>> org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
>>at
>> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.jav

Re: How can TransactionScoped be started with weld-embedded-1.1

[Ove Ranheim]

vice.java)
at 
com.javafiction.common.persistence.test.ProductServiceTest.testFindAll(ProductServiceTest.java:56)


Thanks to Ivan for making this demo!

I'm after exact equivalent of this test case. The test case fails on: 
deltaspikeProductDAO.save(product);

The demo demonstrates that it works with Spring Data, but breaks with 
DeltaSpike Data.

Cheers,
Ove

On 07 Mar 2014, at 21:46, Gerhard Petracek  wrote:

> hi ove,
> 
> please provide a link to a demo-app which illustrates the issue.
> 
> regards,
> gerhard
> 
> http://www.irian.at
> 
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 
> 
> 2014-03-07 21:27 GMT+01:00 Ove Ranheim :
> 
>> public class TestBean {
>> 
>>@Inject
>>@PartsRepository
>>private EntityManager em;
>> 
>>@Transactional
>>public void transaction(TestEntity entity) {
>>em.persist(entity);
>>}
>> }
>> 
>> and in test-case:
>> 
>>@Inject
>>private TestBean testBean;
>> 
>>@Test
>>public void testMe() throws Exception {
>>testBean.transaction(m); // <== exception message below
>>}
>> 
>> stacktrace:
>> 
>> java.lang.NullPointerException: null
>>at
>> org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44)
>>at
>> org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53)
>>at org.jboss.weld.util.Beans.injectEEFields(Beans.java:331)
>>at
>> org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:59)
>>at
>> org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
>>at
>> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
>>at
>> org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
>>at
>> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
>>at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:150)
>>at
>> org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
>>at
>> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:733)
>>at
>> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:789)
>>at
>> org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
>>at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
>>at
>> org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
>>at
>> org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
>>at
>> org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
>>at
>> org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
>>at
>> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
>>at
>> org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
>>at
>> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
>>at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:150)
>>at
>> org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
>>at
>> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:733)
>>at
>> org.jboss.weld.bean.interceptor.CdiInterceptorFactory.create(CdiInterceptorFactory.java:45)
>>at
>> org.jboss.weld.interceptor.proxy.InterceptionContext.initInterceptorInstanceMap(InterceptionContext.java:93)
>>at
>> org.jboss.weld.interceptor.proxy.InterceptionContext.of(InterceptionContext.java:68)
>>at
>> org.jboss.weld.interceptor.proxy.InterceptionContext.forNonConstructorInterception(InterceptionContext.java:63)
>>at
>> org.jboss.weld.injection.producer.InterceptorApplyingInstantiator.newInstance(InterceptorApplyingInstantiator.java:53)
>>at
>> org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:85)
>>at
>> org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:183)
>>at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:149)
>>at
>> org.jboss.we

Re: How can TransactionScoped be started with weld-embedded-1.1

[Ove Ranheim]

But I want to use JTA, that's why I include the Narayana and JTA-and-Hiberante.


On 08 Mar 2014, at 08:58, Thomas Hug  wrote:

> Hi Ove,
> 
> By default, the DS JPA module comes with a RESOURCE_LOCAL transaction
> strategy (which the Data module is reusing). Your persistence.xml states a
> JTA transaction type though, so you have to change the transaction strategy
> according to [1].
> 
> Hope that helps,
> Thomas
> 
> [1] http://deltaspike.apache.org/jpa.html#jta-support
> 
> 
> On Fri, Mar 7, 2014 at 11:39 PM, Ove Ranheim  wrote:
> 
>> Hi Gerhard,
>> 
>> Ivan Vasyliev already made a great example that demonstrate this issue
>> (btw: https://issues.apache.org/jira/browse/DELTASPIKE-473).
>> 
>> Please have a look at:
>> https://github.com/vasilievip/cdi-jpa-jta-generic-dao
>> 
>> To properly demonstrate DS behaviour, you must disable the Spring stuff,
>> hence you need to:
>> 
>> pom.xml (comment out)
>> 
>>
>> 
>> SprintDataProductDAO.java (comment out):
>> 
>> public interface SpringDataProductDAO
>> /* extends JpaRepository */
>> {
>> 
>> }
>> 
>> ProductService.java (comment out)
>> 
>> //@Inject
>> //SpringDataProductDAO springProductDAO;
>> 
>> //@Transactional
>> //public List findAll() {
>> //assert springProductDAO != null;
>> //List products = new ArrayList();
>> //Iterator productIterator =
>> springProductDAO.findAll().iterator();
>> //while (productIterator.hasNext()) {
>> //products.add(productIterator.next());
>> //}
>> //return products;
>> //}
>> //
>> //@Transactional
>> //public Long save(Product product) {
>> //assert springProductDAO != null;
>> //springProductDAO.save(product);
>> //return product.getId();
>> //}
>> 
>> Exception stracktrace:
>> 
>> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.841 sec
>> <<< FAILURE! - in com.javafiction.common.persistence.test.ProductServiceTest
>> testFindAll(com.javafiction.common.persistence.test.ProductServiceTest)
>> Time elapsed: 1.808 sec  <<< ERROR!
>> org.apache.deltaspike.data.api.QueryInvocationException: Failed calling
>> Repository:
>> [Repository=com.acme.persistence.DeltaspikeProductDAO,entity=com.acme.model.Product,method=save,exception=class
>> java.lang.IllegalStateException,message=A JTA EntityManager cannot use
>> getTransaction()
>>at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.getTransaction(AbstractEntityManagerImpl.java:1368)
>>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
>> com.javafiction.common.persistence.resources.JtaEntityManagerProxy.invoke(JtaEntityManagerProxy.java:45)
>>at com.sun.proxy.$Proxy63.getTransaction(Unknown Source)
>>at
>> org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.getTransaction(ResourceLocalTransactionStrategy.java:308)
>>at
>> org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.rollbackAllTransactions(ResourceLocalTransactionStrategy.java:274)
>>at
>> org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.execute(ResourceLocalTransactionStrategy.java:153)
>>at
>> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeTransactional(TransactionalQueryRunner.java:72)
>>at
>> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeQuery(TransactionalQueryRunner.java:54)
>>at
>> org.apache.deltaspike.data.impl.handler.QueryHandler.invoke(QueryHandler.java:80)
>>at com.sun.proxy.$Proxy61.save(Unknown Source)
>>at com.acme.services.ProductService.save2(ProductService.java:72)
>> // <= this is the real issue
>>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.apa

DS Logging

[Ove Ranheim]

Hi,

How can I capture the DS logger for slf4j? The first part of the log uses 
logback, but DS doesn't get captured by slf4j/logback.


13:52:01.681 [main] INFO  org.jboss.weld.Version - WELD-000900: 2.1.2 (Final)
13:52:02.011 [main] INFO  org.jboss.weld.Bootstrap - WELD-000101: Transactional 
services not available. Injection of @Inject UserTransaction not available. 
Transactional observers will be invoked synchronously.
13:52:02.284 [main] INFO  o.s.d.j.r.cdi.JpaRepositoryExtension - Activating CDI 
extension for Spring Data JPA repositories.
13:52:02.350 [main] WARN  org.jboss.weld.Event - WELD-000411: Observer method 
[BackedAnnotatedMethod] protected 
org.springframework.data.repository.cdi.CdiRepositoryExtensionSupport.processAnnotatedType(@Observes
 ProcessAnnotatedType) receives events for all annotated types. 
Consider restricting events using @WithAnnotations or a generic type with 
bounds.
13:52:02.362 [main] WARN  org.jboss.weld.Event - WELD-000411: Observer method 
[BackedAnnotatedMethod] protected 
org.apache.deltaspike.core.impl.message.MessageBundleExtension.detectInterfaces(@Observes
 ProcessAnnotatedType) receives events for all annotated types. 
Consider restricting events using @WithAnnotations or a generic type with 
bounds.
13:52:02.397 [main] WARN  org.jboss.weld.Event - WELD-000411: Observer method 
[BackedAnnotatedMethod] protected 
org.apache.deltaspike.core.impl.exclude.extension.ExcludeExtension.vetoBeans(@Observes
 ProcessAnnotatedType, BeanManager) receives events for all annotated 
types. Consider restricting events using @WithAnnotations or a generic type 
with bounds.
Mar 08, 2014 1:52:02 PM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: org.apache.deltaspike.core.impl.scope.DeltaSpikeContextExtension 
activated=true
Mar 08, 2014 1:52:02 PM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: org.apache.deltaspike.core.impl.config.ConfigurationExtension 
activated=true
Mar 08, 2014 1:52:02 PM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: 
org.apache.deltaspike.core.impl.exception.control.extension.ExceptionControlExtension
 activated=true
Mar 08, 2014 1:52:02 PM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: org.apache.deltaspike.core.impl.message.MessageBundleExtension 
activated=true
Mar 08, 2014 1:52:02 PM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: 
org.apache.deltaspike.core.impl.message.NamedMessageBundleInvocationHandler 
activated=true
Mar 08, 2014 1:52:02 PM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: org.apache.deltaspike.core.impl.exclude.extension.ExcludeExtension 
activated=true
Mar 08, 2014 1:52:02 PM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: 
org.apache.deltaspike.core.impl.exclude.CustomProjectStageBeanFilter 
activated=true
Mar 08, 2014 1:52:02 PM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: org.apache.deltaspike.core.impl.exclude.GlobalAlternative 
activated=true
Mar 08, 2014 1:52:02 PM org.apache.deltaspike.core.util.ClassDeactivationUtils 
cacheResult
INFO: class: org.apache.deltaspike.core.impl.jmx.MBeanExtension activated=true
Mar 08, 2014 1:52:02 PM org.apache.deltaspike.core.util.ProjectStageProducer 
initProjectStage
INFO: Computed the following DeltaSpike ProjectStage: UnitTest
Running com.parts.persistence.test.testcontrol.CdiPartsRepositoryTest
Mar 08, 2014 1:52:03 PM 
org.apache.deltaspike.testcontrol.api.junit.CdiTestSuiteRunner$LogRunListener 
testStarted
INFO: [run] 
com.parts.persistence.test.testcontrol.CdiPartsRepositoryTest#testTxSyncManager
Mar 08, 2014 1:52:03 PM 
org.apache.deltaspike.testcontrol.api.junit.CdiTestSuiteRunner$LogRunListener 
testFinished
INFO: [finished] 
com.parts.persistence.test.testcontrol.CdiPartsRepositoryTest#testTxSyncManager
Mar 08, 2014 1:52:03 PM 
org.apache.deltaspike.testcontrol.api.junit.CdiTestSuiteRunner$LogRunListener 
testStarted
INFO: [run] com.parts.persistence.test.testcontrol.CdiPartsRepositoryTest#testMe

My slf4j dependencies are:


org.slf4j
slf4j-api


org.slf4j
jul-to-slf4j
1.7.5


ch.qos.logback
logback-classic
1.0.13



Cheers,
Ove
 

Re: first steps for the next release

[Ove Ranheim]

+1 awesome :-)


2014-03-12 11:26 GMT+01:00 Romain Manni-Bucau :

> +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  >:
> > +1
> > thanks gerhard
> >
> >
> > 2014-03-12 11:14 GMT+01:00 Gerhard Petracek :
> >
> >> 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
> >>
>

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

[Ove Ranheim]

+1

Sent from my iPhone

> On 16. mars 2014, at 20:50, Thomas Andraschko  
> wrote:
> 
> +1
> 
> 
> 2014-03-16 20:19 GMT+01:00 Romain Manni-Bucau :
> 
>> +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 :
>>> +1.
>>> 
>>> Don't forget to cancel the prior vote.
>>> 
>>> On Sun, Mar 16, 2014 at 1:31 PM, Gerhard Petracek 
>> 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
>> 

Re: [VOTE] logo-shape

[Ove Ranheim]

+1 #12 and #1

Ove

Sent from my iPhone

> On 11. juni 2014, at 21:41, Cody Lerum  wrote:
> 
> +1 for #1
> 
>> On Wed, Jun 11, 2014 at 10:51 AM, Gerhard Petracek  
>> wrote:
>> hi @ all,
>> 
>> this first vote is just about the basic shape/style and >not< the color.
>> 
>> i've uploaded the candidates provided by jim at [1].
>> please send a +1 for one (or two) logo shape/s.
>> (there will be a 2nd vote about the color afterwards.)
>> 
>> regards,
>> gerhard
>> 
>> [1] http://s.apache.org/DS_LOGO1_VOTE1

Custom TransactionServices in DS/Weld

[Ove Ranheim]

Hi,

I'd like to register my own TransactionServices implementation (custom 
NarayanaTransactionServices). Is there a way to register this in DS (config 
source?), so it would be loaded during WeldBoostrap startup? 
(https://github.com/stuartwdouglas/weld-core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldStartup.java#L205)

Here's another example using Bitronix: 
https://developer.jboss.org/message/848326#848326

Br, Ove

Re: Custom TransactionServices in DS/Weld

[Ove Ranheim]

Hi Gerhard

Maybe my question wasn't clear enough. The purpose was to have a custom 
TransactionService (weld-interface) loaded during container boot. I brought 
this up on the [1] JBoss Weld Forum and through [2] WELD-1495.

Thanks to Jozef Hartinger for creating a [3][4] PR today. Weld 3.0.0.Alpha2 
will most likely support an SPI that allows us to override load behaviour of 
ie. MockTransactionServices in arquillian-weld-ee-embedded-1.1 during startup. 
Basically, Weld can load a custom transaction service that overrides an 
existing bootstrap by other integrators.

The BeanManagedUserTransactionStrategy requires JTA service to be available by 
the container in order to be used. I've made my temporary patch for Weld 2.2.4 
and it works as expected.

Cheers
Ove

[1] https://developer.jboss.org/message/905533#905533
[2] https://issues.jboss.org/browse/WELD-1495
[3] https://github.com/weld/core/pull/682
[4] 
https://github.com/jharting/core/commit/962f8eff5cc09002c3a45404021108f10cf1fce2


On 30 Sep 2014, at 21:02, Gerhard Petracek  wrote:

> hi ove,
> 
> please have a look at the hints about (a custom) TransactionStrategy (see
> [1]).
> 
> regards,
> gerhard
> 
> [1] http://deltaspike.apache.org/documentation/jpa.html
> 
> 
> 
> 2014-09-29 21:57 GMT+02:00 Ove Ranheim :
> 
>> Hi,
>> 
>> I'd like to register my own TransactionServices implementation (custom
>> NarayanaTransactionServices). Is there a way to register this in DS (config
>> source?), so it would be loaded during WeldBoostrap startup? (
>> https://github.com/stuartwdouglas/weld-core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldStartup.java#L205
>> )
>> 
>> Here's another example using Bitronix:
>> https://developer.jboss.org/message/848326#848326
>> 
>> Br, Ove
>> 
>> 

DS Data and WeldEE causes: URL does not exist: archive:test.war/WEB-INF/classes/META-INF/persistence.xml

[Ove Ranheim]

Hi,

I have a test case that uses jpa-module and hibernate; using 
org.jboss.arquillian.container:arquillian-weld-ee-embedded-1.1:1.0.0.CR8. The 
persistence.xml and the test case works correctly.

When I add the data-module, it tries to load the persistence.xml over again and 
it fails with: URL does not exist: 
archive:test.war/WEB-INF/classes/META-INF/persistence.xml

* Is there a way to disable DescriptorReader to load persistence.xml?
* Why does data-module load the persistence.xml?
* Any other way to circumvent this problem?
* Is this a bug?

I read through Mark's blog post: 
http://struberg.wordpress.com/2012/03/27/unit-testing-strategies-for-cdi-based-projects/,
 which indicates that this may be due to a  classloading issue. The links to 
Arquillian Wiki is broken (under "Embedded style Arquillian tests"), so I'm a 
bit lost.

Regards
Ove


INFO: class: org.apache.deltaspike.data.impl.RepositoryExtension activated=true
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: -123,542.439 
sec <<< FAILURE! - in org.jboss.weld.WeldTransactionServicesTest
org.jboss.weld.WeldTransactionServicesTest  Time elapsed: -123,542.44 sec  <<< 
ERROR!
org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
java.lang.IllegalArgumentException: URL does not exist: 
archive:test.war/WEB-INF/classes/META-INF/persistence.xml
at 
org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
at 
org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
at 
org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
at 
org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
at 
org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
at 
org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
at 
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271)
at 
org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
at 
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:258)
at 
org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:237)
at 
org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:174)
at 
org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:133)
at 
org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:107)
at 
org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54)
at 
org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42)
at 
org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:45)
at 
org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:385)
at 
org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
at 
org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.startContainer(TestContainer.java:273)
at 
org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:105)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Re: Data Module - some issues in SE/Maven Tests

[Ove Ranheim]

Which class should be excluded in beans.xml to omit the
"archive:.../persistence.xml" exception?

2014-09-02 11:29 GMT+02:00 John D. Ament :

> For the first issue, looks like if I just exclude the file from the archive
> my problems are resolved.  I'll go with that for now.  For some reason,
> this issue doesn't pop up using META-INF/apache-deltaspike.properties but
> using the same approach doesn't fix it.
>
> For the second, the easiest fix I have (that's also a bit clean) is to
> simply veto the class within the repository extension.  If there are no
> objections, I'll commit that change this morning.  Right now I cannot
> exclude the API from the uber jar.
>
> John
>
>
> On Tue, Sep 2, 2014 at 3:17 AM, Thomas Hug  wrote:
>
> > Instead of patching the second one, for an uber-jar it might also be a
> > valid recommendation to exclude the class over the beans.xml.
> >
> >
> > On Tue, Sep 2, 2014 at 8:12 AM, Thomas Hug  wrote:
> >
> > > Hi John
> > >
> > > First one should - as Romain mentioned - usually not be a problem.
> Might
> > > still be worth adding the exception check as I've run into problems on
> > WLS
> > > with this particular approach. We lose the ability to deal with
> entities
> > > defined in orm.xml's but that's probably still better than crashing :-)
> > >
> > > The second one comes from creating an uber-jar - the api module doesn't
> > > have a beans.xml. Can't think of a different approach to get rid of
> this
> > > one...
> > >
> > >
> > > On Tue, Sep 2, 2014 at 6:54 AM, Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > >> Hi
> > >>
> > >> Archive url issue is due to the arquillian adapter (so no problem for
> > data
> > >> module)
> > >>
> > >> Can't the other one be fixed using @Typed?
> > >> Le 1 sept. 2014 21:41, "John D. Ament"  a
> > écrit :
> > >>
> > >> > Hi All!
> > >> >
> > >> > I've hit a couple of issues with the Data Module and wanted to know
> if
> > >> it
> > >> > was worth fixing.
> > >> >
> > >> > First, my sample app can be found at [1] (note you'll need JDK8 to
> > run)
> > >> and
> > >> > you can run the test JPATest to see the results, using
> > >> >
> > >> > mvn -Dtest=JPATest -Ddeltaspike.version=1.0.2
> > >> >
> > >> > First issue you'll note is that the following output (or something
> > >> similar
> > >> > to it will be given):
> > >> >
> > >> > java.lang.IllegalArgumentException: URL does not exist:
> > >> > archive:se-examples.jar/META-INF/persistence.xml
> > >> >
> > >> > at
> > >> >
> > >> >
> > >>
> >
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
> > >> >
> > >> > at
> > >> >
> > >> >
> > >>
> >
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
> > >> >
> > >> > at
> > >> >
> > >> >
> > >>
> >
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
> > >> >
> > >> > at
> > >> >
> > >> >
> > >>
> >
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
> > >> >
> > >> > at
> > >> >
> > >> >
> > >>
> >
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
> > >> >
> > >> > at
> > >> >
> > >> >
> > >>
> >
> org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:73)
> > >> >
> > >> > (full stack available at [2], test.log).  It seems like the
> > >> > RepositoryExtension is picking up on my persistence.xml and
> > aggressively
> > >> > trying to parse them (at this point, I don't have any @Repository's
> > >> defined
> > >> > in my app).  For some reason it cannot parse this URL but it does
> seem
> > >> to
> > >> > pick up the persistence.xml from target/classes/META-INF so it does
> > >> > eventually parse it.  To work around this, I wrapped
> > >> > DescriptorReader.readAllFromClassPath's result.add with an exception
> > >> check.
> > >> >  I figure if it can't read the descriptor, no reason to make the
> whole
> > >> app
> > >> > die.  What do you think?
> > >> >
> > >> > Second issue, after fixing this one, was that
> AbstractEntityRepository
> > >> was
> > >> > being picked up as a @Repository and erroring out saying that
> there's
> > no
> > >> > entity for it. This one I wasn't expecting.  To fix it, in
> > >> > RepsitoryComponents, I added an explicit check if it was the base
> > >> class, if
> > >> > it was return null rather than exception and check for null in the
> add
> > >> > method.  This also fixed things and the tests started running fine.
> > >> This
> > >> > fix seems more hacky, and I'm wondering if I'm just doing something
> > >> wrong
> > >> > to make this class be picked up.
> > >> >
> > >> > You can see the summary of changes in the gist's patch.txt.
> > >> >
> > >> > John
> > >> >
> > >> >
> > >> > [1]: https://github.com/johnament/restful-and-beyond-tut2184
> > >> > [2]: https://gist.github.com/johnament/d4a55ce7251062ee0b8

Re: DS Data and WeldEE causes: URL does not exist: archive:test.war/WEB-INF/classes/META-INF/persistence.xml

[Ove Ranheim]

Hi Thomas

I created this issue: https://issues.apache.org/jira/browse/DELTASPIKE-740.

Thanks for point out John's posting.

Best regards
Ove

On 10 Oct 2014, at 09:47, Thomas Hug  wrote:

> Hi Ove
> 
> AFAIR John ran into similar issues recently, see
> http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201409.mbox/%3ccaoqetn9hat9yiorqtsafbo5ysmntngaqpet4bnxtw9-czw5...@mail.gmail.com%3E
> 
> The reason we look for persistence.xml is to extract the orm.xml files -
> we're mainly interested in those as they define entities, primary keys etc.
> which is cached for later usage. Agree that failing deployments might be
> too aggressive. An option would be to have a dedicated extension for
> scanning which can be deactivated (as most use cases will have annotation
> based entities anyway).
> 
> On Fri, Oct 10, 2014 at 8:13 AM, Ove Ranheim  wrote:
> 
>> Hi,
>> 
>> I have a test case that uses jpa-module and hibernate; using
>> org.jboss.arquillian.container:arquillian-weld-ee-embedded-1.1:1.0.0.CR8.
>> The persistence.xml and the test case works correctly.
>> 
>> When I add the data-module, it tries to load the persistence.xml over
>> again and it fails with: URL does not exist:
>> archive:test.war/WEB-INF/classes/META-INF/persistence.xml
>> 
>> * Is there a way to disable DescriptorReader to load persistence.xml?
>> * Why does data-module load the persistence.xml?
>> * Any other way to circumvent this problem?
>> * Is this a bug?
>> 
>> I read through Mark's blog post:
>> http://struberg.wordpress.com/2012/03/27/unit-testing-strategies-for-cdi-based-projects/,
>> which indicates that this may be due to a  classloading issue. The links to
>> Arquillian Wiki is broken (under "Embedded style Arquillian tests"), so I'm
>> a bit lost.
>> 
>> Regards
>> Ove
>> 
>> 
>> INFO: class: org.apache.deltaspike.data.impl.RepositoryExtension
>> activated=true
>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
>> -123,542.439 sec <<< FAILURE! - in
>> org.jboss.weld.WeldTransactionServicesTest
>> org.jboss.weld.WeldTransactionServicesTest  Time elapsed: -123,542.44 sec
>> <<< ERROR!
>> org.jboss.weld.exceptions.DefinitionException: Exception List with 1
>> exceptions:
>> Exception 0 :
>> java.lang.IllegalArgumentException: URL does not exist:
>> archive:test.war/WEB-INF/classes/META-INF/persistence.xml
>>at
>> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
>>at
>> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
>>at
>> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
>>at
>> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
>>at
>> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
>>at
>> org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:74)
>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>at java.lang.reflect.Method.invoke(Method.java:483)
>>at
>> org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
>>at
>> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271)
>>at
>> org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
>>at
>> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:258)
>>at
>> org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:237)
>>at
>> org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:174)
>>at
>> org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:133)
>>at
>> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:107)
>>at
>> org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54)
>>at
>> org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42)
>>at
>>

Re: DS Data and WeldEE causes: URL does not exist: archive:test.war/WEB-INF/classes/META-INF/persistence.xml

[Ove Ranheim]

Hi John,

I followed your excellent rest and beyond showcase. Switched to properties for 
building my EntityManagerFactory and it works.

Still I hope DELTASPIKE-740 will be fixed. I'm studying the rest and beyond. 
It's exactly what I'm after. A lightweight stack using bits of EE. And Undertow 
is awesome!!

Cheers
Ove

On 11 Oct 2014, at 16:08, John D. Ament  wrote:

> Ove,
> 
> Please try the same thing I did - don't include persistence.xml in your JAR
> file.  Assuming it's in the right spot on your classpath, it should still
> get picked up when running embedded.
> 
> I was planning to add a failDeploymentIfPersistenceXmlNotReadable to
> apache-deltaspike.properties to handle this case.  By default you would get
> the current behaviour, but you could turn it off if you so choose.  I
> simply didn't have time before J1 to fix it.  WDYT?
> 
> John
> 
> On Sat, Oct 11, 2014 at 5:23 AM, Ove Ranheim  wrote:
> 
>> Hi Thomas
>> 
>> I created this issue: https://issues.apache.org/jira/browse/DELTASPIKE-740
>> .
>> 
>> Thanks for point out John's posting.
>> 
>> Best regards
>> Ove
>> 
>> On 10 Oct 2014, at 09:47, Thomas Hug  wrote:
>> 
>>> Hi Ove
>>> 
>>> AFAIR John ran into similar issues recently, see
>>> 
>> http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201409.mbox/%3ccaoqetn9hat9yiorqtsafbo5ysmntngaqpet4bnxtw9-czw5...@mail.gmail.com%3E
>>> 
>>> The reason we look for persistence.xml is to extract the orm.xml files -
>>> we're mainly interested in those as they define entities, primary keys
>> etc.
>>> which is cached for later usage. Agree that failing deployments might be
>>> too aggressive. An option would be to have a dedicated extension for
>>> scanning which can be deactivated (as most use cases will have annotation
>>> based entities anyway).
>>> 
>>> On Fri, Oct 10, 2014 at 8:13 AM, Ove Ranheim  wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I have a test case that uses jpa-module and hibernate; using
>>>> 
>> org.jboss.arquillian.container:arquillian-weld-ee-embedded-1.1:1.0.0.CR8.
>>>> The persistence.xml and the test case works correctly.
>>>> 
>>>> When I add the data-module, it tries to load the persistence.xml over
>>>> again and it fails with: URL does not exist:
>>>> archive:test.war/WEB-INF/classes/META-INF/persistence.xml
>>>> 
>>>> * Is there a way to disable DescriptorReader to load persistence.xml?
>>>> * Why does data-module load the persistence.xml?
>>>> * Any other way to circumvent this problem?
>>>> * Is this a bug?
>>>> 
>>>> I read through Mark's blog post:
>>>> 
>> http://struberg.wordpress.com/2012/03/27/unit-testing-strategies-for-cdi-based-projects/
>> ,
>>>> which indicates that this may be due to a  classloading issue. The
>> links to
>>>> Arquillian Wiki is broken (under "Embedded style Arquillian tests"), so
>> I'm
>>>> a bit lost.
>>>> 
>>>> Regards
>>>> Ove
>>>> 
>>>> 
>>>> INFO: class: org.apache.deltaspike.data.impl.RepositoryExtension
>>>> activated=true
>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
>>>> -123,542.439 sec <<< FAILURE! - in
>>>> org.jboss.weld.WeldTransactionServicesTest
>>>> org.jboss.weld.WeldTransactionServicesTest  Time elapsed: -123,542.44
>> sec
>>>> <<< ERROR!
>>>> org.jboss.weld.exceptions.DefinitionException: Exception List with 1
>>>> exceptions:
>>>> Exception 0 :
>>>> java.lang.IllegalArgumentException: URL does not exist:
>>>> archive:test.war/WEB-INF/classes/META-INF/persistence.xml
>>>>   at
>>>> 
>> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
>>>>   at
>>>> 
>> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
>>>>   at
>>>> 
>> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
>>>>   at
>>>> 
>> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
>>>>   at
>>>> 
>> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(Per

ExternalContainer and No active context for RequestScoped

[Ove Ranheim]

Hi,

I'm looking into the ExternalContainer impl in test-control and it throws the 
exception: No active contexts for scope type 
javax.enterprise.context.RequestScoped

Fair enough, but how do I start the ReqeustScope using cdictrl (?), since it is 
the CdiTestControl that actually boots the container.

@RunWith(PartsTestRunner.class)
@TestControl(startScopes = RequestScoped.class, startExternalContainers = true)
public class CdiTest {
}

@ApplicationScoped
public class UndertowTestContainer implements TestAware, ExternalContainer {
  ...
}

And added 
META-INF/services/org.apache.deltaspike.testcontrol.spi.ExternalContainer :
com.parts.server.undertow.container.UndertowTestContainer

The documentation is slightly sparse, so hope you can advise.

Best regards
Ove


Oct 15, 2014 6:48:39 PM 
org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareTestContext
 bootExternalContainers
WARNING: booting 
com.parts.server.undertow.container.UndertowTestContainer$Proxy$_$$_WeldClientProxy
 failed
org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active 
contexts for scope type javax.enterprise.context.RequestScoped
at 
org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:687)
at 
org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:79)
at 
org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99)
at 
org.jboss.weld.proxies.DynamicMockManager$1289583109$Proxy$_$$_WeldClientProxy.getMock(Unknown
 Source)
at 
org.apache.deltaspike.testcontrol.impl.mock.MockAwareInjectionTargetWrapper.produce(MockAwareInjectionTargetWrapper.java:59)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:149)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
at 
org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98)
at 
org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78)
at 
com.parts.server.undertow.container.UndertowTestContainer$Proxy$_$$_WeldClientProxy.setTestClass(Unknown
 Source)
at 
org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareTestContext.bootExternalContainers(CdiTestRunner.java:522)
at 
org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareTestContext.applyBeforeClassConfig(CdiTestRunner.java:458)
at 
org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$BeforeClassStatement.evaluate(CdiTestRunner.java:360)
at 
org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$AfterClassStatement.evaluate(CdiTestRunner.java:387)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.run(CdiTestRunner.java:136)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:141)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:114)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:86)
at 
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

18:48:39.635 [main] WARN  o.a.d.t.api.junit.CdiTestRunner - booting 
com.parts.server.undertow.container.UndertowTestContainer$Proxy$_$$_WeldClientProxy
 failed
org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active 
contexts for scope type javax.enterprise.context.RequestScoped
at 
org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:687) 
~[weld-core-2.2.4.Final.jar:2014-07-18 16:55]
at 
org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:79)
 ~[weld-core-2.2.4.Final.jar:2014-07-18 16:55]
at 
org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99) 
~[weld-core-2.2.4.Final.jar:2014-07-18 16:55]
at 
org.jboss

Unable to enable alternative BeanManagedUserTransactionStrategy

[Ove Ranheim]

Hi,

I’m get an error when I try to enable the BeanManagedUserTransactionStrategy in 
beans.xml.

Any ideas?

Ove

org.jboss.weld.exceptions.DeploymentException: WELD-001422: Enabled alternative 
org.apache.deltaspike.jpa.impl.transaction.BeanManagedUserTransactionStrategy
 in 
file:/.../parts-backend/persistence/impl/target/test-classes/META-INF/beans.xml@19
 is not an alternative
at 
org.jboss.weld.bootstrap.Validator.validateEnabledAlternativeClasses(Validator.java:725)
at 
org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:483)
at 
org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:437)
at 
org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:151)
at 
org.apache.deltaspike.cdise.weld.WeldContainerControl.boot(WeldContainerControl.java:65)
at 
org.apache.deltaspike.cdise.weld.WeldContainerControl.boot(WeldContainerControl.java:73)
at 
org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareTestContext.applyBeforeClassConfig(CdiTestRunner.java:462)
at 
org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$BeforeClassStatement.evaluate(CdiTestRunner.java:365)
at 
org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$AfterClassStatement.evaluate(CdiTestRunner.java:392)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.run(CdiTestRunner.java:141)
at 
com.parts.mock.undertow.api.PartsTestRunner.run(PartsTestRunner.java:154)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:141)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:114)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:86)
at 
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

Re: Unable to enable alternative BeanManagedUserTransactionStrategy

[Ove Ranheim]

Hi Gerhard,

Please have a look at this Gist: 
https://gist.github.com/oranheim/97e65c33ef1ed58fdcac 
<https://gist.github.com/oranheim/97e65c33ef1ed58fdcac>

The reason for the exception below, was due to wrong JNDI lookup in 
BeanManagedUserTransactionStrategy. Now that I’ve fixed that, it turns out 
BeanManagedUserTransactionStrategy#resolveEntityManagerForQualifier is not able 
to resolve my EntityManager.

I made a simple test to check if ActiveEntityManagerHolder is able to resolve 
my @Inject @PartsRepository EntityManager. When the EM is injectedon the test 
case it works. But not in the 
BeanManagedUserTransactionStrategy#resolveEntityManagerForQualifier, because 
ActiveEntityManagerHolder.get() returns null.

Is something wrong with my EntityManager producer (see gist)? 

Br, Ove


> On 02 Mar 2015, at 00:05, Gerhard Petracek  wrote:
> 
> hi ove,
> 
> please provide more details about your setup.
> 
> regards,
> gerhard
> 
> 
> 
> 2015-03-01 23:47 GMT+01:00 Ove Ranheim :
> 
>> Hi,
>> 
>> I’m get an error when I try to enable the
>> BeanManagedUserTransactionStrategy in beans.xml.
>> 
>> Any ideas?
>> 
>> Ove
>> 
>> org.jboss.weld.exceptions.DeploymentException: WELD-001422: Enabled
>> alternative
>> org.apache.deltaspike.jpa.impl.transaction.BeanManagedUserTransactionStrategy
>> in
>> file:/.../parts-backend/persistence/impl/target/test-classes/META-INF/beans.xml@19
>> is not an alternative
>>at
>> org.jboss.weld.bootstrap.Validator.validateEnabledAlternativeClasses(Validator.java:725)
>>at
>> org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:483)
>>at
>> org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:437)
>>at
>> org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
>>at org.jboss.weld.environment.se.Weld.initialize(Weld.java:151)
>>at
>> org.apache.deltaspike.cdise.weld.WeldContainerControl.boot(WeldContainerControl.java:65)
>>at
>> org.apache.deltaspike.cdise.weld.WeldContainerControl.boot(WeldContainerControl.java:73)
>>at
>> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareTestContext.applyBeforeClassConfig(CdiTestRunner.java:462)
>>at
>> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$BeforeClassStatement.evaluate(CdiTestRunner.java:365)
>>at
>> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$AfterClassStatement.evaluate(CdiTestRunner.java:392)
>>at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>>at
>> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.run(CdiTestRunner.java:141)
>>at
>> com.parts.mock.undertow.api.PartsTestRunner.run(PartsTestRunner.java:154)
>>at org.junit.runners.Suite.runChild(Suite.java:128)
>>at org.junit.runners.Suite.runChild(Suite.java:24)
>>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>>at
>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>>at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>>at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>>at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>>at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
>>at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
>>at
>> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:141)
>>at
>> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:114)
>>at
>> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:86)
>>at
>> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
>>at
>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>>at
>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>>at
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>> 
>> 
>> 

[jira] [Commented] (DELTASPIKE-308) Port functionality from Seam Mail module

[Ove Ranheim (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669119#comment-13669119
 ] 

Ove Ranheim commented on DELTASPIKE-308:


CDI Mail is discontinued and Seam Mail was its foundation.

If CDI Mail doesn't follow JSR specs, maybe Apache James Protocols is a 
candiate: http://james.apache.org/protocols/index.html

The performance is great and it is as usable as JavaMail can be. The IMAP4 impl 
is awesome.

> Port functionality from Seam Mail module
> 
>
> Key: DELTASPIKE-308
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-308
> Project: DeltaSpike
>  Issue Type: Wish
>Reporter: Adrian Mitev
>Assignee: Cody Lerum
>Priority: Minor
> Fix For: 0.5
>
>
> seam-mail is a nice module that eases the mail sending and contains a fluent 
> api for that. Such API will be very useful for many users.

--
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-740) Data module causes arquillian-weld-ee-embedded to fail when persistence.xml is present

[Ove Ranheim (JIRA)]

Ove Ranheim created DELTASPIKE-740:
--

 Summary: Data module causes arquillian-weld-ee-embedded to fail 
when persistence.xml is present
 Key: DELTASPIKE-740
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-740
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 1.0.3
 Environment: arquillian:1.0.3.Final
org.jboss.arquillian.container:arquillian-weld-ee-embedded-1.1:1.0.0.CR8
Reporter: Ove Ranheim


When persistence.xml is added to shrinkwrap using weld-ee container the Data 
module fails to load and the test case crashes. 

{code}
@Deployment
public static WebArchive createDeployment() {

return ShrinkWrap.create(WebArchive.class, "test.war")
.addAsLibraries(ShrinkWrapArchiveUtil.getArchives(null, 
"META-INF/beans.xml", new String[]{
"org.apache.deltaspike.core",
"org.apache.deltaspike.descriptor.category"
}, null, null))
.addPackage(MyRepository.class.getPackage())
.addClass(TestEntity.class)
.addAsResource("META-INF/persistence.xml")
.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml")
;
}
{code}

{code}
INFO: class: org.apache.deltaspike.data.impl.RepositoryExtension activated=true
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: -123,542.439 
sec <<< FAILURE! - in org.jboss.weld.WeldTransactionServicesTest
org.jboss.weld.WeldTransactionServicesTest  Time elapsed: -123,542.44 sec  <<< 
ERROR!
org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
java.lang.IllegalArgumentException: URL does not exist: 
archive:test.war/WEB-INF/classes/META-INF/persistence.xml
at 
org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
at 
org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
at 
org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
at 
org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
at 
org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
at 
org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
at 
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271)
at 
org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
at 
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:258)
at 
org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:237)
at 
org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:174)
at 
org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:133)
at 
org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:107)
at 
org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54)
at 
org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42)
at 
org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:45)
at 
org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:385)
at 
org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
at 
org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.startContainer(TestContainer.java:273)
at 
org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:105)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127