date:20131001

Re: DS + JSF 2.2

2013-10-01 Thread Mark Struberg

well, the stuff I had is mostly committed to DS already. It's really my lack of 
time and that I'm not currently have many JSF projects which indirectly (lack 
of time) prevent me from doing more work on that part. I use almost all other 
parts of DS in my current project though. 

Actually if it would be only me then I would switch the current project to JSF 
because although JSF is not perfect from a UI perspective it is still miles 
better than many of it's 'modern' competitors in regards of the data processing 
lifecycle. 
So I'm really keen to finish the rest of the ds-jsf scopes - but I don't have 
enough time and power to do it alone of course.

LieGrue,
strub




- Original Message -
> From: Thomas Andraschko 
> To: dev@deltaspike.apache.org
> Cc: 
> Sent: Tuesday, 1 October 2013, 20:00
> Subject: Re: DS + JSF 2.2
> 
> +1 Gerhard
> 
> "we" should really try to take it to the street.
> 
> I don't know if i can help you that much but i finished with my work on
> PrimeFaces 4.0 - so if you need help, just ping me!
> 
> 
> 
> 2013/10/1 Gerhard Petracek 
> 
>>  since you started almost a year ago, it would be nice if you push the
>>  current draft to your github repository.
>> 
>>  regards,
>>  gerhard
>> 
>> 
>> 
>>  2013/10/1 Mark Struberg 
>> 
>>  > Yes, I intended to fix this since a long time. But I'm atm fully 
> blasted
>>  > with $$dayjob work. And the current customer does not use JSF but 
> Vaadin
>>  > (which is nice for rendering but has nothing like the data lifecycle 
> of
>>  > JSF, so it's much work we need to du ourself). So I can really 
> only work
>>  on
>>  > it in my very limited spare time.
>>  >
>>  >
>>  > LieGrue,
>>  > strub
>>  >
>>  >
>>  >
>>  > - Original Message -
>>  > > From: Thomas Andraschko 
>>  > > To: dev@deltaspike.apache.org
>>  > > Cc:
>>  > > Sent: Monday, 30 September 2013, 22:47
>>  > > Subject: Re: DS + JSF 2.2
>>  > >
>>  > > Hi Gerhard,
>>  > >
>>  > > thanks - i already know your blog post :)
>>  > > Hopefully this features will be included directly to DS for the 
> next
>>  > > release.
>>  > > I mean, you already did the work to move it the DS base.
>>  > > So i would believe that only reviews left.
>>  > >
>>  > > Regards,
>>  > > Thomas
>>  > >
>>  > >
>>  > >
>>  > >
>>  > > 2013/9/30 Gerhard Petracek 
>>  > >
>>  > >>  hi thomas,
>>  > >>
>>  > >>  for now you have to wait for mark and/or you can have a look 
> at [1].
>>  > >>  (it isn't about jsf 2.2, however, as a codi user you 
> will see that
>>  you
>>  > > are
>>  > >>  used to it.)
>>  > >>
>>  > >>  regards,
>>  > >>  gerhard
>>  > >>
>>  > >>  [1]
>>  > >>
>>  >
>>  http://os890.blogspot.co.at/2013/07/add-on-codi-scopes-for-deltaspike.html
>>  > >>
>>  > >>
>>  > >>
>>  > >>  2013/9/30 Thomas Andraschko 
> 
>>  > >>
>>  > >>  > Is there any documentation available for this config?
>>  > >>  > Are both id's from DS?
>>  > >>  > If not, can't DS reuse "windowId"?
>>  > >>  > I would like to use WindowScoped in the future, so just 
> disabling
>>  > this
>>  > >>  > feature isn't the best approach.
>>  > >>  >
>>  > >>  >
>>  > >>  >
>>  > >>  > 2013/9/30 John D. Ament 
>>  > >>  >
>>  > >>  > > Yes, you just need to override the client window 
> render mode by
>>  > >>  > > creating your own config.
>>  > >>  > >
>>  > >>  > > On Mon, Sep 30, 2013 at 3:54 PM, Thomas Andraschko
>>  > >>  > >  wrote:
>>  > >>  > > > Hi,
>>  > >>  > > >
>>  > >>  > > > is DS currently 100% compatible with JSF 2.2?
>>  > >>  > > > AFAIR we also have a ClientWindow API in DS 
> and i get 2
>>  > > unique id's
>>  > >>  in
>>  > >>  > > the
>>  > >>  > > > URL with GF4:
>>  > >>  > > > ?dsRid=79&windowId=7441
>>  > >>  > > >
>>  > >>  > > > Can i disable one of these IDs?
>>  > >>  > > >
>>  > >>  > > > Regards,
>>  > >>  > > > Thomas
>>  > >>  > >
>>  > >>  >
>>  > >>
>>  > >
>>  >
>> 
>

Re: DS + JSF 2.2

2013-10-01 Thread Thomas Andraschko

+1 Gerhard

"we" should really try to take it to the street.

I don't know if i can help you that much but i finished with my work on
PrimeFaces 4.0 - so if you need help, just ping me!



2013/10/1 Gerhard Petracek 

