Re: [VOTE] Release of Apache DeltaSpike 1.1.0
Very cool to see the project moving forward. Thank you guys. 2014-11-02 15:58 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: @karl: see e.g. [1] regards, gerhard [1] http://s.apache.org/iua 2014-11-02 12:31 GMT+01:00 karl.kil...@gmail.com: Hello, It runs well for me. I would like to try the new stuff, any release notes? Thanks for all the work guys! Cheers 2 nov 2014 kl. 08:05 skrev Romain Manni-Bucau rmannibu...@gmail.com: +1 Le 1 nov. 2014 21:49, Gerhard Petracek gerhard.petra...@gmail.com a écrit : +1 regards, gerhard 2014-11-01 21:46 GMT+01:00 Gerhard Petracek gpetra...@apache.org: Hi, I was running the needed tasks to get the 12th release of Apache DeltaSpike out. The artifacts are deployed to Nexus [1] (and [2]). The tag is available at [3] and will get pushed to the ASF repository once the vote passed. Please take a look at the 1.1.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [4]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachedeltaspike-1015 [2] https://repository.apache.org/content/repositories/orgapachedeltaspike-1015/org/apache/deltaspike/deltaspike-project/1.1.0/deltaspike-project-1.1.0-source-release.zip [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.1.0 [4] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Jean-Louis
Re: [VOTE] Release of Apache DeltaSpike 1.1.0
+1 LieGrue, strub On Saturday, 1 November 2014, 21:47, Gerhard Petracek gpetra...@apache.org wrote: Hi, I was running the needed tasks to get the 12th release of Apache DeltaSpike out. The artifacts are deployed to Nexus [1] (and [2]). The tag is available at [3] and will get pushed to the ASF repository once the vote passed. Please take a look at the 1.1.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [4]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachedeltaspike-1015 [2] https://repository.apache.org/content/repositories/orgapachedeltaspike-1015/org/apache/deltaspike/deltaspike-project/1.1.0/deltaspike-project-1.1.0-source-release.zip [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.1.0 [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] Release of Apache DeltaSpike 1.1.0
+1 2014-11-03 10:59 GMT+01:00 Mark Struberg strub...@yahoo.de: +1 LieGrue, strub On Saturday, 1 November 2014, 21:47, Gerhard Petracek gpetra...@apache.org wrote: Hi, I was running the needed tasks to get the 12th release of Apache DeltaSpike out. The artifacts are deployed to Nexus [1] (and [2]). The tag is available at [3] and will get pushed to the ASF repository once the vote passed. Please take a look at the 1.1.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [4]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachedeltaspike-1015 [2] https://repository.apache.org/content/repositories/orgapachedeltaspike-1015/org/apache/deltaspike/deltaspike-project/1.1.0/deltaspike-project-1.1.0-source-release.zip [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.1.0 [4] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
[jira] [Commented] (DELTASPIKE-760) TestControl module creates Applicationscoped beans more than once for single test
[ https://issues.apache.org/jira/browse/DELTASPIKE-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14194473#comment-14194473 ] Björn Schmidt commented on DELTASPIKE-760: -- I'm very sorry, My fault, I just didn't see it. It's not a DS bug, Code completion added JSF ApplicationScoped annotation instead of CDI. But only for one file, I didn't expect that. TestControl module creates Applicationscoped beans more than once for single test - Key: DELTASPIKE-760 URL: https://issues.apache.org/jira/browse/DELTASPIKE-760 Project: DeltaSpike Issue Type: Bug Components: CdiControl Affects Versions: 1.0.3 Reporter: Björn Schmidt Assignee: Mark Struberg I have a test that is @RunWith(CdiTestRunner.class), is @Injecting an @ApplicationScopedBean1 which itself @Injects another @ApplicationScopedBean2 and then I have another @Inject directly in the test class which also @Injects the @ApplicationScopedBean2. The CDI implementation used is Weld-SE ApplicationScopedBean2 contains a cache. What's happeneing is, that ApplicationScopedBean2 gets created twice, once for ApplicationScopedBean1 and once for the test class. So when I then call ApplicationScopedBean2.invalidateMyCache() in the test and then ask ApplicationScopedBean1.getSomethingFromYourApplicationScopedBean2sCache, then because its two different beans I still get some cached values. Of course all calls are done within the same test method! Deployed on a server the whole thing works as expected, only one bean of type ApplicationScopedBean2 is being created. But the whole purpose of having DeltaSpike is to be able to test stuff exactly as it would be on the server, right? So I'm not sure, if this is a Bug, a known limitation (couldn't find anything about that) or a configuration problem with my test setup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-766) Created beans don't seem to get destroyed when using CdiTestRunner
Björn Schmidt created DELTASPIKE-766: Summary: Created beans don't seem to get destroyed when using CdiTestRunner Key: DELTASPIKE-766 URL: https://issues.apache.org/jira/browse/DELTASPIKE-766 Project: DeltaSpike Issue Type: Improvement Components: TestControl Affects Versions: 1.0.3 Reporter: Björn Schmidt Priority: Minor I'm using the CDITestRunner in order to test some long running imports using Weld-Se. During the import a SessionProducer is producing ~1k db sessions (has nothing to do with web session) in a loop via Instance.get(). On a live system this is resutling in 1k calls to the following methods 1. producer method of session producer being called 2. postconstruct method of session being called 3. work done 4. disposes methog of producer being called 3. predestroy being called but with the testcontrol module only 1,2 and 3 happens, 3 and 4 are never called, not even when weld shuts down. Only the predestroy method of the producer is called in which I then have to collect and close all 1k created sessions. Question: is this a bug, supposed to be this way, or a configuration problem? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-766) Created beans don't seem to get destroyed when using CdiTestRunner
[ https://issues.apache.org/jira/browse/DELTASPIKE-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Björn Schmidt updated DELTASPIKE-766: - Description: I'm using the CDITestRunner in order to test some long running imports using Weld-Se. During the import a SessionProducer is producing ~1k db sessions (has nothing to do with web session) in a loop via Instance.get(). On a live system this is resutling in 1k calls to the following methods 1. producer method of session producer being called 2. postconstruct method of session being called 3. work done 4. disposes method of producer being called 5. predestroy of session being called but with the testcontrol module only 1,2 and 3 happens, 4 and 5 are never called, not even when weld shuts down. Only the predestroy method of the producer is called in which I then have to collect and close all 1k created sessions. Question: is this a bug, supposed to be this way, or a configuration problem? was: I'm using the CDITestRunner in order to test some long running imports using Weld-Se. During the import a SessionProducer is producing ~1k db sessions (has nothing to do with web session) in a loop via Instance.get(). On a live system this is resutling in 1k calls to the following methods 1. producer method of session producer being called 2. postconstruct method of session being called 3. work done 4. disposes methog of producer being called 3. predestroy being called but with the testcontrol module only 1,2 and 3 happens, 3 and 4 are never called, not even when weld shuts down. Only the predestroy method of the producer is called in which I then have to collect and close all 1k created sessions. Question: is this a bug, supposed to be this way, or a configuration problem? Created beans don't seem to get destroyed when using CdiTestRunner -- Key: DELTASPIKE-766 URL: https://issues.apache.org/jira/browse/DELTASPIKE-766 Project: DeltaSpike Issue Type: Improvement Components: TestControl Affects Versions: 1.0.3 Reporter: Björn Schmidt Priority: Minor I'm using the CDITestRunner in order to test some long running imports using Weld-Se. During the import a SessionProducer is producing ~1k db sessions (has nothing to do with web session) in a loop via Instance.get(). On a live system this is resutling in 1k calls to the following methods 1. producer method of session producer being called 2. postconstruct method of session being called 3. work done 4. disposes method of producer being called 5. predestroy of session being called but with the testcontrol module only 1,2 and 3 happens, 4 and 5 are never called, not even when weld shuts down. Only the predestroy method of the producer is called in which I then have to collect and close all 1k created sessions. Question: is this a bug, supposed to be this way, or a configuration problem? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-760) TestControl module creates Applicationscoped beans more than once for single test
[ https://issues.apache.org/jira/browse/DELTASPIKE-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14194488#comment-14194488 ] Gerhard Petracek commented on DELTASPIKE-760: - np - just fyi: if you have the ee-api on the test-classpath, you can just add the jsf-module provided by deltaspike. it will convert beans with jsf-scopes but without @ManagedBean to cdi-beans with the corresponding cdi-scope. TestControl module creates Applicationscoped beans more than once for single test - Key: DELTASPIKE-760 URL: https://issues.apache.org/jira/browse/DELTASPIKE-760 Project: DeltaSpike Issue Type: Bug Components: CdiControl Affects Versions: 1.0.3 Reporter: Björn Schmidt Assignee: Mark Struberg I have a test that is @RunWith(CdiTestRunner.class), is @Injecting an @ApplicationScopedBean1 which itself @Injects another @ApplicationScopedBean2 and then I have another @Inject directly in the test class which also @Injects the @ApplicationScopedBean2. The CDI implementation used is Weld-SE ApplicationScopedBean2 contains a cache. What's happeneing is, that ApplicationScopedBean2 gets created twice, once for ApplicationScopedBean1 and once for the test class. So when I then call ApplicationScopedBean2.invalidateMyCache() in the test and then ask ApplicationScopedBean1.getSomethingFromYourApplicationScopedBean2sCache, then because its two different beans I still get some cached values. Of course all calls are done within the same test method! Deployed on a server the whole thing works as expected, only one bean of type ApplicationScopedBean2 is being created. But the whole purpose of having DeltaSpike is to be able to test stuff exactly as it would be on the server, right? So I'm not sure, if this is a Bug, a known limitation (couldn't find anything about that) or a configuration problem with my test setup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-766) Created beans don't seem to get destroyed when using CdiTestRunner
[ https://issues.apache.org/jira/browse/DELTASPIKE-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14194500#comment-14194500 ] Gerhard Petracek commented on DELTASPIKE-766: - i can't reproduce it - please provide a link to a demo-app which illustrates the issue. just fyi: if you aren't sure about an issue, you are very welcome to ask on our (users-)mailing-list. Created beans don't seem to get destroyed when using CdiTestRunner -- Key: DELTASPIKE-766 URL: https://issues.apache.org/jira/browse/DELTASPIKE-766 Project: DeltaSpike Issue Type: Improvement Components: TestControl Affects Versions: 1.0.3 Reporter: Björn Schmidt Priority: Minor I'm using the CDITestRunner in order to test some long running imports using Weld-Se. During the import a SessionProducer is producing ~1k db sessions (has nothing to do with web session) in a loop via Instance.get(). On a live system this is resutling in 1k calls to the following methods 1. producer method of session producer being called 2. postconstruct method of session being called 3. work done 4. disposes method of producer being called 5. predestroy of session being called but with the testcontrol module only 1,2 and 3 happens, 4 and 5 are never called, not even when weld shuts down. Only the predestroy method of the producer is called in which I then have to collect and close all 1k created sessions. Question: is this a bug, supposed to be this way, or a configuration problem? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-766) Created beans don't seem to get destroyed when using CdiTestRunner
[ https://issues.apache.org/jira/browse/DELTASPIKE-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14194542#comment-14194542 ] Björn Schmidt commented on DELTASPIKE-766: -- Will do, please give me a day, or two ;) Created beans don't seem to get destroyed when using CdiTestRunner -- Key: DELTASPIKE-766 URL: https://issues.apache.org/jira/browse/DELTASPIKE-766 Project: DeltaSpike Issue Type: Improvement Components: TestControl Affects Versions: 1.0.3 Reporter: Björn Schmidt Priority: Minor I'm using the CDITestRunner in order to test some long running imports using Weld-Se. During the import a SessionProducer is producing ~1k db sessions (has nothing to do with web session) in a loop via Instance.get(). On a live system this is resutling in 1k calls to the following methods 1. producer method of session producer being called 2. postconstruct method of session being called 3. work done 4. disposes method of producer being called 5. predestroy of session being called but with the testcontrol module only 1,2 and 3 happens, 4 and 5 are never called, not even when weld shuts down. Only the predestroy method of the producer is called in which I then have to collect and close all 1k created sessions. Question: is this a bug, supposed to be this way, or a configuration problem? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-749) Doc: Security: Making intitially requested and secured page available for redirect after login
[
https://issues.apache.org/jira/browse/DELTASPIKE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14194736#comment-14194736
]
Ron Smeral commented on DELTASPIKE-749:
---
#1 Agreed, the AuthenticationListener should have e.g. window/session scope.
#2 The way I see it seems to be in contradiction to your point #2: IMHO,
AccessDecisionVoters should really do just that one thing which is voting and
nothing else, any other behaviour added to a voter makes the design dirty.
#3 AuthenticationListener is a custom view-specific component responsible for
handling login cases (success/fail/whatever). The exception handling is just an
added behaviour.
#4 You're right, it would be cleaner to observe some LoginFailedEvent instead
of handling the exception.
#5 Documenting both seems like an overkill to me, for such a simple thing which
most app developers will probably implement in a way most appropriate for their
application.
I also think including both, a generic CDI version and a PicketLink version is
too much, I suggest keeping just the PL version and adding a note, that it's
easy to implement this for any other framework by handling appropriate events
and making appropriate authorization check calls in the voter.
I suggest keeping the combination of #1, #2, #4:
A plain voter:
- the one in the PL example in the doc is wrong, since it's called
AdminAccessDecisionVoter, but only calls {{isLoggedIn()}}
- also, why use BeanProvider in the method body instead of an injection point,
when the bean is an injection target?
{code:java|title=AdminAccessDecisionVoter.java}
@SessionScoped //or @WindowScoped
public class AdminAccessDecisionVoter extends AbstractAccessDecisionVoter {
@Inject
RelationshipManager relMgr;
@Inject
Identity id;
@Inject
IdentityManager idm;
@Override
protected void checkPermission(AccessDecisionVoterContext context,
SetSecurityViolation violations) {
if(!BasicModel.hasRole(relMgr, id.getAccount(), BasicModel.getRole(idm,
admin))) {
violations.add(/*...*/);
}
}
}
{code}
And a view-specific observer like this:
{code:java|title=AuthenticationListener.java}
@SessionScoped
public class AuthenticationListener {
@Inject ViewNavigationHandler viewNavigationHandler;
@Inject ViewConfigResolver viewConfigResolver;
private Class? extends ViewConfig deniedPage;
public void rememberDeniedView(@Observes LoginFailedEvent evt) {
deniedPage =
viewConfigResolver.getViewConfigDescriptor(FacesContext.getCurrentInstance().getViewRoot().getViewId()).getConfigClass();
evt.handledAndContinue();
}
public void handleLoggedIn(@Observes LoggedInEvent event) {
if(deniedPage != null) {
viewNavigationHandler.navigateTo(deniedPage);
deniedPage = null;
}
viewNavigationHandler.navigateTo(Pages.Home.class);
}
}
{code}
Doc: Security: Making intitially requested and secured page available for
redirect after login
--
Key: DELTASPIKE-749
URL: https://issues.apache.org/jira/browse/DELTASPIKE-749
Project: DeltaSpike
Issue Type: Bug
Components: Documentation
Reporter: Ron Smeral
Priority: Minor
http://deltaspike.apache.org/documentation/security.html#_making_intitially_requested_and_secured_page_available_for_redirect_after_login
In _CDI Implementation to redirect the login to the first denied page_:
* change Usuario to User
* why use {{char[]}} for password? Is that some security measure, to prevent
interned Strings of passwords hanging around in memory? If so, that should be
noted, otherwise it should be changed to String, it's confusing.
In CDI and PL implementations:
* -the AdminAccessDecisionVoter should implement AccessDecisionVoter, not
extend AbstractAccessDecisionVoter-
* I think the {{AdminAccessDecisionVoter}} should be agnostic of the view
layer and therefore shouldn't inject {{ViewConfigResolver}} and shouldn't
keep the denied page itself.
Maybe the listener could handle the {{AccessDeniedException}} instead:
Basic voter:
{code:java|title=AdminAccessDecisionVoter.java}
@SessionScoped //or @WindowScoped
public class AdminAccessDecisionVoter extends AbstractAccessDecisionVoter {
@Override
protected void checkPermission(AccessDecisionVoterContext context,
SetSecurityViolation violations) {
// voting stuff
}
}
{code}
The listener/holder/handler:
{code:java|title=AuthenticationListener.java}
@ExceptionHandler
public class AuthenticationListener {
@Inject ViewNavigationHandler viewNavigationHandler;
@Inject ViewConfigResolver viewConfigResolver;
private Class? extends ViewConfig deniedPage;
public void
[jira] [Created] (DELTASPIKE-767) Review javadoc in core/api
Ron Smeral created DELTASPIKE-767: - Summary: Review javadoc in core/api Key: DELTASPIKE-767 URL: https://issues.apache.org/jira/browse/DELTASPIKE-767 Project: DeltaSpike Issue Type: Task Components: Documentation Reporter: Ron Smeral Priority: Minor Fix typos and mistakes in javadoc Restructure as necessary to increase comprehensibility Unify formatting -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-767) Review javadoc in core/api
[ https://issues.apache.org/jira/browse/DELTASPIKE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14194752#comment-14194752 ] Ron Smeral commented on DELTASPIKE-767: --- https://github.com/apache/deltaspike/pull/10 Review javadoc in core/api -- Key: DELTASPIKE-767 URL: https://issues.apache.org/jira/browse/DELTASPIKE-767 Project: DeltaSpike Issue Type: Task Components: Documentation Reporter: Ron Smeral Priority: Minor Fix typos and mistakes in javadoc Restructure as necessary to increase comprehensibility Unify formatting -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-749) Doc: Security: Making intitially requested and secured page available for redirect after login
[
https://issues.apache.org/jira/browse/DELTASPIKE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14195107#comment-14195107
]
Gerhard Petracek commented on DELTASPIKE-749:
-
only the artifact which keeps the denied-page needs to be session- or
window-scoped.
@#2: personally i would agree, however, there are more pragmatic minds out
there and imo for them we should always show the minimal way - otherwise they
see it as over-complicated...
@#3: since you changed the notion of AuthenticationListener, we are talking
about the same same name, but a different artifact (since it isn't an
exception-handler any longer... what you tried to do initially is an
exception-observer - we don't have that, but a lot of users are trying to do
that (esp. in context of security violations) and therefore i discussed it
already with jason. that's the reason why it worked at all... in case of
security-exceptions we handle it differently, because we don't have such
observers. it isn't consistent/correct, but too many users are using it like
you tried to do it, because it's what you expect. however, it isn't what
exception-control is doing usually, so we don't like to promote this special
handling.)
since deltaspike isn't bound to picketlink the primary documentation needs to
be independent - documenting the integration with security-providers like
picketlink is just a bonus for our documentation (which is **very welcome**).
so far we just included that one, because a full example (with manual
login/logout) isn't that complicated, but it looks a bit long...
- +1 for your 2nd code-suggestion, but we need to add details about the
possible scopes of AdminAccessDecisionVoter (since a voter should be stateless,
if you keep the state in other beans...)
Doc: Security: Making intitially requested and secured page available for
redirect after login
--
Key: DELTASPIKE-749
URL: https://issues.apache.org/jira/browse/DELTASPIKE-749
Project: DeltaSpike
Issue Type: Bug
Components: Documentation
Reporter: Ron Smeral
Priority: Minor
http://deltaspike.apache.org/documentation/security.html#_making_intitially_requested_and_secured_page_available_for_redirect_after_login
In _CDI Implementation to redirect the login to the first denied page_:
* change Usuario to User
* why use {{char[]}} for password? Is that some security measure, to prevent
interned Strings of passwords hanging around in memory? If so, that should be
noted, otherwise it should be changed to String, it's confusing.
In CDI and PL implementations:
* -the AdminAccessDecisionVoter should implement AccessDecisionVoter, not
extend AbstractAccessDecisionVoter-
* I think the {{AdminAccessDecisionVoter}} should be agnostic of the view
layer and therefore shouldn't inject {{ViewConfigResolver}} and shouldn't
keep the denied page itself.
Maybe the listener could handle the {{AccessDeniedException}} instead:
Basic voter:
{code:java|title=AdminAccessDecisionVoter.java}
@SessionScoped //or @WindowScoped
public class AdminAccessDecisionVoter extends AbstractAccessDecisionVoter {
@Override
protected void checkPermission(AccessDecisionVoterContext context,
SetSecurityViolation violations) {
// voting stuff
}
}
{code}
The listener/holder/handler:
{code:java|title=AuthenticationListener.java}
@ExceptionHandler
public class AuthenticationListener {
@Inject ViewNavigationHandler viewNavigationHandler;
@Inject ViewConfigResolver viewConfigResolver;
private Class? extends ViewConfig deniedPage;
public void rememberDeniedView(@BeforeHandles
ExceptionEventErrorViewAwareAccessDeniedException evt) {
deniedPage =
viewConfigResolver.getViewConfigDescriptor(FacesContext.getCurrentInstance().getViewRoot().getViewId()).getConfigClass();
evt.handledAndContinue();
}
public void handleLoggedIn(@Observes UserLoggedInEvent event) {
if(deniedPage != null) {
viewNavigationHandler.navigateTo(deniedPage);
deniedPage = null;
}
viewNavigationHandler.navigateTo(Pages.Home.class);
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-767) Review javadoc in core/api
[ https://issues.apache.org/jira/browse/DELTASPIKE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-767: Assignee: Rafael Benevides Review javadoc in core/api -- Key: DELTASPIKE-767 URL: https://issues.apache.org/jira/browse/DELTASPIKE-767 Project: DeltaSpike Issue Type: Task Components: Documentation Reporter: Ron Smeral Assignee: Rafael Benevides Priority: Minor Fix typos and mistakes in javadoc Restructure as necessary to increase comprehensibility Unify formatting -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-768) GET request parameter type discrepancy silently discarded with JSF
Fabien MARSAUD created DELTASPIKE-768:
-
Summary: GET request parameter type discrepancy silently discarded
with JSF
Key: DELTASPIKE-768
URL: https://issues.apache.org/jira/browse/DELTASPIKE-768
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 1.0.3
Environment: Glassfish 3.1.2.2, JSF 2.1.28, Weld 1.1.14, Richfaces,
Rewrite
Reporter: Fabien MARSAUD
Priority: Minor
I have a request scoped managed bean which receives paypal IPN notifications.
IPNs contain a shared secret String parameter transferred as a http GET param.
I had a correct setSecret(String) on my backing bean, but because of a bad 5
year-old copy/paste, I had the wrong return type on getSecret(). It was never
noticed because the *getter* was never called anywhere, and with Seam we used
until our previous release , secret was *set* without complaining anyway.
On the page: {code}
f:metadata
f:viewParam name=secret value=#{orderPaypalIPN.secret} /
/f:metadata{code}
In the code:{code}
@Named(orderPaypalIPN)
@RequestScoped
public class OrderPaypalIPNHandler {
private String secret;
public Long getSecret() { //***TYPO: LONG INSTEAD OF STRING***
return null; //security reason
}
public void setSecret(String secret) {
this.secret = secret;
}
{code}
So, when we were using Seam, secret was correctly set, then used by the rest
of the code. When we started using DeltaSpike instead, secret was not set
anymore (even though the issue was with the getter, not the setter). I'm OK
with it (more strict, better), except that the get/set discrepancy is not
logged. I think it should be.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-768) GET request parameter silently discarded upon type discrepancy with JSF
[
https://issues.apache.org/jira/browse/DELTASPIKE-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabien MARSAUD updated DELTASPIKE-768:
--
Summary: GET request parameter silently discarded upon type discrepancy
with JSF (was: GET request parameter type discrepancy silently discarded with
JSF)
GET request parameter silently discarded upon type discrepancy with JSF
---
Key: DELTASPIKE-768
URL: https://issues.apache.org/jira/browse/DELTASPIKE-768
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 1.0.3
Environment: Glassfish 3.1.2.2, JSF 2.1.28, Weld 1.1.14, Richfaces,
Rewrite
Reporter: Fabien MARSAUD
Priority: Minor
Labels: jsf, parameter, request
I have a request scoped managed bean which receives paypal IPN notifications.
IPNs contain a shared secret String parameter transferred as a http GET
param.
I had a correct setSecret(String) on my backing bean, but because of a bad 5
year-old copy/paste, I had the wrong return type on getSecret(). It was never
noticed because the *getter* was never called anywhere, and with Seam we used
until our previous release , secret was *set* without complaining anyway.
On the page: {code}
f:metadata
f:viewParam name=secret value=#{orderPaypalIPN.secret} /
/f:metadata{code}
In the code:{code}
@Named(orderPaypalIPN)
@RequestScoped
public class OrderPaypalIPNHandler {
private String secret;
public Long getSecret() { //***TYPO: LONG INSTEAD OF STRING***
return null; //security reason
}
public void setSecret(String secret) {
this.secret = secret;
}
{code}
So, when we were using Seam, secret was correctly set, then used by the
rest of the code. When we started using DeltaSpike instead, secret was not
set anymore (even though the issue was with the getter, not the setter). I'm
OK with it (more strict, better), except that the get/set discrepancy is not
logged. I think it should be.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-768) GET request parameter silently discarded upon type discrepancy with JSF
[
https://issues.apache.org/jira/browse/DELTASPIKE-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabien MARSAUD updated DELTASPIKE-768:
--
Description:
I have a request scoped managed bean which receives paypal IPN notifications.
IPNs contain a shared secret String parameter transferred as a http GET param.
I had a correct setSecret(String) on my backing bean, but because of a bad 5
year-old copy/paste, I had the wrong return type on getSecret(). It was never
noticed because the *getter* was never called anywhere, and with Seam we used
until our previous release , secret was *set* without complaining anyway.
On the page: {code}
f:metadata
f:viewParam name=secret value=#{orderPaypalIPN.secret} /
/f:metadata{code}
In the code:{code}
@Named(orderPaypalIPN)
@RequestScoped
public class OrderPaypalIPNHandler {
private String secret;
//getter needed by JSF2
public Long getSecret() { //***TYPO: LONG INSTEAD OF STRING***
return null; //security reason
}
public void setSecret(String secret) {
this.secret = secret;
}
{code}
So, when we were using Seam, secret was correctly set, then used by the rest
of the code. When we started using DeltaSpike instead, secret was not set
anymore (even though the issue was with the getter, not the setter). I'm OK
with it (more strict, better), except that the get/set discrepancy is not
logged. I think it should be.
was:
I have a request scoped managed bean which receives paypal IPN notifications.
IPNs contain a shared secret String parameter transferred as a http GET param.
I had a correct setSecret(String) on my backing bean, but because of a bad 5
year-old copy/paste, I had the wrong return type on getSecret(). It was never
noticed because the *getter* was never called anywhere, and with Seam we used
until our previous release , secret was *set* without complaining anyway.
On the page: {code}
f:metadata
f:viewParam name=secret value=#{orderPaypalIPN.secret} /
/f:metadata{code}
In the code:{code}
@Named(orderPaypalIPN)
@RequestScoped
public class OrderPaypalIPNHandler {
private String secret;
public Long getSecret() { //***TYPO: LONG INSTEAD OF STRING***
return null; //security reason
}
public void setSecret(String secret) {
this.secret = secret;
}
{code}
So, when we were using Seam, secret was correctly set, then used by the rest
of the code. When we started using DeltaSpike instead, secret was not set
anymore (even though the issue was with the getter, not the setter). I'm OK
with it (more strict, better), except that the get/set discrepancy is not
logged. I think it should be.
GET request parameter silently discarded upon type discrepancy with JSF
---
Key: DELTASPIKE-768
URL: https://issues.apache.org/jira/browse/DELTASPIKE-768
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 1.0.3
Environment: Glassfish 3.1.2.2, JSF 2.1.28, Weld 1.1.14, Richfaces,
Rewrite
Reporter: Fabien MARSAUD
Priority: Minor
Labels: jsf, parameter, request
I have a request scoped managed bean which receives paypal IPN notifications.
IPNs contain a shared secret String parameter transferred as a http GET
param.
I had a correct setSecret(String) on my backing bean, but because of a bad 5
year-old copy/paste, I had the wrong return type on getSecret(). It was never
noticed because the *getter* was never called anywhere, and with Seam we used
until our previous release , secret was *set* without complaining anyway.
On the page: {code}
f:metadata
f:viewParam name=secret value=#{orderPaypalIPN.secret} /
/f:metadata{code}
In the code:{code}
@Named(orderPaypalIPN)
@RequestScoped
public class OrderPaypalIPNHandler {
private String secret;
//getter needed by JSF2
public Long getSecret() { //***TYPO: LONG INSTEAD OF STRING***
return null; //security reason
}
public void setSecret(String secret) {
this.secret = secret;
}
{code}
So, when we were using Seam, secret was correctly set, then used by the
rest of the code. When we started using DeltaSpike instead, secret was not
set anymore (even though the issue was with the getter, not the setter). I'm
OK with it (more strict, better), except that the get/set discrepancy is not
logged. I think it should be.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
