Date   

Re: notice: javaserverfaces/mojarra is read-only now

Neil Griffin
 

Hi Bill,

I'm sure there are many JSF webapps out there running on Tomcat that simply bundle Mojarra in WEB-INF/lib.

Portlet applications in Pluto do not rely on the version of JSF included with the server, since the only released distribution of Pluto is for Tomcat.

Similarly, portlet applications in Liferay do not rely on the version of JSF included with the server.

We would be grateful if Oracle would consider releasing Mojarra 2.2 on an as-needed basis for the next year or so. We will focus on supporting JSF 2.3 in a portlet environment as soon as we get JSR 378 out the door.


Best Regards,

Neil

On 4/26/18 4:34 PM, Bill Shannon wrote:
I would expect that the Java EE server vendors would be providing any required updates to the version of JSF included with their server.  That's what Oracle will do for WebLogic.  Exactly how we do that for older versions is still under discussion.
Kyle Stiemann wrote on 04/25/2018 04:05 PM:
Hi Bill,
The Liferay Faces team is currently working on JSR 378 which is a Portlet Bridge for Portlet 3.0 + JSF 2.2. The JSR for Portlet 3.0 + JSF 2.3 hasn't yet been filed. Our customers are using Java EE 7 app servers which are not compatible with Mojarra 2.3. And since many app servers (includingOracle's own WebLogic Server <http://www.oracle.com/technetwork/middleware/weblogic/downloads/index.html>) only support Java EE 7 right now, there is no way to upgrade to Mojarra 2.3. We need to be able to provide bug fixes for Mojarra 2.2 for the sake of our customers who are using these standards based technologies.

Mojarra 1.2 and 2.1 only need security fixes, but Mojarra 2.2 is still widely used and depended on by many projects with no option to upgrade to Mojarra 2.3, so we need to be able to fix bugs and get regular releases for it.

- Kyle



On Wed, Apr 25, 2018 at 4:51 PM, Bill Shannon <bill.shannon@oracle.com <mailto:bill.shannon@oracle.com>> wrote:

Hi Kyle.

We have a plan for how to support older releases but we're still discussing the plan to make sure it's workable.

In general, we expect support to move to the Eclipse community and the Eclipse Mojarra project.  We're only contributing the current release to Eclipse so support for older releases has to be handled differently.  At this point we only expect to be dealing with critical security problems in older releases, which hopefully will be relatively rare.  If such a problem occurs, we can unarchive the old github project temporarily while we fix the critical security bug.  For other issues, we hope the community will quickly move to the Eclipse version.

Is Liferay distributing versions of Mojarra with Liferay products?


Kyle Stiemann wrote on 04/25/18 06:02 AM:
Thanks Zhijun,
I guess I misunderstood your initial email. Are you saying the the project is only archived temporarily (and oracle has yet to decide how to handle legacy releases)? I thought that the project was being permanently archived and that the Liferay Faces team would have no way to contribute fixes for legacy releases.

- Kyle

On Tue, Apr 24, 2018 at 10:13 PM, <ren.zhijun@oracle.com <mailto:ren.zhijun@oracle.com>> wrote:

Hi Kyle,

Thanks for your question, during the donation process, if you want to file issue or commit code, you can notify me and I can un-archive the project temporarily for you.  The release cut will be done according to the requirements from upper products.

We are discussing how to handle legacy releases support and maintenance after the donation is done.

Thanks,

Zhijun


On 24/04/2018 9:13 PM, Kyle Stiemann wrote:
Hi Zhijun,
Since the public repo has been archived, how does Oracle plan to maintain the 2.3.x, 2.2.x, and 2.1.x versions of Mojarra? How can the community contribute fixes and bug reports for those versions? How often will those versions of Mojarra be released?

- Kyle

On Tue, Apr 24, 2018 at 3:48 AM, <ren.zhijun@oracle.com <mailto:ren.zhijun@oracle.com>> wrote:

Hi,