> since you started almost a year ago, it would be nice if you push the
> current draft to your github repository.
>
> regards,
> gerhard
>
>
>
> 2013/10/1 Mark Struberg 
>
> > Yes, I intended to fix this since a long time. But I'm atm fully blasted
> > with $$dayjob work. And the current customer does not use JSF but Vaadin
> > (which is nice for rendering but has nothing like the data lifecycle of
> > JSF, so it's much work we need to du ourself). So I can really only work
> on
> > it in my very limited spare time.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > - Original Message -
> > > From: Thomas Andraschko 
> > > To: dev@deltaspike.apache.org
> > > Cc:
> > > Sent: Monday, 30 September 2013, 22:47
> > > Subject: Re: DS + JSF 2.2
> > >
> > > Hi Gerhard,
> > >
> > > thanks - i already know your blog post :)
> > > Hopefully this features will be included directly to DS for the next
> > > release.
> > > I mean, you already did the work to move it the DS base.
> > > So i would believe that only reviews left.
> > >
> > > Regards,
> > > Thomas
> > >
> > >
> > >
> > >
> > > 2013/9/30 Gerhard Petracek 
> > >
> > >>  hi thomas,
> > >>
> > >>  for now you have to wait for mark and/or you can have a look at [1].
> > >>  (it isn't about jsf 2.2, however, as a codi user you will see that
> you
> > > are
> > >>  used to it.)
> > >>
> > >>  regards,
> > >>  gerhard
> > >>
> > >>  [1]
> > >>
> >
> http://os890.blogspot.co.at/2013/07/add-on-codi-scopes-for-deltaspike.html
> > >>
> > >>
> > >>
> > >>  2013/9/30 Thomas Andraschko 
> > >>
> > >>  > Is there any documentation available for this config?
> > >>  > Are both id's from DS?
> > >>  > If not, can't DS reuse "windowId"?
> > >>  > I would like to use WindowScoped in the future, so just disabling
> > this
> > >>  > feature isn't the best approach.
> > >>  >
> > >>  >
> > >>  >
> > >>  > 2013/9/30 John D. Ament 
> > >>  >
> > >>  > > Yes, you just need to override the client window render mode by
> > >>  > > creating your own config.
> > >>  > >
> > >>  > > On Mon, Sep 30, 2013 at 3:54 PM, Thomas Andraschko
> > >>  > >  wrote:
> > >>  > > > Hi,
> > >>  > > >
> > >>  > > > is DS currently 100% compatible with JSF 2.2?
> > >>  > > > AFAIR we also have a ClientWindow API in DS and i get 2
> > > unique id's
> > >>  in
> > >>  > > the
> > >>  > > > URL with GF4:
> > >>  > > > ?dsRid=79&windowId=7441
> > >>  > > >
> > >>  > > > Can i disable one of these IDs?
> > >>  > > >
> > >>  > > > Regards,
> > >>  > > > Thomas
> > >>  > >
> > >>  >
> > >>
> > >
> >
>

org.apache.deltaspike.data.impl.handler.EntityManagerLookup broken?

2013-10-01 Thread Romain Manni-Bucau

Hi,

in org.apache.deltaspike.data.impl.handler.EntityManagerLookup#lookupFor we
use the em resolver then we return the entityManager.get() instead of the
result. Is it intended?

Why not using a qualifier to resolve the em? It was easier IMO

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

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

2013-10-01 Thread Jason Porter (JIRA)


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

Jason Porter commented on DELTASPIKE-414:
-

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

> HttpServletRequest (and others) injection not working in servlet filters from 
> web.xml
> -
>
> Key: DELTASPIKE-414
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-414
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Servlet-Module
>Affects Versions: 0.5
>Reporter: Emond Papegaaij
>
> DeltaSpike uses a filter to record the request and response objects for 
> injection in that thread. This filter is configured in web-fragment.xml, 
> which is loaded before other web-fragments, but not before web.xml. Filters 
> from web.xml will be first in the chain, breaking request and response 
> injection into these filters with "Attempt to access the request/response 
> without an active HTTP request" (RequestResponseHolder:85).
> We are moving from Solder, where the request and response objects were 
> recorded in a ServletRequestListener, which is always fired first, regardless 
> of it's position in the web.xml/web-fragment.xml. I think DeltaSpike should 
> use the same approach.
> For now, a workaround is to copy the configuration of 
> RequestResponseHolderFilter to your web.xml and put it before all other 
> filters.



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

Re: Data Module

2013-10-01 Thread Thomas Hug

+1 on the feature, just been busy on a project where that would have been
handy.

And apologies for letting the thread quiet, will I'll try to propose
something over the next two weeks based on the initial API suggestion (and
get some other JIRA issues finally done...).


On Tue, Oct 1, 2013 at 4:31 PM, Jean-Louis MONTEIRO wrote:

