[jira] [Commented] (DELTASPIKE-674) Possible regression due to changes in ConfigResolver

[Sven Panko (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083020#comment-14083020
 ] 

Sven Panko commented on DELTASPIKE-674:
---

Hmmm, the ConfigPropertyEARTest doesn't seem to pick up any of the changes I 
made. I will investigate this further.

> 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
>
>
> 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 docs plan - About documentation format

[Rafael Benevides]

As talked with Gerhard.

The reasons to use asciidoc are because  it's easily exportable to PDF, 
HTML, and it's also easy to contribute. It can be used to export also to 
epub and It can be used to write books...


Em 8/1/14, 13:46, Rafael Benevides escreveu:

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.

- The documentation location: Recommendation to be out of the site source.
- The documentation format: Suggested to use asciidoc.

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

Red Hat

Better technology. Faster innovation. Powered by community collaboration.
See how it works at www.redhat.com 

LinkedIn  Youtube 

[jira] [Commented] (DELTASPIKE-674) Possible regression due to changes in ConfigResolver

[Rafael Benevides (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14082624#comment-14082624
 ] 

Rafael Benevides commented on DELTASPIKE-674:
-

Hi [~spanko] I tryied yout patch but it failed on the tests with `mvn clean 
install -Pwildfly-build-managed` and also for other containers. My application 
example that I used to dignose the issue (which is basically similar to your 
code) also fails to resolve the properties. Can you check that, please ?

> 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
>
>
> 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)

DeltaSpike docs plan

[Rafael Benevides]

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.

- The documentation location: Recommendation to be out of the site source.
- The documentation format: Suggested to use asciidoc.

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

Red Hat

Better technology. Faster innovation. Powered by community collaboration.
See how it works at www.redhat.com 

LinkedIn  Youtube 

DeltaSpike docs plan

[Rafael Benevides]

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.

- The documentation location: Recommendation to be out of the site source.
- The documentation format: Suggested to use asciidoc.

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

Red Hat

Better technology. Faster innovation. Powered by community collaboration.
See how it works at www.redhat.com 

LinkedIn  Youtube 

[jira] [Updated] (DELTASPIKE-674) Possible regression due to changes in ConfigResolver

[Sven Panko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sven Panko updated DELTASPIKE-674:
--

Attachment: diff_DELTASPIKE-674

> 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
>
>
> 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)

[jira] [Updated] (DELTASPIKE-674) Possible regression due to changes in ConfigResolver

[Sven Panko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sven Panko updated DELTASPIKE-674:
--

Attachment: patch_DELTASPIKE-674

John, first of all many thanks for your explanation. I agree that serving all 
party guests is cumbersome and tedious to say the least ;)

Since I had a real problem at hand now and didn't want to add all of my EJB 
jars as a dependency to the EAR I took your idea to derive the classloader to 
use for property lookup from the injection point and patched a few classes in 
the core component. The result is that I now resolve every property using the 
classloader that is responsible for loading the class that contains the 
ConfigProperty annotation, which is exactly what I needed. I also added a 
fallback if I don't specify a classloader, so that it reverts to the current 
mechanism (ConfigResolver.class.getClassLoader()). I attached my solution to 
this issue.

I would be delighted if my changes find its way into the project, but I am also 
aware that it might need more testing - I only tested it in my scenario. All of 
the existing unit tests work as expected of course.

> 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
>
> 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)

[jira] [Updated] (DELTASPIKE-674) Possible regression due to changes in ConfigResolver

[Sven Panko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sven Panko updated DELTASPIKE-674:
--

Attachment: (was: patch_DELTASPIKE-674)

> 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
>
> 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)

[jira] [Commented] (DELTASPIKE-679) NPE in BeanManagerProvider if parentClassLoader is null

[Sven Panko (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14082087#comment-14082087
 ] 

Sven Panko commented on DELTASPIKE-679:
---

Hey Christian,

works as expected now, thank you!

> NPE in BeanManagerProvider if parentClassLoader is null
> ---
>
> Key: DELTASPIKE-679
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-679
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.0, 1.0.1
> Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1
>Reporter: Sven Panko
>Assignee: Christian Kaltepoth
> Fix For: 1.0.2
>
>
> I am encountering an NPE  in BeanManagerProvider.getParentBeanManagerInfo() 
> if the parentClassLoader is null. In my scenario I had to add Wildfly's 
> jboss-modules.jar to the JVM's bootclasspath (using 
> -Xbootclasspath/a:"jboss-modules.jar"). It seems as if this causes the 
> parentClassLoader returned by the first statement to be null, which causes an 
> NPE in the following if-statement (see below). I patched my local 
> installation and added a check for parentClassLoader == null and everything 
> works as expected now.
> I am honestly not 100% sure why classLoader.getParent() returns null and why 
> this only happens if I put the jboss-modules.jar on the bootclasspath, but 
> unfortunately I have to do this to circumvent a JAXP problem (see 
> https://community.jboss.org/thread/171177). 
> In addition to that I am not sure whether this is actually related to the 
> message "When using the BeanManager to retrieve Beans before the Container is 
> started, non-portable behaviour results!" At first I thought this occurred 
> because of @Startup I placed on some of my singleton EJBs, but even after 
> removing the startup annotation and using a timer to trigger initialization 
> of some classes, I still get this message (and my container is fully booted 
> at that time). 
> Source:
> {code:java}
> private BeanManagerInfo getParentBeanManagerInfo(ClassLoader classLoader)
> {
> ClassLoader parentClassLoader = classLoader.getParent();
> if (parentClassLoader.equals(ClassLoader.getSystemClassLoader()))
> {
> return null;
> }
> BeanManagerInfo bmi = getBeanManagerInfo(parentClassLoader);
> if (bmi == null)
> {
> bmi = getParentBeanManagerInfo(parentClassLoader);
> }
> return bmi;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)