[jira] [Comment Edited] (DELTASPIKE-674) Possible regression due to changes in ConfigResolver
[
https://issues.apache.org/jira/browse/DELTASPIKE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14086008#comment-14086008
]
Sven Panko edited comment on DELTASPIKE-674 at 8/5/14 8:48 AM:
---
Ok, I found the problem. It is caused by the
ConfigurationExtension.registerUserConfigSources() method. This method collects
all PropertyFileConfig implementations and adds them programmatically to the
(automatically detected) config sources via ConfigResolver.addConfigSources().
Since classloader information is lost at that point, the addConfigSources()
method has no way to determine which bundle originally provided the config
sources and uses the classloader of the ConfigResolver class to add the config
source. Later on the lookup will be done using the bundle's classloader, which
of course will fail.
I fixed this by letting ConfigurationExtension.registerUserConfigSources() call
a newly created ConfigResolver.addConfigSources() method that expects a Map as
input, using the classloader of the PropertyFileConfig as the key and the
resolved sources as the value.
{{diff_DELTASPIKE-674_update1}} contains all changes from
{{diff_DELTASPIKE-674}} and the aforementioned bugfix.
There is one caveat, though. This fix must be considered invasive, because the
original ConfigResolver.addConfigSources() method cannot be fixed to
incorporate the correct classloader lookup. At the least it should be
deprecated if my changes will be applied, because in the future it should not
be used by extension developers.
Additionally I only tested it using John's wildfly-build-managed profile, I
don't know whether other profiles cause problems here as well.
was (Author: spanko):
Ok, I found the problem. It is caused by the
ConfigurationExtension.registerUserConfigSources() method. This method collects
all PropertyFileConfig implementations and adds them programmatically to the
(automatically detected) config sources via ConfigResolver.addConfigSources().
Since classloader information is lost at that point, the addConfigSources()
method has no way to determine which bundle originally provided the config
sources and uses the classloader of the ConfigResolver class to add the config
source. Later on the lookup will be done using the bundle's classloader, which
of course will fail.
I fixed this by letting ConfigurationExtension.registerUserConfigSources() call
a newly created ConfigResolver.addConfigSources() method that expects a Map as
input, using the classloader of the PropertyFileConfig as the key and the
resolved sources as the value.
{{diff_DELTASPIKE-674_update1}} contains all changes from
{{diff_DELTASPIKE-674}} and the aforementioned bugfix.
There is one caveat, though. This fix must be considered invasive, because the
original ConfigResolver.addConfigSources() method cannot be fixed to
incorporate the correct classloader lookup. At the least it should be
deprecated if my changes will be applied, because in the future it should not
be used by extension developers.
Possible regression due to changes in ConfigResolver
Key: DELTASPIKE-674
URL: https://issues.apache.org/jira/browse/DELTASPIKE-674
Project: DeltaSpike
Issue Type: Bug
Components: Core
Affects Versions: 1.0.1
Environment: Java 1.7.45, Mac OS X 10.9, Wildfly 8.1
Reporter: Sven Panko
Assignee: Rafael Benevides
Attachments: diff_DELTASPIKE-674, diff_DELTASPIKE-674_update1
I just upgraded from 1.0.0 to 1.0.1 to see the fix in DELTASPIKE-648 in
action. The problem now is: my property files are not picked up at all (I
described my workaround in DELTASPIKE-648). I debugged the code to see that
the changes are now in fact loading everything with the EAR classloader, but
this loader fails to see my custom ConfigSourceProvider.
Important to note: an additional thing I changed between this issue and the
time I reported 648: I configured Wildfly to isolate supdeployments within an
EAR, which was previously disabled. 1.0.0 still correctly sees my property
files, but 1.0.1 does not. I haven't checked whether 1.0.1 picks up the files
if I revert back to the unisolated state.
My suspicion is that the EAR classloader does not see the
ConfigSourceProvider's inside the EJB jars. Since every lookup now uses this
classloader it will never see any such implementations unless they are part
of the global module that is comprised of the jars in the /lib directory of
the EAR.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: [DeltaSpike SHADOW] DeltaSpike docs plan
On 1 Aug 2014, at 17:46, Rafael Benevides benevi...@redhat.com wrote:
Hi all,
As you may known, Red Hat docs team was called to help on DeltaSpike docs.
After a long period, they have analyzed the documentation and bring us an
awesome plan that is available here:
https://docs.google.com/document/d/186f_amQ9XuREq8FcO7orxvOjQZtvEEYa7WPj1e8p8bM/edit#heading=h.4sqhyz68wgg2
The document is opened for comments.
Something that was also discussed not only inside Red Hat but with some
community members is about the format and source of the documentation. I
strongly believe that we should have the documentation somewhere else but the
DS site source. It could improve the ease to the community to contribute with
it. Having said that, it's also suggested that we should use asciidoc as
documentation format.
So what we have until now ?
- The documentation plan to be reviewed and approved by the DS community.
Then we can talk about the plans to make it happen.
+1 for the content changes, whatever else. This is the most important thing for
the wider community IMO.
- The documentation location: Recommendation to be out of the site source.
This would be nice. It can then be imported by e.g. an svn submodule or git
checkout as part of the site build
- The documentation format: Suggested to use asciidoc.
+1 asciidoc is really nice, it allows you do a lot of stuff you would like to
do in markdown (e.g. tables) but can’t without non-standard extensions.
Please, read the plan and lets discuss about these 3 topics individually.
Michelle Murray (whose team provided the plan and she is copied on this
Thread) can follow the feedback.
--
Rafael Benevides | Senior Software Engineer
JBoss Developer
M: +55-61-9269-6576
{a8aabf3a-4467-4e37-9bc5-48b1d7b494a2}_LATAM_RedHat.jpg
Better technology. Faster innovation. Powered by community collaboration.
See how it works at www.redhat.com
linkedin.png youtube.png
[jira] [Created] (DELTASPIKE-681) Handling AccessDeniedException will run the secured method
Gabor Kaposi created DELTASPIKE-681:
---
Summary: Handling AccessDeniedException will run the secured method
Key: DELTASPIKE-681
URL: https://issues.apache.org/jira/browse/DELTASPIKE-681
Project: DeltaSpike
Issue Type: Bug
Components: Core, Security-Module
Affects Versions: 1.0.1
Reporter: Gabor Kaposi
I'm using DeltaSpike Security Module together with Picketlink. I created an
annotation:
@Retention(value = RetentionPolicy.RUNTIME)
@Target({ ElementType.TYPE, ElementType.METHOD })
@Documented
@SecurityBindingType
public @interface Admin { }
Created an authorizer method:
@Secures
@Admin
public boolean doSecuredCheck(InvocationContext invocationContext, BeanManager
manager) throws Exception {
return false; //Nobody is an admin!
}
An created a secured method:
@Admin
public void test() {
System.out.println(in method);
}
So far this works fine, the method will not run when invoked from a
h:commandButton, because the authorizer method returns false. An
AccessDeniedException is thrown which will be displayed on the error page. It
is very ugly.
I wanted to handle the exception gracefully, so I created an exception handler:
void printExceptions(@Handles ExceptionEventAccessDeniedException evt) {
FacesContext.getCurrentInstance().addMessage(null, new
FacesMessage(You have no access!));
}
The exception handler is being called, no ugly error page, and I can see the
You have no access! message appearing on the page.
Hovewer I can also see this in the console:
in method
So handling the exception caused to secured method to actually run!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (DELTASPIKE-681) Handling AccessDeniedException will run the secured method
[
https://issues.apache.org/jira/browse/DELTASPIKE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-681:
Priority: Minor (was: Major)
@gabor:
i agree with you that it should be that way.
in fact it works as designed (which is not intuitive imo).
once you have a handler, the corresponding exception is handled/consumed and
everything continues as usual.
what you are trying to do is to just observe an exception.
that's currently just supported by @Secured (with that it works and you just
have to care about DELTASPIKE-637).
Handling AccessDeniedException will run the secured method
--
Key: DELTASPIKE-681
URL: https://issues.apache.org/jira/browse/DELTASPIKE-681
Project: DeltaSpike
Issue Type: Bug
Components: Core, Security-Module
Affects Versions: 1.0.1
Reporter: Gabor K
Priority: Minor
I'm using DeltaSpike Security Module together with Picketlink. I created an
annotation:
@Retention(value = RetentionPolicy.RUNTIME)
@Target({ ElementType.TYPE, ElementType.METHOD })
@Documented
@SecurityBindingType
public @interface Admin { }
Created an authorizer method:
@Secures
@Admin
public boolean doSecuredCheck(InvocationContext invocationContext,
BeanManager manager) throws Exception {
return false; //Nobody is an admin!
}
An created a secured method:
@Admin
public void test() {
System.out.println(in method);
}
So far this works fine, the method will not run when invoked from a
h:commandButton, because the authorizer method returns false. An
AccessDeniedException is thrown which will be displayed on the error page. It
is very ugly.
I wanted to handle the exception gracefully, so I created an exception
handler:
void printExceptions(@Handles ExceptionEventAccessDeniedException evt) {
FacesContext.getCurrentInstance().addMessage(null, new
FacesMessage(You have no access!));
}
The exception handler is being called, no ugly error page, and I can see the
You have no access! message appearing on the page.
Hovewer I can also see this in the console:
in method
So handling the exception caused to secured method to actually run!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
first steps for the next release
hi @ all, if there are no objections, i will start with the first steps for the next release (v1.0.2) by the end of next week. regards, gerhard
[jira] [Resolved] (DELTASPIKE-681) Handling AccessDeniedException will run the secured method
[
https://issues.apache.org/jira/browse/DELTASPIKE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek resolved DELTASPIKE-681.
-
Resolution: Fixed
Fix Version/s: 1.0.2
i aligned the handling. now both (@Secures and @Secured) handle it the same way
(like in v1.0.0)
Handling AccessDeniedException will run the secured method
--
Key: DELTASPIKE-681
URL: https://issues.apache.org/jira/browse/DELTASPIKE-681
Project: DeltaSpike
Issue Type: Bug
Components: Core, Security-Module
Affects Versions: 1.0.1
Reporter: Gabor K
Priority: Minor
Fix For: 1.0.2
Attachments: DELTASPIKE-681.patch
I'm using DeltaSpike Security Module together with Picketlink. I created an
annotation:
@Retention(value = RetentionPolicy.RUNTIME)
@Target({ ElementType.TYPE, ElementType.METHOD })
@Documented
@SecurityBindingType
public @interface Admin { }
Created an authorizer method:
@Secures
@Admin
public boolean doSecuredCheck(InvocationContext invocationContext,
BeanManager manager) throws Exception {
return false; //Nobody is an admin!
}
An created a secured method:
@Admin
public void test() {
System.out.println(in method);
}
So far this works fine, the method will not run when invoked from a
h:commandButton, because the authorizer method returns false. An
AccessDeniedException is thrown which will be displayed on the error page. It
is very ugly.
I wanted to handle the exception gracefully, so I created an exception
handler:
void printExceptions(@Handles ExceptionEventAccessDeniedException evt) {
FacesContext.getCurrentInstance().addMessage(null, new
FacesMessage(You have no access!));
}
The exception handler is being called, no ugly error page, and I can see the
You have no access! message appearing on the page.
Hovewer I can also see this in the console:
in method
So handling the exception caused to secured method to actually run!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DELTASPIKE-665) Add utility method to always get new context control.
[ https://issues.apache.org/jira/browse/DELTASPIKE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14087127#comment-14087127 ] John D. Ament commented on DELTASPIKE-665: -- I think I've found the pattern. Anytime the caller is using some kind of thread pool, this issue pops up. When you use manually created threads, the current approach works fine. I'm not sure the differences yet, but it seems to be mostly used by servlet containers, which makes sense based on IO workers. Add utility method to always get new context control. - Key: DELTASPIKE-665 URL: https://issues.apache.org/jira/browse/DELTASPIKE-665 Project: DeltaSpike Issue Type: Improvement Components: CdiControl Affects Versions: 1.0.0 Reporter: John D. Ament Assignee: John D. Ament Fix For: 1.0.2 While working on DELTASPIKE-653 I got tripped up on the fact that the context controller returned by the CdiContainer is one specific to the container object. Ideally, if we expect the SE features to be available without core, we should add a method to the container that always gives back a new instance of the controller. Certainlly, internally the controller can be used by the container to start the primary contexts, but for consumers we need to manually start a context. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-665) Add utility method to always get new context control.
[ https://issues.apache.org/jira/browse/DELTASPIKE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament resolved DELTASPIKE-665. -- Resolution: Fixed Added utility method. Add utility method to always get new context control. - Key: DELTASPIKE-665 URL: https://issues.apache.org/jira/browse/DELTASPIKE-665 Project: DeltaSpike Issue Type: Improvement Components: CdiControl Affects Versions: 1.0.0 Reporter: John D. Ament Assignee: John D. Ament Fix For: 1.0.2 While working on DELTASPIKE-653 I got tripped up on the fact that the context controller returned by the CdiContainer is one specific to the container object. Ideally, if we expect the SE features to be available without core, we should add a method to the container that always gives back a new instance of the controller. Certainlly, internally the controller can be used by the container to start the primary contexts, but for consumers we need to manually start a context. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-653) Provide a platform inspecific servlet listener
[ https://issues.apache.org/jira/browse/DELTASPIKE-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament resolved DELTASPIKE-653. -- Resolution: Fixed Provide a platform inspecific servlet listener -- Key: DELTASPIKE-653 URL: https://issues.apache.org/jira/browse/DELTASPIKE-653 Project: DeltaSpike Issue Type: Improvement Components: Servlet-Module Affects Versions: 1.0.0 Reporter: John D. Ament Assignee: John D. Ament Fix For: 1.0.2 Provide a servlet request listener, similar to the ones provided by Weld and OWB, except that it uses our context controller to start various requested contexts. This is meant to be platform inspecific. you can set a filter init param deltaspike.servlet.start.contexts to indicate which contexts to start when a request comes in. By default it will start a RequestScope, but others may be configured if so chosen. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-666) Improve BeanManager consistency
[ https://issues.apache.org/jira/browse/DELTASPIKE-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament resolved DELTASPIKE-666. -- Resolution: Fixed Improve BeanManager consistency --- Key: DELTASPIKE-666 URL: https://issues.apache.org/jira/browse/DELTASPIKE-666 Project: DeltaSpike Issue Type: Improvement Components: CdiControl Affects Versions: 1.0.0 Reporter: John D. Ament Assignee: John D. Ament Fix For: 1.0.2 Currently, looking at the OWB, OpenEJB and Weld implementations, the use of beanManager and getBeanManager() is not consistent. They should all use beanManager which has already been retrieved. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: first steps for the next release
+1 On Tue, Aug 5, 2014 at 5:24 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, if there are no objections, i will start with the first steps for the next release (v1.0.2) by the end of next week. regards, gerhard
Re: first steps for the next release
+1 2014-08-06 4:27 GMT+02:00 John D. Ament john.d.am...@gmail.com: +1 On Tue, Aug 5, 2014 at 5:24 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, if there are no objections, i will start with the first steps for the next release (v1.0.2) by the end of next week. regards, gerhard -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