> Yep, I still think it's useful.
>
> JLouis
>
>
> 2013/10/1 Romain Manni-Bucau 
>
> > Not particularly
> >
> > the thread ends while the feature is useful IMO so simply asking what to
> do
> > next ;)
> >
> > *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/10/1 Jason Porter 
> >
> > > Was this my action item?
> > >
> > > Sent from my iPhone
> > >
> > > > On Oct 1, 2013, at 7:43, Romain Manni-Bucau 
> > > wrote:
> > > >
> > > > Hi
> > > >
> > > > any news on it?
> > > >
> > > > @ResultMapper was good to me
> > > >
> > > > *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/7/12 Jason Porter 
> > > >
> > > >> On Fri, Jul 12, 2013 at 12:13 AM, Romain Manni-Bucau
> > > >> wrote:
> > > >>
> > > >>> Ps: you can make a cdi bean an ejb from cdi extension
> > > >>>
> > > >>
> > > >> No, the bootstrapping for each container do not communicate to my
> > > >> knowledge.
> > > >>
> > > >>
> > > >>> Le 12 juil. 2013 08:12, "Romain Manni-Bucau" <
> rmannibu...@gmail.com>
> > a
> > > >>> écrit :
> > > >>>
> > >  Hi
> > > 
> > >  Depending the case DTO are not an option.
> > > 
> > >  I agree in rest app i wouldnt it but if not possible (maybe
> through
> > >  another Bean) it would kill this module for half of the usages i
> see
> > > >>> since
> > >  i'd need to add this layer.
> > >  Le 12 juil. 2013 06:55, "hantsy"  a écrit :
> > > 
> > > > No DTO please, data module for data access, why we care about
> DTO.
> > > >
> > > > A question about the data, the difference for EJB and none EJB
> > > > environment.
> > > >
> > > > if possible in a EJB envoriment, proxy the Repository and add
> > > >> @Stateless
> > > > and transaction declaration to Repository automatically at
> runtime.
> > > >
> > > > Regards
> > > >
> > > > Hantsy
> > > >> On 7/10/2013 23:23, Thomas Hug wrote:
> > > >> I wouldn't label the feature with DTO but rather as some general
> > > >>> result
> > > >> transformation - might also be useful for e.g. native queries.
> > Going
> > > > back
> > > >> to the API suggestion, from that perspective such an annotation
> > > >> should
> > > >> probably also work on method level, so I'd keep the forEntity
> out
> > > >>> there.
> > > >>
> > > >>
> > > >> On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament <
> > > >>> john.d.am...@gmail.com
> > > >> wrote:
> > > >>
> > > >>> Personally, I don't like this idea.
> > > >>>
> > > >>> A DAO should do DAO stuff.
> > > >>> A DTO should do DTO stuff.
> > > >>>
> > > >>> The transformation of your entities into some other POJO
> > shouldn't
> > > >> be
> > > >>> inside your DAO.
> > > >>>
> > > >>> Right now, I use google guava to do DTO work on entities going
> > back
> > > >>> and
> > > >>> forth over a REST API.  Works well IMHO.
> > > >>>
> > > >>> John
> > > >>>
> > > >>>
> > > >>> On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
> > > >>> wrote:
> > > >>>
> > >  globally my answer meant "if forEntity is sometimes mandatory,
> > > > sometimes
> > >  not this is maybe not the right place"
> > > 
> > >  i thought to add it to mapper config
> > > 
> > >  *Romain Manni-Bucau*
> > >  *Twitter: @rmannibucau *
> > >  *Blog: **http://rmannibucau.wordpress.com/*<
> > >  http://rmannibucau.wordpress.com/>
> > >  *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > >  *Github: https://github.com/rmannibucau*
> > > 
> > > 
> > > 
> > >  2013/7/10 Thomas Hug 
> > > 
> > > > Making forEntity non-optional would then be redundant for the
> > > >>> regular
> > >  cases
> > > > using the base interface, so I wouldn't. But I see that it
> > should
> > > >>> be
> > > > clearly documented then as things might get confusing...
> > > >
> > > >
> > > > On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
> > > > wrote:
> > > >
> > > >

Re: Data Module

2013-10-01 Thread Jean-Louis MONTEIRO

Yep, I still think it's useful.

JLouis


2013/10/1 Romain Manni-Bucau 

