[jira] [Created] (DELTASPIKE-494) Add support to templates in FacesMessages
Esteve created DELTASPIKE-494: - Summary: Add support to templates in FacesMessages Key: DELTASPIKE-494 URL: https://issues.apache.org/jira/browse/DELTASPIKE-494 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Esteve Add support to string templates in FacesMessages like Seam did in org.jboss.seam.faces.facesMessages. http://docs.jboss.org/seam/2.0.2.SP1/api/org/jboss/seam/faces/FacesMessages.html Thanks -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Servlet Module - Do we really need @Web?
Because our customers have different servers (tomcat7 and even 6, glassfish, jboss), so it would be a great enhancement for product development. 2014/1/3 John D. Ament > If you're in servlet 3.1/CDI 1.1 you don't even need the servlet > module (so why include it as a dependency?) > > On Fri, Jan 3, 2014 at 1:09 PM, Romain Manni-Bucau > wrote: > > -0 both injections can be different depending on containers using some > > advanced stuff out of ee but affecting ee lifecycle (at least in tomcat) > > but your proposal sounds acceptable. > > Le 3 janv. 2014 17:58, "Thomas Andraschko" > a > > écrit : > > > >> Hi, > >> > >> IMHO @Web is somehow annoying. > >> HttpServlet e.g. is always "web", so @Web is just a overhead and doesn't > >> look nice. > >> > >> Can't we just veto the producers if CDI1.1 is available? > >> The code would be the same with CDI 1.0 + DS, CDI 1.1 without or with > DS. > >> > >> Regards, > >> Thomas > >> >
Re: Servlet Module - Do we really need @Web?
If you're in servlet 3.1/CDI 1.1 you don't even need the servlet module (so why include it as a dependency?) On Fri, Jan 3, 2014 at 1:09 PM, Romain Manni-Bucau wrote: > -0 both injections can be different depending on containers using some > advanced stuff out of ee but affecting ee lifecycle (at least in tomcat) > but your proposal sounds acceptable. > Le 3 janv. 2014 17:58, "Thomas Andraschko" a > écrit : > >> Hi, >> >> IMHO @Web is somehow annoying. >> HttpServlet e.g. is always "web", so @Web is just a overhead and doesn't >> look nice. >> >> Can't we just veto the producers if CDI1.1 is available? >> The code would be the same with CDI 1.0 + DS, CDI 1.1 without or with DS. >> >> Regards, >> Thomas >>
Re: Servlet Module - Do we really need @Web?
-0 both injections can be different depending on containers using some advanced stuff out of ee but affecting ee lifecycle (at least in tomcat) but your proposal sounds acceptable. Le 3 janv. 2014 17:58, "Thomas Andraschko" a écrit : > Hi, > > IMHO @Web is somehow annoying. > HttpServlet e.g. is always "web", so @Web is just a overhead and doesn't > look nice. > > Can't we just veto the producers if CDI1.1 is available? > The code would be the same with CDI 1.0 + DS, CDI 1.1 without or with DS. > > Regards, > Thomas >
Servlet Module - Do we really need @Web?
Hi, IMHO @Web is somehow annoying. HttpServlet e.g. is always "web", so @Web is just a overhead and doesn't look nice. Can't we just veto the producers if CDI1.1 is available? The code would be the same with CDI 1.0 + DS, CDI 1.1 without or with DS. Regards, Thomas
Re: DS ExceptionHandling for JSF?
Ahh, you already attached an patch. Could you re-upload it? I will take care of it. 2014/1/3 Thomas Andraschko > Ahh cool! > Will you finish it for the next release? > > > 2014/1/3 Cody Lerum > >> See https://issues.apache.org/jira/browse/DELTASPIKE-341 >> >> On Fri, Jan 3, 2014 at 1:21 AM, Thomas Andraschko >> wrote: >> > Hi, >> > >> > what about providing DS' exception handling (@ExceptionHandler etc.) for >> > JSF? >> > AFAICS we would just need a small JSF ExceptionHandler. >> > >> > Regards, >> > Thomas >> > >
Re: DS ExceptionHandling for JSF?
Ahh cool! Will you finish it for the next release? 2014/1/3 Cody Lerum > See https://issues.apache.org/jira/browse/DELTASPIKE-341 > > On Fri, Jan 3, 2014 at 1:21 AM, Thomas Andraschko > wrote: > > Hi, > > > > what about providing DS' exception handling (@ExceptionHandler etc.) for > > JSF? > > AFAICS we would just need a small JSF ExceptionHandler. > > > > Regards, > > Thomas >
Re: DS ExceptionHandling for JSF?
See https://issues.apache.org/jira/browse/DELTASPIKE-341 On Fri, Jan 3, 2014 at 1:21 AM, Thomas Andraschko wrote: > Hi, > > what about providing DS' exception handling (@ExceptionHandler etc.) for > JSF? > AFAICS we would just need a small JSF ExceptionHandler. > > Regards, > Thomas
Re: Optimizing the integration tests
Hi Christian,
looking at the arquillian.xml files, they are 99% the same, the only one
that actually differs (other than whitespace, comments and missing
cdicontainer.version property) is the one in the data module, containing
a testDatabase configuration for tomee. So, we could have just one
arquillian.xml file somewhere in the testsuite root, copy it over using
resources-plugin, and override it only when necessary.
One minor problem is -- and this is for the container unpacking too --
that to point to the testsuite root, every pom would need to keep a
relative reference to it (e.g.
../../..), which is ugly, but doable.
On 3.1.2014 06:26, Christian Kaltepoth wrote:
Hey Ron,
yeah, there are differences between arquillian.xml files. But why? I don't
see any reason for having different arquillian.xml files between modules.
Actually the integration test Maven profiles are also located in a single
parent pom and not in each individual module pom. IMHO we should treat
arquillian.xml the same way. Unless there is a good reason for having
multiple ones.
I agree that we should unpack the container only once. I'm not sure I like
to use java.io.tmpdir though. It would be nice to have it in the top-level
"target" directory or something like that. That would ensure that running
"mvn clean" would also remove the unpacked container.
Christian
2014/1/2 Ron Smeral
On 2.1.2014 17:55, Christian Kaltepoth wrote:
Hey all,
there are two things I would like to address regarding our integration
test
suite.
1. Currently each module has its own arquillian.xml file. IMHO this
doesn't
make sense. What about using a single arquillian.xml and placing it in the
test-utils module?
+0, there are minor differences among them currently (though not sure if
necessary), and it would make it more difficult to make an individual
modification if there was single arquillian.xml.
2. We have both "managed" and "remote" profiles for some containers. But
the "managed" profiles (especially Wildfly + Glassfish) require you to
manually download and setup the corresponding container which I would like
to avoid. I think it would be nicer if the "managed" profiles could do
this
automatically. This would simplify the process of running the tests
locally
before committing and it would also be easier to create CI jobs for them.
See [1] for an example of a profile which sets up the container
automatically and therefore runs out of the box even in transient CI
environments like Travis [2].
There already is such profile at least for JBoss AS7
(jbossas-build-managed-7) and at this very moment I'm adding such profile
for WildFly. However, currently there is a minor drawback to the current
approach -- the container is unpacked for every module and so almost 5 GB
of diskspace is required to run the whole testsuite, which is quite
impractical. It would be nice to have the container unpacked to a shared
location, e.g. ${java.io.tmpdir}, just as in the ocpsoft rewrite pom you
linked. I'll try that in the AS7 and WF8 profiles.
Thoughts?
[1] https://github.com/ocpsoft/rewrite/blob/master/pom.xml#L706
[2] https://travis-ci.org/ocpsoft/rewrite/builds/16192940
Christian
--
Ron Smeral
JBoss Quality Engineer
Brno
--
Ron Smeral
JBoss Quality Engineer
Brno
[jira] [Updated] (DELTASPIKE-493) inconsistent handling in WindowContextImpl#closeWindow
[ https://issues.apache.org/jira/browse/DELTASPIKE-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-493: Summary: inconsistent handling in WindowContextImpl#closeWindow (was: inconsistent handling in WindowContext#closeWindow) > inconsistent handling in WindowContextImpl#closeWindow > -- > > Key: DELTASPIKE-493 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-493 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 0.5 >Reporter: Gerhard Petracek >Assignee: Mark Struberg > Fix For: 0.6 > > > if WindowContext#closeWindow gets called for the current window-id, the > window is still active afterwards -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (DELTASPIKE-493) inconsistent handling in WindowContextImpl#closeWindow
[ https://issues.apache.org/jira/browse/DELTASPIKE-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-493. - Resolution: Fixed > inconsistent handling in WindowContextImpl#closeWindow > -- > > Key: DELTASPIKE-493 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-493 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 0.5 >Reporter: Gerhard Petracek >Assignee: Mark Struberg > Fix For: 0.6 > > > if WindowContext#closeWindow gets called for the current window-id, the > window is still active afterwards -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (DELTASPIKE-493) inconsistent handling in WindowContext#closeWindow
Gerhard Petracek created DELTASPIKE-493: --- Summary: inconsistent handling in WindowContext#closeWindow Key: DELTASPIKE-493 URL: https://issues.apache.org/jira/browse/DELTASPIKE-493 Project: DeltaSpike Issue Type: Bug Components: Core Affects Versions: 0.5 Reporter: Gerhard Petracek Assignee: Mark Struberg Fix For: 0.6 if WindowContext#closeWindow gets called for the current window-id, the window is still active afterwards -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Test-Control injects in test class object only
short addition: i've added a test for it and it looks fine here (see [1]). fyi - basically there are two "modes": #1 the test-class is a cdi-bean as well (src/test/resources/META-INF/beans.xml is needed) #2 the test-class isn't a cdi-bean (due to a missing beans.xml or @Typed() or @Exclude,...) -> BeanProvider#injectFields is used as fallback regards, gerhard [1] https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commit;h=4939550ed208c4e6be98ee12e6019ebe7d271afd 2014/1/3 Gerhard Petracek > hi dirk, > > deltaspike just delegates the injection to the cdi-container. > > regards, > gerhard > > > > 2014/1/3 Dirk Weil > >> Hi! >> >> >> >> I've just come around Test-Control - great module, simplifies in-container >> testing a lot. But I discovered one thing and I'm not sure if it's >> intended >> or a bug: >> >> >> >> @Inject is resolved for fields of the test class object itself only, not >> for >> fields of base classes. As a workaround I use >> BeanProvider.injectFields(this), but I would expect injections to be >> resolved automatically for the test class object as a whole, not just for >> the derived class part. >> >> >> >> Regards, Dirk >> >> >
Re: Test-Control injects in test class object only
hi dirk, deltaspike just delegates the injection to the cdi-container. regards, gerhard 2014/1/3 Dirk Weil > Hi! > > > > I've just come around Test-Control - great module, simplifies in-container > testing a lot. But I discovered one thing and I'm not sure if it's intended > or a bug: > > > > @Inject is resolved for fields of the test class object itself only, not > for > fields of base classes. As a workaround I use > BeanProvider.injectFields(this), but I would expect injections to be > resolved automatically for the test class object as a whole, not just for > the derived class part. > > > > Regards, Dirk > >
Test-Control injects in test class object only
Hi! I've just come around Test-Control - great module, simplifies in-container testing a lot. But I discovered one thing and I'm not sure if it's intended or a bug: @Inject is resolved for fields of the test class object itself only, not for fields of base classes. As a workaround I use BeanProvider.injectFields(this), but I would expect injections to be resolved automatically for the test class object as a whole, not just for the derived class part. Regards, Dirk
Re: Optimizing the integration tests
@christian: +1
(@as7: sounds like a missing cleanup, like it's done for tomee)
regards,
gerhard
2014/1/3 Christian Kaltepoth
> Hey Ron,
>
> yeah, there are differences between arquillian.xml files. But why? I don't
> see any reason for having different arquillian.xml files between modules.
> Actually the integration test Maven profiles are also located in a single
> parent pom and not in each individual module pom. IMHO we should treat
> arquillian.xml the same way. Unless there is a good reason for having
> multiple ones.
>
> I agree that we should unpack the container only once. I'm not sure I like
> to use java.io.tmpdir though. It would be nice to have it in the top-level
> "target" directory or something like that. That would ensure that running
> "mvn clean" would also remove the unpacked container.
>
> Christian
>
>
> 2014/1/2 Ron Smeral
>
> >
> > On 2.1.2014 17:55, Christian Kaltepoth wrote:
> >
> >> Hey all,
> >>
> >> there are two things I would like to address regarding our integration
> >> test
> >> suite.
> >>
> >> 1. Currently each module has its own arquillian.xml file. IMHO this
> >> doesn't
> >> make sense. What about using a single arquillian.xml and placing it in
> the
> >> test-utils module?
> >>
> > +0, there are minor differences among them currently (though not sure if
> > necessary), and it would make it more difficult to make an individual
> > modification if there was single arquillian.xml.
> >
> >
> >> 2. We have both "managed" and "remote" profiles for some containers. But
> >> the "managed" profiles (especially Wildfly + Glassfish) require you to
> >> manually download and setup the corresponding container which I would
> like
> >> to avoid. I think it would be nicer if the "managed" profiles could do
> >> this
> >> automatically. This would simplify the process of running the tests
> >> locally
> >> before committing and it would also be easier to create CI jobs for
> them.
> >> See [1] for an example of a profile which sets up the container
> >> automatically and therefore runs out of the box even in transient CI
> >> environments like Travis [2].
> >>
> > There already is such profile at least for JBoss AS7
> > (jbossas-build-managed-7) and at this very moment I'm adding such profile
> > for WildFly. However, currently there is a minor drawback to the current
> > approach -- the container is unpacked for every module and so almost 5 GB
> > of diskspace is required to run the whole testsuite, which is quite
> > impractical. It would be nice to have the container unpacked to a shared
> > location, e.g. ${java.io.tmpdir}, just as in the ocpsoft rewrite pom you
> > linked. I'll try that in the AS7 and WF8 profiles.
> >
> >
> >
> >> Thoughts?
> >>
> >> [1] https://github.com/ocpsoft/rewrite/blob/master/pom.xml#L706
> >> [2] https://travis-ci.org/ocpsoft/rewrite/builds/16192940
> >>
> >> Christian
> >>
> >>
> >> --
> > Ron Smeral
> > JBoss Quality Engineer
> > Brno
> >
> >
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>
DS ExceptionHandling for JSF?
Hi, what about providing DS' exception handling (@ExceptionHandler etc.) for JSF? AFAICS we would just need a small JSF ExceptionHandler. Regards, Thomas
