Re: DeltaSpike release tomorrow?
I just tested the current snapshots with one of our apps. Looks good. So +1 if all the jenkins builds are fine. 2013/5/27 Jason Porter lightguard...@gmail.com Let's get this thing going out. +1 — Sent from Mailbox for iPhone On Sun, May 26, 2013 at 2:59 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: +1 *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/5/26 Mark Struberg strub...@yahoo.de Hi folks! We waited way too long to get it out of the door. Thus if there is no real show-stopper, then I gonna start the release train tomorrow. We will ship 0.5 pretty fast afterwards anyway. LieGrue, strub -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
Re: Servlet module
Sure, as I already wrote I would start in a separate branch on github and merge later after 0.4 is out. 2013/5/14 Mark Struberg strub...@yahoo.de +1. Could you please start working on it in a branch? I really like to release 0.4 sonish (maybe end of this week?) After that we could go for it in master. LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org deltaspike-dev@incubator.apache.org Cc: Sent: Monday, 13 May 2013, 18:35 Subject: Re: Servlet module I see no reason not to. Just keep rebasing (if you're working in a separate module there shouldn't be any conflicts) until we're able to start work on 0.5. On Mon, May 13, 2013 at 10:16 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Since the module is light +1 Le 13 mai 2013 18:11, John D. Ament john.d.am...@gmail.com a écrit : +1. This is actually one thing I need to finish porting an app from seam3 to DS. If you want help doing it let me know. On Mon, May 13, 2013 at 12:03 PM, Christian Kaltepoth christ...@kaltepoth.de wrote: Hey all, as I already discussed with Mark and Arne two weeks ago, I'm really interested in working on the servlet module for DeltaSpike. This topic was discussed several times on the list (see [1], [2]) and I think there was an agreement to target this for 0.5. Although 0.4 hasn't been released yet, I would love to spend some time hacking on this. :) In my opinion the most important features for the module would be: - Producers for servlet objects like the HttpServletRequest, ServletContext, etc. As this will be part of CDI 1.1, the producer should use a custom qualifier. - Bridging of the servlet lifecycle events to the CDI event bus. I think these are the most important features which are required for many real world applications. I'll start working on this on a separate branch on my GitHub repo. This way I can prototype the module and then ask for your feedback before merging it at a later point in time. WDYT? Any comments or ideas? :) Christian [1] http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/seam-servlet-stuff-to-deltaspike-td4653869.html [2] http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Servlet-module-td4654725.html -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal -- Jason Porter http://en.gravatar.com/lightguardjp -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
Servlet module
Hey all, as I already discussed with Mark and Arne two weeks ago, I'm really interested in working on the servlet module for DeltaSpike. This topic was discussed several times on the list (see [1], [2]) and I think there was an agreement to target this for 0.5. Although 0.4 hasn't been released yet, I would love to spend some time hacking on this. :) In my opinion the most important features for the module would be: - Producers for servlet objects like the HttpServletRequest, ServletContext, etc. As this will be part of CDI 1.1, the producer should use a custom qualifier. - Bridging of the servlet lifecycle events to the CDI event bus. I think these are the most important features which are required for many real world applications. I'll start working on this on a separate branch on my GitHub repo. This way I can prototype the module and then ask for your feedback before merging it at a later point in time. WDYT? Any comments or ideas? :) Christian [1] http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/seam-servlet-stuff-to-deltaspike-td4653869.html [2] http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Servlet-module-td4654725.html -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
[jira] [Closed] (DELTASPIKE-361) ?dsRid=191windowId=-8996 parameters in links
[
https://issues.apache.org/jira/browse/DELTASPIKE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Kaltepoth closed DELTASPIKE-361.
--
Resolution: Won't Fix
That's not a bug, that's a feature. :)
Actually this is an important part of the new window scope in 0.4-incubating.
If you want to get rid of the query parameters, you have to add a class like
this to your project:
@Specializes
public class CustomWindowConfig extends DefaultClientWindowConfig {
@Override
public ClientWindowRenderMode getClientWindowRenderMode( FacesContext
facesContext ) {
return ClientWindowRenderMode.NONE;
}
}
After adding this, you shouldn't see the query parameters any more. But you
also won't be able to use the window scope.
?dsRid=191windowId=-8996 parameters in links
-
Key: DELTASPIKE-361
URL: https://issues.apache.org/jira/browse/DELTASPIKE-361
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 0.4-incubating
Environment: Deltaspike + Weld + JSF2 + Richfaces 4 + WildFly 7.2.0
Reporter: Dmitry Shultz
Labels: dsRid, jsf
Hi there,
After building from the recent 0.4-incubating snapshot all the links
generated by JSF have extra parameters appended (for example
?dsRid=191windowId=-8996).
Can be experienced here: http://diligesoft.com (because I ended up having
recent deltaspike snapshot artifacts in my repository and it was used for the
recent build/deployment)
Definetely not a showstopper, just wanted to let you guys know :)
Thanks,
Dmitry
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DELTASPIKE-362) BeanManagerProvider floods log file with warnings on AS7
Christian Kaltepoth created DELTASPIKE-362: -- Summary: BeanManagerProvider floods log file with warnings on AS7 Key: DELTASPIKE-362 URL: https://issues.apache.org/jira/browse/DELTASPIKE-362 Project: DeltaSpike Issue Type: Bug Components: Core Affects Versions: 0.4-incubating Reporter: Christian Kaltepoth Priority: Minor Fix For: 0.4-incubating Users reported that when deploying DeltaSpike in an EAR archive to AS7, they get flooded by messages like this: When using the BeanManager to retrieve Beans before the Container is started, non-portable behaviour results! This warning is created by BeanManagerProvider here: https://github.com/apache/incubator-deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/provider/BeanManagerProvider.java#L170 The the following mails on the users list: http://mail-archives.apache.org/mod_mbox/incubator-deltaspike-users/201305.mbox/%3C518D5774.60909%40gmail.com%3E http://mail-archives.apache.org/mod_mbox/incubator-deltaspike-users/201304.mbox/%3C3125CD8F11FD1440B3E8452DC32521A2ADDBCEE6%40sExchange-01.PSC.local%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: windowId postback detection
@Mark With your 'exclude-area' idea you are referring to something like Orchestra's o:separateConversationContext, right? I think this could be a really interesting feature for some usecases and we should definitively support it. Regarding the auto detection for links that have to be decorated: I'm not really sure if there is a need to explicitly configure a set of domains for this. I guess the decorating is somehow similar to what HttpServletResponse.encodeURL() does and would even be implemented by wrapping it (or the corresponding stuff in ExternalContext), correct? So why don't we simply decorate all links that go though encodeURL unless we are in an exclude area case? Christian 2013/4/23 Jason Porter lightguard...@gmail.com Interesting idea. What does the rest of the community think? On Tue, Apr 23, 2013 at 11:01 AM, Mark Struberg strub...@yahoo.de wrote: yes, we will certainly need to do lots of testing with this new approach. But it seems much more in sync with the JSF-2.2 idea which requires to detect the proper windowId even before the restore-view phase. In the old CODI implementation we parsed it from a custom Component which we added to the view tree ourselfs. maybe we can do both. There was also an idea about having an 'exclude-area'. Means a tag which will exclude the containing GET links from using the browser tab detection. We might also think about a mechanism to detect the links which need to get decorated. Something like ds:windowId domain=this, someurl.com, otherurl.org/ For other links we will not add the windowId nor store away the dom tree for our 'snapshot view' on the intermediate page. LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org deltaspike-dev@incubator.apache.org Cc: Sent: Tuesday, 23 April 2013, 18:22 Subject: Re: windowId postback detection I'm good either way, but the custom component idea seems to be consensus, also if the user doesn't want it they can always leave out the new component. On Mon, Apr 22, 2013 at 12:38 AM, Thomas Andraschko andraschko.tho...@gmail.com wrote: +1 for the custom component 2013/4/22 Christian Kaltepoth christ...@kaltepoth.de I like the idea of a custom component because it makes it more explicit what the component is used for and perhaps would even provide more control over what is happening. So +1 for a custom component 2013/4/21 Mark Struberg strub...@yahoo.de Gerhard brought up another alternative: simply provide a component which doesn't render any html but adds the windowhandler.js and stores the component in the ViewRoot. LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, 21 April 2013, 20:56 Subject: Re: windowId postback detection 1 sounds easier to track too Le 21 avr. 2013 18:09, Mark Struberg strub...@yahoo.de a écrit : Hi! There are technically 2 options for extracting the windowId on POSTs: 1.) setting a hidden UIOutput component in the ViewRoot 2.) provide a custom renderkit/ResponseStateManager I think 1.) is much easier. Any input? LIeGrue, strub -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal -- Jason Porter http://en.gravatar.com/lightguardjp -- Jason Porter http://en.gravatar.com/lightguardjp -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
Re: windowId postback detection
I like the idea of a custom component because it makes it more explicit what the component is used for and perhaps would even provide more control over what is happening. So +1 for a custom component 2013/4/21 Mark Struberg strub...@yahoo.de Gerhard brought up another alternative: simply provide a component which doesn't render any html but adds the windowhandler.js and stores the component in the ViewRoot. LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, 21 April 2013, 20:56 Subject: Re: windowId postback detection 1 sounds easier to track too Le 21 avr. 2013 18:09, Mark Struberg strub...@yahoo.de a écrit : Hi! There are technically 2 options for extracting the windowId on POSTs: 1.) setting a hidden UIOutput component in the ViewRoot 2.) provide a custom renderkit/ResponseStateManager I think 1.) is much easier. Any input? LIeGrue, strub -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
Re: Weekly or biweekly IRC meeting
+1 I like that idea. IRC or Hangout would be fine. 2013/4/11 Romain Manni-Bucau rmannibu...@gmail.com will depend how many people will attend i guess, but hangout to start sounds good *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/4/11 Jean-Louis MONTEIRO jeano...@gmail.com Yep, like this way to go. Much more efficient. JLouis 2013/4/11 Mark Struberg strub...@yahoo.de +1 for hangouts. Much easier and quicker. Of course only to identify options and discuss opportunities. All info must get summed up to the mailing list afterwards. LieGrue, strub - Original Message - From: Jean-Louis MONTEIRO jeano...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Thursday, April 11, 2013 8:18 AM Subject: Re: Weekly or biweekly IRC meeting Using Google Hangouts is also another way to go. Jean-Louis 2013/4/11 Romain Manni-Bucau rmannibu...@gmail.com If thats 1h +1 Le 11 avr. 2013 01:04, Jason Porter lightguard...@gmail.com a écrit : It'll still be an issue, someone is going to be waking up really early or staying up late for it. Though perhaps something like a 12:00 or 13:00 UTC may work if I recall most people's time zones. On Wed, Apr 10, 2013 at 4:55 PM, John D. Ament john.d.am...@gmail.com wrote: It would be good for identifying who's got what on their plates and how to get moving forward. I recall for Seam 3 the biggest issue was time of day for the meeting. On Wed, Apr 10, 2013 at 6:25 PM, Cody Lerum cody.le...@gmail.com wrote: Would anyone else be in favor of having a weekly or biweekly IRC meeting where the we can discuss status of the project as well as interact with the users? We could keep a transcript which would would be posted to the list, and require all decisions happen on the list. Thoughts? -C -- Jason Porter http://en.gravatar.com/lightguardjp -- Jean-Louis -- Jean-Louis -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
Re: Road to 1.0.0
+1 for such a roadmap Especially because this will help users to get an idea of where the project is going and when we expect certain features to be available. Christian 2013/4/7 Cody Lerum cody.le...@gmail.com I'm in favor of this at least until we have a 1.0 release. The dates should be thought of as goals rather than deadlines since this is all volunteer. This would also give the project a more defined roadmap for users to follow. On Sun, Apr 7, 2013 at 11:59 AM, Jason Porter lightguard...@gmail.com wrote: Perhaps we should look at a time boxed idea (I think it's been brought up before, worth discussing again I think). I understand we may not have anything to release during a time slot, so we could not do one in those slots, but maybe a month or three week time boxed set of releases would be good. Thoughts? -- Jason Porter http://en.gravatar.com/lightguardjp -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
Re: [DISCUSS] re-visit annotation package/s
+1 for dropping 2013/3/31 Cody Lerum cody.le...@gmail.com drop em. On Sun, Mar 31, 2013 at 10:35 AM, Mark Struberg strub...@yahoo.de wrote: yes, let's drop them. annotations are like interfaces nowadays. So this is just superfluous. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 31, 2013 5:30 PM Subject: [DISCUSS] re-visit annotation package/s hi @ all, we had an agreement to use a (sub-)package named annotation for all our annotations within a package. however, it feels a bit clumsy if a package (currently) just contains annotations. e.g. org.apache.deltaspike.core.api.exclude only contains the package annotation. currently we have a mixture (some parts are using the annotation package and some don't) - we have to align it the one way or the other. i'm currently in favour of dropping the annotation-package/s. regards, gerhard -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
Re: [DISCUSS] features related to the jsf lifecycle
+1 2012/10/19 Jason Porter lightguard...@gmail.com +1 On Thu, Oct 18, 2012 at 3:42 PM, Mark Struberg strub...@yahoo.de wrote: +1 LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Thursday, October 18, 2012 11:39 PM Subject: Re: [DISCUSS] features related to the jsf lifecycle if there are no objections, i'll import the annotations tomorrow. - we can change the names later on (as soon as we have an agreement). regards, gerhard 2012/10/17 Jason Porter lightguard...@gmail.com I honestly don't have a preference for the names. +1 for @BeforePhase / @AfterPhase On Wed, Oct 17, 2012 at 12:38 PM, Brian Leathem bleat...@gmail.com wrote: On Wed 17 Oct 2012 11:17:46 AM PDT, Brian Leathem wrote: can we not build on the @ListenerFor annotation in JSF [1]? @ListenerFor(phaseEventClass=.**..) or, if we need a unique name, perhaps: @ListenerForPhase(**phaseEventClass=...) As Gerhard pointed out in IRC, this would just be a marker annotation, and hence empty: @ListenerForPhase() Brian -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: [DISCUSS] features related to the jsf lifecycle
+1 for @BeforePhase and @AfterPhase.
I like that this forces the user to specify both the concrete phase and the
time (before vs after).
+0.8 for @BeforeFacesRequest, @AfterFacesRequest and @JsfPhaseListener
I like the concept, but I suggest that we use Jsf or Faces consistently
in the annotation names. So if we use @BeforeFacesRequest, we should also
use @FacesPhaseListener. This would also apply to the enum JsfPhaseId.
Perhaps we could just use Phase here?
Christian
2012/10/17 Pete Muir pm...@redhat.com
+0 from me, I would be happy with either + don't really use JSF anymore ;-)
On 17 Oct 2012, at 10:27, Mark Struberg wrote:
+1
looks really good!
LieGrue,
strub
- Original Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
To: deltaspike deltaspike-dev@incubator.apache.org
Cc:
Sent: Wednesday, October 17, 2012 11:14 AM
Subject: Re: [DISCUSS] features related to the jsf lifecycle
+1 for:
@BeforePhase / @AfterPhase
@BeforeFacesRequest / @AfterFacesRequest
@JsfPhaseListener
regards,
gerhard
2012/10/17 Gerhard Petracek gerhard.petra...@gmail.com
hi @ all,
the support of cdi-observers for jsf phase-events in codi and
seam-faces
is very similar.
a central difference is that codi uses only one additional annotation
per
observer.
initially it was a workaround for a portability issue. however, you
only
have to remember one annotation (per observer) and you get the rest via
std. auto-complete.
example:
protected void observePreRenderView(@Observes
@BeforePhase(RENDER_RESPONSE) PhaseEvent phaseEvent) {
//...
}
codi even supports to filter it for views - e.g.:
@View(DemoPage.class)
public void observePostInvokeApplication(@Observes
@AfterPhase(JsfPhaseId.INVOKE_APPLICATION) PhaseEvent event) {
//...
}
but we have to postpone that part for now until we have an agreement
concerning type-safe view-config and navigation.
(@View is also used for other features in codi.)
furthermore, we could add @BeforeFacesRequest and @AfterFacesRequest.
technically we could merge them with the annotations for phase-events,
but
i wouldn't do it (because it's a slightly different topic and might
confuse
users).
moreover, we could add @JsfPhaseListener which allows to add std. jsf
phase-listeners without xml config and enables injection support for
them.
in codi we really register those listeners - per default you don't
have
an overhead. however, we needed some workarounds for mojarra.
- as an alternative we could register one ds-phase-listener per
default
which delegates to beans with @JsfPhaseListener.
since we don't support jsf 1.2, we can skip
JsfLifecyclePhaseInformation
(jsf 2.0+ provides FacesContext#getCurrentPhaseId).
regards,
gerhard
--
Christian Kaltepoth
Blog: http://chkal.blogspot.com/
Twitter: http://twitter.com/chkal
Re: seam-servlet stuff to deltaspike
+1 for adding it to 0.4 as a separate servlet module. I think these are very important features. Especially the event propagation and the injection of servlet-related objects. Christian 2012/10/12 Jason Porter lightguard...@gmail.com Sounds like we're good to add it. Shall we add it for v0.4? On Fri, Oct 12, 2012 at 11:04 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 for an own module. regards, gerhard 2012/10/12 Mark Struberg strub...@yahoo.de +1 for modules/servlet :) LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Friday, October 12, 2012 5:12 PM Subject: Re: seam-servlet stuff to deltaspike I have no problem adding it. It certainly should be its own module though. We may also need to rethink some of how the code was working. I remember there being problems, but maybe it's simply because we put it into solder. On Fri, Oct 12, 2012 at 9:08 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: +1 *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/10/12 Adrian Mitev adrian.mi...@gmail.com Hi all! The stuff in the old seam-servlet module [1], [2] and [3] (now merged in seam-solder) are quite useful and are great candidate for adding in Deltaspike. 1 - http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/servlet-events.html 2 - http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/injectablerefs.html 3 - http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/exception-handling.html -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: [VOTE] Apache DeltaSpike 0.3-incubating
+1
2012/8/17 Ken Finnigan k...@kenfinnigan.me:
+1
Ken
On Wed, Aug 15, 2012 at 5:56 AM, Mark Struberg strub...@yahoo.de wrote:
Hi!
I like to call a VOTE on the Apache DeltaSpike 0.3-incubating release.
The Maven staging repository:
https://repository.apache.org/content/repositories/orgapachedeltaspike-010/
The source release package:
https://repository.apache.org/content/repositories/orgapachedeltaspike-010/org/apache/deltaspike/deltaspike-project/0.3-incubating/
I've pushed the GIT release branch to my github account:
https://github.com/struberg/incubator-deltaspike/tree/deltaspike-0.3-incubating
(The branch will be pushed and merged to master after the VOTE passed.)
The TAG can be found here:
https://github.com/struberg/incubator-deltaspike/tree/deltaspike-project-0.3-incubating
Please note:
This VOTE is majority approval with a minimum of three +1votes of PPMC
members.
The VOTE is open for 72 hours.
[+1] all fine, ship it
[+0] I don't care but smells fine
[-1] stop it, this stuff contains a blocker ${insertreason}
LieGrue,
strub
--
Christian Kaltepoth
Blog: http://chkal.blogspot.com/
Twitter: http://twitter.com/chkal
Re: Welcome Romain Manni-Bucau as Apache DeltaSpike committer!
Welcome on board! 2012/7/10 Jason Porter lightguard...@gmail.com Welcome! On Tue, Jul 10, 2012 at 2:48 PM, Mark Struberg strub...@yahoo.de wrote: As result of his continued contributions, the Apache DeltaSpike PPMC has extended an invitation to become a DeltaSpike committer to Romain Manni-Bucau! Welcome on board! LieGrue, strub -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: Welcome Charles Moulliard as Apache DeltaSpike committer!
Congratulations and welcome! 2012/7/10 Jason Porter lightguard...@gmail.com Glad to have you! On Tue, Jul 10, 2012 at 3:05 PM, Mark Struberg strub...@yahoo.de wrote: As result of his continued contributions, the Apache DeltaSpike PPMC has extended an invitation to become a DeltaSpike committer to Charles Moulliard! Welcome on board! LieGrue, strub -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: [DISCUSS] drop the integration-test module?
+1 for dropping it. As I already mentioned some time ago, having two places for the tests (tests in the integration-test module and test in the module itself) is IMHO a bad idea. And I think it is easier to have the tests directly in the modules. Regarding the failsafe plugin: Would this bring us any advantage apart from the fact that the integration tests would run in a different Maven phase? Christian 2012/7/6 Romain Manni-Bucau rmannibu...@gmail.com: if surefire is still used for weld or owb by default +1 - Romain 2012/7/6 Mark Struberg strub...@yahoo.de and merge those profiles to the main impl modules? Our integration tests are currently pretty hard to debug as we unpack the test sources to the integration test module and then run the tests. It was originally planed that the core tests do always run with Weld or OWB and only the container specific tests will run again if an EE container got specified. But it turned out that this is a bit complicated to debug. Thus I'm thinking about dropping the integration-test modules and move all the profiles to parent/code/pom.xml I also like to move the integration tests from moving the surefire plugin to failsafe. LieGrue, strub -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: A little pain can be a gain
I think Charles is right. I got similar exceptions when I used different versions of JBoss AS7 and the Arquillian container adapter. Christian 2012/7/6 Charles Moulliard cmoulli...@gmail.com Mark, Could it be possible as explained here that you sue different jars file between arquillian and JBoss AS7 ? https://community.jboss.org/message/720744 Regards, Charles Moulliard Apache Committer Blog : http://cmoulliard.blogspot.com Twitter : http://twitter.com/cmoulliard Linkedin : http://www.linkedin.com/in/charlesmoulliard Skype: cmoulliard On Fri, Jul 6, 2012 at 3:08 PM, Mark Struberg strub...@yahoo.de wrote: I've now pushed the changes in our integration-test handling to master. What works already: * OWB * Weld * TomEE JBossAS7 both build and managed can compile but fail with a weird Exception. I definitely need help on this! http://pastie.org/4209858 $ mvn clean install -Pjbossas-build-managed-7 txs and LieGrue, strub -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: Missing features for Seam 3 users adoption
+1 for starting with JSF in 0.4 IMHO it is very important to have JSF support in place soon because CDI + JSF is a very common application stack. And as soon as there is some basic integration, people will hopefully start using DS in real life projects and we will get more feedback. Christian 2012/7/2 Mark Struberg strub...@yahoo.de: really good points. What about starting with JSF in 0.4? Which of course also means that we need to get 0.3 out of the door soon. Which in turn means that we still need to do a bit of review ;) I'll start a discussion about 0.3 final cleanup. LieGrue, strub - Original Message - From: Cody Lerum cody.le...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, July 2, 2012 2:48 AM Subject: Missing features for Seam 3 users adoption I'm going to try and outline the three features that I think DeltaSpike is currently missing before we can steer existing Seam 3 users to the project. Once we have these features covered I think we can start picking up some legacy Seam users thus growing the DeltaSpike community. I think these may be the tipping point for some larger adoption. 1. Security + JSF integration: Path level security ie /private/home.xhtml and /public/home.xhtml. Includes mechanism to redirect to a view denied page or a login page if not logged in. 2. JSF + Transaction integration: Provide a means to handle transactions for the restore, invoke and render phases. 3. JSF Messages support: Support creating JSF messages and having them displayed after page redirects / conversational boundaries. These might not missing, but are lacking clear steps for a new user to piece the various modules together to provide the required functionality. Might just be a doc issue. Do we still have a published roadmap as I'm having a hard time finding it? If we do have a roadmap, where do these features fit on it and do you think it makes sense to target these specific features. Thanks! -C -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: Add pages from old web site
To be honest, I don't think splitting the documentation into two different parts (developer and user) is a good idea. I think people may be confused which of the two documents they have to read if they are looking for a specific information. Especially for advanced use cases (like using extension points of the API) the difference between the two could be not clear for everyone. Christian 2012/7/2 Charles Moulliard cmoulli...@gmail.com: I agree on the idea to separate the user guide from developer guide as we have done that for Apache Karaf project (http://karaf.apache.org/manual/latest-2.2.x/users-guide/index.html, http://karaf.apache.org/manual/latest-2.2.x/developers-guide/index.html). And as you can see, there are no overlap between content of the 2 guides. Users and Developers guide will have 2 different goals. The developer guide will be focused on How to build the code, debug, maintain it and also How to develop CDI extensions, new modules while User guide will be more focused on providing examples of using @ConfigProperty, Running DeltaSpike with JavaSE + weld / own, OSGI. So I don't see any overlapping from this perspective as they drive 2 difference scopes. - Apache Committer / Sr. Pr. Consultant at FuseSource.com Email: [hidden email] Twitter : @cmoulliard, @fusenews Blog : http://cmoulliard.blogspot.com -- View this message in context: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Add-pages-from-old-web-site-tp4652925p4652933.html Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at Nabble.com. -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: [DISCUSS] Adding Solder Exception Handling aka Seam Catch to DeltaSpike v0.2-incubating
+1 for adding it to a separate module 2012/2/28 Jason Porter lightguard...@gmail.com: Yeah, that's fine. On Tue, Feb 28, 2012 at 00:01, Mark Struberg strub...@yahoo.de wrote: +1, but it should be an own module and not part or core, right? LieGrue, strub - Original Message - From: Christian Kaltepoth christ...@kaltepoth.de To: deltaspike-dev@incubator.apache.org Cc: Sent: Tuesday, February 28, 2012 7:11 AM Subject: Re: [DISCUSS] Adding Solder Exception Handling aka Seam Catch to DeltaSpike v0.2-incubating +1 2012/2/27 Pete Muir pm...@redhat.com: +1 to basic idea and concept. On 24 Feb 2012, at 17:55, Jason Porter wrote: fyi: please check [1] before you answer. [2] and [2a] contain the current Solder implementatation the basic concept: Slight modifications and a bug fix or two from what is there currently, otherwise a straight code drop (with changes obviously for packages). please send +1, +0 or -1 because... for the basic idea as well as the basic concept. if there are basic objections, please also add them to [3] regards, gerhard [1] http://markmail.org/message/7yefspfuvtz4jvmp [2] https://github.com/seam/solder/tree/develop/api/src/main/java/org/jboss/solder/exception [2a] https://github.com/seam/solder/tree/develop/impl/src/main/java/org/jboss/solder/exception [3] https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: release branches
+1 for Mark's suggestion. 2012/2/13 Gerhard Petracek gerhard.petra...@gmail.com: +1 regards, gerhard 2012/2/13 Mark Struberg strub...@yahoo.de I'd say we just push the release-branch + the release-tag and then merge them over to master. This is only needed to upgrade the versions. LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike deltaspike-dev@incubator.apache.org Sent: Monday, February 13, 2012 1:49 PM Subject: release branches hi @ all, since a new commit was pushed before we merged back the release branch, we have to discuss release branches right now. the options i see right now are: 1) we push the external named release-branch as it is (+ tag) and rebase the master 2) we merge the external release branch locally and just push the result as i did with the master at [1] 3) we don't allow pushes (in the future) before we pushed the fast forwarded master. regards, gerhard [1] https://github.com/os890/DS_Discuss -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: [VOTE] Release of Apache DeltaSpike 0.1-incubating
+1 2012/2/4 Jason Porter lightguard...@gmail.com: +1 looks good to me. On Fri, Feb 3, 2012 at 18:22, Gerhard Petracek gerhard.petra...@gmail.comwrote: the source-release looks fine - +1 regards, gerhard 2012/2/4 Gerhard Petracek gpetra...@apache.org Hi, I'd like to call a VOTE on releasing Apache DeltaSpike 0.1-incubating. Maven staging repository: https://repository.apache.org/content/repositories/orgapachedeltaspike-187/ Source release: https://repository.apache.org/content/repositories/orgapachedeltaspike-187/org/apache/deltaspike/deltaspike-project/0.1-incubating/deltaspike-project-0.1-incubating-source-release.zip Git release branch: http://s.apache.org/PbX (The branch will be pushed after the required votes passed.) Please take a look at the 0.1-incubating artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes of PPMC (or IPMC) members. This vote is open for 72 hours. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why ... Thanks, Gerhard -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
+1 for implementing both to see how it works out
+1 for building @Secured on top of @SecurityBindingType
Christian
2012/2/1 Jason Porter lightguard...@gmail.com:
I'm going to put my vote in with Arne.
+1 for @Secured implemented on top of @SecurityBindingType.
On Wed, Feb 1, 2012 at 06:52, Arne Limburg
arne.limb...@openknowledge.dewrote:
If we implement @Secured on top of @SecurityBindingType this could even be
a permanent solution.
So my +1 for that.
-Ursprüngliche Nachricht-
Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
Gesendet: Mittwoch, 1. Februar 2012 12:33
An: deltaspike-dev@incubator.apache.org
Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
hi @ all,
i talked with shane about further details of the current implementation.
- if we don't see an agreement this week:
+1 for adding both (at least for now).
we have to add features to both @Secured as well as @SecurityBindingType.
maybe we will see that one of both is better as soon as we have the final
implementation (and therefore all the details) and we can remove the other
approach.
if we see that both make sense, we just keep them.
regards,
gerhard
2012/2/1 Gerhard Petracek gerhard.petra...@gmail.com
yes - that's possible as well.
short addition - 3b allows:
@TwoOf //introduced by the user
@Secured({AccessDecisionVoter1.class, AccessDecisionVoter2.class,
AccessDecisionVoter3.class})
(i wouldn't do it that way, because i wouldn't use a custom annotation
for such use-cases. however, users can decide it on their own.)
regards,
gerhard
2012/2/1 Arne Limburg arne.limb...@openknowledge.de
Basically we are discussing, if the access control logic goes into a
class that implements an interface (which is AccessDecisionVoter) or
into a method that is annotated with @Secures.
Note that both approaches can be built with the other.
I prefer the second way since it looks more like the CDI way.
Another option is to provide both APIs. Then we only would have to
decide which one is core and which one is based on the other.
Cheers,
Arne
-Ursprüngliche Nachricht-
Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
Gesendet: Mittwoch, 1. Februar 2012 08:54
An: deltaspike-dev@incubator.apache.org
Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
@christian: that's correct. but the advantage of using custom
annotation arguments can't be used any more.
and that's also one of my concerns - simple cases work (but also
simple cases are more complex than the usage of @Secured) and such
advanced
use-cases are restricted.
in some cases it's worth to add more complexity, because it makes
sense
for supporting advanced use-cases!
but right now i don't see it here.
it would be possible to extend the approach of @Secured.
examples:
#1
//...
@Secured(MyAccessDecisionVoter.class)
public class SecuredBean
{
//...
}
users who prefer custom annotations can use stereotypes:
#2
//...
@Admin
public class SecuredBean
{
//...
}
//...
@Stereotype
@Secured(AdminAccessDecisionVoter.class)
public @interface Admin
{
}
#3
//...
//...
@AdminOrUser
public class SecuredBean
{
//...
}
a)
//...
@Stereotype
@Secured(oneOf = {AdminAccessDecisionVoter.class,
UserAccessDecisionVoter.class})
// @Secured(allOf = {AdminAccessDecisionVoter.class,
UserAccessDecisionVoter.class})
// ...
public @interface AdminOrUser
{
}
or
b)
//...
@Stereotype
//users could even provide a custom interceptor strategy and
introduce custom versions of @OneOf or other annotations @OneOf
@Secured({AdminAccessDecisionVoter.class,
UserAccessDecisionVoter.class}) public @interface AdminOrUser { }
or
c)
//...
@Stereotype
@Secured(value = {AdminAccessDecisionVoter.class,
UserAccessDecisionVoter.class}, mode = ONE_OF) public @interface
AdminOrUser { }
regards,
gerhard
2012/2/1 Christian Kaltepoth christ...@kaltepoth.de
What about something like this:
public @interface AnyOf {
Class? extends Annotation[] value(); }
Usage:
@AnyOf({User.class, Admin.class})
public void doSomething() {
// something
}
It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java
syntax. :)
Christian
2012/1/31 Arne Limburg arne.limb...@openknowledge.de:
Yes, that would work, but that annotation is not that nice. I
would have
expected something like
@AnyOf({@User, @Admin})
which unfortunately is no valid Java syntax.
Instead of that someone could write something like
@AnyOf(role1 = @User, role2 = @Admin) which could be used like
Shane suggests. Sadly enough there is no easy
way to provide a default @AnyOf annotation. So the users have to
write their own versions any time they need one
Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
, but discussing security mechanisms without discussing the stuff which needs to get secured is only half of the truth ;) LieGrue, strub [1] https://cwiki.apache.org/**EXTCDI/jsf-usage.html#** JSFUsage-TypesafeViewConfig https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-TypesafeViewC onfig - Original Message - From: Gerhard Petracekgerhard.petracek@**gmail.com gerhard.petra...@gmail.com To: deltaspike-dev@incubator.**apache.org deltaspike-dev@incubator.apache.org Cc: Sent: Tuesday, January 31, 2012 1:31 PM Subject: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured in case of myfaces codi it's also used for secured view and it is integrated with the default-error-view concept (as mentioned in the ticket we will postpone this part). furthermore it's used by codi-scopes to avoid a different expiration behaviour of beans cause by a security check (see the mentioned AccessDecisionVoterContext). regards, gerhard 2012/1/31 Arne Limburgarne.limburg@**openknowledge.de arne.limb...@openknowledge.de Hi, My first objection when I saw the CODI feature the first time, was that it maybe is too basic: When I have to implement the Voter anyway (or my security-framework of choice delivers it), why should I use @Secured at all? I mean, what is the REAL benefit of using @Secured over a custom annotation implemented by myself or delivered by my security-framework of choice. The only benefit I see is when using different security sources, but this is a rare use case imho. Cheers, Arne -Ursprüngliche Nachricht- Von: Gerhard Petracek [mailto:gerhard.petracek@**gmail.com gerhard.petra...@gmail.com ] Gesendet: Dienstag, 31. Januar 2012 13:14 An: deltaspike-dev@incubator.**apache.org deltaspike-dev@incubator.apache.org Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured that's one option. a 2nd option is to use a deltaspike-security-impl. module which can provide e.g. an adapter for 3rd party security-framework. or users just add a possible deltaspike-add-on provided by an external community e.g. by a security-framework itself. regards, gerhard 2012/1/31 John D. Amentjohn.d.am...@gmail.com Is it up to the developer to define the bean that implements an interface? On Tue, Jan 31, 2012 at 6:59 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, imo this feature of myfaces codi-core is a nice starting point for the security-api discussion, because the basic idea behind it is a very thin integration layer (which can be used by other modules). the basic concept: a cdi interceptor invokes (inline) voters to secure the target method/s. a voter is a (custom) cdi bean which implements a specific interface and therefore has access to the InvocationContext. furthermore, a voter detects 0-n violations andcan be used to integrate 3rd party security-frameworks. [1] provides a bit more details of the basic concept as well as the basic usage of @Secured. please send +1, +0 or -1 because... for thebasic concept. (please addbasic objections also to [2]. we can discuss details e.g. further objections about the concrete implementation (e.g. internal classes,...) as soon as we agreed on including this concept.) regards, gerhard [1] https://issues.apache.org/**jira/browse/DELTASPIKE-64 https://issues.apache.org/jira/browse/DELTASPIKE-64 [2] https://cwiki.apache.org/**confluence/display/DeltaSpike/** SE+Feature+Rank https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ran k ing -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
[jira] [Commented] (DELTASPIKE-63) Integration test profiles for OWB and Weld don't honor category annotations
[
https://issues.apache.org/jira/browse/DELTASPIKE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13195807#comment-13195807
]
Christian Kaltepoth commented on DELTASPIKE-63:
---
Hey all,
I spent quite some time on this one but now I think I got it right. I'll give a
short summary of what was wrong and what I did to fix it.
* Surefire was ignoring the JUnit categories for some reason. I updated the
Surefire plugin to version 2.11 and manually added the JUnit provider in the
correct version as a dependency to the plugin. Now both groups and
excludedGroups work fine.
* The OWB and Weld profiles didn't configure any JUnit categories for their
test execution. Therefore both ran all the tests regardless of their category.
Now both exclude WebProfileCategory and FullProfileCategory which works fine. I
also updated the profiles for AS7 and Glassfish to execute all the tests as
both containers support all the test categories.
* Another thing that went wrong was that the integration-test module didn't
execute the core tests at all. But somehow this was fixed together with the
update to Surefire 2.11. The only thing I had to change was to include
arquillian.xml on the classpath for the core test execution as this file is
required for the AS7 and Glassfish profiles.
* The test ExcludeTest didn't work correctly on AS7 which was caused by an
invalid packaging of the test archive.
The nice thing about my changes is that now all tests without any @Category
annotation are executed in all the profiles. Therefore we don't need to add
SeCategory to all the tests. Actually we could even remove SeCategory as it
isn't required anymore.
The only drawback of my changes is that every module that has parent-code or
parent-it as it's parent needs to have the category marker interfaces in the
test classpath, even core-api. For now I copied the 3 interfaces to the
core-api module. But we could thing about moving them to a separate
dependency later.
I'm attaching the patch to this ticket. I would apply it but I didn't receive
my Apache account up to now. If somebody runs into these problems, feel free to
apply it! :)
Integration test profiles for OWB and Weld don't honor category annotations
---
Key: DELTASPIKE-63
URL: https://issues.apache.org/jira/browse/DELTASPIKE-63
Project: DeltaSpike
Issue Type: Bug
Components: Tests
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Reporter: Christian Kaltepoth
Assignee: Gerhard Petracek
Attachments: DELTASPIKE-63.patch
It seems like the integration test profiles for OWB and Weld ignore the
@Category annotations used to restrict tests to a certain runtime environment
like WebProfile or FullProfile. This problem occurs when running the
tests in both core-impl and integration-test.
To reproduce this just add this failing method to some test class and execute
the tests in the default profile OWB:
@Test
@Category(WebProfileCategory.class)
public void testCategory() {
fail(Should not get executed!);
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DELTASPIKE-63) Integration test profiles for OWB and Weld don't honor category annotations
[
https://issues.apache.org/jira/browse/DELTASPIKE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Kaltepoth updated DELTASPIKE-63:
--
Attachment: DELTASPIKE-63.patch
Patch for the integration test issues
Integration test profiles for OWB and Weld don't honor category annotations
---
Key: DELTASPIKE-63
URL: https://issues.apache.org/jira/browse/DELTASPIKE-63
Project: DeltaSpike
Issue Type: Bug
Components: Tests
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Reporter: Christian Kaltepoth
Assignee: Gerhard Petracek
Attachments: DELTASPIKE-63.patch
It seems like the integration test profiles for OWB and Weld ignore the
@Category annotations used to restrict tests to a certain runtime environment
like WebProfile or FullProfile. This problem occurs when running the
tests in both core-impl and integration-test.
To reproduce this just add this failing method to some test class and execute
the tests in the default profile OWB:
@Test
@Category(WebProfileCategory.class)
public void testCategory() {
fail(Should not get executed!);
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Question on integration test structure
Done! https://issues.apache.org/jira/browse/DELTASPIKE-63 Christian 2012/1/26 Mark Struberg strub...@yahoo.de: yes, that should be the case (OWB and Weld only invoking the SE tests). If not, then please file a Jira and we gonna work on it. txs and LieGrue, strub - Original Message - From: Christian Kaltepoth christ...@kaltepoth.de To: deltaspike-dev@incubator.apache.org Cc: Sent: Thursday, January 26, 2012 5:35 PM Subject: Question on integration test structure Hi @ all, I just started to work on adding some more integration tests for the features that have been implemented up till now. But I'm a bit confused on how the integration tests are organized. Most tests have been added directly to the core-impl module and are executed there using either OWB or Weld. After that the integration-test module unpacks the tests of core-impl and executed them again. Beside OWB and Weld the integration-test module contains profiles for AS7 and Glassfish which execute only the JUnit categories SE, WebProfile and FullProfile. The problem seems to be that the OWB and Weld profiles completely ignore the JUnit categories and execute everything. So tests annotated with @WebProfile also get executed and fail. I think the OWB and Weld profiles need to be configured to execute only the @SeCategory tests. But this would require to add this annotation to most of the existing tests which is not very nice (but required?). And thoughts on this? Christian -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
[DISCUSS] BeanManagerProvider API
Hey @all, yesterday I had a deeper look at the BeanManagerProvider implementation and found something that could be improved. I created DELTASPIKE-56 (see [1]) for this but it turned out that we should discuss this topic on the mailing list. I saw that getBeanManager() may return null in some rare circumstances. Unfortunately this forces everyone calling this method to check the result for null. I think most code calling the method absolutely requires the BeanManager and cannot proceed without it. My first idea was to add another method getRequiredBeanManager() that doesn't return null if the BeanManager is not available but instead throws a meaningful runtime exception. That's what Solder does per default. Calling Solder's BeanManagerLocator.getBeanManager() without a BeanManager being available will result in a BeanManagerUnavailableException (see [2]). However Mark suggested that throwing an exception should be the default behavior. I for myself like Mark's idea. What do you think? Christian [1] https://issues.apache.org/jira/browse/DELTASPIKE-56 [2] https://github.com/seam/solder/blob/master/api/src/main/java/org/jboss/solder/beanManager/BeanManagerLocator.java#L82 -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: [DISCUSS] [DELTASPIKE-54] AnnotationInstanceProvider
+1 for having a deeper look at Matt's approach. It looks clean, fluent and is type-safe. I would love to see something like this for AnnotationInstanceProvider. Christian 2012/1/19 Jason Porter lightguard...@gmail.com: +1 Sent from my iPhone On Jan 19, 2012, at 6:10, Pete Muir pm...@redhat.com wrote: +1 On 19 Jan 2012, at 13:08, Gerhard Petracek wrote: hi @ all, ok - that would mean we merge the implementations referred by DELTASPIKE-54 and DELTASPIKE-55 @fail-fast in case of invalid names or values: +1 regards, gerhard 2012/1/19 Arne Limburg arne.limb...@openknowledge.de +0.5 from me, too. At least we need a method to create a memberless annotation as Pete suggests. In addition there should be a simple way to create an annotation that has just a value() attribute. Additionally I am thinking about a more typesafe approach, but I am afraid we can't find one. So imho at least we need provider.get(SimpleAnnotation.class) and maybe provider.get(AnnotationWithOneAttribute.class, attributeValue) And the get(...) has to check the types of the values to get a fail-fast-behavior. regards, Arne -Ursprüngliche Nachricht- Von: Pete Muir [mailto:pm...@redhat.com] Gesendet: Donnerstag, 19. Januar 2012 13:17 An: deltaspike-dev@incubator.apache.org Betreff: Re: [DISCUSS] [DELTASPIKE-54] AnnotationInstanceProvider +0.5 from me as well. I would want to see AnnotationInstanceProvider enhanced to have the ability to create a memberless annotation instance without having to provide an empty map as an argument. I would like to spend some time considering a type safe approach such as Matt's *in addition to* the map of values, which as Gerhard mentions we will need for XML config. On 18 Jan 2012, at 23:04, Gerhard Petracek wrote: as mentioned by pete (earlier), the additional features (DELTASPIKE-54 vs DELTASPIKE-55) aren't type-safe. - +0.5 afaik we will need it for further features which need such a generic approach (no +1 because we haven't discussed them so far) regards, gerhard 2012/1/18 Jason Porter lightguard...@gmail.com This should be DELTASPIKE-55 On Wed, Jan 18, 2012 at 14:26, Jason Porter lightguard...@gmail.com wrote: fyi: please check [1] before you answer. [2] is the implementation used in Solder. It also contains the functionality of CODI's SimpleLiteral. the basic concept: Provide a way to create an instance of an annotation at runtime using Proxy. This implementation is also able to provide values for the annotation parameters. please send +1, +0 or -1 because... for the basic idea as well as the basic concept. [1] http://markmail.org/message/7yefspfuvtz4jvmp [2] https://github.com/seam/solder/blob/develop/impl/src/test/java/org/jb oss/solder/test/util/AnnotationInstanceProviderTest.java [3] https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ran king -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: [DISCUSS] deltaspike v0.1
I really like the idea of releasing early and often! +1 2012/1/14 Matthias Wessendorf mat...@apache.org: +1 On Saturday, January 14, 2012, Mark Struberg strub...@yahoo.de wrote: +1 just finishing the integration tests and the ConfigResolver stuff a bit. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Saturday, January 14, 2012 1:10 AM Subject: [DISCUSS] deltaspike v0.1 hi @ all, we resolved over 30 jira-tickets and we finished (agreement + import/implementation) ~10 mechanisms/features. imo: we should release early and often + it would be nice to start with the first steps for a release and start with the release of v0.1 in about 1-2 weeks. (the first release might take a bit longer because we have to ensure that our setup is ok; we have to write the release guide;... .) regards, gerhard -- Sent from Gmail Mobile -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
[jira] [Updated] (DELTASPIKE-49) Remove -XX:+UseFastAccessorMethods as JVM argument for Jboss startup for integration tests
[ https://issues.apache.org/jira/browse/DELTASPIKE-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Kaltepoth updated DELTASPIKE-49: -- Attachment: DELTASPIKE-49.patch Hey there. I know that it is somehow silly to supply a patch for this issue as it is a one-liner. However I think this could be a great opportunity to experiment with the way patch submissions could work in the future. I think most of us are familiar with GitHub and the way pull request work. But as the ASF repository doesn't offer something similar we will have to find some other process. Of cause ordinary patch files will be sufficient in many cases. But as soon as contributions consist of more than one commit this doesn't work very well any more. For this issue I just created a local branch, committed the changes and created the patch with: $ git format-patch --stdout master ../DELTASPIKE-49.patch This results in a patch in mailbox format. Applying it is very easy: $ git am ../DELTASPIKE-49.patch The nice thing about this way of applying a patch is that it preserves the individual commits including the commit messages. If this works fine we could add a page to the wiki describing this process. Remove -XX:+UseFastAccessorMethods as JVM argument for Jboss startup for integration tests -- Key: DELTASPIKE-49 URL: https://issues.apache.org/jira/browse/DELTASPIKE-49 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.1-SNAPSHOT Reporter: Rudy De Busscher Assignee: Gerhard Petracek Priority: Minor Attachments: DELTASPIKE-49.patch When running the integration tests on a JRockit JVM, the JBoss server isn't starting up due to the parameter specified in arquillian.xml. On the mailing list there was a discussion and agreement to remove this option. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DELTASPIKE-12) define coding conventions
[ https://issues.apache.org/jira/browse/DELTASPIKE-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Kaltepoth updated DELTASPIKE-12: -- Attachment: deltaspike-code-conventions.xml I've created an Eclipse Code Formatter profile based on these conventions. I think this is very interesting for people using Eclipse who want to start some hacking. :) Perhaps we could add this profile and the one for IntelliJ to the git repository? define coding conventions - Key: DELTASPIKE-12 URL: https://issues.apache.org/jira/browse/DELTASPIKE-12 Project: DeltaSpike Issue Type: Task Reporter: Gerhard Petracek Assignee: Mark Struberg Attachments: deltaspike-code-conventions.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DELTASPIKE-12) define coding conventions
[ https://issues.apache.org/jira/browse/DELTASPIKE-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Kaltepoth updated DELTASPIKE-12: -- Attachment: deltaspike-code-conventions-fixed.xml I'm sorry. I did mistake regarding the indentation for wrapped lines. Here is the correct formatter profile. define coding conventions - Key: DELTASPIKE-12 URL: https://issues.apache.org/jira/browse/DELTASPIKE-12 Project: DeltaSpike Issue Type: Task Reporter: Gerhard Petracek Assignee: Mark Struberg Attachments: deltaspike-code-conventions-fixed.xml, deltaspike-code-conventions.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-35) Create testing structure
[ https://issues.apache.org/jira/browse/DELTASPIKE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13180289#comment-13180289 ] Christian Kaltepoth commented on DELTASPIKE-35: --- I cannot reproduce this. The integration tests are working fine for me. Even after manually deleting the activation jars from my local repository Maven downloads activation-1.1.jar and the build runs fine. Create testing structure Key: DELTASPIKE-35 URL: https://issues.apache.org/jira/browse/DELTASPIKE-35 Project: DeltaSpike Issue Type: Task Components: Core Affects Versions: 0.1-SNAPSHOT Reporter: Jason Porter Assignee: Jason Porter Fix For: 0.1-SNAPSHOT -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] [DELTASPIKE-27] CodiConfig
AFAIK the name DeltaSpike was meant only as a code name for the incubation process (see [1]). So I don't think SpikeConfig would be a good choice as the project name may change in the future. [1] http://wiki.apache.org/incubator/DeltaSpikeProposal#line-175 2011/12/24 John D. Ament john.d.am...@gmail.com +1 How about SpikeConfig? On Fri, Dec 23, 2011 at 3:27 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 for a new name. (initially it was a bit more. we reduced the functionality later on.) we could call it e.g. ModuleConfig regards, gerhard 2011/12/23 Jason Porter lightguard...@gmail.com +1 Needs a better name though :P On Thu, Dec 22, 2011 at 04:03, Christian Kaltepoth christ...@kaltepoth.dewrote: +1 I really like this way of configuration. It should definitively be part of DeltaSpike. Christian 2011/12/22 Mark Struberg strub...@yahoo.de: +1 Please note that CodiConfig doesn't contain any logic! It's really just a marker interface to mark our SPI classes which are to be implemented/overwritten in a customer project to configure the provided functionality. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Wednesday, December 21, 2011 9:41 PM Subject: Re: [DISCUSS] [DELTASPIKE-27] CodiConfig +1 regards, gerhard 2011/12/21 Gerhard Petracek gerhard.petra...@gmail.com hi @ all, fyi: please check [1] before you answer. [2] shows how to provide custom config-values in a type-safe manner. the basic concept: CodiConfig itself is just a marker interface to find all config classes easily. a config class is a simple application scoped cdi-bean with getter methods. a config can be accessed easily via std. cdi injection. users see the default-values as well as custom configured values easily. to provide custom values, users just have to extend the config class, annotate it with @Specializes and to override the corresponding method. furthermore, it's possible to provide config modules which allow to use different kinds of config formats like xml files, property files,... (due to the @Specializes bug in weld, we had to introduce a workaround. however, since weld v1.1.4 it's fixed and so we don't need the workarounds we introduced for it and it's as simple as the previous description.) please send +1, +0 or -1 because... for the basic idea as well as the basic concept. if there are basic objections, please also add them to [3] regards, gerhard [1] http://markmail.org/message/7yefspfuvtz4jvmp [2] https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Config+and+SPI [3] https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: [DISCUSS] [DELTASPIKE-8] @Veto
Perhaps we should build a list of all suggestions and then start a vote which one to use. I think these are the names that were suggested: @Veto @Skip @Exclude @Deactivate @Ignore 2011/12/23 Gerhard Petracek gerhard.petra...@gmail.com: hi arne, would be also ok for me - +1 regards, gerhard 2011/12/23 Arne Limburg arne.limb...@openknowledge.de What about @Exclude? Cheers, Arne -Ursprüngliche Nachricht- Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] Gesendet: Freitag, 23. Dezember 2011 21:28 An: deltaspike-dev@incubator.apache.org Betreff: Re: [DISCUSS] [DELTASPIKE-8] @Veto +0.5 for @Skip as mentioned in the original thread @Veto is accurate from a technical perspective, but it sounds strange for users who aren't aware of the mechanism behind. if we are talking only about @Veto vs @Skip and not about the other alternatives: +1 for @Skip regards, gerhard 2011/12/23 Dan Allen dan.j.al...@gmail.com Veto is rationally the most appropriate since it directly translates to calling ProcessAnnotatedType#veto() However, I'd like to offer one other alternative: @Skip While veto describes what the extension is doing internally, skip is how the developer perceives the result of the action. The class is skipped over during the scanning process. This is similar to the suggestion @Ignore, and I think both would get the point across equally well. -Dan p.s. Apologizes for dropping the rest of the thread. I wasn't receiving messages when this thread started. -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: [DISCUSS] (DELTASPIKE-15) @DefaultBean
+1 2011/12/23 Gerhard Petracek gerhard.petra...@gmail.com: +1 if we keep the impl in impl-bda [1] regards, gerhard [1] https://cwiki.apache.org/confluence/display/DeltaSpike/Project+Structure 2011/12/23 Jason Porter lightguard...@gmail.com fyi: please check [1] before you answer. [2] is the implementation used in Solder. The use case for it really seems more like @Typed, but in practice it's being used to go around BDA issues in containers. the basic concept: Provides a bean with a type and qualifiers that may be different than the concrete type. please send +1, +0 or -1 because... for the basic idea as well as the basic concept. if there are basic objections, please also add them to [3] [1] http://markmail.org/message/7yefspfuvtz4jvmp [2] http://docs.jboss.org/seam/3/3.1.0.CR1/reference/en-US/html/solder-defaultbeans.html [3] https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: [DISCUSS] [DELTASPIKE-27] CodiConfig
+1 I really like this way of configuration. It should definitively be part of DeltaSpike. Christian 2011/12/22 Mark Struberg strub...@yahoo.de: +1 Please note that CodiConfig doesn't contain any logic! It's really just a marker interface to mark our SPI classes which are to be implemented/overwritten in a customer project to configure the provided functionality. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Wednesday, December 21, 2011 9:41 PM Subject: Re: [DISCUSS] [DELTASPIKE-27] CodiConfig +1 regards, gerhard 2011/12/21 Gerhard Petracek gerhard.petra...@gmail.com hi @ all, fyi: please check [1] before you answer. [2] shows how to provide custom config-values in a type-safe manner. the basic concept: CodiConfig itself is just a marker interface to find all config classes easily. a config class is a simple application scoped cdi-bean with getter methods. a config can be accessed easily via std. cdi injection. users see the default-values as well as custom configured values easily. to provide custom values, users just have to extend the config class, annotate it with @Specializes and to override the corresponding method. furthermore, it's possible to provide config modules which allow to use different kinds of config formats like xml files, property files,... (due to the @Specializes bug in weld, we had to introduce a workaround. however, since weld v1.1.4 it's fixed and so we don't need the workarounds we introduced for it and it's as simple as the previous description.) please send +1, +0 or -1 because... for the basic idea as well as the basic concept. if there are basic objections, please also add them to [3] regards, gerhard [1] http://markmail.org/message/7yefspfuvtz4jvmp [2] https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Config+and+SPI [3] https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: [VOTE] coding conventions (DELTASPIKE-12)
+1 (non-binding) 2011/12/18 Jason Porter lightguard...@gmail.com: +1 On Sat, Dec 17, 2011 at 17:58, Gerhard Petracek gerhard.petra...@gmail.comwrote: +1 regards, gerhard 2011/12/18 Gerhard Petracek gerhard.petra...@gmail.com Hi, I asked [1] to add alternative settings to DELTASPIKE-12, since we have seen several different opinions (about details). Nobody added an alternative set. So I start the formal vote with the suggested set right now. If we don't see a majority, we have to re-visit this topic again (+ we would need a new vote with at least one concrete alternative). Please review the coding conventions at [2] and vote. (Its content is also included below for your convenience). [ ] +1 I'm ok with the coding conventions [ ] +0 [ ] -1 I've major objections, because... The vote is open for 72 hours. Thanks, Gerhard [1] http://s.apache.org/Ga8 [2] http://s.apache.org/SAj --- 1) no tabs, only spaces (4 spaces). 2) bracelets on new line 3) force bracelets 4) 4 spaces indent size 5) a space between keyword and round bracket 6) a space before and after an operand 7) line width: 120 8) no underscore at the beginning 9) no wildcard imports -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