> Not particularly
>
> the thread ends while the feature is useful IMO so simply asking what to do
> next ;)
>
> *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/10/1 Jason Porter 
>
> > Was this my action item?
> >
> > Sent from my iPhone
> >
> > > On Oct 1, 2013, at 7:43, Romain Manni-Bucau 
> > wrote:
> > >
> > > Hi
> > >
> > > any news on it?
> > >
> > > @ResultMapper was good to me
> > >
> > > *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/7/12 Jason Porter 
> > >
> > >> On Fri, Jul 12, 2013 at 12:13 AM, Romain Manni-Bucau
> > >> wrote:
> > >>
> > >>> Ps: you can make a cdi bean an ejb from cdi extension
> > >>>
> > >>
> > >> No, the bootstrapping for each container do not communicate to my
> > >> knowledge.
> > >>
> > >>
> > >>> Le 12 juil. 2013 08:12, "Romain Manni-Bucau" 
> a
> > >>> écrit :
> > >>>
> >  Hi
> > 
> >  Depending the case DTO are not an option.
> > 
> >  I agree in rest app i wouldnt it but if not possible (maybe through
> >  another Bean) it would kill this module for half of the usages i see
> > >>> since
> >  i'd need to add this layer.
> >  Le 12 juil. 2013 06:55, "hantsy"  a écrit :
> > 
> > > No DTO please, data module for data access, why we care about DTO.
> > >
> > > A question about the data, the difference for EJB and none EJB
> > > environment.
> > >
> > > if possible in a EJB envoriment, proxy the Repository and add
> > >> @Stateless
> > > and transaction declaration to Repository automatically at runtime.
> > >
> > > Regards
> > >
> > > Hantsy
> > >> On 7/10/2013 23:23, Thomas Hug wrote:
> > >> I wouldn't label the feature with DTO but rather as some general
> > >>> result
> > >> transformation - might also be useful for e.g. native queries.
> Going
> > > back
> > >> to the API suggestion, from that perspective such an annotation
> > >> should
> > >> probably also work on method level, so I'd keep the forEntity out
> > >>> there.
> > >>
> > >>
> > >> On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament <
> > >>> john.d.am...@gmail.com
> > >> wrote:
> > >>
> > >>> Personally, I don't like this idea.
> > >>>
> > >>> A DAO should do DAO stuff.
> > >>> A DTO should do DTO stuff.
> > >>>
> > >>> The transformation of your entities into some other POJO
> shouldn't
> > >> be
> > >>> inside your DAO.
> > >>>
> > >>> Right now, I use google guava to do DTO work on entities going
> back
> > >>> and
> > >>> forth over a REST API.  Works well IMHO.
> > >>>
> > >>> John
> > >>>
> > >>>
> > >>> On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
> > >>> wrote:
> > >>>
> >  globally my answer meant "if forEntity is sometimes mandatory,
> > > sometimes
> >  not this is maybe not the right place"
> > 
> >  i thought to add it to mapper config
> > 
> >  *Romain Manni-Bucau*
> >  *Twitter: @rmannibucau *
> >  *Blog: **http://rmannibucau.wordpress.com/*<
> >  http://rmannibucau.wordpress.com/>
> >  *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >  *Github: https://github.com/rmannibucau*
> > 
> > 
> > 
> >  2013/7/10 Thomas Hug 
> > 
> > > Making forEntity non-optional would then be redundant for the
> > >>> regular
> >  cases
> > > using the base interface, so I wouldn't. But I see that it
> should
> > >>> be
> > > clearly documented then as things might get confusing...
> > >
> > >
> > > On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
> > > wrote:
> > >
> > >> do you mean you force forEntity = Person.class?
> > >>
> > >> looks ok for me since the only constraint is to add the dto
> > >> types
> > > somewhere
> > >> :)
> > >>
> > >> *Romain Manni-Bucau*
> > >> *Twitter: @rmannibucau *
> > >> *Blog: **http://rmannibucau.wordpress.com/*<
> > >> http://rmannibucau.wordpress.com/>
> > >> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > >> *Github: https://github.com/rmannibucau*
> > >>
> > >>
> > >>
> > >> 2013/7/10 Thomas Hug 
> > >>
> > >>

Re: Data Module

2013-10-01 Thread Romain Manni-Bucau

Not particularly

the thread ends while the feature is useful IMO so simply asking what to do
next ;)

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



2013/10/1 Jason Porter 

