Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi, 1. All classes in org.apache.myfaces.spi. I did not change anything here, just internal imports (from *.spi.impl to *.spi.util)! 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. Geronimo (for which we did the SPI stuff) includes MyFaces 2.0.x. Here we are talking about 2.1.x. Furthermore, one call to organize imports does the trick, so I do not see a problem here. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can add methods there, but relocate this package to org.apache.myfaces.spi.data is not necessary. I think the package name is correct. OK, fine. I thought the relocation to org.apache.myfaces.spi.* would fit better, since it is the myfaces-spi module and, again, since we're talking about 2.1.x, not 2.0.x here. But if you want to keep the package-name, I have no problem with that. org.apache.myfaces.config.element is fine too, however, you may not expect it to be in the myfaces-spi module. [...] Considering this, I think the costs involved on the changes proposed are too big compared with the benefits, which are very limited and almost inexistent from user point of view. From a user point of view: maybe yes. But from a developer point of view myfaces-shaded-impl is an epic fail. I know it was an easy an fast solution at the time we got 2.1.0 out, but for the long term this has to be changed. Please think about it, you use 2.0.5 (or any other _previous_ version) in myfaces-impl-ee6 as if it was 2.1.x-SNAPSHOT. Thus you use internals of previous versions which might not even be there anymore in the current 2.1.x-SNAPSHOT. And the worst part of it: you don't even see it at build time, b/c it's a separate module and myfaces-impl-ee6 is shaded into myfaces-impl (and shade does not warn about this kind of stuff, of course). Considering this, it was ok to create shaded-impl in order to get the 2.1.0 release out, but for future releases (maybe also towards 2.2.0), this must be done in another way. I have to say that I won't support a 2.1.2 release including the shaded-impl module. Regards, Jakob 2011/7/10 Leonardo Uribe lu4...@gmail.com: Hi Gerhard Ok, in theory the parts that we should not change, or otherwise that will trigger a change on JEE containers are: 1. All classes in org.apache.myfaces.spi. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can add methods there, but relocate this package to org.apache.myfaces.spi.data is not necessary. I think the package name is correct. regards, Leonardo Uribe 2011/7/9 Gerhard Petracek gerhard.petra...@gmail.com: hi leo, thx for checking it. it would be great, if you can post a list of parts (not classes) which would break. so we can discuss this topic in a more concrete manner. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/10 Leonardo Uribe lu4...@gmail.com Hi Good to know that. Unfortunately, do a change on the spi related classes will break existing integration code with containers like Geronimo, JBoss and others too. Considering this, I think the costs involved on the changes proposed are too big compared with the benefits, which are very limited and almost inexistent from user point of view. regards, Leonardo Uribe 2011/7/8 Werner Punz werner.p...@gmail.com: I have no problem if you break Ext-Script, after all I program against the impl, so whatever change you do I have to patch it in my codebase anyway. Don´t feel stopped by it. Werner Am 08.07.11 18:27, schrieb Gerhard Petracek: hi, thx for reviewing the changes. for sure we can discuss when we are going to do such changes. however, if ext-script is the only reason against it, we can do it right now imo. there is no problem with shipping a small update of ext-script and the user base is currently small enough to communicate this change easily. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com Hi In principle I agree with this change, but after a quick patch review I saw some package
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, 1. All classes in org.apache.myfaces.spi. I did not change anything here, just internal imports (from *.spi.impl to *.spi.util)! It is questionable to create .spi.util. After all, it is not supposed that package be consumed by container integration code, so it should be on spi.impl. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. Geronimo (for which we did the SPI stuff) includes MyFaces 2.0.x. Here we are talking about 2.1.x. Furthermore, one call to organize imports does the trick, so I do not see a problem here. Look the page of JSR-314 spec http://www.jcp.org/en/jsr/summary?id=314 You will notice 2.1.x is not a new JSR like the future JSR-344 (JSF 2.2), and instead is tagged as Maintenance Release 2. So, to be consistent, it should be possible to change between 2.0 and 2.1 on the same server. That's the most important reason to be so conservative or strict with 2.1. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can add methods there, but relocate this package to org.apache.myfaces.spi.data is not necessary. I think the package name is correct. OK, fine. I thought the relocation to org.apache.myfaces.spi.* would fit better, since it is the myfaces-spi module and, again, since we're talking about 2.1.x, not 2.0.x here. But if you want to keep the package-name, I have no problem with that. org.apache.myfaces.config.element is fine too, however, you may not expect it to be in the myfaces-spi module. [...] Considering this, I think the costs involved on the changes proposed are too big compared with the benefits, which are very limited and almost inexistent from user point of view. From a user point of view: maybe yes. But from a developer point of view myfaces-shaded-impl is an epic fail. I know it was an easy an fast solution at the time we got 2.1.0 out, but for the long term this has to be changed. Please think about it, you use 2.0.5 (or any other _previous_ version) in myfaces-impl-ee6 as if it was 2.1.x-SNAPSHOT. Thus you use internals of previous versions which might not even be there anymore in the current 2.1.x-SNAPSHOT. And the worst part of it: you don't even see it at build time, b/c it's a separate module and myfaces-impl-ee6 is shaded into myfaces-impl (and shade does not warn about this kind of stuff, of course). I know the hack done to compile 2.1 is not very clean, but it works. The idea is replace 2.0.5 ref with 2.1.0 in future versions. Note myfaces-shaded-impl is a module that is just for allow compile myfaces-impl-ee6, and nobody else. It is not an epic fail, because it does not cause any changes on the code that cause problems. Considering this, it was ok to create shaded-impl in order to get the 2.1.0 release out, but for future releases (maybe also towards 2.2.0), this must be done in another way. In fact, the idea is do something in 2.2.x, but that will take some time, so maybe we can keep in mind those changes until get there. I have to say that I won't support a 2.1.2 release including the shaded-impl module. I hope my arguments could be enough to convince you about the opposite. regards , Leonardo Uribe Regards, Jakob 2011/7/10 Leonardo Uribe lu4...@gmail.com: Hi Gerhard Ok, in theory the parts that we should not change, or otherwise that will trigger a change on JEE containers are: 1. All classes in org.apache.myfaces.spi. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can add methods there, but relocate this package to org.apache.myfaces.spi.data is not necessary. I think the package name is correct. regards, Leonardo Uribe 2011/7/9 Gerhard Petracek gerhard.petra...@gmail.com: hi leo, thx for checking it. it would be great, if you can post a list of parts (not classes) which would break. so we can discuss this topic in a more concrete manner. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/10 Leonardo Uribe lu4...@gmail.com Hi Good to know that. Unfortunately, do a change on the spi related classes will break existing integration code with containers like Geronimo, JBoss and others too. Considering this, I think the costs
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi, No, sorry Leo, they are not enough. Frankly, I don't understand why you are blocking this solution. It is easy, it does not break anything (if we do not change the package names), it is a lot more clean and we can get rid of the shaded-impl module. If we don't do this now, we will maybe have to use this ugly module for a long time.. And yes: in my opinion it is an epic fail. If you think otherwise, that's ok, but just because you say so and I don't does not make your statement true. I think we have to start a vote for this one just like we did with the resource-handler stuff. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, 1. All classes in org.apache.myfaces.spi. I did not change anything here, just internal imports (from *.spi.impl to *.spi.util)! It is questionable to create .spi.util. After all, it is not supposed that package be consumed by container integration code, so it should be on spi.impl. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. Geronimo (for which we did the SPI stuff) includes MyFaces 2.0.x. Here we are talking about 2.1.x. Furthermore, one call to organize imports does the trick, so I do not see a problem here. Look the page of JSR-314 spec http://www.jcp.org/en/jsr/summary?id=314 You will notice 2.1.x is not a new JSR like the future JSR-344 (JSF 2.2), and instead is tagged as Maintenance Release 2. So, to be consistent, it should be possible to change between 2.0 and 2.1 on the same server. That's the most important reason to be so conservative or strict with 2.1. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can add methods there, but relocate this package to org.apache.myfaces.spi.data is not necessary. I think the package name is correct. OK, fine. I thought the relocation to org.apache.myfaces.spi.* would fit better, since it is the myfaces-spi module and, again, since we're talking about 2.1.x, not 2.0.x here. But if you want to keep the package-name, I have no problem with that. org.apache.myfaces.config.element is fine too, however, you may not expect it to be in the myfaces-spi module. [...] Considering this, I think the costs involved on the changes proposed are too big compared with the benefits, which are very limited and almost inexistent from user point of view. From a user point of view: maybe yes. But from a developer point of view myfaces-shaded-impl is an epic fail. I know it was an easy an fast solution at the time we got 2.1.0 out, but for the long term this has to be changed. Please think about it, you use 2.0.5 (or any other _previous_ version) in myfaces-impl-ee6 as if it was 2.1.x-SNAPSHOT. Thus you use internals of previous versions which might not even be there anymore in the current 2.1.x-SNAPSHOT. And the worst part of it: you don't even see it at build time, b/c it's a separate module and myfaces-impl-ee6 is shaded into myfaces-impl (and shade does not warn about this kind of stuff, of course). I know the hack done to compile 2.1 is not very clean, but it works. The idea is replace 2.0.5 ref with 2.1.0 in future versions. Note myfaces-shaded-impl is a module that is just for allow compile myfaces-impl-ee6, and nobody else. It is not an epic fail, because it does not cause any changes on the code that cause problems. Considering this, it was ok to create shaded-impl in order to get the 2.1.0 release out, but for future releases (maybe also towards 2.2.0), this must be done in another way. In fact, the idea is do something in 2.2.x, but that will take some time, so maybe we can keep in mind those changes until get there. I have to say that I won't support a 2.1.2 release including the shaded-impl module. I hope my arguments could be enough to convince you about the opposite. regards , Leonardo Uribe Regards, Jakob 2011/7/10 Leonardo Uribe lu4...@gmail.com: Hi Gerhard Ok, in theory the parts that we should not change, or otherwise that will trigger a change on JEE containers are: 1. All classes in org.apache.myfaces.spi. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can add methods there, but relocate this package to org.apache.myfaces.spi.data is not necessary. I think the package name is correct. regards,
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi I'll be clear and direct. What makes statements true or false are the reasons behind it. Until this moment, you are not question the reasons behind the reasoning proposed. To be short, my argumentation is we can't change for now: 1. Everything inside org.apache.myfaces.spi 2. LifecycleProvided 3. Everything inside org.apache.myfaces.config.element because JSF 2.1 is a maintenance release (not a mayor release) which already has it first version (but even without a version). Do that will create bugs on server integration code. The problem is there is no way to detect such changes or create a proper patch from the server side point of view without use some ugly reflection code and that really s...cks!. Let it to JSF 2.2 (which is another JSR) sounds better because in that time I think we can get rid of implee6 too in one move!. In that version, just change the poms, and move all code to impl and that's it. In conclusion, here we have a technical restriction that doesn't allow us to move further, so we can't really make a vote because there is no decision to make, we just can't change the code!. The idea of an API in impl module is precisely make the promise that we will be nice and do not change that stuff until the next major version. Unfortunately there is nothing we can do in 2.1.x branch. regards, Leonardo Uribe 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, No, sorry Leo, they are not enough. Frankly, I don't understand why you are blocking this solution. It is easy, it does not break anything (if we do not change the package names), it is a lot more clean and we can get rid of the shaded-impl module. If we don't do this now, we will maybe have to use this ugly module for a long time.. And yes: in my opinion it is an epic fail. If you think otherwise, that's ok, but just because you say so and I don't does not make your statement true. I think we have to start a vote for this one just like we did with the resource-handler stuff. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, 1. All classes in org.apache.myfaces.spi. I did not change anything here, just internal imports (from *.spi.impl to *.spi.util)! It is questionable to create .spi.util. After all, it is not supposed that package be consumed by container integration code, so it should be on spi.impl. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. Geronimo (for which we did the SPI stuff) includes MyFaces 2.0.x. Here we are talking about 2.1.x. Furthermore, one call to organize imports does the trick, so I do not see a problem here. Look the page of JSR-314 spec http://www.jcp.org/en/jsr/summary?id=314 You will notice 2.1.x is not a new JSR like the future JSR-344 (JSF 2.2), and instead is tagged as Maintenance Release 2. So, to be consistent, it should be possible to change between 2.0 and 2.1 on the same server. That's the most important reason to be so conservative or strict with 2.1. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can add methods there, but relocate this package to org.apache.myfaces.spi.data is not necessary. I think the package name is correct. OK, fine. I thought the relocation to org.apache.myfaces.spi.* would fit better, since it is the myfaces-spi module and, again, since we're talking about 2.1.x, not 2.0.x here. But if you want to keep the package-name, I have no problem with that. org.apache.myfaces.config.element is fine too, however, you may not expect it to be in the myfaces-spi module. [...] Considering this, I think the costs involved on the changes proposed are too big compared with the benefits, which are very limited and almost inexistent from user point of view. From a user point of view: maybe yes. But from a developer point of view myfaces-shaded-impl is an epic fail. I know it was an easy an fast solution at the time we got 2.1.0 out, but for the long term this has to be changed. Please think about it, you use 2.0.5 (or any other _previous_ version) in myfaces-impl-ee6 as if it was 2.1.x-SNAPSHOT. Thus you use internals of previous versions which might not even be there anymore in the current 2.1.x-SNAPSHOT. And the worst part of it: you don't even see it at build time, b/c it's a separate module and myfaces-impl-ee6 is shaded into myfaces-impl (and shade does not warn about this kind of stuff, of course). I know the hack done to compile 2.1 is not very clean, but it works. The idea is replace 2.0.5 ref with 2.1.0 in future versions. Note myfaces-shaded-impl is a module that is just for allow compile myfaces-impl-ee6, and nobody
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi, Leo, I really get your point that we can't change this stuff. Changing SPI stuff (even just renaming packages) will break application server integation code, we all got it now.. That's why I suggested (a few mails ago, but unfortunately too vague) keeping the package names *.spi, *.spi.impl and *.config.element as is, but still moving *.spi and *.config.element to a new module called myfaces-spi. This alone will let us be able to remove shaded-impl, no code change is actually required, just moving some classes from myfaces-impl into myfaces-spi. In the end (-- the myfaces-impl jar), it will all be back in myfaces-impl again, because of shade. I will provide a new patch by tomorrow and then start a vote for it. There really is no technical reason for not committing such a solution at this point. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi I'll be clear and direct. What makes statements true or false are the reasons behind it. Until this moment, you are not question the reasons behind the reasoning proposed. To be short, my argumentation is we can't change for now: 1. Everything inside org.apache.myfaces.spi 2. LifecycleProvided 3. Everything inside org.apache.myfaces.config.element because JSF 2.1 is a maintenance release (not a mayor release) which already has it first version (but even without a version). Do that will create bugs on server integration code. The problem is there is no way to detect such changes or create a proper patch from the server side point of view without use some ugly reflection code and that really s...cks!. Let it to JSF 2.2 (which is another JSR) sounds better because in that time I think we can get rid of implee6 too in one move!. In that version, just change the poms, and move all code to impl and that's it. In conclusion, here we have a technical restriction that doesn't allow us to move further, so we can't really make a vote because there is no decision to make, we just can't change the code!. The idea of an API in impl module is precisely make the promise that we will be nice and do not change that stuff until the next major version. Unfortunately there is nothing we can do in 2.1.x branch. regards, Leonardo Uribe 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, No, sorry Leo, they are not enough. Frankly, I don't understand why you are blocking this solution. It is easy, it does not break anything (if we do not change the package names), it is a lot more clean and we can get rid of the shaded-impl module. If we don't do this now, we will maybe have to use this ugly module for a long time.. And yes: in my opinion it is an epic fail. If you think otherwise, that's ok, but just because you say so and I don't does not make your statement true. I think we have to start a vote for this one just like we did with the resource-handler stuff. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, 1. All classes in org.apache.myfaces.spi. I did not change anything here, just internal imports (from *.spi.impl to *.spi.util)! It is questionable to create .spi.util. After all, it is not supposed that package be consumed by container integration code, so it should be on spi.impl. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. Geronimo (for which we did the SPI stuff) includes MyFaces 2.0.x. Here we are talking about 2.1.x. Furthermore, one call to organize imports does the trick, so I do not see a problem here. Look the page of JSR-314 spec http://www.jcp.org/en/jsr/summary?id=314 You will notice 2.1.x is not a new JSR like the future JSR-344 (JSF 2.2), and instead is tagged as Maintenance Release 2. So, to be consistent, it should be possible to change between 2.0 and 2.1 on the same server. That's the most important reason to be so conservative or strict with 2.1. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can add methods there, but relocate this package to org.apache.myfaces.spi.data is not necessary. I think the package name is correct. OK, fine. I thought the relocation to org.apache.myfaces.spi.* would fit better, since it is the myfaces-spi module and, again, since we're talking about 2.1.x, not 2.0.x here. But if you want to keep the package-name, I have no problem with that. org.apache.myfaces.config.element is fine too, however, you may not expect it to be in the myfaces-spi module. [...] Considering this, I think the costs involved on the changes proposed are too big compared with the benefits, which are very limited and almost inexistent from user point of view. From a
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
hi jakob, i suggest the same approach like before. last time leo requested some changes and had to start the vote (with a short description) and this time it's your turn. if you feel that we need a vote about it, please feel free to start one. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/11 Jakob Korherr jakob.korh...@gmail.com Hi, Leo, I really get your point that we can't change this stuff. Changing SPI stuff (even just renaming packages) will break application server integation code, we all got it now.. That's why I suggested (a few mails ago, but unfortunately too vague) keeping the package names *.spi, *.spi.impl and *.config.element as is, but still moving *.spi and *.config.element to a new module called myfaces-spi. This alone will let us be able to remove shaded-impl, no code change is actually required, just moving some classes from myfaces-impl into myfaces-spi. In the end (-- the myfaces-impl jar), it will all be back in myfaces-impl again, because of shade. I will provide a new patch by tomorrow and then start a vote for it. There really is no technical reason for not committing such a solution at this point. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi I'll be clear and direct. What makes statements true or false are the reasons behind it. Until this moment, you are not question the reasons behind the reasoning proposed. To be short, my argumentation is we can't change for now: 1. Everything inside org.apache.myfaces.spi 2. LifecycleProvided 3. Everything inside org.apache.myfaces.config.element because JSF 2.1 is a maintenance release (not a mayor release) which already has it first version (but even without a version). Do that will create bugs on server integration code. The problem is there is no way to detect such changes or create a proper patch from the server side point of view without use some ugly reflection code and that really s...cks!. Let it to JSF 2.2 (which is another JSR) sounds better because in that time I think we can get rid of implee6 too in one move!. In that version, just change the poms, and move all code to impl and that's it. In conclusion, here we have a technical restriction that doesn't allow us to move further, so we can't really make a vote because there is no decision to make, we just can't change the code!. The idea of an API in impl module is precisely make the promise that we will be nice and do not change that stuff until the next major version. Unfortunately there is nothing we can do in 2.1.x branch. regards, Leonardo Uribe 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, No, sorry Leo, they are not enough. Frankly, I don't understand why you are blocking this solution. It is easy, it does not break anything (if we do not change the package names), it is a lot more clean and we can get rid of the shaded-impl module. If we don't do this now, we will maybe have to use this ugly module for a long time.. And yes: in my opinion it is an epic fail. If you think otherwise, that's ok, but just because you say so and I don't does not make your statement true. I think we have to start a vote for this one just like we did with the resource-handler stuff. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, 1. All classes in org.apache.myfaces.spi. I did not change anything here, just internal imports (from *.spi.impl to *.spi.util)! It is questionable to create .spi.util. After all, it is not supposed that package be consumed by container integration code, so it should be on spi.impl. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. Geronimo (for which we did the SPI stuff) includes MyFaces 2.0.x. Here we are talking about 2.1.x. Furthermore, one call to organize imports does the trick, so I do not see a problem here. Look the page of JSR-314 spec http://www.jcp.org/en/jsr/summary?id=314 You will notice 2.1.x is not a new JSR like the future JSR-344 (JSF 2.2), and instead is tagged as Maintenance Release 2. So, to be consistent, it should be possible to change between 2.0 and 2.1 on the same server. That's the most important reason to be so conservative or strict with 2.1. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can add methods there, but relocate this package to org.apache.myfaces.spi.data is not necessary. I think the package name
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi Gerhard, OK, thx. Will do so! Regards, Jakob 2011/7/11 Gerhard Petracek gerhard.petra...@gmail.com: hi jakob, i suggest the same approach like before. last time leo requested some changes and had to start the vote (with a short description) and this time it's your turn. if you feel that we need a vote about it, please feel free to start one. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/11 Jakob Korherr jakob.korh...@gmail.com Hi, Leo, I really get your point that we can't change this stuff. Changing SPI stuff (even just renaming packages) will break application server integation code, we all got it now.. That's why I suggested (a few mails ago, but unfortunately too vague) keeping the package names *.spi, *.spi.impl and *.config.element as is, but still moving *.spi and *.config.element to a new module called myfaces-spi. This alone will let us be able to remove shaded-impl, no code change is actually required, just moving some classes from myfaces-impl into myfaces-spi. In the end (-- the myfaces-impl jar), it will all be back in myfaces-impl again, because of shade. I will provide a new patch by tomorrow and then start a vote for it. There really is no technical reason for not committing such a solution at this point. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi I'll be clear and direct. What makes statements true or false are the reasons behind it. Until this moment, you are not question the reasons behind the reasoning proposed. To be short, my argumentation is we can't change for now: 1. Everything inside org.apache.myfaces.spi 2. LifecycleProvided 3. Everything inside org.apache.myfaces.config.element because JSF 2.1 is a maintenance release (not a mayor release) which already has it first version (but even without a version). Do that will create bugs on server integration code. The problem is there is no way to detect such changes or create a proper patch from the server side point of view without use some ugly reflection code and that really s...cks!. Let it to JSF 2.2 (which is another JSR) sounds better because in that time I think we can get rid of implee6 too in one move!. In that version, just change the poms, and move all code to impl and that's it. In conclusion, here we have a technical restriction that doesn't allow us to move further, so we can't really make a vote because there is no decision to make, we just can't change the code!. The idea of an API in impl module is precisely make the promise that we will be nice and do not change that stuff until the next major version. Unfortunately there is nothing we can do in 2.1.x branch. regards, Leonardo Uribe 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, No, sorry Leo, they are not enough. Frankly, I don't understand why you are blocking this solution. It is easy, it does not break anything (if we do not change the package names), it is a lot more clean and we can get rid of the shaded-impl module. If we don't do this now, we will maybe have to use this ugly module for a long time.. And yes: in my opinion it is an epic fail. If you think otherwise, that's ok, but just because you say so and I don't does not make your statement true. I think we have to start a vote for this one just like we did with the resource-handler stuff. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, 1. All classes in org.apache.myfaces.spi. I did not change anything here, just internal imports (from *.spi.impl to *.spi.util)! It is questionable to create .spi.util. After all, it is not supposed that package be consumed by container integration code, so it should be on spi.impl. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. Geronimo (for which we did the SPI stuff) includes MyFaces 2.0.x. Here we are talking about 2.1.x. Furthermore, one call to organize imports does the trick, so I do not see a problem here. Look the page of JSR-314 spec http://www.jcp.org/en/jsr/summary?id=314 You will notice 2.1.x is not a new JSR like the future JSR-344 (JSF 2.2), and instead is tagged as Maintenance Release 2. So, to be consistent, it should be possible to change between 2.0 and 2.1 on the same server. That's the most important reason to be so conservative or strict with 2.1. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, Leo, I really get your point that we can't change this stuff. Changing SPI stuff (even just renaming packages) will break application server integation code, we all got it now.. That's why I suggested (a few mails ago, but unfortunately too vague) keeping the package names *.spi, *.spi.impl and *.config.element as is, but still moving *.spi and *.config.element to a new module called myfaces-spi. This alone will let us be able to remove shaded-impl, no code change is actually required, just moving some classes from myfaces-impl into myfaces-spi. In the end (-- the myfaces-impl jar), it will all be back in myfaces-impl again, because of shade. That's something different to the patch that we are discussing. I would like to move just the classes that are real API, and preserve *.spi.impl on impl module. Yes, that's a viable alternative. I will provide a new patch by tomorrow and then start a vote for it. There really is no technical reason for not committing such a solution at this point. Probably. Really in my mind a module that holds public myfaces impl API sounds better than a spi module, because after all the intention is say ... these classes are public api to be used to provide hooks over myfaces implementation ... and ... these classes will be stable, so it is safe to reference it in you code as long as you are using myfaces as your jsf impl Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi I'll be clear and direct. What makes statements true or false are the reasons behind it. Until this moment, you are not question the reasons behind the reasoning proposed. To be short, my argumentation is we can't change for now: 1. Everything inside org.apache.myfaces.spi 2. LifecycleProvided 3. Everything inside org.apache.myfaces.config.element because JSF 2.1 is a maintenance release (not a mayor release) which already has it first version (but even without a version). Do that will create bugs on server integration code. The problem is there is no way to detect such changes or create a proper patch from the server side point of view without use some ugly reflection code and that really s...cks!. Let it to JSF 2.2 (which is another JSR) sounds better because in that time I think we can get rid of implee6 too in one move!. In that version, just change the poms, and move all code to impl and that's it. In conclusion, here we have a technical restriction that doesn't allow us to move further, so we can't really make a vote because there is no decision to make, we just can't change the code!. The idea of an API in impl module is precisely make the promise that we will be nice and do not change that stuff until the next major version. Unfortunately there is nothing we can do in 2.1.x branch. regards, Leonardo Uribe 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, No, sorry Leo, they are not enough. Frankly, I don't understand why you are blocking this solution. It is easy, it does not break anything (if we do not change the package names), it is a lot more clean and we can get rid of the shaded-impl module. If we don't do this now, we will maybe have to use this ugly module for a long time.. And yes: in my opinion it is an epic fail. If you think otherwise, that's ok, but just because you say so and I don't does not make your statement true. I think we have to start a vote for this one just like we did with the resource-handler stuff. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, 1. All classes in org.apache.myfaces.spi. I did not change anything here, just internal imports (from *.spi.impl to *.spi.util)! It is questionable to create .spi.util. After all, it is not supposed that package be consumed by container integration code, so it should be on spi.impl. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. Geronimo (for which we did the SPI stuff) includes MyFaces 2.0.x. Here we are talking about 2.1.x. Furthermore, one call to organize imports does the trick, so I do not see a problem here. Look the page of JSR-314 spec http://www.jcp.org/en/jsr/summary?id=314 You will notice 2.1.x is not a new JSR like the future JSR-344 (JSF 2.2), and instead is tagged as Maintenance Release 2. So, to be consistent, it should be possible to change between 2.0 and 2.1 on the same server. That's the most important reason to be so conservative or strict with 2.1. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can add methods there, but relocate this package to
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi 2011/7/11 Gerhard Petracek gerhard.petra...@gmail.com: hi jakob, i suggest the same approach like before. last time leo requested some changes and had to start the vote (with a short description) and this time it's your turn. if you feel that we need a vote about it, please feel free to start one. Of course, as long as the alternative proposed be possible and valid. But anyway I think the discussion point (do not change packages) has been accepted, right?. Leonardo Uribe regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/11 Jakob Korherr jakob.korh...@gmail.com Hi, Leo, I really get your point that we can't change this stuff. Changing SPI stuff (even just renaming packages) will break application server integation code, we all got it now.. That's why I suggested (a few mails ago, but unfortunately too vague) keeping the package names *.spi, *.spi.impl and *.config.element as is, but still moving *.spi and *.config.element to a new module called myfaces-spi. This alone will let us be able to remove shaded-impl, no code change is actually required, just moving some classes from myfaces-impl into myfaces-spi. In the end (-- the myfaces-impl jar), it will all be back in myfaces-impl again, because of shade. I will provide a new patch by tomorrow and then start a vote for it. There really is no technical reason for not committing such a solution at this point. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi I'll be clear and direct. What makes statements true or false are the reasons behind it. Until this moment, you are not question the reasons behind the reasoning proposed. To be short, my argumentation is we can't change for now: 1. Everything inside org.apache.myfaces.spi 2. LifecycleProvided 3. Everything inside org.apache.myfaces.config.element because JSF 2.1 is a maintenance release (not a mayor release) which already has it first version (but even without a version). Do that will create bugs on server integration code. The problem is there is no way to detect such changes or create a proper patch from the server side point of view without use some ugly reflection code and that really s...cks!. Let it to JSF 2.2 (which is another JSR) sounds better because in that time I think we can get rid of implee6 too in one move!. In that version, just change the poms, and move all code to impl and that's it. In conclusion, here we have a technical restriction that doesn't allow us to move further, so we can't really make a vote because there is no decision to make, we just can't change the code!. The idea of an API in impl module is precisely make the promise that we will be nice and do not change that stuff until the next major version. Unfortunately there is nothing we can do in 2.1.x branch. regards, Leonardo Uribe 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, No, sorry Leo, they are not enough. Frankly, I don't understand why you are blocking this solution. It is easy, it does not break anything (if we do not change the package names), it is a lot more clean and we can get rid of the shaded-impl module. If we don't do this now, we will maybe have to use this ugly module for a long time.. And yes: in my opinion it is an epic fail. If you think otherwise, that's ok, but just because you say so and I don't does not make your statement true. I think we have to start a vote for this one just like we did with the resource-handler stuff. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, 1. All classes in org.apache.myfaces.spi. I did not change anything here, just internal imports (from *.spi.impl to *.spi.util)! It is questionable to create .spi.util. After all, it is not supposed that package be consumed by container integration code, so it should be on spi.impl. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. Geronimo (for which we did the SPI stuff) includes MyFaces 2.0.x. Here we are talking about 2.1.x. Furthermore, one call to organize imports does the trick, so I do not see a problem here. Look the page of JSR-314 spec http://www.jcp.org/en/jsr/summary?id=314 You will notice 2.1.x is not a new JSR like the future JSR-344 (JSF 2.2), and instead is tagged as Maintenance Release 2. So, to be consistent, it should be possible to change between 2.0 and 2.1 on the same server. That's the most important reason to be so conservative or strict with 2.1. 3. All classes on org.apache.myfaces.config.element. These classes are an
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
hi leo, if both of you agree on the rest, we won't need a vote - that's right. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/12 Leonardo Uribe lu4...@gmail.com Hi 2011/7/11 Gerhard Petracek gerhard.petra...@gmail.com: hi jakob, i suggest the same approach like before. last time leo requested some changes and had to start the vote (with a short description) and this time it's your turn. if you feel that we need a vote about it, please feel free to start one. Of course, as long as the alternative proposed be possible and valid. But anyway I think the discussion point (do not change packages) has been accepted, right?. Leonardo Uribe regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/11 Jakob Korherr jakob.korh...@gmail.com Hi, Leo, I really get your point that we can't change this stuff. Changing SPI stuff (even just renaming packages) will break application server integation code, we all got it now.. That's why I suggested (a few mails ago, but unfortunately too vague) keeping the package names *.spi, *.spi.impl and *.config.element as is, but still moving *.spi and *.config.element to a new module called myfaces-spi. This alone will let us be able to remove shaded-impl, no code change is actually required, just moving some classes from myfaces-impl into myfaces-spi. In the end (-- the myfaces-impl jar), it will all be back in myfaces-impl again, because of shade. I will provide a new patch by tomorrow and then start a vote for it. There really is no technical reason for not committing such a solution at this point. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi I'll be clear and direct. What makes statements true or false are the reasons behind it. Until this moment, you are not question the reasons behind the reasoning proposed. To be short, my argumentation is we can't change for now: 1. Everything inside org.apache.myfaces.spi 2. LifecycleProvided 3. Everything inside org.apache.myfaces.config.element because JSF 2.1 is a maintenance release (not a mayor release) which already has it first version (but even without a version). Do that will create bugs on server integration code. The problem is there is no way to detect such changes or create a proper patch from the server side point of view without use some ugly reflection code and that really s...cks!. Let it to JSF 2.2 (which is another JSR) sounds better because in that time I think we can get rid of implee6 too in one move!. In that version, just change the poms, and move all code to impl and that's it. In conclusion, here we have a technical restriction that doesn't allow us to move further, so we can't really make a vote because there is no decision to make, we just can't change the code!. The idea of an API in impl module is precisely make the promise that we will be nice and do not change that stuff until the next major version. Unfortunately there is nothing we can do in 2.1.x branch. regards, Leonardo Uribe 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, No, sorry Leo, they are not enough. Frankly, I don't understand why you are blocking this solution. It is easy, it does not break anything (if we do not change the package names), it is a lot more clean and we can get rid of the shaded-impl module. If we don't do this now, we will maybe have to use this ugly module for a long time.. And yes: in my opinion it is an epic fail. If you think otherwise, that's ok, but just because you say so and I don't does not make your statement true. I think we have to start a vote for this one just like we did with the resource-handler stuff. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, 1. All classes in org.apache.myfaces.spi. I did not change anything here, just internal imports (from *.spi.impl to *.spi.util)! It is questionable to create .spi.util. After all, it is not supposed that package be consumed by container integration code, so it should be on spi.impl. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. Geronimo (for which we did the SPI stuff) includes MyFaces 2.0.x. Here we are talking about 2.1.x. Furthermore, one call to organize imports does the trick, so I do not see a problem here. Look the page of JSR-314 spec
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi Gerhard Ok, in theory the parts that we should not change, or otherwise that will trigger a change on JEE containers are: 1. All classes in org.apache.myfaces.spi. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can add methods there, but relocate this package to org.apache.myfaces.spi.data is not necessary. I think the package name is correct. regards, Leonardo Uribe 2011/7/9 Gerhard Petracek gerhard.petra...@gmail.com: hi leo, thx for checking it. it would be great, if you can post a list of parts (not classes) which would break. so we can discuss this topic in a more concrete manner. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/10 Leonardo Uribe lu4...@gmail.com Hi Good to know that. Unfortunately, do a change on the spi related classes will break existing integration code with containers like Geronimo, JBoss and others too. Considering this, I think the costs involved on the changes proposed are too big compared with the benefits, which are very limited and almost inexistent from user point of view. regards, Leonardo Uribe 2011/7/8 Werner Punz werner.p...@gmail.com: I have no problem if you break Ext-Script, after all I program against the impl, so whatever change you do I have to patch it in my codebase anyway. Don´t feel stopped by it. Werner Am 08.07.11 18:27, schrieb Gerhard Petracek: hi, thx for reviewing the changes. for sure we can discuss when we are going to do such changes. however, if ext-script is the only reason against it, we can do it right now imo. there is no problem with shipping a small update of ext-script and the user base is currently small enough to communicate this change easily. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com Hi In principle I agree with this change, but after a quick patch review I saw some package relocation for some classes (from org.apache.myfaces.config.element to org.apache.myfaces.spi.data). Those changes will break extensions scripting code. Such changes should be done between major versions (2.2.0). Please do not change the package names. regards, Leonardo Uribe 2011/7/8 Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com Hi guys, We currently use the shaded-impl module in core 2.1.x to solve a cyclic dependency problem. However, this introduces redundancy and complexity and may lead to some strange issues. This can be solved by the introduction of a myfaces-spi module (which is then packed together with myfaces-impl, just like myfaces-impl-ee6 is). Please see MYFACES-3211 [1] for a detailed description of the solution and a patch for it. If there are no objections, I will commit this patch soon! Regards, Jakob [1] https://issues.apache.org/jira/browse/MYFACES-3211 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi Good to know that. Unfortunately, do a change on the spi related classes will break existing integration code with containers like Geronimo, JBoss and others too. Considering this, I think the costs involved on the changes proposed are too big compared with the benefits, which are very limited and almost inexistent from user point of view. regards, Leonardo Uribe 2011/7/8 Werner Punz werner.p...@gmail.com: I have no problem if you break Ext-Script, after all I program against the impl, so whatever change you do I have to patch it in my codebase anyway. Don´t feel stopped by it. Werner Am 08.07.11 18:27, schrieb Gerhard Petracek: hi, thx for reviewing the changes. for sure we can discuss when we are going to do such changes. however, if ext-script is the only reason against it, we can do it right now imo. there is no problem with shipping a small update of ext-script and the user base is currently small enough to communicate this change easily. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com Hi In principle I agree with this change, but after a quick patch review I saw some package relocation for some classes (from org.apache.myfaces.config.element to org.apache.myfaces.spi.data). Those changes will break extensions scripting code. Such changes should be done between major versions (2.2.0). Please do not change the package names. regards, Leonardo Uribe 2011/7/8 Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com Hi guys, We currently use the shaded-impl module in core 2.1.x to solve a cyclic dependency problem. However, this introduces redundancy and complexity and may lead to some strange issues. This can be solved by the introduction of a myfaces-spi module (which is then packed together with myfaces-impl, just like myfaces-impl-ee6 is). Please see MYFACES-3211 [1] for a detailed description of the solution and a patch for it. If there are no objections, I will commit this patch soon! Regards, Jakob [1] https://issues.apache.org/jira/browse/MYFACES-3211 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
hi leo, thx for checking it. it would be great, if you can post a list of parts (not classes) which would break. so we can discuss this topic in a more concrete manner. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/10 Leonardo Uribe lu4...@gmail.com Hi Good to know that. Unfortunately, do a change on the spi related classes will break existing integration code with containers like Geronimo, JBoss and others too. Considering this, I think the costs involved on the changes proposed are too big compared with the benefits, which are very limited and almost inexistent from user point of view. regards, Leonardo Uribe 2011/7/8 Werner Punz werner.p...@gmail.com: I have no problem if you break Ext-Script, after all I program against the impl, so whatever change you do I have to patch it in my codebase anyway. Don´t feel stopped by it. Werner Am 08.07.11 18:27, schrieb Gerhard Petracek: hi, thx for reviewing the changes. for sure we can discuss when we are going to do such changes. however, if ext-script is the only reason against it, we can do it right now imo. there is no problem with shipping a small update of ext-script and the user base is currently small enough to communicate this change easily. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com Hi In principle I agree with this change, but after a quick patch review I saw some package relocation for some classes (from org.apache.myfaces.config.element to org.apache.myfaces.spi.data). Those changes will break extensions scripting code. Such changes should be done between major versions (2.2.0). Please do not change the package names. regards, Leonardo Uribe 2011/7/8 Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com Hi guys, We currently use the shaded-impl module in core 2.1.x to solve a cyclic dependency problem. However, this introduces redundancy and complexity and may lead to some strange issues. This can be solved by the introduction of a myfaces-spi module (which is then packed together with myfaces-impl, just like myfaces-impl-ee6 is). Please see MYFACES-3211 [1] for a detailed description of the solution and a patch for it. If there are no objections, I will commit this patch soon! Regards, Jakob [1] https://issues.apache.org/jira/browse/MYFACES-3211 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Proposal: Get rid of shaded-impl module in core 2.1.x
Hi guys, We currently use the shaded-impl module in core 2.1.x to solve a cyclic dependency problem. However, this introduces redundancy and complexity and may lead to some strange issues. This can be solved by the introduction of a myfaces-spi module (which is then packed together with myfaces-impl, just like myfaces-impl-ee6 is). Please see MYFACES-3211 [1] for a detailed description of the solution and a patch for it. If there are no objections, I will commit this patch soon! Regards, Jakob [1] https://issues.apache.org/jira/browse/MYFACES-3211 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
+1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Jakob Korherr jakob.korh...@gmail.com Hi guys, We currently use the shaded-impl module in core 2.1.x to solve a cyclic dependency problem. However, this introduces redundancy and complexity and may lead to some strange issues. This can be solved by the introduction of a myfaces-spi module (which is then packed together with myfaces-impl, just like myfaces-impl-ee6 is). Please see MYFACES-3211 [1] for a detailed description of the solution and a patch for it. If there are no objections, I will commit this patch soon! Regards, Jakob [1] https://issues.apache.org/jira/browse/MYFACES-3211 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi In principle I agree with this change, but after a quick patch review I saw some package relocation for some classes (from org.apache.myfaces.config.element to org.apache.myfaces.spi.data). Those changes will break extensions scripting code. Such changes should be done between major versions (2.2.0). Please do not change the package names. regards, Leonardo Uribe 2011/7/8 Gerhard Petracek gerhard.petra...@gmail.com: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Jakob Korherr jakob.korh...@gmail.com Hi guys, We currently use the shaded-impl module in core 2.1.x to solve a cyclic dependency problem. However, this introduces redundancy and complexity and may lead to some strange issues. This can be solved by the introduction of a myfaces-spi module (which is then packed together with myfaces-impl, just like myfaces-impl-ee6 is). Please see MYFACES-3211 [1] for a detailed description of the solution and a patch for it. If there are no objections, I will commit this patch soon! Regards, Jakob [1] https://issues.apache.org/jira/browse/MYFACES-3211 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
hi, thx for reviewing the changes. for sure we can discuss when we are going to do such changes. however, if ext-script is the only reason against it, we can do it right now imo. there is no problem with shipping a small update of ext-script and the user base is currently small enough to communicate this change easily. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Leonardo Uribe lu4...@gmail.com Hi In principle I agree with this change, but after a quick patch review I saw some package relocation for some classes (from org.apache.myfaces.config.element to org.apache.myfaces.spi.data). Those changes will break extensions scripting code. Such changes should be done between major versions (2.2.0). Please do not change the package names. regards, Leonardo Uribe 2011/7/8 Gerhard Petracek gerhard.petra...@gmail.com: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Jakob Korherr jakob.korh...@gmail.com Hi guys, We currently use the shaded-impl module in core 2.1.x to solve a cyclic dependency problem. However, this introduces redundancy and complexity and may lead to some strange issues. This can be solved by the introduction of a myfaces-spi module (which is then packed together with myfaces-impl, just like myfaces-impl-ee6 is). Please see MYFACES-3211 [1] for a detailed description of the solution and a patch for it. If there are no objections, I will commit this patch soon! Regards, Jakob [1] https://issues.apache.org/jira/browse/MYFACES-3211 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi Thinking more about it, I have a question about this change. The intention of shaded-impl, is do some hack to allow use some classes provided in impl (spi package, StartupServletExternalContextImpl ... ) for implee6 module. As soon as our implementation requires JDK 1.6, this hack will be gone, and maybe that will be on 2.2.x, right? (but the idea is keep compatibility with previous JDK even if JSF 2.1 claims it requires JDK 1.6 or upper). On the patch proposed I see a refactor of the spi and a call to StartupServletExternalContextImpl using reflection. My question is it is worth that change?, given this module will only be living for a short time and it will be removed sooner or later? Does that module suppose an unnecessary complexity?. regards, Leonardo Uribe 2011/7/8 Leonardo Uribe lu4...@gmail.com: Hi In principle I agree with this change, but after a quick patch review I saw some package relocation for some classes (from org.apache.myfaces.config.element to org.apache.myfaces.spi.data). Those changes will break extensions scripting code. Such changes should be done between major versions (2.2.0). Please do not change the package names. regards, Leonardo Uribe 2011/7/8 Gerhard Petracek gerhard.petra...@gmail.com: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Jakob Korherr jakob.korh...@gmail.com Hi guys, We currently use the shaded-impl module in core 2.1.x to solve a cyclic dependency problem. However, this introduces redundancy and complexity and may lead to some strange issues. This can be solved by the introduction of a myfaces-spi module (which is then packed together with myfaces-impl, just like myfaces-impl-ee6 is). Please see MYFACES-3211 [1] for a detailed description of the solution and a patch for it. If there are no objections, I will commit this patch soon! Regards, Jakob [1] https://issues.apache.org/jira/browse/MYFACES-3211 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
I have no problem if you break Ext-Script, after all I program against the impl, so whatever change you do I have to patch it in my codebase anyway. Don´t feel stopped by it. Werner Am 08.07.11 18:27, schrieb Gerhard Petracek: hi, thx for reviewing the changes. for sure we can discuss when we are going to do such changes. however, if ext-script is the only reason against it, we can do it right now imo. there is no problem with shipping a small update of ext-script and the user base is currently small enough to communicate this change easily. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com Hi In principle I agree with this change, but after a quick patch review I saw some package relocation for some classes (from org.apache.myfaces.config.element to org.apache.myfaces.spi.data). Those changes will break extensions scripting code. Such changes should be done between major versions (2.2.0). Please do not change the package names. regards, Leonardo Uribe 2011/7/8 Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com Hi guys, We currently use the shaded-impl module in core 2.1.x to solve a cyclic dependency problem. However, this introduces redundancy and complexity and may lead to some strange issues. This can be solved by the introduction of a myfaces-spi module (which is then packed together with myfaces-impl, just like myfaces-impl-ee6 is). Please see MYFACES-3211 [1] for a detailed description of the solution and a patch for it. If there are no objections, I will commit this patch soon! Regards, Jakob [1] https://issues.apache.org/jira/browse/MYFACES-3211 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