*/Please be aware that the repository javaserverfaces/mojarra <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_javaserverfaces_mojarra&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=jQElfR-dM3OSoiWBc0gG9b1RPuD_bwz5aGvriGrTwyA&m=BCUq4NjDp42diFqKUY-uCCxJKSRhwwHUzqI_IAh6RSM&s=Ju71I2BlGZTlf5eKFMEvObyC8NKrFZQwdTtxpbir_y0&e=> has been archived as this project is now part of the EE4J initiative. All activities are now happening in the corresponding Eclipse repository ee4j-mojarra <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse-2Dee4j_mojarra&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=jQElfR-dM3OSoiWBc0gG9b1RPuD_bwz5aGvriGrTwyA&m=BCUq4NjDp42diFqKUY-uCCxJKSRhwwHUzqI_IAh6RSM&s=wUxxODWnGh-RSM4ClCTlJtWfD7xyroibsZb-O32FF4I&e=>. The issue tracker is now located at issues
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse-2Dee4j_mojarra_issues&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=jQElfR-dM3OSoiWBc0gG9b1RPuD_bwz5aGvriGrTwyA&m=BCUq4NjDp42diFqKUY-uCCxJKSRhwwHUzqI_IAh6RSM&s=60uSxvHVt81nfZsIYgAx-OsAroNqJRsQEUpGOYrBsAg&e=>; the EE4J community mailing list is located here [https://accounts.eclipse.org/mailing-list/ee4j-community <https://urldefense.proofpoint.com/v2/url?u=https-3A__accounts.eclipse.org_mailing-2Dlist_ee4j-2Dcommunity&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=jQElfR-dM3OSoiWBc0gG9b1RPuD_bwz5aGvriGrTwyA&m=BCUq4NjDp42diFqKUY-uCCxJKSRhwwHUzqI_IAh6RSM&s=FErpAzP1JCy1kfJzLTJTY-OD47eHqPV_w7xudi8hG6Y&e=>]./*

*/Thanks,/*

*/Zhijun
/*

*/
/*


Re: About the diff between 2.3 and master

ren.zhijun@...
 

Hi Arjan,

When will you do the merge from 2.3.x to master? at least we need to fix CTS failure issue soon, to be efficient, you can commit the fix firstly in https://github.com/javaserverfaces/mojarra, then I can migrate the merge to EE4J repo.

Thanks,

Zhijun


On 28/04/2018 4:06 AM, arjan tijms wrote:
Hi,

On Fri, Apr 27, 2018 at 9:48 PM, Bill Shannon <bill.shannon@...> wrote:
My understanding is that the master isn't passing the JSF 2.3 TCK, perhaps because some API changes have been introduced?

The API project in master has not been touched, it's 100% identical to the 2.3 branch. 

But it's always possible an accidental bug has crept in the implementation project that causes faulty behaviour (this would have been my mistake then).

In this case, if I'm not mistaken, it's only a NullPointerException that's accidentally wrapped in a FacesException.
 
Do you expect master to be JSF 2.3 compatible?

Yes indeed, it should be fully 2.3 compatible. No behaviour (should) have been changed.
 
I think we would like to get master back to JSF 2.3 compatible so we can contribute it to Eclipse.  How difficult will that be?

I can only assume it should be easy. I'll take a look at the exception right away. The contribution to Mojarra has already been done, hasn't it? 

 
  The bug fixes that have been applied to the branch can either be applied to master now or can be applied to the Eclipse project after it's created.

I've just created an issue to track this effort: https://github.com/eclipse-ee4j/mojarra/issues/4380

I can apply the bug fixes to either repo (Oracle or Eclipse), but since the master has already been transferred I assume that Eclipse is easiest.

Please advise, so I can potentially start with this task this weekend.

Kind regards,
Arjan Tijms










 

arjan tijms wrote on 04/27/18 04:11 AM:
Hi,

The major difference between MOJARRA_2_3X_ROLLING and master are the number of patches Bauke and Kyle did while the vetting of the master was already in progress.

I think MOJARRA_2_3X_ROLLING can not just be donated, as it hasn't been vetted. All the license checks and removal of (non-compliant) libraries has been done in master.

The patches however should all be very focussed individual changes, and as they have been applied to MOJARRA_2_2X_ROLLING and before as well, I think it will be much easier to apply them one by one to the master at Eclipse.

Kind regards,
Arjan



On Fri, Apr 27, 2018 at 5:14 AM, <ren.zhijun@...> wrote:
Hi Arjan,

In our Github project javaserverfaces/mojarra, MOJARRA_2_3X_ROLLING branch is "119 commits ahead, 297 commits behind master".

What's the main differences between the two branches?  The merge from 2.3 to master will be very difficult cause you have done file structure refactoring, right?

For current donation to Eclipse, can we donate MOJARRA_2_3X_ROLLING instead of master branch? it means that 297 commits in master will not be donated to Eclipse, do you have concern about it?


Thanks,

Zhijun







Re: About the diff between 2.3 and master

Arjan Tijms
 

Hi,

A potential fix for the CTS failure has been committed here: https://github.com/javaserverfaces/mojarra/pull/4372

I was waiting for a reproducer for the failure, but as the fix seems simple enough hopefully that one will fix it.

If that fix works I'll start with the merge.

Kind regards,
Arjan





On Mon, May 7, 2018 at 4:33 AM, <ren.zhijun@...> wrote:

Hi Arjan,

When will you do the merge from 2.3.x to master? at least we need to fix CTS failure issue soon, to be efficient, you can commit the fix firstly in https://github.com/javaserverfaces/mojarra, then I can migrate the merge to EE4J repo.

Thanks,

Zhijun


On 28/04/2018 4:06 AM, arjan tijms wrote:
Hi,

On Fri, Apr 27, 2018 at 9:48 PM, Bill Shannon <bill.shannon@...> wrote:
My understanding is that the master isn't passing the JSF 2.3 TCK, perhaps because some API changes have been introduced?

The API project in master has not been touched, it's 100% identical to the 2.3 branch. 

But it's always possible an accidental bug has crept in the implementation project that causes faulty behaviour (this would have been my mistake then).

In this case, if I'm not mistaken, it's only a NullPointerException that's accidentally wrapped in a FacesException.
 
Do you expect master to be JSF 2.3 compatible?

Yes indeed, it should be fully 2.3 compatible. No behaviour (should) have been changed.
 
I think we would like to get master back to JSF 2.3 compatible so we can contribute it to Eclipse.  How difficult will that be?

I can only assume it should be easy. I'll take a look at the exception right away. The contribution to Mojarra has already been done, hasn't it? 

 
  The bug fixes that have been applied to the branch can either be applied to master now or can be applied to the Eclipse project after it's created.

I've just created an issue to track this effort: https://github.com/eclipse-ee4j/mojarra/issues/4380

I can apply the bug fixes to either repo (Oracle or Eclipse), but since the master has already been transferred I assume that Eclipse is easiest.

Please advise, so I can potentially start with this task this weekend.

Kind regards,
Arjan Tijms










 

arjan tijms wrote on 04/27/18 04:11 AM:
Hi,

The major difference between MOJARRA_2_3X_ROLLING and master are the number of patches Bauke and Kyle did while the vetting of the master was already in progress.

I think MOJARRA_2_3X_ROLLING can not just be donated, as it hasn't been vetted. All the license checks and removal of (non-compliant) libraries has been done in master.

The patches however should all be very focussed individual changes, and as they have been applied to MOJARRA_2_2X_ROLLING and before as well, I think it will be much easier to apply them one by one to the master at Eclipse.

Kind regards,
Arjan



On Fri, Apr 27, 2018 at 5:14 AM, <ren.zhijun@...> wrote:
Hi Arjan,

In our Github project javaserverfaces/mojarra, MOJARRA_2_3X_ROLLING branch is "119 commits ahead, 297 commits behind master".

What's the main differences between the two branches?  The merge from 2.3 to master will be very difficult cause you have done file structure refactoring, right?

For current donation to Eclipse, can we donate MOJARRA_2_3X_ROLLING instead of master branch? it means that 297 commits in master will not be donated to Eclipse, do you have concern about it?


Thanks,

Zhijun








Re: About the diff between 2.3 and master

Ruolin Li
 

Hi, Arjan, 

I've tested the fix with CTS cases. 
The previously-failed case passed . 

The reproducer was sent in another mail. 

Thanks and best regards
Ruolin


On May 7, 2018, at 20:01, arjan tijms <arjan.tijms@...> wrote:

Hi,

A potential fix for the CTS failure has been committed here: https://github.com/javaserverfaces/mojarra/pull/4372

I was waiting for a reproducer for the failure, but as the fix seems simple enough hopefully that one will fix it.

If that fix works I'll start with the merge.

Kind regards,
Arjan





On Mon, May 7, 2018 at 4:33 AM,  <ren.zhijun@...> wrote:

Hi Arjan,

When will you do the merge from 2.3.x to master? at least we need to fix CTS failure issue soon, to be efficient, you can commit the fix firstly in https://github.com/javaserverfaces/mojarra, then I can migrate the merge to EE4J repo.

Thanks,

Zhijun


On 28/04/2018 4:06 AM, arjan tijms wrote:
Hi,

On Fri, Apr 27, 2018 at 9:48 PM, Bill Shannon <bill.shannon@...> wrote:
My understanding is that the master isn't passing the JSF 2.3 TCK, perhaps because some API changes have been introduced?

The API project in master has not been touched, it's 100% identical to the 2.3 branch. 

But it's always possible an accidental bug has crept in the implementation project that causes faulty behaviour (this would have been my mistake then).

In this case, if I'm not mistaken, it's only a NullPointerException that's accidentally wrapped in a FacesException.
 
Do you expect master to be JSF 2.3 compatible?

Yes indeed, it should be fully 2.3 compatible. No behaviour (should) have been changed.
 
I think we would like to get master back to JSF 2.3 compatible so we can contribute it to Eclipse.  How difficult will that be?

I can only assume it should be easy. I'll take a look at the exception right away. The contribution to Mojarra has already been done, hasn't it? 

 
  The bug fixes that have been applied to the branch can either be applied to master now or can be applied to the Eclipse project after it's created.

I've just created an issue to track this effort: https://github.com/eclipse-ee4j/mojarra/issues/4380

I can apply the bug fixes to either repo (Oracle or Eclipse), but since the master has already been transferred I assume that Eclipse is easiest.

Please advise, so I can potentially start with this task this weekend.

Kind regards,
Arjan Tijms










 

arjan tijms wrote on 04/27/18 04:11 AM:
Hi,

The major difference between MOJARRA_2_3X_ROLLING and master are the number of patches Bauke and Kyle did while the vetting of the master was already in progress.

I think MOJARRA_2_3X_ROLLING can not just be donated, as it hasn't been vetted. All the license checks and removal of (non-compliant) libraries has been done in master.

The patches however should all be very focussed individual changes, and as they have been applied to MOJARRA_2_2X_ROLLING and before as well, I think it will be much easier to apply them one by one to the master at Eclipse.

Kind regards,
Arjan



On Fri, Apr 27, 2018 at 5:14 AM, <ren.zhijun@...> wrote:
Hi Arjan,

In our Github project javaserverfaces/mojarra, MOJARRA_2_3X_ROLLING branch is "119 commits ahead, 297 commits behind master".

What's the main differences between the two branches?  The merge from 2.3 to master will be very difficult cause you have done file structure refactoring, right?

For current donation to Eclipse, can we donate MOJARRA_2_3X_ROLLING instead of master branch? it means that 297 commits in master will not be donated to Eclipse, do you have concern about it?


Thanks,

Zhijun








61 - 64 of 64