> Was this my action item?
>
> Sent from my iPhone
>
> > On Oct 1, 2013, at 7:43, Romain Manni-Bucau 
> wrote:
> >
> > Hi
> >
> > any news on it?
> >
> > @ResultMapper was good to me
> >
> > *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/7/12 Jason Porter 
> >
> >> On Fri, Jul 12, 2013 at 12:13 AM, Romain Manni-Bucau
> >> wrote:
> >>
> >>> Ps: you can make a cdi bean an ejb from cdi extension
> >>>
> >>
> >> No, the bootstrapping for each container do not communicate to my
> >> knowledge.
> >>
> >>
> >>> Le 12 juil. 2013 08:12, "Romain Manni-Bucau"  a
> >>> écrit :
> >>>
>  Hi
> 
>  Depending the case DTO are not an option.
> 
>  I agree in rest app i wouldnt it but if not possible (maybe through
>  another Bean) it would kill this module for half of the usages i see
> >>> since
>  i'd need to add this layer.
>  Le 12 juil. 2013 06:55, "hantsy"  a écrit :
> 
> > No DTO please, data module for data access, why we care about DTO.
> >
> > A question about the data, the difference for EJB and none EJB
> > environment.
> >
> > if possible in a EJB envoriment, proxy the Repository and add
> >> @Stateless
> > and transaction declaration to Repository automatically at runtime.
> >
> > Regards
> >
> > Hantsy
> >> On 7/10/2013 23:23, Thomas Hug wrote:
> >> I wouldn't label the feature with DTO but rather as some general
> >>> result
> >> transformation - might also be useful for e.g. native queries. Going
> > back
> >> to the API suggestion, from that perspective such an annotation
> >> should
> >> probably also work on method level, so I'd keep the forEntity out
> >>> there.
> >>
> >>
> >> On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament <
> >>> john.d.am...@gmail.com
> >> wrote:
> >>
> >>> Personally, I don't like this idea.
> >>>
> >>> A DAO should do DAO stuff.
> >>> A DTO should do DTO stuff.
> >>>
> >>> The transformation of your entities into some other POJO shouldn't
> >> be
> >>> inside your DAO.
> >>>
> >>> Right now, I use google guava to do DTO work on entities going back
> >>> and
> >>> forth over a REST API.  Works well IMHO.
> >>>
> >>> John
> >>>
> >>>
> >>> On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
> >>> wrote:
> >>>
>  globally my answer meant "if forEntity is sometimes mandatory,
> > sometimes
>  not this is maybe not the right place"
> 
>  i thought to add it to mapper config
> 
>  *Romain Manni-Bucau*
>  *Twitter: @rmannibucau *
>  *Blog: **http://rmannibucau.wordpress.com/*<
>  http://rmannibucau.wordpress.com/>
>  *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>  *Github: https://github.com/rmannibucau*
> 
> 
> 
>  2013/7/10 Thomas Hug 
> 
> > Making forEntity non-optional would then be redundant for the
> >>> regular
>  cases
> > using the base interface, so I wouldn't. But I see that it should
> >>> be
> > clearly documented then as things might get confusing...
> >
> >
> > On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
> > wrote:
> >
> >> do you mean you force forEntity = Person.class?
> >>
> >> looks ok for me since the only constraint is to add the dto
> >> types
> > somewhere
> >> :)
> >>
> >> *Romain Manni-Bucau*
> >> *Twitter: @rmannibucau *
> >> *Blog: **http://rmannibucau.wordpress.com/*<
> >> http://rmannibucau.wordpress.com/>
> >> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >> *Github: https://github.com/rmannibucau*
> >>
> >>
> >>
> >> 2013/7/10 Thomas Hug 
> >>
> >>> Hmm and I assumed DTOs are dead and buried :-)
> >>>
> >>> Packing this in the base interface feels kind of clunky to me -
> >>> also
> >>> considering that there are repositories without the need to
> >>> extend
>  the
> >> base
> >>> interface. What about something like
> >>>
> >>> @Repository(forEntity = Person.

Re: Data Module

2013-10-01 Thread Jason Porter

Was this my action item?

Sent from my iPhone

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

Re: Data Module

2013-10-01 Thread Romain Manni-Bucau

Hi

any news on it?

@ResultMapper was good to me

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



2013/7/12 Jason Porter 

> On Fri, Jul 12, 2013 at 12:13 AM, Romain Manni-Bucau
> wrote:
>
> > Ps: you can make a cdi bean an ejb from cdi extension
> >
>
> No, the bootstrapping for each container do not communicate to my
> knowledge.
>
>
> > Le 12 juil. 2013 08:12, "Romain Manni-Bucau"  a
> > écrit :
> >
> > > Hi
> > >
> > > Depending the case DTO are not an option.
> > >
> > > I agree in rest app i wouldnt it but if not possible (maybe through
> > > another Bean) it would kill this module for half of the usages i see
> > since
> > > i'd need to add this layer.
> > > Le 12 juil. 2013 06:55, "hantsy"  a écrit :
> > >
> > >> No DTO please, data module for data access, why we care about DTO.
> > >>
> > >> A question about the data, the difference for EJB and none EJB
> > >> environment.
> > >>
> > >> if possible in a EJB envoriment, proxy the Repository and add
> @Stateless
> > >> and transaction declaration to Repository automatically at runtime.
> > >>
> > >> Regards
> > >>
> > >> Hantsy
> > >> On 7/10/2013 23:23, Thomas Hug wrote:
> > >> > I wouldn't label the feature with DTO but rather as some general
> > result
> > >> > transformation - might also be useful for e.g. native queries. Going
> > >> back
> > >> > to the API suggestion, from that perspective such an annotation
> should
> > >> > probably also work on method level, so I'd keep the forEntity out
> > there.
> > >> >
> > >> >
> > >> > On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament <
> > john.d.am...@gmail.com
> > >> >wrote:
> > >> >
> > >> >> Personally, I don't like this idea.
> > >> >>
> > >> >> A DAO should do DAO stuff.
> > >> >> A DTO should do DTO stuff.
> > >> >>
> > >> >> The transformation of your entities into some other POJO shouldn't
> be
> > >> >> inside your DAO.
> > >> >>
> > >> >> Right now, I use google guava to do DTO work on entities going back
> > and
> > >> >> forth over a REST API.  Works well IMHO.
> > >> >>
> > >> >> John
> > >> >>
> > >> >>
> > >> >> On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
> > >> >> wrote:
> > >> >>
> > >> >>> globally my answer meant "if forEntity is sometimes mandatory,
> > >> sometimes
> > >> >>> not this is maybe not the right place"
> > >> >>>
> > >> >>> i thought to add it to mapper config
> > >> >>>
> > >> >>> *Romain Manni-Bucau*
> > >> >>> *Twitter: @rmannibucau *
> > >> >>> *Blog: **http://rmannibucau.wordpress.com/*<
> > >> >>> http://rmannibucau.wordpress.com/>
> > >> >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > >> >>> *Github: https://github.com/rmannibucau*
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> 2013/7/10 Thomas Hug 
> > >> >>>
> > >>  Making forEntity non-optional would then be redundant for the
> > regular
> > >> >>> cases
> > >>  using the base interface, so I wouldn't. But I see that it should
> > be
> > >>  clearly documented then as things might get confusing...
> > >> 
> > >> 
> > >>  On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
> > >>  wrote:
> > >> 
> > >> > do you mean you force forEntity = Person.class?
> > >> >
> > >> > looks ok for me since the only constraint is to add the dto
> types
> > >>  somewhere
> > >> > :)
> > >> >
> > >> > *Romain Manni-Bucau*
> > >> > *Twitter: @rmannibucau *
> > >> > *Blog: **http://rmannibucau.wordpress.com/*<
> > >> > http://rmannibucau.wordpress.com/>
> > >> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > >> > *Github: https://github.com/rmannibucau*
> > >> >
> > >> >
> > >> >
> > >> > 2013/7/10 Thomas Hug 
> > >> >
> > >> >> Hmm and I assumed DTOs are dead and buried :-)
> > >> >>
> > >> >> Packing this in the base interface feels kind of clunky to me -
> > >> >> also
> > >> >> considering that there are repositories without the need to
> > extend
> > >> >>> the
> > >> > base
> > >> >> interface. What about something like
> > >> >>
> > >> >> @Repository(forEntity = Person.class)
> > >> >> @ResultMapper(entityMapper = MapperX.class, keyMapper =
> > >> >>> MapperY.class)
> > >> >> public interface PersonRepository extends
> > >> >> EntityRepository > >> >> DtoPk> { ... }
> > >> >>
> > >> >> Having the Entity on @Repository takes precedence and the type
> > >>  parameters
> > >> >> are in this case just for convenience.
> > >> >>
> > >> >>
> > >> >>
> > >> >> On Wed, Jul 10, 2013 at 2:35 PM, Romain Manni-Bucau
> > >> >> wrote:
> > >> >>
> > >> >>> +1
> > >> >>>
> > >> >>> just to complete this thread the main issue is not the
> > >> >>> impleme

