Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
Sorry about my previous remark. I was thinking that we would like to integrate the "Spring Integration" project. Confusion around the wording. +1 to move into the direction to integrate Spring AND CDI. This was the motivation of my tweet of yesterday evening but not related to this thread ( https://twitter.com/cmoulliard/statuses/426105815683321856). On Thu, Jan 23, 2014 at 7:42 AM, Romain Manni-Bucau wrote: > @Charles: ? don't get the point. You would like to use camel to bridge > spring and cdi? seems just overengineered and not efficient compared > to real integration + why doing a route, setuping camel context just > for it + you need then to use camel proxies to get a "normal" API > which is a lot to get nothing fancy and surely slow. > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014/1/23 Charles Moulliard : > > -1. Why would you like to support Spring Integration while we have Apache > > Camel which is the most elaborated Spring Java Integration Framework > > available today, easier to setup, ... proposing also annotations > @Produce, > > @Consume to produce an exchange from and to a Camel Route (= list of > > processors) > > > > > > On Wed, Jan 22, 2014 at 7:36 PM, Jason Porter >wrote: > > > >> +1 for adding the Spring integration > >> > >> > >> On Wed, Jan 22, 2014 at 11:21 AM, John D. Ament >> >wrote: > >> > >> > +1 to Romain > >> > I'd like to see something like this for a 1.0 release. It would be a > >> > real game changer. > >> > > >> > On Wed, Jan 22, 2014 at 12:03 PM, Romain Manni-Bucau > >> > wrote: > >> > > I'd release 0.6 before having it, it will surely create discussion > >> > > once we'll get something and it is easy to do something totally > >> > > brokenn in particular when we'll want to get something clever in a > web > >> > > context > >> > > > >> > > btw we shouldn't do it without pivotal IMO > >> > > Romain Manni-Bucau > >> > > Twitter: @rmannibucau > >> > > Blog: http://rmannibucau.wordpress.com/ > >> > > LinkedIn: http://fr.linkedin.com/in/rmannibucau > >> > > Github: https://github.com/rmannibucau > >> > > > >> > > > >> > > > >> > > 2014/1/22 Jason Porter : > >> > >> Do we just want to take what we had in Seam 3 and move it over? > >> > >> > >> > >> > >> > >> On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek < > >> > >> gerhard.petra...@gmail.com> wrote: > >> > >> > >> > >>> hi jason, > >> > >>> > >> > >>> the bridge doesn't introduce an api and the spi just provides a > >> simple > >> > >>> contract for starting the container as well as a bean-filter. > >> > >>> -> if needed, we could improve the implementation at any time. > >> > >>> imo we should add it before the release of v0.6 (since a lot of > users > >> > >>> requested such a bridge). > >> > >>> > >> > >>> regards, > >> > >>> gerhard > >> > >>> > >> > >>> > >> > >>> > >> > >>> 2014/1/22 Jason Porter > >> > >>> > >> > >>> > I'd like to engage the Pivotal Team (anyone have contacts?) to > see > >> > if we > >> > >>> > can get some of there help as well to create a really good > >> > integration. > >> > >>> > > >> > >>> > > >> > >>> > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek < > >> > >>> > gerhard.petra...@gmail.com> wrote: > >> > >>> > > >> > >>> >> hi @ all, > >> > >>> >> > >> > >>> >> i would like to continue with this discussion. > >> > >>> >> > >> > >>> >> [1] describes a two-way bridge which is already based on > >> deltaspike. > >> > >>> >> it offers a simple spi which allows more advanced add-ons like > it > >> is > >> > >>> >> mentioned in [2]. > >> > >>> >> > >> > >>> >> regards, > >> > >>> >> gerhard > >> > >>> >> > >> > >>> >> [1] > >> > >>> >> > >> > >>> > >> > > >> > http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html > >> > >>> >> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html > >> > >>> >> > >> > >>> >> > >> > >>> >> > >> > >>> >> 2013/2/19 Matt Benson > >> > >>> >> > >> > >>> >>> Okay, I spent some time with Sam on IRC hashing this out. > >> Assuming > >> > >>> that > >> > >>> >>> Seam-Spring is covered under the SG(s?) Red Hat has filed for > >> > >>> deltaspike, > >> > >>> >>> his view is that it's not terribly important who does the > initial > >> > code > >> > >>> >>> import, though it would be best for a so-authorized Red > Hatter to > >> > be > >> > >>> the > >> > >>> >>> one to change the file headers. I will be out of pocket for > the > >> > rest > >> > >>> of > >> > >>> >>> the week beyond today, so if you, Marius, are able to work on > the > >> > >>> import > >> > >>> >>> end of this week/early next then that's in any event as soon > as I > >> > would > >> > >>> >>> have been able to get to it anyway. Otherwise, anyone can do > >> that, > >> > >>> with > >> > >>> >>> someone still employed by RH finally applying the change that > >> > modifies > >> > >>> >>> the > >> > >>> >>> headers--which, I sup
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
@Charles: ? don't get the point. You would like to use camel to bridge spring and cdi? seems just overengineered and not efficient compared to real integration + why doing a route, setuping camel context just for it + you need then to use camel proxies to get a "normal" API which is a lot to get nothing fancy and surely slow. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014/1/23 Charles Moulliard : > -1. Why would you like to support Spring Integration while we have Apache > Camel which is the most elaborated Spring Java Integration Framework > available today, easier to setup, ... proposing also annotations @Produce, > @Consume to produce an exchange from and to a Camel Route (= list of > processors) > > > On Wed, Jan 22, 2014 at 7:36 PM, Jason Porter wrote: > >> +1 for adding the Spring integration >> >> >> On Wed, Jan 22, 2014 at 11:21 AM, John D. Ament > >wrote: >> >> > +1 to Romain >> > I'd like to see something like this for a 1.0 release. It would be a >> > real game changer. >> > >> > On Wed, Jan 22, 2014 at 12:03 PM, Romain Manni-Bucau >> > wrote: >> > > I'd release 0.6 before having it, it will surely create discussion >> > > once we'll get something and it is easy to do something totally >> > > brokenn in particular when we'll want to get something clever in a web >> > > context >> > > >> > > btw we shouldn't do it without pivotal IMO >> > > Romain Manni-Bucau >> > > Twitter: @rmannibucau >> > > Blog: http://rmannibucau.wordpress.com/ >> > > LinkedIn: http://fr.linkedin.com/in/rmannibucau >> > > Github: https://github.com/rmannibucau >> > > >> > > >> > > >> > > 2014/1/22 Jason Porter : >> > >> Do we just want to take what we had in Seam 3 and move it over? >> > >> >> > >> >> > >> On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek < >> > >> gerhard.petra...@gmail.com> wrote: >> > >> >> > >>> hi jason, >> > >>> >> > >>> the bridge doesn't introduce an api and the spi just provides a >> simple >> > >>> contract for starting the container as well as a bean-filter. >> > >>> -> if needed, we could improve the implementation at any time. >> > >>> imo we should add it before the release of v0.6 (since a lot of users >> > >>> requested such a bridge). >> > >>> >> > >>> regards, >> > >>> gerhard >> > >>> >> > >>> >> > >>> >> > >>> 2014/1/22 Jason Porter >> > >>> >> > >>> > I'd like to engage the Pivotal Team (anyone have contacts?) to see >> > if we >> > >>> > can get some of there help as well to create a really good >> > integration. >> > >>> > >> > >>> > >> > >>> > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek < >> > >>> > gerhard.petra...@gmail.com> wrote: >> > >>> > >> > >>> >> hi @ all, >> > >>> >> >> > >>> >> i would like to continue with this discussion. >> > >>> >> >> > >>> >> [1] describes a two-way bridge which is already based on >> deltaspike. >> > >>> >> it offers a simple spi which allows more advanced add-ons like it >> is >> > >>> >> mentioned in [2]. >> > >>> >> >> > >>> >> regards, >> > >>> >> gerhard >> > >>> >> >> > >>> >> [1] >> > >>> >> >> > >>> >> > >> http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html >> > >>> >> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> 2013/2/19 Matt Benson >> > >>> >> >> > >>> >>> Okay, I spent some time with Sam on IRC hashing this out. >> Assuming >> > >>> that >> > >>> >>> Seam-Spring is covered under the SG(s?) Red Hat has filed for >> > >>> deltaspike, >> > >>> >>> his view is that it's not terribly important who does the initial >> > code >> > >>> >>> import, though it would be best for a so-authorized Red Hatter to >> > be >> > >>> the >> > >>> >>> one to change the file headers. I will be out of pocket for the >> > rest >> > >>> of >> > >>> >>> the week beyond today, so if you, Marius, are able to work on the >> > >>> import >> > >>> >>> end of this week/early next then that's in any event as soon as I >> > would >> > >>> >>> have been able to get to it anyway. Otherwise, anyone can do >> that, >> > >>> with >> > >>> >>> someone still employed by RH finally applying the change that >> > modifies >> > >>> >>> the >> > >>> >>> headers--which, I suppose, could be prepared by anyone else and >> > simply >> > >>> >>> shared among our private git repos. >> > >>> >>> >> > >>> >>> Matt >> > >>> >>> >> > >>> >>> >> > >>> >>> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici < >> > >>> >>> marius.bogoev...@gmail.com> wrote: >> > >>> >>> >> > >>> >>> > I still am a participant on this thread, but doing more reading >> > than >> > >>> >>> > writing as of late :) >> > >>> >>> > >> > >>> >>> > So, yes, I've been strapped for time with the job and the >> > transition, >> > >>> >>> but >> > >>> >>> > I'd be happy to help out with this at the end of the week or >> > early >> > >>> >>> next. >> > >>> >>> > >> > >>> >>> > With my CLA on file, an
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
-1. Why would you like to support Spring Integration while we have Apache Camel which is the most elaborated Spring Java Integration Framework available today, easier to setup, ... proposing also annotations @Produce, @Consume to produce an exchange from and to a Camel Route (= list of processors) On Wed, Jan 22, 2014 at 7:36 PM, Jason Porter wrote: > +1 for adding the Spring integration > > > On Wed, Jan 22, 2014 at 11:21 AM, John D. Ament >wrote: > > > +1 to Romain > > I'd like to see something like this for a 1.0 release. It would be a > > real game changer. > > > > On Wed, Jan 22, 2014 at 12:03 PM, Romain Manni-Bucau > > wrote: > > > I'd release 0.6 before having it, it will surely create discussion > > > once we'll get something and it is easy to do something totally > > > brokenn in particular when we'll want to get something clever in a web > > > context > > > > > > btw we shouldn't do it without pivotal IMO > > > Romain Manni-Bucau > > > Twitter: @rmannibucau > > > Blog: http://rmannibucau.wordpress.com/ > > > LinkedIn: http://fr.linkedin.com/in/rmannibucau > > > Github: https://github.com/rmannibucau > > > > > > > > > > > > 2014/1/22 Jason Porter : > > >> Do we just want to take what we had in Seam 3 and move it over? > > >> > > >> > > >> On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek < > > >> gerhard.petra...@gmail.com> wrote: > > >> > > >>> hi jason, > > >>> > > >>> the bridge doesn't introduce an api and the spi just provides a > simple > > >>> contract for starting the container as well as a bean-filter. > > >>> -> if needed, we could improve the implementation at any time. > > >>> imo we should add it before the release of v0.6 (since a lot of users > > >>> requested such a bridge). > > >>> > > >>> regards, > > >>> gerhard > > >>> > > >>> > > >>> > > >>> 2014/1/22 Jason Porter > > >>> > > >>> > I'd like to engage the Pivotal Team (anyone have contacts?) to see > > if we > > >>> > can get some of there help as well to create a really good > > integration. > > >>> > > > >>> > > > >>> > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek < > > >>> > gerhard.petra...@gmail.com> wrote: > > >>> > > > >>> >> hi @ all, > > >>> >> > > >>> >> i would like to continue with this discussion. > > >>> >> > > >>> >> [1] describes a two-way bridge which is already based on > deltaspike. > > >>> >> it offers a simple spi which allows more advanced add-ons like it > is > > >>> >> mentioned in [2]. > > >>> >> > > >>> >> regards, > > >>> >> gerhard > > >>> >> > > >>> >> [1] > > >>> >> > > >>> > > > http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html > > >>> >> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html > > >>> >> > > >>> >> > > >>> >> > > >>> >> 2013/2/19 Matt Benson > > >>> >> > > >>> >>> Okay, I spent some time with Sam on IRC hashing this out. > Assuming > > >>> that > > >>> >>> Seam-Spring is covered under the SG(s?) Red Hat has filed for > > >>> deltaspike, > > >>> >>> his view is that it's not terribly important who does the initial > > code > > >>> >>> import, though it would be best for a so-authorized Red Hatter to > > be > > >>> the > > >>> >>> one to change the file headers. I will be out of pocket for the > > rest > > >>> of > > >>> >>> the week beyond today, so if you, Marius, are able to work on the > > >>> import > > >>> >>> end of this week/early next then that's in any event as soon as I > > would > > >>> >>> have been able to get to it anyway. Otherwise, anyone can do > that, > > >>> with > > >>> >>> someone still employed by RH finally applying the change that > > modifies > > >>> >>> the > > >>> >>> headers--which, I suppose, could be prepared by anyone else and > > simply > > >>> >>> shared among our private git repos. > > >>> >>> > > >>> >>> Matt > > >>> >>> > > >>> >>> > > >>> >>> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici < > > >>> >>> marius.bogoev...@gmail.com> wrote: > > >>> >>> > > >>> >>> > I still am a participant on this thread, but doing more reading > > than > > >>> >>> > writing as of late :) > > >>> >>> > > > >>> >>> > So, yes, I've been strapped for time with the job and the > > transition, > > >>> >>> but > > >>> >>> > I'd be happy to help out with this at the end of the week or > > early > > >>> >>> next. > > >>> >>> > > > >>> >>> > With my CLA on file, and the code being granted already, I'm > not > > sure > > >>> >>> what > > >>> >>> > else needs to be done. I'm happy for the code to live in > > DeltaSpike, > > >>> >>> fwiw. > > >>> >>> > > > >>> >>> > On 2013-02-18, at 6:50 PM, Matt Benson > > wrote: > > >>> >>> > > > >>> >>> > > Seems Marius's prior participation on this thread was via a > > gmail > > >>> >>> > address. > > >>> >>> > > With him no longer at Red Hat we definitely want to make sure > > we > > >>> >>> take the > > >>> >>> > > necessary precautions wrt IP. > > >>> >>> > > > > >>> >>> > > Matt > > >>> >>> > > > > >>> >>> > > > > >>> >>> > > On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter < > > >>> >
[jira] [Created] (DELTASPIKE-511) Navigation seems not to work
Paa Kojo Konduah Amos created DELTASPIKE-511:
Summary: Navigation seems not to work
Key: DELTASPIKE-511
URL: https://issues.apache.org/jira/browse/DELTASPIKE-511
Project: DeltaSpike
Issue Type: Bug
Components: BeanValidation-Module, JSF-Module
Affects Versions: 0.5, 0.6
Environment: Ubuntu , Java 7, Eclipse Kepler, Widfly,
Reporter: Paa Kojo Konduah Amos
>From the online documenation on the JSF Module page,
public class MyPage implements ViewConfig{} and
public Class
[jira] [Closed] (DELTASPIKE-510) PersistenceException not handled by @Handles @FacesRequest ExceptionEvent
[
https://issues.apache.org/jira/browse/DELTASPIKE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Esteve closed DELTASPIKE-510.
-
> PersistenceException not handled by @Handles @FacesRequest
> ExceptionEvent
> -
>
> Key: DELTASPIKE-510
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-510
> Project: DeltaSpike
> Issue Type: Bug
> Components: ExceptionControl-Module
>Affects Versions: 0.5
> Environment: JBoss AS 7.1
>Reporter: Esteve
> Labels: exception-handling
>
> Hi,
> I have defined a @ExceptionHandler like this:
> @ExceptionHandler
> public class FacesExceptionHandler {
> @Inject
> private Logger log;
>
> public void handlePersistenceException(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext
> facesContext) {
> log.debug( "JSF Exception handler. Handling
> javax.persistence.PersistenceException: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, "S'ha produït un error al
> emmagatzemar les dades a la base de dades:
> "+evt.getException().getLocalizedMessage() , ""));
> evt.handledAndContinue();
> }
> public void handleOptimisticLockException(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext facesContext) {
> log.debug( "JSF Exception handler. Handling
> OptimisticLockException: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, "El registre ha estat modificat a
> la base de dades per un altre procés. Les dades no s'han guardat.", ""));
> evt.handled();
> }
> public void showFacesMessage(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext facesContext) {
> log.debug( "JSF Exception handler. Handling Throwable: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, evt.getException().getMessage(),
> ""));
> evt.handledAndContinue();
> }
>
>
> }
> But javax.persistence.PersistenceException is not handled:
> (http-localhost-127.0.0.1-8080-4) Error processing Update: :
> javax.persistence.PersistenceException:
> org.hibernate.exception.ConstraintViolationException: Unique index or primary
> key violation: "CONSTRAINT_INDEX_4 ON
> PUBLIC.UNITAT_NEGOCI_CANAL_VENDA(UNITAT_NEGOCI_ID, CANAL_VENDA_ID)"; SQL
> statement:
> update UNITAT_NEGOCI_CANAL_VENDA set CODI_USUARI_ULTIMA_MODIFICACIO=?,
> DATAHORA_CREACIO=?, DATAHORA_ULTIMA_MODIFICACIO=?, DATAHORA_ALTA=?,
> DATAHORA_BAIXA=?, CANAL_VENDA_ID=?, UNITAT_NEGOCI_ID=?, VERSION=? where ID=?
> and VERSION=? [23505-161]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:976)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.jboss.as.jpa.container.AbstractEntityManager.flush(AbstractEntityManager.java:439)
> [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at
> cat.tmb.tdo.ocicommerce.view.UnitatNegociCanalVendaBean.update(UnitatNegociCanalVendaBean.java:157)
> [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.7.0_51]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [rt.jar:1.7.0_51]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at
> org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
> [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:127)
> [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final]
> at
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.
[jira] [Commented] (DELTASPIKE-510) PersistenceException not handled by @Handles @FacesRequest ExceptionEvent
[
https://issues.apache.org/jira/browse/DELTASPIKE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13879213#comment-13879213
]
Jason Porter commented on DELTASPIKE-510:
-
No problem, glad you found the issue!
> PersistenceException not handled by @Handles @FacesRequest
> ExceptionEvent
> -
>
> Key: DELTASPIKE-510
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-510
> Project: DeltaSpike
> Issue Type: Bug
> Components: ExceptionControl-Module
>Affects Versions: 0.5
> Environment: JBoss AS 7.1
>Reporter: Esteve
> Labels: exception-handling
>
> Hi,
> I have defined a @ExceptionHandler like this:
> @ExceptionHandler
> public class FacesExceptionHandler {
> @Inject
> private Logger log;
>
> public void handlePersistenceException(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext
> facesContext) {
> log.debug( "JSF Exception handler. Handling
> javax.persistence.PersistenceException: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, "S'ha produït un error al
> emmagatzemar les dades a la base de dades:
> "+evt.getException().getLocalizedMessage() , ""));
> evt.handledAndContinue();
> }
> public void handleOptimisticLockException(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext facesContext) {
> log.debug( "JSF Exception handler. Handling
> OptimisticLockException: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, "El registre ha estat modificat a
> la base de dades per un altre procés. Les dades no s'han guardat.", ""));
> evt.handled();
> }
> public void showFacesMessage(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext facesContext) {
> log.debug( "JSF Exception handler. Handling Throwable: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, evt.getException().getMessage(),
> ""));
> evt.handledAndContinue();
> }
>
>
> }
> But javax.persistence.PersistenceException is not handled:
> (http-localhost-127.0.0.1-8080-4) Error processing Update: :
> javax.persistence.PersistenceException:
> org.hibernate.exception.ConstraintViolationException: Unique index or primary
> key violation: "CONSTRAINT_INDEX_4 ON
> PUBLIC.UNITAT_NEGOCI_CANAL_VENDA(UNITAT_NEGOCI_ID, CANAL_VENDA_ID)"; SQL
> statement:
> update UNITAT_NEGOCI_CANAL_VENDA set CODI_USUARI_ULTIMA_MODIFICACIO=?,
> DATAHORA_CREACIO=?, DATAHORA_ULTIMA_MODIFICACIO=?, DATAHORA_ALTA=?,
> DATAHORA_BAIXA=?, CANAL_VENDA_ID=?, UNITAT_NEGOCI_ID=?, VERSION=? where ID=?
> and VERSION=? [23505-161]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:976)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.jboss.as.jpa.container.AbstractEntityManager.flush(AbstractEntityManager.java:439)
> [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at
> cat.tmb.tdo.ocicommerce.view.UnitatNegociCanalVendaBean.update(UnitatNegociCanalVendaBean.java:157)
> [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.7.0_51]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [rt.jar:1.7.0_51]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at
> org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
> [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:127)
[jira] [Resolved] (DELTASPIKE-510) PersistenceException not handled by @Handles @FacesRequest ExceptionEvent
[
https://issues.apache.org/jira/browse/DELTASPIKE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Esteve resolved DELTASPIKE-510.
---
Resolution: Invalid
> PersistenceException not handled by @Handles @FacesRequest
> ExceptionEvent
> -
>
> Key: DELTASPIKE-510
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-510
> Project: DeltaSpike
> Issue Type: Bug
> Components: ExceptionControl-Module
>Affects Versions: 0.5
> Environment: JBoss AS 7.1
>Reporter: Esteve
> Labels: exception-handling
>
> Hi,
> I have defined a @ExceptionHandler like this:
> @ExceptionHandler
> public class FacesExceptionHandler {
> @Inject
> private Logger log;
>
> public void handlePersistenceException(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext
> facesContext) {
> log.debug( "JSF Exception handler. Handling
> javax.persistence.PersistenceException: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, "S'ha produït un error al
> emmagatzemar les dades a la base de dades:
> "+evt.getException().getLocalizedMessage() , ""));
> evt.handledAndContinue();
> }
> public void handleOptimisticLockException(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext facesContext) {
> log.debug( "JSF Exception handler. Handling
> OptimisticLockException: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, "El registre ha estat modificat a
> la base de dades per un altre procés. Les dades no s'han guardat.", ""));
> evt.handled();
> }
> public void showFacesMessage(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext facesContext) {
> log.debug( "JSF Exception handler. Handling Throwable: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, evt.getException().getMessage(),
> ""));
> evt.handledAndContinue();
> }
>
>
> }
> But javax.persistence.PersistenceException is not handled:
> (http-localhost-127.0.0.1-8080-4) Error processing Update: :
> javax.persistence.PersistenceException:
> org.hibernate.exception.ConstraintViolationException: Unique index or primary
> key violation: "CONSTRAINT_INDEX_4 ON
> PUBLIC.UNITAT_NEGOCI_CANAL_VENDA(UNITAT_NEGOCI_ID, CANAL_VENDA_ID)"; SQL
> statement:
> update UNITAT_NEGOCI_CANAL_VENDA set CODI_USUARI_ULTIMA_MODIFICACIO=?,
> DATAHORA_CREACIO=?, DATAHORA_ULTIMA_MODIFICACIO=?, DATAHORA_ALTA=?,
> DATAHORA_BAIXA=?, CANAL_VENDA_ID=?, UNITAT_NEGOCI_ID=?, VERSION=? where ID=?
> and VERSION=? [23505-161]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:976)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.jboss.as.jpa.container.AbstractEntityManager.flush(AbstractEntityManager.java:439)
> [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at
> cat.tmb.tdo.ocicommerce.view.UnitatNegociCanalVendaBean.update(UnitatNegociCanalVendaBean.java:157)
> [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.7.0_51]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [rt.jar:1.7.0_51]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at
> org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
> [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:127)
> [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final]
> at
> org.jboss.as.weld.ej
[jira] [Commented] (DELTASPIKE-510) PersistenceException not handled by @Handles @FacesRequest ExceptionEvent
[
https://issues.apache.org/jira/browse/DELTASPIKE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13879211#comment-13879211
]
Esteve commented on DELTASPIKE-510:
---
Jason,
Thanks for your rapid answer. I saw I was catching the Exception before
handlers could handle it. (I am using Forge and it has overwritten my bean).
Thanks.
> PersistenceException not handled by @Handles @FacesRequest
> ExceptionEvent
> -
>
> Key: DELTASPIKE-510
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-510
> Project: DeltaSpike
> Issue Type: Bug
> Components: ExceptionControl-Module
>Affects Versions: 0.5
> Environment: JBoss AS 7.1
>Reporter: Esteve
> Labels: exception-handling
>
> Hi,
> I have defined a @ExceptionHandler like this:
> @ExceptionHandler
> public class FacesExceptionHandler {
> @Inject
> private Logger log;
>
> public void handlePersistenceException(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext
> facesContext) {
> log.debug( "JSF Exception handler. Handling
> javax.persistence.PersistenceException: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, "S'ha produït un error al
> emmagatzemar les dades a la base de dades:
> "+evt.getException().getLocalizedMessage() , ""));
> evt.handledAndContinue();
> }
> public void handleOptimisticLockException(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext facesContext) {
> log.debug( "JSF Exception handler. Handling
> OptimisticLockException: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, "El registre ha estat modificat a
> la base de dades per un altre procés. Les dades no s'han guardat.", ""));
> evt.handled();
> }
> public void showFacesMessage(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext facesContext) {
> log.debug( "JSF Exception handler. Handling Throwable: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, evt.getException().getMessage(),
> ""));
> evt.handledAndContinue();
> }
>
>
> }
> But javax.persistence.PersistenceException is not handled:
> (http-localhost-127.0.0.1-8080-4) Error processing Update: :
> javax.persistence.PersistenceException:
> org.hibernate.exception.ConstraintViolationException: Unique index or primary
> key violation: "CONSTRAINT_INDEX_4 ON
> PUBLIC.UNITAT_NEGOCI_CANAL_VENDA(UNITAT_NEGOCI_ID, CANAL_VENDA_ID)"; SQL
> statement:
> update UNITAT_NEGOCI_CANAL_VENDA set CODI_USUARI_ULTIMA_MODIFICACIO=?,
> DATAHORA_CREACIO=?, DATAHORA_ULTIMA_MODIFICACIO=?, DATAHORA_ALTA=?,
> DATAHORA_BAIXA=?, CANAL_VENDA_ID=?, UNITAT_NEGOCI_ID=?, VERSION=? where ID=?
> and VERSION=? [23505-161]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:976)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.jboss.as.jpa.container.AbstractEntityManager.flush(AbstractEntityManager.java:439)
> [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at
> cat.tmb.tdo.ocicommerce.view.UnitatNegociCanalVendaBean.update(UnitatNegociCanalVendaBean.java:157)
> [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.7.0_51]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [rt.jar:1.7.0_51]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at
> org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
> [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>
[jira] [Commented] (DELTASPIKE-510) PersistenceException not handled by @Handles @FacesRequest ExceptionEvent
[
https://issues.apache.org/jira/browse/DELTASPIKE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13879186#comment-13879186
]
Jason Porter commented on DELTASPIKE-510:
-
This is working exactly as it should, and exactly as it is documented. Take a
look at http://deltaspike.apache.org/core.html#exception-handler-annotations,
the last example. In both the example and the code in your project the
exception handlers are being qualified, exactly the same way qualifiers in base
CDI.
Without seeing where this exception is coming from (is the exception qualified
when it's sent to exception handling?) the best I can surmise is that the
exception when it is sent for exception handling is not receiving the
{{@FacesRequest}} qualifier, therefore none of the handlers in your code will
pick it up.
> PersistenceException not handled by @Handles @FacesRequest
> ExceptionEvent
> -
>
> Key: DELTASPIKE-510
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-510
> Project: DeltaSpike
> Issue Type: Bug
> Components: ExceptionControl-Module
>Affects Versions: 0.5
> Environment: JBoss AS 7.1
>Reporter: Esteve
> Labels: exception-handling
>
> Hi,
> I have defined a @ExceptionHandler like this:
> @ExceptionHandler
> public class FacesExceptionHandler {
> @Inject
> private Logger log;
>
> public void handlePersistenceException(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext
> facesContext) {
> log.debug( "JSF Exception handler. Handling
> javax.persistence.PersistenceException: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, "S'ha produït un error al
> emmagatzemar les dades a la base de dades:
> "+evt.getException().getLocalizedMessage() , ""));
> evt.handledAndContinue();
> }
> public void handleOptimisticLockException(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext facesContext) {
> log.debug( "JSF Exception handler. Handling
> OptimisticLockException: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, "El registre ha estat modificat a
> la base de dades per un altre procés. Les dades no s'han guardat.", ""));
> evt.handled();
> }
> public void showFacesMessage(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext facesContext) {
> log.debug( "JSF Exception handler. Handling Throwable: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, evt.getException().getMessage(),
> ""));
> evt.handledAndContinue();
> }
>
>
> }
> But javax.persistence.PersistenceException is not handled:
> (http-localhost-127.0.0.1-8080-4) Error processing Update: :
> javax.persistence.PersistenceException:
> org.hibernate.exception.ConstraintViolationException: Unique index or primary
> key violation: "CONSTRAINT_INDEX_4 ON
> PUBLIC.UNITAT_NEGOCI_CANAL_VENDA(UNITAT_NEGOCI_ID, CANAL_VENDA_ID)"; SQL
> statement:
> update UNITAT_NEGOCI_CANAL_VENDA set CODI_USUARI_ULTIMA_MODIFICACIO=?,
> DATAHORA_CREACIO=?, DATAHORA_ULTIMA_MODIFICACIO=?, DATAHORA_ALTA=?,
> DATAHORA_BAIXA=?, CANAL_VENDA_ID=?, UNITAT_NEGOCI_ID=?, VERSION=? where ID=?
> and VERSION=? [23505-161]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:976)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.jboss.as.jpa.container.AbstractEntityManager.flush(AbstractEntityManager.java:439)
> [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at
> cat.tmb.tdo.ocicommerce.view.UnitatNegociCanalVendaBean.update(UnitatNegociCanalVendaBean.java:157)
> [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.7.0_51]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [rt.jar:1.7.0_51]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at
> org.jboss.as.ee.component.Mana
[jira] [Created] (DELTASPIKE-510) PersistenceException not handled by @Handles @FacesRequest ExceptionEvent
Esteve created DELTASPIKE-510:
-
Summary: PersistenceException not handled by @Handles
@FacesRequest ExceptionEvent
Key: DELTASPIKE-510
URL: https://issues.apache.org/jira/browse/DELTASPIKE-510
Project: DeltaSpike
Issue Type: Bug
Components: ExceptionControl-Module
Affects Versions: 0.5
Environment: JBoss AS 7.1
Reporter: Esteve
Hi,
I have defined a @ExceptionHandler like this:
@ExceptionHandler
public class FacesExceptionHandler {
@Inject
private Logger log;
public void handlePersistenceException(@Handles @FacesRequest
ExceptionEvent evt, FacesContext
facesContext) {
log.debug( "JSF Exception handler. Handling
javax.persistence.PersistenceException: ", evt);
facesContext.addMessage(null, new
FacesMessage(FacesMessage.SEVERITY_ERROR, "S'ha produït un error al
emmagatzemar les dades a la base de dades:
"+evt.getException().getLocalizedMessage() , ""));
evt.handledAndContinue();
}
public void handleOptimisticLockException(@Handles @FacesRequest
ExceptionEvent evt, FacesContext facesContext) {
log.debug( "JSF Exception handler. Handling
OptimisticLockException: ", evt);
facesContext.addMessage(null, new
FacesMessage(FacesMessage.SEVERITY_ERROR, "El registre ha estat modificat a la
base de dades per un altre procés. Les dades no s'han guardat.", ""));
evt.handled();
}
public void showFacesMessage(@Handles @FacesRequest
ExceptionEvent evt, FacesContext facesContext) {
log.debug( "JSF Exception handler. Handling Throwable: ", evt);
facesContext.addMessage(null, new
FacesMessage(FacesMessage.SEVERITY_ERROR, evt.getException().getMessage(), ""));
evt.handledAndContinue();
}
}
But javax.persistence.PersistenceException is not handled:
(http-localhost-127.0.0.1-8080-4) Error processing Update: :
javax.persistence.PersistenceException:
org.hibernate.exception.ConstraintViolationException: Unique index or primary
key violation: "CONSTRAINT_INDEX_4 ON
PUBLIC.UNITAT_NEGOCI_CANAL_VENDA(UNITAT_NEGOCI_ID, CANAL_VENDA_ID)"; SQL
statement:
update UNITAT_NEGOCI_CANAL_VENDA set CODI_USUARI_ULTIMA_MODIFICACIO=?,
DATAHORA_CREACIO=?, DATAHORA_ULTIMA_MODIFICACIO=?, DATAHORA_ALTA=?,
DATAHORA_BAIXA=?, CANAL_VENDA_ID=?, UNITAT_NEGOCI_ID=?, VERSION=? where ID=?
and VERSION=? [23505-161]
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
[hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
[hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
[hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
at
org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:976)
[hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
at
org.jboss.as.jpa.container.AbstractEntityManager.flush(AbstractEntityManager.java:439)
[jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
at
cat.tmb.tdo.ocicommerce.view.UnitatNegociCanalVendaBean.update(UnitatNegociCanalVendaBean.java:157)
[classes:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.7.0_51]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[rt.jar:1.7.0_51]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.7.0_51]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
at
org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
[jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
[jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
[jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:127)
[jboss-as-weld-7.1.1.Final.jar:7.1.1.Final]
at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:135)
[jboss-as-weld-7.1.1.Final.jar:7.1.1.Final]
at
org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36)
[jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
[jboss-invocation
[jira] [Created] (DELTASPIKE-509) [perf] cache map in DefaultClientWindow#getQueryURLParameters
Thomas Andraschko created DELTASPIKE-509: Summary: [perf] cache map in DefaultClientWindow#getQueryURLParameters Key: DELTASPIKE-509 URL: https://issues.apache.org/jira/browse/DELTASPIKE-509 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Priority: Minor Currently a new map will be created for each actionUrl -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
+1 for adding the Spring integration On Wed, Jan 22, 2014 at 11:21 AM, John D. Ament wrote: > +1 to Romain > I'd like to see something like this for a 1.0 release. It would be a > real game changer. > > On Wed, Jan 22, 2014 at 12:03 PM, Romain Manni-Bucau > wrote: > > I'd release 0.6 before having it, it will surely create discussion > > once we'll get something and it is easy to do something totally > > brokenn in particular when we'll want to get something clever in a web > > context > > > > btw we shouldn't do it without pivotal IMO > > Romain Manni-Bucau > > Twitter: @rmannibucau > > Blog: http://rmannibucau.wordpress.com/ > > LinkedIn: http://fr.linkedin.com/in/rmannibucau > > Github: https://github.com/rmannibucau > > > > > > > > 2014/1/22 Jason Porter : > >> Do we just want to take what we had in Seam 3 and move it over? > >> > >> > >> On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek < > >> gerhard.petra...@gmail.com> wrote: > >> > >>> hi jason, > >>> > >>> the bridge doesn't introduce an api and the spi just provides a simple > >>> contract for starting the container as well as a bean-filter. > >>> -> if needed, we could improve the implementation at any time. > >>> imo we should add it before the release of v0.6 (since a lot of users > >>> requested such a bridge). > >>> > >>> regards, > >>> gerhard > >>> > >>> > >>> > >>> 2014/1/22 Jason Porter > >>> > >>> > I'd like to engage the Pivotal Team (anyone have contacts?) to see > if we > >>> > can get some of there help as well to create a really good > integration. > >>> > > >>> > > >>> > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek < > >>> > gerhard.petra...@gmail.com> wrote: > >>> > > >>> >> hi @ all, > >>> >> > >>> >> i would like to continue with this discussion. > >>> >> > >>> >> [1] describes a two-way bridge which is already based on deltaspike. > >>> >> it offers a simple spi which allows more advanced add-ons like it is > >>> >> mentioned in [2]. > >>> >> > >>> >> regards, > >>> >> gerhard > >>> >> > >>> >> [1] > >>> >> > >>> > http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html > >>> >> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html > >>> >> > >>> >> > >>> >> > >>> >> 2013/2/19 Matt Benson > >>> >> > >>> >>> Okay, I spent some time with Sam on IRC hashing this out. Assuming > >>> that > >>> >>> Seam-Spring is covered under the SG(s?) Red Hat has filed for > >>> deltaspike, > >>> >>> his view is that it's not terribly important who does the initial > code > >>> >>> import, though it would be best for a so-authorized Red Hatter to > be > >>> the > >>> >>> one to change the file headers. I will be out of pocket for the > rest > >>> of > >>> >>> the week beyond today, so if you, Marius, are able to work on the > >>> import > >>> >>> end of this week/early next then that's in any event as soon as I > would > >>> >>> have been able to get to it anyway. Otherwise, anyone can do that, > >>> with > >>> >>> someone still employed by RH finally applying the change that > modifies > >>> >>> the > >>> >>> headers--which, I suppose, could be prepared by anyone else and > simply > >>> >>> shared among our private git repos. > >>> >>> > >>> >>> Matt > >>> >>> > >>> >>> > >>> >>> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici < > >>> >>> marius.bogoev...@gmail.com> wrote: > >>> >>> > >>> >>> > I still am a participant on this thread, but doing more reading > than > >>> >>> > writing as of late :) > >>> >>> > > >>> >>> > So, yes, I've been strapped for time with the job and the > transition, > >>> >>> but > >>> >>> > I'd be happy to help out with this at the end of the week or > early > >>> >>> next. > >>> >>> > > >>> >>> > With my CLA on file, and the code being granted already, I'm not > sure > >>> >>> what > >>> >>> > else needs to be done. I'm happy for the code to live in > DeltaSpike, > >>> >>> fwiw. > >>> >>> > > >>> >>> > On 2013-02-18, at 6:50 PM, Matt Benson > wrote: > >>> >>> > > >>> >>> > > Seems Marius's prior participation on this thread was via a > gmail > >>> >>> > address. > >>> >>> > > With him no longer at Red Hat we definitely want to make sure > we > >>> >>> take the > >>> >>> > > necessary precautions wrt IP. > >>> >>> > > > >>> >>> > > Matt > >>> >>> > > > >>> >>> > > > >>> >>> > > On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter < > >>> >>> lightguard...@gmail.com > >>> >>> > >wrote: > >>> >>> > > > >>> >>> > >> I'm pretty sure we've granted Seam Spring to Apache. I'll > need to > >>> >>> check > >>> >>> > to > >>> >>> > >> see if Marius has subscribed to this list on a personal email > as > >>> he > >>> >>> has > >>> >>> > >> embarked on a new adventure outside of Red Hat. > >>> >>> > >> > >>> >>> > >> > >>> >>> > >> On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson < > >>> gudnabr...@gmail.com> > >>> >>> > wrote: > >>> >>> > >> > >>> >>> > >>> Let me refine my plan to say that it would be *best* if > Marius > >>> >>> does the > >>> >>> > >>> commit since AIUI this is mostly code h
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
+1 to Romain I'd like to see something like this for a 1.0 release. It would be a real game changer. On Wed, Jan 22, 2014 at 12:03 PM, Romain Manni-Bucau wrote: > I'd release 0.6 before having it, it will surely create discussion > once we'll get something and it is easy to do something totally > brokenn in particular when we'll want to get something clever in a web > context > > btw we shouldn't do it without pivotal IMO > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014/1/22 Jason Porter : >> Do we just want to take what we had in Seam 3 and move it over? >> >> >> On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek < >> gerhard.petra...@gmail.com> wrote: >> >>> hi jason, >>> >>> the bridge doesn't introduce an api and the spi just provides a simple >>> contract for starting the container as well as a bean-filter. >>> -> if needed, we could improve the implementation at any time. >>> imo we should add it before the release of v0.6 (since a lot of users >>> requested such a bridge). >>> >>> regards, >>> gerhard >>> >>> >>> >>> 2014/1/22 Jason Porter >>> >>> > I'd like to engage the Pivotal Team (anyone have contacts?) to see if we >>> > can get some of there help as well to create a really good integration. >>> > >>> > >>> > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek < >>> > gerhard.petra...@gmail.com> wrote: >>> > >>> >> hi @ all, >>> >> >>> >> i would like to continue with this discussion. >>> >> >>> >> [1] describes a two-way bridge which is already based on deltaspike. >>> >> it offers a simple spi which allows more advanced add-ons like it is >>> >> mentioned in [2]. >>> >> >>> >> regards, >>> >> gerhard >>> >> >>> >> [1] >>> >> >>> http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html >>> >> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html >>> >> >>> >> >>> >> >>> >> 2013/2/19 Matt Benson >>> >> >>> >>> Okay, I spent some time with Sam on IRC hashing this out. Assuming >>> that >>> >>> Seam-Spring is covered under the SG(s?) Red Hat has filed for >>> deltaspike, >>> >>> his view is that it's not terribly important who does the initial code >>> >>> import, though it would be best for a so-authorized Red Hatter to be >>> the >>> >>> one to change the file headers. I will be out of pocket for the rest >>> of >>> >>> the week beyond today, so if you, Marius, are able to work on the >>> import >>> >>> end of this week/early next then that's in any event as soon as I would >>> >>> have been able to get to it anyway. Otherwise, anyone can do that, >>> with >>> >>> someone still employed by RH finally applying the change that modifies >>> >>> the >>> >>> headers--which, I suppose, could be prepared by anyone else and simply >>> >>> shared among our private git repos. >>> >>> >>> >>> Matt >>> >>> >>> >>> >>> >>> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici < >>> >>> marius.bogoev...@gmail.com> wrote: >>> >>> >>> >>> > I still am a participant on this thread, but doing more reading than >>> >>> > writing as of late :) >>> >>> > >>> >>> > So, yes, I've been strapped for time with the job and the transition, >>> >>> but >>> >>> > I'd be happy to help out with this at the end of the week or early >>> >>> next. >>> >>> > >>> >>> > With my CLA on file, and the code being granted already, I'm not sure >>> >>> what >>> >>> > else needs to be done. I'm happy for the code to live in DeltaSpike, >>> >>> fwiw. >>> >>> > >>> >>> > On 2013-02-18, at 6:50 PM, Matt Benson wrote: >>> >>> > >>> >>> > > Seems Marius's prior participation on this thread was via a gmail >>> >>> > address. >>> >>> > > With him no longer at Red Hat we definitely want to make sure we >>> >>> take the >>> >>> > > necessary precautions wrt IP. >>> >>> > > >>> >>> > > Matt >>> >>> > > >>> >>> > > >>> >>> > > On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter < >>> >>> lightguard...@gmail.com >>> >>> > >wrote: >>> >>> > > >>> >>> > >> I'm pretty sure we've granted Seam Spring to Apache. I'll need to >>> >>> check >>> >>> > to >>> >>> > >> see if Marius has subscribed to this list on a personal email as >>> he >>> >>> has >>> >>> > >> embarked on a new adventure outside of Red Hat. >>> >>> > >> >>> >>> > >> >>> >>> > >> On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson < >>> gudnabr...@gmail.com> >>> >>> > wrote: >>> >>> > >> >>> >>> > >>> Let me refine my plan to say that it would be *best* if Marius >>> >>> does the >>> >>> > >>> commit since AIUI this is mostly code he personally authored, but >>> >>> as >>> >>> > long >>> >>> > >>> as RH intends for Seam-Spring to be donated to Apache deltaspike, >>> >>> > probably >>> >>> > >>> no irreparable *harm* would be caused by another Red Hatter >>> >>> pulling the >>> >>> > >>> trigger. >>> >>> > >>> >>> >>> > >>> Matt >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson < >>> gudnabr...@gmai
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
I'd release 0.6 before having it, it will surely create discussion once we'll get something and it is easy to do something totally brokenn in particular when we'll want to get something clever in a web context btw we shouldn't do it without pivotal IMO Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014/1/22 Jason Porter : > Do we just want to take what we had in Seam 3 and move it over? > > > On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek < > gerhard.petra...@gmail.com> wrote: > >> hi jason, >> >> the bridge doesn't introduce an api and the spi just provides a simple >> contract for starting the container as well as a bean-filter. >> -> if needed, we could improve the implementation at any time. >> imo we should add it before the release of v0.6 (since a lot of users >> requested such a bridge). >> >> regards, >> gerhard >> >> >> >> 2014/1/22 Jason Porter >> >> > I'd like to engage the Pivotal Team (anyone have contacts?) to see if we >> > can get some of there help as well to create a really good integration. >> > >> > >> > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek < >> > gerhard.petra...@gmail.com> wrote: >> > >> >> hi @ all, >> >> >> >> i would like to continue with this discussion. >> >> >> >> [1] describes a two-way bridge which is already based on deltaspike. >> >> it offers a simple spi which allows more advanced add-ons like it is >> >> mentioned in [2]. >> >> >> >> regards, >> >> gerhard >> >> >> >> [1] >> >> >> http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html >> >> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html >> >> >> >> >> >> >> >> 2013/2/19 Matt Benson >> >> >> >>> Okay, I spent some time with Sam on IRC hashing this out. Assuming >> that >> >>> Seam-Spring is covered under the SG(s?) Red Hat has filed for >> deltaspike, >> >>> his view is that it's not terribly important who does the initial code >> >>> import, though it would be best for a so-authorized Red Hatter to be >> the >> >>> one to change the file headers. I will be out of pocket for the rest >> of >> >>> the week beyond today, so if you, Marius, are able to work on the >> import >> >>> end of this week/early next then that's in any event as soon as I would >> >>> have been able to get to it anyway. Otherwise, anyone can do that, >> with >> >>> someone still employed by RH finally applying the change that modifies >> >>> the >> >>> headers--which, I suppose, could be prepared by anyone else and simply >> >>> shared among our private git repos. >> >>> >> >>> Matt >> >>> >> >>> >> >>> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici < >> >>> marius.bogoev...@gmail.com> wrote: >> >>> >> >>> > I still am a participant on this thread, but doing more reading than >> >>> > writing as of late :) >> >>> > >> >>> > So, yes, I've been strapped for time with the job and the transition, >> >>> but >> >>> > I'd be happy to help out with this at the end of the week or early >> >>> next. >> >>> > >> >>> > With my CLA on file, and the code being granted already, I'm not sure >> >>> what >> >>> > else needs to be done. I'm happy for the code to live in DeltaSpike, >> >>> fwiw. >> >>> > >> >>> > On 2013-02-18, at 6:50 PM, Matt Benson wrote: >> >>> > >> >>> > > Seems Marius's prior participation on this thread was via a gmail >> >>> > address. >> >>> > > With him no longer at Red Hat we definitely want to make sure we >> >>> take the >> >>> > > necessary precautions wrt IP. >> >>> > > >> >>> > > Matt >> >>> > > >> >>> > > >> >>> > > On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter < >> >>> lightguard...@gmail.com >> >>> > >wrote: >> >>> > > >> >>> > >> I'm pretty sure we've granted Seam Spring to Apache. I'll need to >> >>> check >> >>> > to >> >>> > >> see if Marius has subscribed to this list on a personal email as >> he >> >>> has >> >>> > >> embarked on a new adventure outside of Red Hat. >> >>> > >> >> >>> > >> >> >>> > >> On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson < >> gudnabr...@gmail.com> >> >>> > wrote: >> >>> > >> >> >>> > >>> Let me refine my plan to say that it would be *best* if Marius >> >>> does the >> >>> > >>> commit since AIUI this is mostly code he personally authored, but >> >>> as >> >>> > long >> >>> > >>> as RH intends for Seam-Spring to be donated to Apache deltaspike, >> >>> > probably >> >>> > >>> no irreparable *harm* would be caused by another Red Hatter >> >>> pulling the >> >>> > >>> trigger. >> >>> > >>> >> >>> > >>> Matt >> >>> > >>> >> >>> > >>> >> >>> > >>> On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson < >> gudnabr...@gmail.com >> >>> > >> >>> > >>> wrote: >> >>> > >>> >> >>> > I think this received enough +1 votes (I'll add mine now) to >> >>> proceed. >> >>> > >>> If >> >>> > a Red Hatter (Marius?) would do the simplest repackaging >> possible >> >>> and >> >>> > commit that then others could join in the quest to modula
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
Do we just want to take what we had in Seam 3 and move it over? On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek < gerhard.petra...@gmail.com> wrote: > hi jason, > > the bridge doesn't introduce an api and the spi just provides a simple > contract for starting the container as well as a bean-filter. > -> if needed, we could improve the implementation at any time. > imo we should add it before the release of v0.6 (since a lot of users > requested such a bridge). > > regards, > gerhard > > > > 2014/1/22 Jason Porter > > > I'd like to engage the Pivotal Team (anyone have contacts?) to see if we > > can get some of there help as well to create a really good integration. > > > > > > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek < > > gerhard.petra...@gmail.com> wrote: > > > >> hi @ all, > >> > >> i would like to continue with this discussion. > >> > >> [1] describes a two-way bridge which is already based on deltaspike. > >> it offers a simple spi which allows more advanced add-ons like it is > >> mentioned in [2]. > >> > >> regards, > >> gerhard > >> > >> [1] > >> > http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html > >> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html > >> > >> > >> > >> 2013/2/19 Matt Benson > >> > >>> Okay, I spent some time with Sam on IRC hashing this out. Assuming > that > >>> Seam-Spring is covered under the SG(s?) Red Hat has filed for > deltaspike, > >>> his view is that it's not terribly important who does the initial code > >>> import, though it would be best for a so-authorized Red Hatter to be > the > >>> one to change the file headers. I will be out of pocket for the rest > of > >>> the week beyond today, so if you, Marius, are able to work on the > import > >>> end of this week/early next then that's in any event as soon as I would > >>> have been able to get to it anyway. Otherwise, anyone can do that, > with > >>> someone still employed by RH finally applying the change that modifies > >>> the > >>> headers--which, I suppose, could be prepared by anyone else and simply > >>> shared among our private git repos. > >>> > >>> Matt > >>> > >>> > >>> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici < > >>> marius.bogoev...@gmail.com> wrote: > >>> > >>> > I still am a participant on this thread, but doing more reading than > >>> > writing as of late :) > >>> > > >>> > So, yes, I've been strapped for time with the job and the transition, > >>> but > >>> > I'd be happy to help out with this at the end of the week or early > >>> next. > >>> > > >>> > With my CLA on file, and the code being granted already, I'm not sure > >>> what > >>> > else needs to be done. I'm happy for the code to live in DeltaSpike, > >>> fwiw. > >>> > > >>> > On 2013-02-18, at 6:50 PM, Matt Benson wrote: > >>> > > >>> > > Seems Marius's prior participation on this thread was via a gmail > >>> > address. > >>> > > With him no longer at Red Hat we definitely want to make sure we > >>> take the > >>> > > necessary precautions wrt IP. > >>> > > > >>> > > Matt > >>> > > > >>> > > > >>> > > On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter < > >>> lightguard...@gmail.com > >>> > >wrote: > >>> > > > >>> > >> I'm pretty sure we've granted Seam Spring to Apache. I'll need to > >>> check > >>> > to > >>> > >> see if Marius has subscribed to this list on a personal email as > he > >>> has > >>> > >> embarked on a new adventure outside of Red Hat. > >>> > >> > >>> > >> > >>> > >> On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson < > gudnabr...@gmail.com> > >>> > wrote: > >>> > >> > >>> > >>> Let me refine my plan to say that it would be *best* if Marius > >>> does the > >>> > >>> commit since AIUI this is mostly code he personally authored, but > >>> as > >>> > long > >>> > >>> as RH intends for Seam-Spring to be donated to Apache deltaspike, > >>> > probably > >>> > >>> no irreparable *harm* would be caused by another Red Hatter > >>> pulling the > >>> > >>> trigger. > >>> > >>> > >>> > >>> Matt > >>> > >>> > >>> > >>> > >>> > >>> On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson < > gudnabr...@gmail.com > >>> > > >>> > >>> wrote: > >>> > >>> > >>> > I think this received enough +1 votes (I'll add mine now) to > >>> proceed. > >>> > >>> If > >>> > a Red Hatter (Marius?) would do the simplest repackaging > possible > >>> and > >>> > commit that then others could join in the quest to modularize > the > >>> hell > >>> > >>> out > >>> > of it. :) Presumably we'd do this on a branch until considered > >>> > "baked" > >>> > enough to merge to master. > >>> > > >>> > Let's go! > >>> > > >>> > Matt > >>> > > >>> > > >>> > On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg < > >>> > arne.limb...@openknowledge.de> wrote: > >>> > > >>> > > Hi, > >>> > > > >>> > > Some ideas from my side, too ([1] and [2]). Unfortunately it is > >>> in > >>> > >>> german. > >>> > > But everyone of you can read the code. We used an
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
hi jason, the bridge doesn't introduce an api and the spi just provides a simple contract for starting the container as well as a bean-filter. -> if needed, we could improve the implementation at any time. imo we should add it before the release of v0.6 (since a lot of users requested such a bridge). regards, gerhard 2014/1/22 Jason Porter > I'd like to engage the Pivotal Team (anyone have contacts?) to see if we > can get some of there help as well to create a really good integration. > > > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek < > gerhard.petra...@gmail.com> wrote: > >> hi @ all, >> >> i would like to continue with this discussion. >> >> [1] describes a two-way bridge which is already based on deltaspike. >> it offers a simple spi which allows more advanced add-ons like it is >> mentioned in [2]. >> >> regards, >> gerhard >> >> [1] >> http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html >> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html >> >> >> >> 2013/2/19 Matt Benson >> >>> Okay, I spent some time with Sam on IRC hashing this out. Assuming that >>> Seam-Spring is covered under the SG(s?) Red Hat has filed for deltaspike, >>> his view is that it's not terribly important who does the initial code >>> import, though it would be best for a so-authorized Red Hatter to be the >>> one to change the file headers. I will be out of pocket for the rest of >>> the week beyond today, so if you, Marius, are able to work on the import >>> end of this week/early next then that's in any event as soon as I would >>> have been able to get to it anyway. Otherwise, anyone can do that, with >>> someone still employed by RH finally applying the change that modifies >>> the >>> headers--which, I suppose, could be prepared by anyone else and simply >>> shared among our private git repos. >>> >>> Matt >>> >>> >>> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici < >>> marius.bogoev...@gmail.com> wrote: >>> >>> > I still am a participant on this thread, but doing more reading than >>> > writing as of late :) >>> > >>> > So, yes, I've been strapped for time with the job and the transition, >>> but >>> > I'd be happy to help out with this at the end of the week or early >>> next. >>> > >>> > With my CLA on file, and the code being granted already, I'm not sure >>> what >>> > else needs to be done. I'm happy for the code to live in DeltaSpike, >>> fwiw. >>> > >>> > On 2013-02-18, at 6:50 PM, Matt Benson wrote: >>> > >>> > > Seems Marius's prior participation on this thread was via a gmail >>> > address. >>> > > With him no longer at Red Hat we definitely want to make sure we >>> take the >>> > > necessary precautions wrt IP. >>> > > >>> > > Matt >>> > > >>> > > >>> > > On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter < >>> lightguard...@gmail.com >>> > >wrote: >>> > > >>> > >> I'm pretty sure we've granted Seam Spring to Apache. I'll need to >>> check >>> > to >>> > >> see if Marius has subscribed to this list on a personal email as he >>> has >>> > >> embarked on a new adventure outside of Red Hat. >>> > >> >>> > >> >>> > >> On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson >>> > wrote: >>> > >> >>> > >>> Let me refine my plan to say that it would be *best* if Marius >>> does the >>> > >>> commit since AIUI this is mostly code he personally authored, but >>> as >>> > long >>> > >>> as RH intends for Seam-Spring to be donated to Apache deltaspike, >>> > probably >>> > >>> no irreparable *harm* would be caused by another Red Hatter >>> pulling the >>> > >>> trigger. >>> > >>> >>> > >>> Matt >>> > >>> >>> > >>> >>> > >>> On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson >> > >>> > >>> wrote: >>> > >>> >>> > I think this received enough +1 votes (I'll add mine now) to >>> proceed. >>> > >>> If >>> > a Red Hatter (Marius?) would do the simplest repackaging possible >>> and >>> > commit that then others could join in the quest to modularize the >>> hell >>> > >>> out >>> > of it. :) Presumably we'd do this on a branch until considered >>> > "baked" >>> > enough to merge to master. >>> > >>> > Let's go! >>> > >>> > Matt >>> > >>> > >>> > On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg < >>> > arne.limb...@openknowledge.de> wrote: >>> > >>> > > Hi, >>> > > >>> > > Some ideas from my side, too ([1] and [2]). Unfortunately it is >>> in >>> > >>> german. >>> > > But everyone of you can read the code. We used an advanced >>> version of >>> > >>> that >>> > > code to build a Spring-CDI-Bridge in a large project. >>> Unfortunately >>> > > meanwhile the project is completely migrated to CDI and the code >>> is >>> > >>> lost >>> > > in subversion. Will see, if I find the final version and can >>> donate >>> > it. >>> > > >>> > > Cheers, >>> > > Arne >>> > > >>> > > [1] >>> > > >>> > > >>> > >>> >>> > >>> http://www.openknowledge.de/blog/article/integration-von-spring-in-
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
I'd like to engage the Pivotal Team (anyone have contacts?) to see if we can get some of there help as well to create a really good integration. On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek < gerhard.petra...@gmail.com> wrote: > hi @ all, > > i would like to continue with this discussion. > > [1] describes a two-way bridge which is already based on deltaspike. > it offers a simple spi which allows more advanced add-ons like it is > mentioned in [2]. > > regards, > gerhard > > [1] > http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html > [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html > > > > 2013/2/19 Matt Benson > >> Okay, I spent some time with Sam on IRC hashing this out. Assuming that >> Seam-Spring is covered under the SG(s?) Red Hat has filed for deltaspike, >> his view is that it's not terribly important who does the initial code >> import, though it would be best for a so-authorized Red Hatter to be the >> one to change the file headers. I will be out of pocket for the rest of >> the week beyond today, so if you, Marius, are able to work on the import >> end of this week/early next then that's in any event as soon as I would >> have been able to get to it anyway. Otherwise, anyone can do that, with >> someone still employed by RH finally applying the change that modifies the >> headers--which, I suppose, could be prepared by anyone else and simply >> shared among our private git repos. >> >> Matt >> >> >> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici < >> marius.bogoev...@gmail.com> wrote: >> >> > I still am a participant on this thread, but doing more reading than >> > writing as of late :) >> > >> > So, yes, I've been strapped for time with the job and the transition, >> but >> > I'd be happy to help out with this at the end of the week or early next. >> > >> > With my CLA on file, and the code being granted already, I'm not sure >> what >> > else needs to be done. I'm happy for the code to live in DeltaSpike, >> fwiw. >> > >> > On 2013-02-18, at 6:50 PM, Matt Benson wrote: >> > >> > > Seems Marius's prior participation on this thread was via a gmail >> > address. >> > > With him no longer at Red Hat we definitely want to make sure we take >> the >> > > necessary precautions wrt IP. >> > > >> > > Matt >> > > >> > > >> > > On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter < >> lightguard...@gmail.com >> > >wrote: >> > > >> > >> I'm pretty sure we've granted Seam Spring to Apache. I'll need to >> check >> > to >> > >> see if Marius has subscribed to this list on a personal email as he >> has >> > >> embarked on a new adventure outside of Red Hat. >> > >> >> > >> >> > >> On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson >> > wrote: >> > >> >> > >>> Let me refine my plan to say that it would be *best* if Marius does >> the >> > >>> commit since AIUI this is mostly code he personally authored, but as >> > long >> > >>> as RH intends for Seam-Spring to be donated to Apache deltaspike, >> > probably >> > >>> no irreparable *harm* would be caused by another Red Hatter pulling >> the >> > >>> trigger. >> > >>> >> > >>> Matt >> > >>> >> > >>> >> > >>> On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson >> > >>> wrote: >> > >>> >> > I think this received enough +1 votes (I'll add mine now) to >> proceed. >> > >>> If >> > a Red Hatter (Marius?) would do the simplest repackaging possible >> and >> > commit that then others could join in the quest to modularize the >> hell >> > >>> out >> > of it. :) Presumably we'd do this on a branch until considered >> > "baked" >> > enough to merge to master. >> > >> > Let's go! >> > >> > Matt >> > >> > >> > On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg < >> > arne.limb...@openknowledge.de> wrote: >> > >> > > Hi, >> > > >> > > Some ideas from my side, too ([1] and [2]). Unfortunately it is in >> > >>> german. >> > > But everyone of you can read the code. We used an advanced >> version of >> > >>> that >> > > code to build a Spring-CDI-Bridge in a large project. >> Unfortunately >> > > meanwhile the project is completely migrated to CDI and the code >> is >> > >>> lost >> > > in subversion. Will see, if I find the final version and can >> donate >> > it. >> > > >> > > Cheers, >> > > Arne >> > > >> > > [1] >> > > >> > > >> > >>> >> > >> http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe >> > > r-eine-cdi-extension-erster-teil.html< >> > >>> >> > >> http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-erster-teil.html >> > >> > > [2] >> > > >> > > >> > >>> >> > >> http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe >> > > r-eine-cdi-extension-zweiter-teil.html< >> > >>> >> > >> http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-zweiter-teil.html >> >
[jira] [Created] (DELTASPIKE-508) @Transaction return NPE on qualified Datasource injections
Cloves J. G. Almeida created DELTASPIKE-508: --- Summary: @Transaction return NPE on qualified Datasource injections Key: DELTASPIKE-508 URL: https://issues.apache.org/jira/browse/DELTASPIKE-508 Project: DeltaSpike Issue Type: Bug Components: JPA-Module Affects Versions: 0.5 Environment: Linux, JBoss-EAP-6.2, Java 7 Reporter: Cloves J. G. Almeida When using JTA transactions (and probably Resouce Local), a bean injecting a qualified DataSource _without an EntityManager also being injected_ will fail with an NPE if there's no default EntityManager or won't put the correct datasource into the transaction (and fail or act inconsistently). The reason is that in org.apache.deltaspike.jpa.impl.transaction.TransactionStrategyHelper.resolveEntityManagerQualifiers only injected EntityManagers are scanned for qualifiers used to resolve. A workaround is to place a qualified EntityManager pointing to the same datasource. This is limited, however. Some use cases, like batch processing does not require an EntityManager and one might not be available. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
hi @ all, i would like to continue with this discussion. [1] describes a two-way bridge which is already based on deltaspike. it offers a simple spi which allows more advanced add-ons like it is mentioned in [2]. regards, gerhard [1] http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html 2013/2/19 Matt Benson > Okay, I spent some time with Sam on IRC hashing this out. Assuming that > Seam-Spring is covered under the SG(s?) Red Hat has filed for deltaspike, > his view is that it's not terribly important who does the initial code > import, though it would be best for a so-authorized Red Hatter to be the > one to change the file headers. I will be out of pocket for the rest of > the week beyond today, so if you, Marius, are able to work on the import > end of this week/early next then that's in any event as soon as I would > have been able to get to it anyway. Otherwise, anyone can do that, with > someone still employed by RH finally applying the change that modifies the > headers--which, I suppose, could be prepared by anyone else and simply > shared among our private git repos. > > Matt > > > On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici < > marius.bogoev...@gmail.com> wrote: > > > I still am a participant on this thread, but doing more reading than > > writing as of late :) > > > > So, yes, I've been strapped for time with the job and the transition, but > > I'd be happy to help out with this at the end of the week or early next. > > > > With my CLA on file, and the code being granted already, I'm not sure > what > > else needs to be done. I'm happy for the code to live in DeltaSpike, > fwiw. > > > > On 2013-02-18, at 6:50 PM, Matt Benson wrote: > > > > > Seems Marius's prior participation on this thread was via a gmail > > address. > > > With him no longer at Red Hat we definitely want to make sure we take > the > > > necessary precautions wrt IP. > > > > > > Matt > > > > > > > > > On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter > >wrote: > > > > > >> I'm pretty sure we've granted Seam Spring to Apache. I'll need to > check > > to > > >> see if Marius has subscribed to this list on a personal email as he > has > > >> embarked on a new adventure outside of Red Hat. > > >> > > >> > > >> On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson > > wrote: > > >> > > >>> Let me refine my plan to say that it would be *best* if Marius does > the > > >>> commit since AIUI this is mostly code he personally authored, but as > > long > > >>> as RH intends for Seam-Spring to be donated to Apache deltaspike, > > probably > > >>> no irreparable *harm* would be caused by another Red Hatter pulling > the > > >>> trigger. > > >>> > > >>> Matt > > >>> > > >>> > > >>> On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson > > >>> wrote: > > >>> > > I think this received enough +1 votes (I'll add mine now) to > proceed. > > >>> If > > a Red Hatter (Marius?) would do the simplest repackaging possible > and > > commit that then others could join in the quest to modularize the > hell > > >>> out > > of it. :) Presumably we'd do this on a branch until considered > > "baked" > > enough to merge to master. > > > > Let's go! > > > > Matt > > > > > > On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg < > > arne.limb...@openknowledge.de> wrote: > > > > > Hi, > > > > > > Some ideas from my side, too ([1] and [2]). Unfortunately it is in > > >>> german. > > > But everyone of you can read the code. We used an advanced version > of > > >>> that > > > code to build a Spring-CDI-Bridge in a large project. Unfortunately > > > meanwhile the project is completely migrated to CDI and the code is > > >>> lost > > > in subversion. Will see, if I find the final version and can donate > > it. > > > > > > Cheers, > > > Arne > > > > > > [1] > > > > > > > > >>> > > > http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe > > > r-eine-cdi-extension-erster-teil.html< > > >>> > > > http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-erster-teil.html > > > > > [2] > > > > > > > > >>> > > > http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe > > > r-eine-cdi-extension-zweiter-teil.html< > > >>> > > > http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-zweiter-teil.html > > > > >>> > > > > > > > > > Am 15.10.12 17:16 schrieb "Jason Porter" unter < > > >>> lightguard...@gmail.com>: > > > > > >> You have my +1 Marius. If we can rouse the CDISource guys (mostly > > >>> Rick) > > >> they may have some ideas as well. > > >> > > >> On Mon, Oct 15, 2012 at 1:53 AM, Antoine Sabot-Durand < > > >> anto...@sabot-durand.net> wrote: > > >> > > >>> +1 it would defini