Fw: Deltaspike 0.5 and WLP 8.5.5 problem at startup.

2013-10-01 Thread Mark Struberg



whoops, went only to Lars-Fredrik. Should have gone to the list.

LieGrue,
strub



- Forwarded Message -
> From: Mark Struberg 
> To: Lars-Fredrik Smedberg 
> Cc: 
> Sent: Tuesday, 1 October 2013, 10:17
> Subject: Re: Deltaspike 0.5 and WLP 8.5.5 problem at startup.
> 
> Hi Lars-Fredrik!
> 
> It would be cool if you could open a JIRA ticket [1] and dump your 
> information 
> into it. Perfect would be either a detailed info about how to reproduce or 
> even 
> a small sample project.
> 
> I am working with tomcat+OWB, TomEE and WAS-8.0 at my dayjob but did not yet 
> experience this issue. So we might also contact the folks from IBM to have a 
> look at it.
> 
> Regarding the init stuff. I think the current code is indeed fine. The Spec 
> defines that we must not invoke BeanManager#getBeans() _before_ 
> AfterDeploymentValidation got fired [2]. But we only call it in ADV...
> 
> Nonetheless, plz open a ticket so we can track the progress and new info on 
> this.
> 
> LieGrue,
> strub
> 
> 
> [1] https://issues.apache.org/jira/browse/DELTASPIKE
> 
> [2] 
> http://docs.oracle.com/javaee/7/api/javax/enterprise/inject/spi/BeanManager.html#getBeans%28java.lang.String%29
> 
> 
> 
> 
> 
> 
>> 
>>  From: Lars-Fredrik Smedberg 
>> To: users  
>> Cc: Mark Struberg  
>> Sent: Monday, 30 September 2013, 20:56
>> Subject: Re: Deltaspike 0.5 and WLP 8.5.5 problem at startup.
>> 
>> 
>> 
>> Hi again
>> 
>> 
>> Thanks for your answers
>> 
>> 
>> @gerhard:
>> Thanks for the suggestion, could you point my to some reference on how to 
> configure this in OWB?
>> 
>> 
>> @mark:
>> Is this planned for (or will it most likely show up in)  a certain release? 
> When can I try it out?
>> 
>> 
>> Regards
>> LF
>> 
>> 
>> 
>> On Mon, Sep 30, 2013 at 5:00 PM, Gerhard Petracek 
>  wrote:
>> 
>> @mark:
>>> i showed a similar issue to you in july, however, this is even one small
>>> step before and in some cases disabling the bda-mode helps.
>>> 
>>> -> (still) +1 for doing it lazily.
>>> 
>>> regards,
>>> gerhard
>>> 
>>> 
>>> 
>>> 
>>> 2013/9/30 Mark Struberg 
>>> 
 
 
  Hmm not sure. Actually WindowBeanHolder is part of 
> deltaspike-core-impl
  and a standard @SessionScoped bean.
 
  Maybe it's because we call getBeans in 
> AfterDeploymentValidation. Will try
  to rework this to lazy init inside the Context.
 
  LieGrue,
  strub
 
 
 
 
 
  >
  > From: Gerhard Petracek 
  >To: us...@deltaspike.apache.org
  >Sent: Monday, 30 September 2013, 16:38
  >Subject: Re: Deltaspike 0.5 and WLP 8.5.5 problem at startup.
  >
  >
  >hi lars-fredrik,
  >
  >please try to deactivate the bda-mode.
  >(openwebbeans doesn't activate it per default, but it's 
> active in most
  >ee-servers.)
  >
  >regards,
  >gerhard
  >
  >
  >
  >2013/9/30 Lars-Fredrik Smedberg 
  >
  >> Hi
  >>
  >> I'm trying to get Deltaspike 0.5 running together with 
> WebSphere Liberty
  >> Profile 8.5.5 (which has Apache OpenWebBeans bundled)
  >>
  >> I put the following jars as common library jar files:
  >>
  >> deltaspike-core-api-0.5.jar
  >> deltaspike-core-impl-0.5.jar
  >>
  >> And I get the following in the console logs at startup:
  >>
  >> [ERROR   ] Could not find beans for Type=class
  >> 
> org.apache.deltaspike.core.impl.scope.window.WindowBeanHolder and
  >> qualifiers:[]
  >> Could not find beans for Type=class
  >> 
> org.apache.deltaspike.core.impl.scope.window.WindowBeanHolder and
  >> qualifiers:[]
  >> [ERROR   ] An error occured while starting application 
> context path :
  >> [/rsea]
  >> [INFO    ] FFDC1015I: An FFDC Incident has been created:
  >> "java.lang.IllegalStateException: Could not find 
> beans for Type=class
  >> 
> org.apache.deltaspike.core.impl.scope.window.WindowBeanHolder and
  >> qualifiers:[] com.ibm.ws.webcontainer.osgi.VirtualHost 
> startWebApp" at
  >> ffdc_13.09.30_16.09.20.0.log
  >>
  >> And the FFDC logs contain the following stacktrace:
  >>
  >> Stack Dump = 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.window.DeltaSpikeContextExtension.initializeDeltaSpikeContexts(DeltaSpikeContextExtension.java:50)
  >>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
  >> at
  >>
  >>
 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
  >>  at
  >>
  >>
 
> sun.reflect.DelegatingMe

Re: DS + JSF 2.2

2013-10-01 Thread Gerhard Petracek

since you started almost a year ago, it would be nice if you push the
current draft to your github repository.

regards,
gerhard



2013/10/1 Mark Struberg 

> Yes, I intended to fix this since a long time. But I'm atm fully blasted
> with $$dayjob work. And the current customer does not use JSF but Vaadin
> (which is nice for rendering but has nothing like the data lifecycle of
> JSF, so it's much work we need to du ourself). So I can really only work on
> it in my very limited spare time.
>
>
> LieGrue,
> strub
>
>
>
> - Original Message -
> > From: Thomas Andraschko 
> > To: dev@deltaspike.apache.org
> > Cc:
> > Sent: Monday, 30 September 2013, 22:47
> > Subject: Re: DS + JSF 2.2
> >
> > Hi Gerhard,
> >
> > thanks - i already know your blog post :)
> > Hopefully this features will be included directly to DS for the next
> > release.
> > I mean, you already did the work to move it the DS base.
> > So i would believe that only reviews left.
> >
> > Regards,
> > Thomas
> >
> >
> >
> >
> > 2013/9/30 Gerhard Petracek 
> >
> >>  hi thomas,
> >>
> >>  for now you have to wait for mark and/or you can have a look at [1].
> >>  (it isn't about jsf 2.2, however, as a codi user you will see that you
> > are
> >>  used to it.)
> >>
> >>  regards,
> >>  gerhard
> >>
> >>  [1]
> >>
> http://os890.blogspot.co.at/2013/07/add-on-codi-scopes-for-deltaspike.html
> >>
> >>
> >>
> >>  2013/9/30 Thomas Andraschko 
> >>
> >>  > Is there any documentation available for this config?
> >>  > Are both id's from DS?
> >>  > If not, can't DS reuse "windowId"?
> >>  > I would like to use WindowScoped in the future, so just disabling
> this
> >>  > feature isn't the best approach.
> >>  >
> >>  >
> >>  >
> >>  > 2013/9/30 John D. Ament 
> >>  >
> >>  > > Yes, you just need to override the client window render mode by
> >>  > > creating your own config.
> >>  > >
> >>  > > On Mon, Sep 30, 2013 at 3:54 PM, Thomas Andraschko
> >>  > >  wrote:
> >>  > > > Hi,
> >>  > > >
> >>  > > > is DS currently 100% compatible with JSF 2.2?
> >>  > > > AFAIR we also have a ClientWindow API in DS and i get 2
> > unique id's
> >>  in
> >>  > > the
> >>  > > > URL with GF4:
> >>  > > > ?dsRid=79&windowId=7441
> >>  > > >
> >>  > > > Can i disable one of these IDs?
> >>  > > >
> >>  > > > Regards,
> >>  > > > Thomas
> >>  > >
> >>  >
> >>
> >
>

Re: DS + JSF 2.2

2013-10-01 Thread Mark Struberg

Yes, I intended to fix this since a long time. But I'm atm fully blasted with 
$$dayjob work. And the current customer does not use JSF but Vaadin (which is 
nice for rendering but has nothing like the data lifecycle of JSF, so it's much 
work we need to du ourself). So I can really only work on it in my very limited 
spare time.


LieGrue,
strub



- Original Message -
> From: Thomas Andraschko 
> To: dev@deltaspike.apache.org
> Cc: 
> Sent: Monday, 30 September 2013, 22:47
> Subject: Re: DS + JSF 2.2
> 
> Hi Gerhard,
> 
> thanks - i already know your blog post :)
> Hopefully this features will be included directly to DS for the next
> release.
> I mean, you already did the work to move it the DS base.
> So i would believe that only reviews left.
> 
> Regards,
> Thomas
> 
> 
> 
> 
> 2013/9/30 Gerhard Petracek 
> 
>>  hi thomas,
>> 
>>  for now you have to wait for mark and/or you can have a look at [1].
>>  (it isn't about jsf 2.2, however, as a codi user you will see that you 
> are
>>  used to it.)
>> 
>>  regards,
>>  gerhard
>> 
>>  [1]
>>  http://os890.blogspot.co.at/2013/07/add-on-codi-scopes-for-deltaspike.html
>> 
>> 
>> 
>>  2013/9/30 Thomas Andraschko 
>> 
>>  > Is there any documentation available for this config?
>>  > Are both id's from DS?
>>  > If not, can't DS reuse "windowId"?
>>  > I would like to use WindowScoped in the future, so just disabling this
>>  > feature isn't the best approach.
>>  >
>>  >
>>  >
>>  > 2013/9/30 John D. Ament 
>>  >
>>  > > Yes, you just need to override the client window render mode by
>>  > > creating your own config.
>>  > >
>>  > > On Mon, Sep 30, 2013 at 3:54 PM, Thomas Andraschko
>>  > >  wrote:
>>  > > > Hi,
>>  > > >
>>  > > > is DS currently 100% compatible with JSF 2.2?
>>  > > > AFAIR we also have a ClientWindow API in DS and i get 2 
> unique id's
>>  in
>>  > > the
>>  > > > URL with GF4:
>>  > > > ?dsRid=79&windowId=7441
>>  > > >
>>  > > > Can i disable one of these IDs?
>>  > > >
>>  > > > Regards,
>>  > > > Thomas
>>  > >
>>  >
>> 
>

[jira] [Created] (DELTASPIKE-416) @Folder's name check/resolution is broken

2013-10-01 Thread Thomas Andraschko (JIRA)

Thomas Andraschko created DELTASPIKE-416:


 Summary: @Folder's name check/resolution is broken
 Key: DELTASPIKE-416
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-416
 Project: DeltaSpike
  Issue Type: Bug
  Components: JSF-Module
Affects Versions: 0.5
Reporter: Thomas Andraschko


Example:

@Folder(name = "views")
public interface Views extends ViewConfig
{
@Folder(name = "internal")
@Secured(value = LoggedInAccessDecisionVoter.class, errorView = 
Views.LoginRequired.class)
public interface Internal extends Views...


The LoggedInAccessDecisionVoter will never be called.
If i remove both @Folder annotations, it's working fine.




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

[jira] [Created] (DELTASPIKE-415) Nested @Folder throws IllegalStateException

2013-10-01 Thread Thomas Andraschko (JIRA)

Thomas Andraschko created DELTASPIKE-415:


 Summary: Nested @Folder throws IllegalStateException
 Key: DELTASPIKE-415
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-415
 Project: DeltaSpike
  Issue Type: Bug
  Components: JSF-Module
Affects Versions: 0.5
Reporter: Thomas Andraschko


Example:

@Folder
public interface Views extends ViewConfig
{
@Folder
@Secured(value = LoggedInAccessDecisionVoter.class, errorView = 
Views.LoginRequired.class)
public interface Internal extends Views
{
@View class Home implements Internal { }
}

@View class Login implements Views { }

@View class LoginRequired implements Views { }

@View class Register implements Views { }

@View class Error extends DefaultErrorView implements Views { }
}

Exception:

java.lang.IllegalStateException: Duplicated config for the same folder 
configured. See: xxx.Views$Internal and xxx.Views
at 
org.apache.deltaspike.jsf.impl.config.view.DefaultViewConfigResolver.initCaches(DefaultViewConfigResolver.java:264)
at 
org.apache.deltaspike.jsf.impl.config.view.DefaultViewConfigResolver.(DefaultViewConfigResolver.java:140)
at 
org.apache.deltaspike.jsf.impl.config.view.ViewConfigExtension.transformMetaDataTree(ViewConfigExtension.java:314)
at 
org.apache.deltaspike.jsf.impl.config.view.ViewConfigExtension.buildViewConfig(ViewConfigExtension.java:279)





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

Re: DS + JSF 2.2

Re: DS + JSF 2.2

org.apache.deltaspike.data.impl.handler.EntityManagerLookup broken?

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

Re: Data Module

Re: Data Module

Re: Data Module

Re: Data Module

Re: Data Module

Fw: Deltaspike 0.5 and WLP 8.5.5 problem at startup.

Re: DS + JSF 2.2

Re: DS + JSF 2.2

[jira] [Created] (DELTASPIKE-416) @Folder's name check/resolution is broken

[jira] [Created] (DELTASPIKE-415) Nested @Folder throws IllegalStateException

14 matches

Site Navigation

Mail list logo

Footer information