date:20100805

Hello Stan,

welcome back. We do understand that you can not make any promise on that topic.
The fact that some folks at JBoss are thinking about shipping MyFaces
(as an alternative option)
is a good news for this entire community here. Especially it is a
great motivation for the
folks that did the main work on ensuring Apache MyFaces 2.x is a great success.

On the missing pieces: I am sure that there will be some interested in
working on them.

Thanks,
Matthias Wessendorf
PMC Chair Apache MyFaces

On Wed, Aug 4, 2010 at 8:42 PM,  ssilv...@redhat.com wrote:
 Hi guys,

 Would you like to see MyFaces Core ship with JBoss AS6?  If so, read on.

 If you've been around MyFaces awhile, you probably remember that JBoass AS
 used to ship with MyFaces instead of Mojarra.  It was regrettable, but at
 the time Mojarra was far ahead spec-wise and the powers that be decided my
 time would be better spent integrating Mojarra instead of improving MyFaces.

 However, with JBoss AS6 M4, this is no longer an either or proposition.
  Both MyFaces and Mojarra can live side-by-side.  The application can decide
 which implementation to use: http://community.jboss.org/wiki/JSFonJBossAS6

 What's more, changing the default JSF implementation for AS6 is just a
 matter of changing the defaultJSFConfig property in an XML file.

 I've talked internally at JBoss about adding MyFaces to the JBoss AS
 community distribution.  Some were for it, and some were very, very for it.
  Nobody so far is against it.

 The good part is that I don't think it's a lot of work.  It's probably just
 three or four classes that implement SPI's that I'm guessing MyFaces already
 has.

 So this is where the MyFaces Dev group comes in.  MyFaces Core 2.0 will run
 OK on JBoss AS6 right now.  However, there is some integration work that is
 needed for full JEE5 and JEE6 compliance.  We need:
 * An injection provider SPI similar to Mojarra's
 com.sun.faces.spi.InjectionProvider.
 * The JBoss/MyFaces implementation of the SPI.  I expect this will be very
 similar to
 org.jboss.web.jsf.integration.injection.JBossDelegatingInjectionProvider.
 * An AnnotationProvider SPI similar to Mojarra's
 com.sun.faces.spi.AnnotationProvider.
 * A JBoss/MyFaces implementation of the SPI similar to
 org.jboss.web.jsf.integration.config.JBossAnnotationProvider.
 * A ServletContextListener class to call for initialization.  I expect this
 will extend from MyFacesServletContextListener and be very similar to
 org.jboss.web.jsf.integration.config.JBossMojarra20ConfigureListener.

 If MyFaces Dev decides to take this on, then the code will probably live at
 Apache and I'll bring it into JBoss AS using Maven.  I don't have time to
 write and maintain the code myself but I'm happy to help out with guidance
 and to do some refactoring of my code to make this easier.  BTW, the
 JBoss/Mojarra integration code lives here:
  http://anonsvn.jboss.org/repos/jbossas/projects/jboss-jsf-int/trunk/jboss-faces/

 Lastly, let me say that I can't make hard promises right now.  I don't know
 if someone at JBoss/RedHat will come along and nix the idea.  However, even
 if we can't ship MyFaces you will have all the integration points ready and
 have an easy way to drop in MyFaces whenever you want to use it with JBoss
 AS.

 WDYT??







-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: MyFaces shipping with JBoss AS6?

2010-08-05 Thread Jan-Kees van Andel

Hi,

Great news! It would be very nice if JBoss ships with MyFaces 2. This also
opens up possibilities to do some enhancements to increase developer
productivity in JBoss, like better resource reloading and so on. Or doing
some things more efficient by plugging into the JBoss infrastructure. Just
thinking out loud... :)

One thing about the JBoss SVN link Stan sent. I took a quick peek at the
license header in a Java file and saw that it's LGPL licensed. AFAIK, this
is not compatible with ASL, so I suggest to not look at the code while
implementing the stuff Stan asked for.

WDYT?

Regards,
Jan-Kees


2010/8/5 Matthias Wessendorf mat...@apache.org

 Hello Stan,

 welcome back. We do understand that you can not make any promise on that
 topic.
 The fact that some folks at JBoss are thinking about shipping MyFaces
 (as an alternative option)
 is a good news for this entire community here. Especially it is a
 great motivation for the
 folks that did the main work on ensuring Apache MyFaces 2.x is a great
 success.

 On the missing pieces: I am sure that there will be some interested in
 working on them.

 Thanks,
 Matthias Wessendorf
 PMC Chair Apache MyFaces

 On Wed, Aug 4, 2010 at 8:42 PM,  ssilv...@redhat.com wrote:
  Hi guys,
 
  Would you like to see MyFaces Core ship with JBoss AS6?  If so, read on.
 
  If you've been around MyFaces awhile, you probably remember that JBoass
 AS
  used to ship with MyFaces instead of Mojarra.  It was regrettable, but at
  the time Mojarra was far ahead spec-wise and the powers that be decided
 my
  time would be better spent integrating Mojarra instead of improving
 MyFaces.
 
  However, with JBoss AS6 M4, this is no longer an either or proposition.
   Both MyFaces and Mojarra can live side-by-side.  The application can
 decide
  which implementation to use:
 http://community.jboss.org/wiki/JSFonJBossAS6
 
  What's more, changing the default JSF implementation for AS6 is just a
  matter of changing the defaultJSFConfig property in an XML file.
 
  I've talked internally at JBoss about adding MyFaces to the JBoss AS
  community distribution.  Some were for it, and some were very, very for
 it.
   Nobody so far is against it.
 
  The good part is that I don't think it's a lot of work.  It's probably
 just
  three or four classes that implement SPI's that I'm guessing MyFaces
 already
  has.
 
  So this is where the MyFaces Dev group comes in.  MyFaces Core 2.0 will
 run
  OK on JBoss AS6 right now.  However, there is some integration work that
 is
  needed for full JEE5 and JEE6 compliance.  We need:
  * An injection provider SPI similar to Mojarra's
  com.sun.faces.spi.InjectionProvider.
  * The JBoss/MyFaces implementation of the SPI.  I expect this will be
 very
  similar to
  org.jboss.web.jsf.integration.injection.JBossDelegatingInjectionProvider.
  * An AnnotationProvider SPI similar to Mojarra's
  com.sun.faces.spi.AnnotationProvider.
  * A JBoss/MyFaces implementation of the SPI similar to
  org.jboss.web.jsf.integration.config.JBossAnnotationProvider.
  * A ServletContextListener class to call for initialization.  I expect
 this
  will extend from MyFacesServletContextListener and be very similar to
  org.jboss.web.jsf.integration.config.JBossMojarra20ConfigureListener.
 
  If MyFaces Dev decides to take this on, then the code will probably live
 at
  Apache and I'll bring it into JBoss AS using Maven.  I don't have time to
  write and maintain the code myself but I'm happy to help out with
 guidance
  and to do some refactoring of my code to make this easier.  BTW, the
  JBoss/Mojarra integration code lives here:
 
 http://anonsvn.jboss.org/repos/jbossas/projects/jboss-jsf-int/trunk/jboss-faces/
 
  Lastly, let me say that I can't make hard promises right now.  I don't
 know
  if someone at JBoss/RedHat will come along and nix the idea.  However,
 even
  if we can't ship MyFaces you will have all the integration points ready
 and
  have an easy way to drop in MyFaces whenever you want to use it with
 JBoss
  AS.
 
  WDYT??
 
 
 
 



 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf

Re: MyFaces shipping with JBoss AS6?

At Apache we can not have code that contains (L)GPL code; or depends on it.

We had discussion(s) about this in the past. The below link contains references
to other (Apache) documents:

http://markmail.org/message/qtc4g6vsracgzbok

-Matthias

On Thu, Aug 5, 2010 at 9:55 AM, Jan-Kees van Andel
jankeesvanan...@gmail.com wrote:
 Hi,

 Great news! It would be very nice if JBoss ships with MyFaces 2. This also
 opens up possibilities to do some enhancements to increase developer
 productivity in JBoss, like better resource reloading and so on. Or doing
 some things more efficient by plugging into the JBoss infrastructure. Just
 thinking out loud... :)

 One thing about the JBoss SVN link Stan sent. I took a quick peek at the
 license header in a Java file and saw that it's LGPL licensed. AFAIK, this
 is not compatible with ASL, so I suggest to not look at the code while
 implementing the stuff Stan asked for.

 WDYT?

 Regards,
 Jan-Kees


 2010/8/5 Matthias Wessendorf mat...@apache.org

 Hello Stan,

 welcome back. We do understand that you can not make any promise on that
 topic.
 The fact that some folks at JBoss are thinking about shipping MyFaces
 (as an alternative option)
 is a good news for this entire community here. Especially it is a
 great motivation for the
 folks that did the main work on ensuring Apache MyFaces 2.x is a great
 success.

 On the missing pieces: I am sure that there will be some interested in
 working on them.

 Thanks,
 Matthias Wessendorf
 PMC Chair Apache MyFaces

 On Wed, Aug 4, 2010 at 8:42 PM,  ssilv...@redhat.com wrote:
  Hi guys,
 
  Would you like to see MyFaces Core ship with JBoss AS6?  If so, read on.
 
  If you've been around MyFaces awhile, you probably remember that JBoass
  AS
  used to ship with MyFaces instead of Mojarra.  It was regrettable, but
  at
  the time Mojarra was far ahead spec-wise and the powers that be decided
  my
  time would be better spent integrating Mojarra instead of improving
  MyFaces.
 
  However, with JBoss AS6 M4, this is no longer an either or
  proposition.
   Both MyFaces and Mojarra can live side-by-side.  The application can
  decide
  which implementation to use:
  http://community.jboss.org/wiki/JSFonJBossAS6
 
  What's more, changing the default JSF implementation for AS6 is just a
  matter of changing the defaultJSFConfig property in an XML file.
 
  I've talked internally at JBoss about adding MyFaces to the JBoss AS
  community distribution.  Some were for it, and some were very, very for
  it.
   Nobody so far is against it.
 
  The good part is that I don't think it's a lot of work.  It's probably
  just
  three or four classes that implement SPI's that I'm guessing MyFaces
  already
  has.
 
  So this is where the MyFaces Dev group comes in.  MyFaces Core 2.0 will
  run
  OK on JBoss AS6 right now.  However, there is some integration work that
  is
  needed for full JEE5 and JEE6 compliance.  We need:
  * An injection provider SPI similar to Mojarra's
  com.sun.faces.spi.InjectionProvider.
  * The JBoss/MyFaces implementation of the SPI.  I expect this will be
  very
  similar to
 
  org.jboss.web.jsf.integration.injection.JBossDelegatingInjectionProvider.
  * An AnnotationProvider SPI similar to Mojarra's
  com.sun.faces.spi.AnnotationProvider.
  * A JBoss/MyFaces implementation of the SPI similar to
  org.jboss.web.jsf.integration.config.JBossAnnotationProvider.
  * A ServletContextListener class to call for initialization.  I expect
  this
  will extend from MyFacesServletContextListener and be very similar to
  org.jboss.web.jsf.integration.config.JBossMojarra20ConfigureListener.
 
  If MyFaces Dev decides to take this on, then the code will probably live
  at
  Apache and I'll bring it into JBoss AS using Maven.  I don't have time
  to
  write and maintain the code myself but I'm happy to help out with
  guidance
  and to do some refactoring of my code to make this easier.  BTW, the
  JBoss/Mojarra integration code lives here:
 
   http://anonsvn.jboss.org/repos/jbossas/projects/jboss-jsf-int/trunk/jboss-faces/
 
  Lastly, let me say that I can't make hard promises right now.  I don't
  know
  if someone at JBoss/RedHat will come along and nix the idea.  However,
  even
  if we can't ship MyFaces you will have all the integration points ready
  and
  have an easy way to drop in MyFaces whenever you want to use it with
  JBoss
  AS.
 
  WDYT??
 
 
 
 



 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf





-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: MyFaces shipping with JBoss AS6?

2010-08-05 Thread Martin Marinschek

Hi guys,

sure we would want to have this!

@Leonardo: can you take care of this high priority (next to your
optimization and performance improvement work)?

best regards,

Martin

On 8/4/10, ssilv...@redhat.com ssilv...@redhat.com wrote:
 Hi guys,

 Would you like to see MyFaces Core ship with JBoss AS6?  If so, read on.

 If you've been around MyFaces awhile, you probably remember that
 JBoass AS used to ship with MyFaces instead of Mojarra.  It was
 regrettable, but at the time Mojarra was far ahead spec-wise and the
 powers that be decided my time would be better spent integrating
 Mojarra instead of improving MyFaces.

 However, with JBoss AS6 M4, this is no longer an either or
 proposition.  Both MyFaces and Mojarra can live side-by-side.  The
 application can decide which implementation to use:
 http://community.jboss.org/wiki/JSFonJBossAS6

 What's more, changing the default JSF implementation for AS6 is just a
 matter of changing the defaultJSFConfig property in an XML file.

 I've talked internally at JBoss about adding MyFaces to the JBoss AS
 community distribution.  Some were for it, and some were very, very
 for it.  Nobody so far is against it.

 The good part is that I don't think it's a lot of work.  It's probably
 just three or four classes that implement SPI's that I'm guessing
 MyFaces already has.

 So this is where the MyFaces Dev group comes in.  MyFaces Core 2.0
 will run OK on JBoss AS6 right now.  However, there is some
 integration work that is needed for full JEE5 and JEE6 compliance.  We
 need:
 * An injection provider SPI similar to Mojarra's
 com.sun.faces.spi.InjectionProvider.
 * The JBoss/MyFaces implementation of the SPI.  I expect this will be
 very similar to
 org.jboss.web.jsf.integration.injection.JBossDelegatingInjectionProvider.
 * An AnnotationProvider SPI similar to Mojarra's
 com.sun.faces.spi.AnnotationProvider.
 * A JBoss/MyFaces implementation of the SPI similar to
 org.jboss.web.jsf.integration.config.JBossAnnotationProvider.
 * A ServletContextListener class to call for initialization.  I expect
 this will extend from MyFacesServletContextListener and be very
 similar to
 org.jboss.web.jsf.integration.config.JBossMojarra20ConfigureListener.

 If MyFaces Dev decides to take this on, then the code will probably
 live at Apache and I'll bring it into JBoss AS using Maven.  I don't
 have time to write and maintain the code myself but I'm happy to help
 out with guidance and to do some refactoring of my code to make this
 easier.  BTW, the JBoss/Mojarra integration code lives here:
 http://anonsvn.jboss.org/repos/jbossas/projects/jboss-jsf-int/trunk/jboss-faces/

 Lastly, let me say that I can't make hard promises right now.  I don't
 know if someone at JBoss/RedHat will come along and nix the idea.
 However, even if we can't ship MyFaces you will have all the
 integration points ready and have an easy way to drop in MyFaces
 whenever you want to use it with JBoss AS.

 WDYT??






-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

[jira] Commented: (MYFACES-2855) jsf.js: execute id difference between myfaces and mojarra

2010-08-05 Thread JIRA


[ 
https://issues.apache.org/jira/browse/MYFACES-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12895632#action_12895632
 ] 

Martin Kočí commented on MYFACES-2855:
--

Hi, with today's build a javascript error occurs:

Error: all is not defined
faces/javax.faces.resource/jsf.js?ln=javax.facesstage=Development
Line: 5580

It's an if-condition:

} else if (all) {
  passThrgh[target] = _this.IDENT_ALL;
}




 jsf.js: execute id difference between myfaces and mojarra
 -

 Key: MYFACES-2855
 URL: https://issues.apache.org/jira/browse/MYFACES-2855
 Project: MyFaces Core
  Issue Type: Bug
Reporter: Werner Punz

  h:panelGroup id=bla
h:inputText id=inputbla 
 value=#{myBean2.searchTerm} /
h:commandLink value=Press me for more action 
 action=#{myBean2.doSearch}
f:ajax execute=bla render=content/
/h:commandLink
/h:panelGroup
 causes following output in mojarra
 form2 form2
 form2:inputbla
 javax.faces.ViewState 6697453697014869722:-1090088301633916042
 javax.faces.behavior.even...  action
 javax.faces.partial.ajax  true
 javax.faces.partial.event click
 javax.faces.partial.execu...  form2:j_idt8 form2:bla
 javax.faces.partial.rende...  form2:content
 javax.faces.sourceform2:j_idt8
 in myfaces
 form2:inputbla
 form2_SUBMIT  1
 javax.faces.ViewState 
 EmWJgKYkJoTEWDCzpUwZQR3Ek94rGnxK1V6NEZgO6yDgPANeOc1wplJjDYezu2cx9aQ7ZSKNPyGY 
 L8P9y5DwH2codFvGPjklD04wuxG4XXTPutNww3pdzIsMkw0=
 javax.faces.behavior.even...  action
 javax.faces.partial.ajax  true
 javax.faces.partial.event click
 javax.faces.partial.execu...  form2:bla
 javax.faces.partial.rende...  form2:content
 javax.faces.sourceform2:j_id1980473354_760ba132
 as it seems mojarra also passes the id/name of the issuing element into 
 execute per default, I have to check the spec if this is correct

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

MYFaces tests 2.0 failing on me

2010-08-05 Thread Werner Punz

Hi do we have a bug here, I have not really dug into the root of the 
problem but I assume we have a hole in what the mockups provide.
I am working on the oamsubmit issue, and also because it is connected I 
am working on double include prevention code for the ppr case.

But now I have run into this:

java.lang.IllegalArgumentException: no factory 
javax.faces.context.PartialViewContextFactory configured for this 
application.

   at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:177)
   at 
org.apache.myfaces.test.mock.MockFacesContext20.getPartialViewContext(MockFacesContext20.java:100)
   at 
org.apache.myfaces.shared_impl.renderkit.html.util.ResourceUtils.renderMyfacesJSInlineIfNecessary(ResourceUtils.java:185)



It seems to me that we do not have a PartialViewContextFactory and hence 
no PartialViewContext currently in our mockup 2.0, right?


Werner

[jira] Commented: (MYFACES-2855) jsf.js: execute id difference between myfaces and mojarra

2010-08-05 Thread Werner Punz (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12895635#action_12895635
 ] 

Werner Punz commented on MYFACES-2855:
--

uups sorry about that... 
it is fixed...


 jsf.js: execute id difference between myfaces and mojarra
 -

 Key: MYFACES-2855
 URL: https://issues.apache.org/jira/browse/MYFACES-2855
 Project: MyFaces Core
  Issue Type: Bug
Reporter: Werner Punz

  h:panelGroup id=bla
h:inputText id=inputbla 
 value=#{myBean2.searchTerm} /
h:commandLink value=Press me for more action 
 action=#{myBean2.doSearch}
f:ajax execute=bla render=content/
/h:commandLink
/h:panelGroup
 causes following output in mojarra
 form2 form2
 form2:inputbla
 javax.faces.ViewState 6697453697014869722:-1090088301633916042
 javax.faces.behavior.even...  action
 javax.faces.partial.ajax  true
 javax.faces.partial.event click
 javax.faces.partial.execu...  form2:j_idt8 form2:bla
 javax.faces.partial.rende...  form2:content
 javax.faces.sourceform2:j_idt8
 in myfaces
 form2:inputbla
 form2_SUBMIT  1
 javax.faces.ViewState 
 EmWJgKYkJoTEWDCzpUwZQR3Ek94rGnxK1V6NEZgO6yDgPANeOc1wplJjDYezu2cx9aQ7ZSKNPyGY 
 L8P9y5DwH2codFvGPjklD04wuxG4XXTPutNww3pdzIsMkw0=
 javax.faces.behavior.even...  action
 javax.faces.partial.ajax  true
 javax.faces.partial.event click
 javax.faces.partial.execu...  form2:bla
 javax.faces.partial.rende...  form2:content
 javax.faces.sourceform2:j_id1980473354_760ba132
 as it seems mojarra also passes the id/name of the issuing element into 
 execute per default, I have to check the spec if this is correct

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (MYFACES-2859) Replacing elements for ajax response changes element order

2010-08-05 Thread Werner Punz (JIRA)


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

Werner Punz updated MYFACES-2859:
-

   Status: Resolved  (was: Patch Available)
Fix Version/s: 2.0.2-SNAPSHOT
   Resolution: Fixed

patch is applied thanks for sending it in


 Replacing elements for ajax response changes element order
 --

 Key: MYFACES-2859
 URL: https://issues.apache.org/jira/browse/MYFACES-2859
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.1, 2.0.2-SNAPSHOT
Reporter: Michael Kurz
 Fix For: 2.0.2-SNAPSHOT

 Attachments: MYFACES-2859-test-webapp.zip, MYFACES-2859.patch


 In my application processing the ajax response for a ajax request changes the 
 order of the elements. I have an html input element with siblings in a div 
 that is replaced with a script and the new input element in the ajax 
 response. The problem is, that the new input element is inserted after the 
 siblings of the original element thus reversing the order of the elements
 I think the problem is in the replaceElements function in _Dom.js. There, 
 oldNode.nextSibling always returns null.
 I created a patch that solves this issue, but I am not sure if there are any 
 side effects. Master of Ajax (Werner) please have a look.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: MYFaces tests 2.0 failing on me

have you done an svn up on the test project?
Last week it caused also a build failure.

-M

On Thu, Aug 5, 2010 at 12:09 PM, Werner Punz werner.p...@gmail.com wrote:
 Hi do we have a bug here, I have not really dug into the root of the problem
 but I assume we have a hole in what the mockups provide.
 I am working on the oamsubmit issue, and also because it is connected I am
 working on double include prevention code for the ppr case.
 But now I have run into this:

 java.lang.IllegalArgumentException: no factory
 javax.faces.context.PartialViewContextFactory configured for this
 application.
   at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:177)
   at
 org.apache.myfaces.test.mock.MockFacesContext20.getPartialViewContext(MockFacesContext20.java:100)
   at
 org.apache.myfaces.shared_impl.renderkit.html.util.ResourceUtils.renderMyfacesJSInlineIfNecessary(ResourceUtils.java:185)


 It seems to me that we do not have a PartialViewContextFactory and hence no
 PartialViewContext currently in our mockup 2.0, right?

 Werner






-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: MYFaces tests 2.0 failing on me

2010-08-05 Thread Werner Punz


Nada, I just use whatever is defined by the maven poms in the core project.

The failure occurred due to my code, but the code from me is correct
the test fails illegally here because it cannot get the 
PartialViewContextFactory, which should be present by JSF2 definition.
My code just triggered it because it probably was the first component 
related code which tried to reach the PartialViewContext.


Werner


Am 05.08.10 12:22, schrieb Matthias Wessendorf:

have you done an svn up on the test project?
Last week it caused also a build failure.

-M

On Thu, Aug 5, 2010 at 12:09 PM, Werner Punzwerner.p...@gmail.com  wrote:

Hi do we have a bug here, I have not really dug into the root of the problem
but I assume we have a hole in what the mockups provide.
I am working on the oamsubmit issue, and also because it is connected I am
working on double include prevention code for the ppr case.
But now I have run into this:

java.lang.IllegalArgumentException: no factory
javax.faces.context.PartialViewContextFactory configured for this
application.
   at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:177)
   at
org.apache.myfaces.test.mock.MockFacesContext20.getPartialViewContext(MockFacesContext20.java:100)
   at
org.apache.myfaces.shared_impl.renderkit.html.util.ResourceUtils.renderMyfacesJSInlineIfNecessary(ResourceUtils.java:185)


It seems to me that we do not have a PartialViewContextFactory and hence no
PartialViewContext currently in our mockup 2.0, right?

Werner

Re: Ann: MyFaces Ajax Fileupload and how to use it

2010-08-05 Thread Martin Marinschek

Hi guys,

I am saying this in a broader scope - not only for the AJAX features.
But our AJAX features which do make sense out of the box (and this one
does) could also be enabled like this.

best regards,

Martin

On 8/2/10, Werner Punz werner.p...@gmail.com wrote:
 Hi Martin this would make only sense if we had a bunch of features which
 can be turned on via such a switch, which we don´t from my perspective
 because the queue control features which we have internally
 cannot be turned on switch like but have to be configured with params
 like myfaces.config.delay = 300

 What maybe would make sense is some kind of myfaces:ajax tag which is an
 extended f:ajax tag which exposes all new features.

 something along the lines of

 myfaces:ajax delay=300 timeout200 execute=... render=... /




 Werner



 Am 01.08.10 21:42, schrieb Martin Marinschek:
 Perfect.

 Can we talk about having the context param STRICT_COMPATIBILITY_MODE
 again, where this is disabled, and if the param is set to false, this
 feature is enabled?

 best regards,

 Martin

 On 7/30/10, Jakob Korherrjakob.korh...@gmail.com  wrote:
 Really great, Werner!

 2010/7/30 Hazem Salehhaz...@apache.org

 Wonderful!



 On Fri, Jul 30, 2010 at 2:10 PM, Matthias Wessendorf
 mat...@apache.orgwrote:

 kick ass!

 great stuff, Werner!

 -Matthias

 On Fri, Jul 30, 2010 at 12:58 PM, Werner Punzwerner.p...@gmail.com
 wrote:
 Hello, as some people might have noticed I recently integrated the
 Ajax
 fileupload into our trunk (2.0.2-SNAPSHOT), I also gave the code to
 the
 JSF
 EG so that it might be part of JSF 2.1 or the base for a similar
 functionality.
 The code changes itself are:

 a) A small patch on the myfaces side to detect the partoal fileupload
 case
 as ajax cycle

 b) Extensions to our scripts which currently are only enabled in dev
 mode
 (it still is up for discussion whether we should enable it for prod or
 not
 since they are non standard)


 Here is what you have to do:

 First turn your server on into development mode via:
 context-param
 param-namejavax.faces.PROJECT_STAGE/param-name
 param-valueDevelopment/param-value
 /context-param

 Then use the code like I do in my working testcase:
 http://www.pastebin.org/432572

 the important thing is following line:

 script type=text/javascript
  myfaces.config =  myfaces.config || {};
  myfaces.config[transportAutoSelection] = true;
 /script
 This enables the auto transport selection, which switches to an iframe
 submit in case of a file uploading form submit.
 This switch cannot be enabled by default because it would break the
 spec
 requirements that an xhr post has to be performed at all costs.

 Also xhr level2 is out of the question for now because it is only
 supported
 by the newest browsers.

 After that it is straight forward, you can use the fileupload
 component
 from
 Tomahawk 2 for instance, it should work straight out of the box.

 I also did a servlet 3.0 fileupload component for prototyping but the
 code
 is too flakey yet (mainly due to spec deficits less due to the
 component
 itself) and I cannot really commit it into the core. Instead I made
 sure
 that the standard fileupload components perform ok.
 So it is ready to be used at least from my point of view, but have in
 mind
 all this will break compatibility to Mojarra if you use it.

 So using it means you are bound to MyFaces, which is something I do
 not
 particularily recommend (hence also donating the prototype code to the
 EG, I
 want something like this in the spec)

 Here again is the pastebin to all relevant files:

 http://www.pastebin.org/432572
 http://www.pastebin.org/432586 for the relevant bean.
 If your fileupload is correctly configured this code should work out
 of
 the
 box.




 Werner







 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf




 --
 Hazem Ahmed Saleh Ahmed

 Author of (The Definitive Guide to Apache MyFaces and Facelets):

 http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370
 http://www.amazon.com/-/e/B002M052KY

 Web blog: http://hazems.blogetery.com/

 [Web 2.0] Mashups Integration with JSF:
 http://code.google.com/p/mashups4jsf/




 --
 Jakob Korherr

 blog: http://www.jakobk.com
 twitter: http://twitter.com/jakobkorherr
 work: http://www.irian.at










-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Ann: MyFaces Ajax Fileupload and how to use it

2010-08-05 Thread Werner Punz

Btw. Martin, I already gave Ed all the needed info and code on how to 
implement it so that they can get everything into the spec for 2.1 
(which hopefully will happen)


I think the entire issue of not being able to support a fileupload in 
the non ajax and ajax case in stock jsf has been going on for way too long.


Roger Kitain also has my proposals for the queue control, I dont know 
what the status on this is, since the richfaces guys have something very 
similar but with the addition of being able to have multiple queues
(which btw. opens a can of worms regarding the component tree 
synchronisation and viewstate handling)



Werner




Am 05.08.10 12:38, schrieb Martin Marinschek:

Hi guys,

I am saying this in a broader scope - not only for the AJAX features.
But our AJAX features which do make sense out of the box (and this one
does) could also be enabled like this.

best regards,

Martin

On 8/2/10, Werner Punzwerner.p...@gmail.com  wrote:

Hi Martin this would make only sense if we had a bunch of features which
can be turned on via such a switch, which we don´t from my perspective
because the queue control features which we have internally
cannot be turned on switch like but have to be configured with params
like myfaces.config.delay = 300

What maybe would make sense is some kind of myfaces:ajax tag which is an
extended f:ajax tag which exposes all new features.

something along the lines of

myfaces:ajax delay=300 timeout200 execute=... render=... /




Werner



Am 01.08.10 21:42, schrieb Martin Marinschek:

Perfect.

Can we talk about having the context param STRICT_COMPATIBILITY_MODE
again, where this is disabled, and if the param is set to false, this
feature is enabled?

best regards,

Martin

On 7/30/10, Jakob Korherrjakob.korh...@gmail.com   wrote:

Really great, Werner!

2010/7/30 Hazem Salehhaz...@apache.org


Wonderful!



On Fri, Jul 30, 2010 at 2:10 PM, Matthias Wessendorf
mat...@apache.orgwrote:


kick ass!

great stuff, Werner!

-Matthias

On Fri, Jul 30, 2010 at 12:58 PM, Werner Punzwerner.p...@gmail.com
wrote:

Hello, as some people might have noticed I recently integrated the
Ajax
fileupload into our trunk (2.0.2-SNAPSHOT), I also gave the code to
the

JSF

EG so that it might be part of JSF 2.1 or the base for a similar
functionality.
The code changes itself are:

a) A small patch on the myfaces side to detect the partoal fileupload

case

as ajax cycle

b) Extensions to our scripts which currently are only enabled in dev

mode

(it still is up for discussion whether we should enable it for prod or

not

since they are non standard)


Here is what you have to do:

First turn your server on into development mode via:
 context-param
 param-namejavax.faces.PROJECT_STAGE/param-name
 param-valueDevelopment/param-value
 /context-param

Then use the code like I do in my working testcase:
http://www.pastebin.org/432572

the important thing is following line:

script type=text/javascript
  myfaces.config =  myfaces.config || {};
  myfaces.config[transportAutoSelection] = true;
/script
This enables the auto transport selection, which switches to an iframe
submit in case of a file uploading form submit.
This switch cannot be enabled by default because it would break the
spec
requirements that an xhr post has to be performed at all costs.

Also xhr level2 is out of the question for now because it is only

supported

by the newest browsers.

After that it is straight forward, you can use the fileupload
component

from

Tomahawk 2 for instance, it should work straight out of the box.

I also did a servlet 3.0 fileupload component for prototyping but the

code

is too flakey yet (mainly due to spec deficits less due to the
component
itself) and I cannot really commit it into the core. Instead I made
sure
that the standard fileupload components perform ok.
So it is ready to be used at least from my point of view, but have in

mind

all this will break compatibility to Mojarra if you use it.

So using it means you are bound to MyFaces, which is something I do
not
particularily recommend (hence also donating the prototype code to the

EG, I

want something like this in the spec)

Here again is the pastebin to all relevant files:

http://www.pastebin.org/432572
http://www.pastebin.org/432586 for the relevant bean.
If your fileupload is correctly configured this code should work out
of

the

box.




Werner








--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf





--
Hazem Ahmed Saleh Ahmed

Author of (The Definitive Guide to Apache MyFaces and Facelets):

http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370
http://www.amazon.com/-/e/B002M052KY

Web blog: http://hazems.blogetery.com/

[Web 2.0] Mashups Integration with JSF:
http://code.google.com/p/mashups4jsf/





--
Jakob Korherr

blog: http://www.jakobk.com
twitter:

Re: MyFaces shipping with JBoss AS6?

2010-08-05 Thread ssilvert

That's OK. I guess I can do the SPI implementations on my end but it
might not make it into JBoss AS6 GA. Let's concentrate on the MyFaces
SPI's for now. How does MyFaces handle the SPI's like Mojarra has?
I'm sure it's OK to look at Mojarra code since it's GPL2, right? If
not, you can look at JavaDoc. We need something similar to:

com.sun.faces.spi.InjectionProvider
https://mojarra.dev.java.net/source/browse/mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/spi/InjectionProvider.java

com.sun.faces.spi.AnnotationProvider
https://mojarra.dev.java.net/source/browse/mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/spi/AnnotationProvider.java

Stan

Quoting Matthias Wessendorf mat...@apache.org:

At Apache we can not have code that contains (L)GPL code; or depends on it.

We had discussion(s) about this in the past. The below link contains
references

to other (Apache) documents:

http://markmail.org/message/qtc4g6vsracgzbok

-Matthias

On Thu, Aug 5, 2010 at 9:55 AM, Jan-Kees van Andel
jankeesvanan...@gmail.com wrote:

Hi,

Great news! It would be very nice if JBoss ships with MyFaces 2. This also
opens up possibilities to do some enhancements to increase developer
productivity in JBoss, like better resource reloading and so on. Or doing
some things more efficient by plugging into the JBoss infrastructure. Just
thinking out loud... :)

One thing about the JBoss SVN link Stan sent. I took a quick peek at the
license header in a Java file and saw that it's LGPL licensed. AFAIK, this
is not compatible with ASL, so I suggest to not look at the code while
implementing the stuff Stan asked for.

WDYT?

Regards,
Jan-Kees

2010/8/5 Matthias Wessendorf mat...@apache.org

Hello Stan,

welcome back. We do understand that you can not make any promise on that
topic.
The fact that some folks at JBoss are thinking about shipping MyFaces
(as an alternative option)
is a good news for this entire community here. Especially it is a
great motivation for the
folks that did the main work on ensuring Apache MyFaces 2.x is a great
success.

On the missing pieces: I am sure that there will be some interested in
working on them.

Thanks,
Matthias Wessendorf
PMC Chair Apache MyFaces

On Wed, Aug 4, 2010 at 8:42 PM, ssilv...@redhat.com wrote:
Hi guys,

Would you like to see MyFaces Core ship with JBoss AS6? If so, read on.

If you've been around MyFaces awhile, you probably remember that JBoass
AS
used to ship with MyFaces instead of Mojarra. It was regrettable, but
at
the time Mojarra was far ahead spec-wise and the powers that be decided
my
time would be better spent integrating Mojarra instead of improving
MyFaces.

However, with JBoss AS6 M4, this is no longer an either or
proposition.
Both MyFaces and Mojarra can live side-by-side. The application can
decide
which implementation to use:
http://community.jboss.org/wiki/JSFonJBossAS6

What's more, changing the default JSF implementation for AS6 is just a
matter of changing the defaultJSFConfig property in an XML file.

I've talked internally at JBoss about adding MyFaces to the JBoss AS
community distribution. Some were for it, and some were very, very for
it.
Nobody so far is against it.

The good part is that I don't think it's a lot of work. It's probably
just
three or four classes that implement SPI's that I'm guessing MyFaces
already
has.

So this is where the MyFaces Dev group comes in. MyFaces Core 2.0 will
run
OK on JBoss AS6 right now. However, there is some integration work that
is
needed for full JEE5 and JEE6 compliance. We need:
* An injection provider SPI similar to Mojarra's
com.sun.faces.spi.InjectionProvider.
* The JBoss/MyFaces implementation of the SPI. I expect this will be
very
similar to

org.jboss.web.jsf.integration.injection.JBossDelegatingInjectionProvider.
* An AnnotationProvider SPI similar to Mojarra's
com.sun.faces.spi.AnnotationProvider.
* A JBoss/MyFaces implementation of the SPI similar to
org.jboss.web.jsf.integration.config.JBossAnnotationProvider.
* A ServletContextListener class to call for initialization. I expect
this
will extend from MyFacesServletContextListener and be very similar to
org.jboss.web.jsf.integration.config.JBossMojarra20ConfigureListener.

If MyFaces Dev decides to take this on, then the code will probably live
at
Apache and I'll bring it into JBoss AS using Maven. I don't have time
to
write and maintain the code myself but I'm happy to help out with
guidance
and to do some refactoring of my code to make this easier. BTW, the
JBoss/Mojarra integration code lives here:

http://anonsvn.jboss.org/repos/jbossas/projects/jboss-jsf-int/trunk/jboss-faces/

Lastly, let me say that I can't make hard promises right now. I don't
know
if someone at JBoss/RedHat will come along and nix the idea. However,
even
if we can't ship MyFaces you will have all the integration points ready
and
have an easy way to drop in MyFaces whenever you want

Re: MyFaces shipping with JBoss AS6?

Well, looking at the RI is for sure not OK.

I didn't see a problem with the previous provided links (the JBoss
code), however
I have not opened any of the provided links yet.

-Matthias

On Thu, Aug 5, 2010 at 1:54 PM, ssilv...@redhat.com wrote:
That's OK. I guess I can do the SPI implementations on my end but it might
not make it into JBoss AS6 GA. Let's concentrate on the MyFaces SPI's for
now. How does MyFaces handle the SPI's like Mojarra has? I'm sure it's OK
to look at Mojarra code since it's GPL2, right? If not, you can look at
JavaDoc. We need something similar to:

com.sun.faces.spi.InjectionProvider
https://mojarra.dev.java.net/source/browse/mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/spi/InjectionProvider.java

com.sun.faces.spi.AnnotationProvider
https://mojarra.dev.java.net/source/browse/mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/spi/AnnotationProvider.java

Stan

Quoting Matthias Wessendorf mat...@apache.org:

At Apache we can not have code that contains (L)GPL code; or depends on
it.

We had discussion(s) about this in the past. The below link contains
references
to other (Apache) documents:

http://markmail.org/message/qtc4g6vsracgzbok

-Matthias

On Thu, Aug 5, 2010 at 9:55 AM, Jan-Kees van Andel
jankeesvanan...@gmail.com wrote:

Hi,

Great news! It would be very nice if JBoss ships with MyFaces 2. This
also
opens up possibilities to do some enhancements to increase developer
productivity in JBoss, like better resource reloading and so on. Or doing
some things more efficient by plugging into the JBoss infrastructure.
Just
thinking out loud... :)

One thing about the JBoss SVN link Stan sent. I took a quick peek at the
license header in a Java file and saw that it's LGPL licensed. AFAIK,
this
is not compatible with ASL, so I suggest to not look at the code while
implementing the stuff Stan asked for.

WDYT?

Regards,
Jan-Kees

2010/8/5 Matthias Wessendorf mat...@apache.org

Hello Stan,

On the missing pieces: I am sure that there will be some interested in
working on them.

Thanks,
Matthias Wessendorf
PMC Chair Apache MyFaces

On Wed, Aug 4, 2010 at 8:42 PM, ssilv...@redhat.com wrote:
Hi guys,

Would you like to see MyFaces Core ship with JBoss AS6? If so, read
on.

If you've been around MyFaces awhile, you probably remember that
JBoass
AS
used to ship with MyFaces instead of Mojarra. It was regrettable, but
at
the time Mojarra was far ahead spec-wise and the powers that be
decided
my
time would be better spent integrating Mojarra instead of improving
MyFaces.

What's more, changing the default JSF implementation for AS6 is just a
matter of changing the defaultJSFConfig property in an XML file.

I've talked internally at JBoss about adding MyFaces to the JBoss AS
community distribution. Some were for it, and some were very, very
for
it.
Nobody so far is against it.

The good part is that I don't think it's a lot of work. It's probably
just
three or four classes that implement SPI's that I'm guessing MyFaces
already
has.

So this is where the MyFaces Dev group comes in. MyFaces Core 2.0
will
run
OK on JBoss AS6 right now. However, there is some integration work
that
is
needed for full JEE5 and JEE6 compliance. We need:
* An injection provider SPI similar to Mojarra's
com.sun.faces.spi.InjectionProvider.
* The JBoss/MyFaces implementation of the SPI. I expect this will be
very
similar to

If MyFaces Dev decides to take this on, then the code will probably
live
at
Apache and I'll bring it into JBoss AS using Maven. I don't have time
to
write and maintain the code myself but I'm happy to help out with
guidance
and to do some refactoring of my code to make this easier. BTW, the
JBoss/Mojarra integration code lives here:

Re: MyFaces shipping with JBoss AS6?

Somehow I think there was already work/discussion about it, based on a
Tomcat interface.
It for sure does bring back some fragile memory. Let me think...

On Thu, Aug 5, 2010 at 2:09 PM, Matthias Wessendorf mat...@apache.org wrote:
Well, looking at the RI is for sure not OK.

I didn't see a problem with the previous provided links (the JBoss
code), however
I have not opened any of the provided links yet.

-Matthias

com.sun.faces.spi.InjectionProvider
https://mojarra.dev.java.net/source/browse/mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/spi/InjectionProvider.java

com.sun.faces.spi.AnnotationProvider
https://mojarra.dev.java.net/source/browse/mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/spi/AnnotationProvider.java

Stan

Quoting Matthias Wessendorf mat...@apache.org:

At Apache we can not have code that contains (L)GPL code; or depends on
it.

We had discussion(s) about this in the past. The below link contains
references
to other (Apache) documents:

http://markmail.org/message/qtc4g6vsracgzbok

-Matthias

On Thu, Aug 5, 2010 at 9:55 AM, Jan-Kees van Andel
jankeesvanan...@gmail.com wrote:

Hi,

Great news! It would be very nice if JBoss ships with MyFaces 2. This
also
opens up possibilities to do some enhancements to increase developer
productivity in JBoss, like better resource reloading and so on. Or doing
some things more efficient by plugging into the JBoss infrastructure.
Just
thinking out loud... :)

One thing about the JBoss SVN link Stan sent. I took a quick peek at the
license header in a Java file and saw that it's LGPL licensed. AFAIK,
this
is not compatible with ASL, so I suggest to not look at the code while
implementing the stuff Stan asked for.

WDYT?

Regards,
Jan-Kees

2010/8/5 Matthias Wessendorf mat...@apache.org

Hello Stan,

On the missing pieces: I am sure that there will be some interested in
working on them.

Thanks,
Matthias Wessendorf
PMC Chair Apache MyFaces

On Wed, Aug 4, 2010 at 8:42 PM, ssilv...@redhat.com wrote:
Hi guys,

Would you like to see MyFaces Core ship with JBoss AS6? If so, read
on.

If you've been around MyFaces awhile, you probably remember that
JBoass
AS
used to ship with MyFaces instead of Mojarra. It was regrettable, but
at
the time Mojarra was far ahead spec-wise and the powers that be
decided
my
time would be better spent integrating Mojarra instead of improving
MyFaces.

What's more, changing the default JSF implementation for AS6 is just a
matter of changing the defaultJSFConfig property in an XML file.

I've talked internally at JBoss about adding MyFaces to the JBoss AS
community distribution. Some were for it, and some were very, very
for
it.
Nobody so far is against it.

The good part is that I don't think it's a lot of work. It's probably
just
three or four classes that implement SPI's that I'm guessing MyFaces
already
has.

So this is where the MyFaces Dev group comes in. MyFaces Core 2.0
will
run
OK on JBoss AS6 right now. However, there is some integration work
that
is
needed for full JEE5 and JEE6 compliance. We need:
* An injection provider SPI similar to Mojarra's
com.sun.faces.spi.InjectionProvider.
* The JBoss/MyFaces implementation of the SPI. I expect this will be
very
similar to

If MyFaces Dev decides to take this on, then the code will probably
live
at
Apache and I'll bring it into JBoss AS using

Re: MyFaces shipping with JBoss AS6?

2010-08-05 Thread ssilvert

Can you look at javadoc comments?

Quoting Matthias Wessendorf mat...@apache.org:

Well, looking at the RI is for sure not OK.

I didn't see a problem with the previous provided links (the JBoss
code), however
I have not opened any of the provided links yet.

-Matthias

On Thu, Aug 5, 2010 at 1:54 PM, ssilv...@redhat.com wrote:

That's OK. I guess I can do the SPI implementations on my end but it might
not make it into JBoss AS6 GA. Let's concentrate on the MyFaces SPI's for
now. How does MyFaces handle the SPI's like Mojarra has? I'm sure it's OK
to look at Mojarra code since it's GPL2, right? If not, you can look at
JavaDoc. We need something similar to:

com.sun.faces.spi.InjectionProvider
https://mojarra.dev.java.net/source/browse/mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/spi/InjectionProvider.java

com.sun.faces.spi.AnnotationProvider
https://mojarra.dev.java.net/source/browse/mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/spi/AnnotationProvider.java

Stan

Quoting Matthias Wessendorf mat...@apache.org:

At Apache we can not have code that contains (L)GPL code; or depends on
it.

We had discussion(s) about this in the past. The below link contains
references
to other (Apache) documents:

http://markmail.org/message/qtc4g6vsracgzbok

-Matthias

On Thu, Aug 5, 2010 at 9:55 AM, Jan-Kees van Andel
jankeesvanan...@gmail.com wrote:

Hi,

Great news! It would be very nice if JBoss ships with MyFaces 2. This
also
opens up possibilities to do some enhancements to increase developer
productivity in JBoss, like better resource reloading and so on. Or doing
some things more efficient by plugging into the JBoss infrastructure.
Just
thinking out loud... :)

One thing about the JBoss SVN link Stan sent. I took a quick peek at the
license header in a Java file and saw that it's LGPL licensed. AFAIK,
this
is not compatible with ASL, so I suggest to not look at the code while
implementing the stuff Stan asked for.

WDYT?

Regards,
Jan-Kees

2010/8/5 Matthias Wessendorf mat...@apache.org

Hello Stan,

On the missing pieces: I am sure that there will be some interested in
working on them.

Thanks,
Matthias Wessendorf
PMC Chair Apache MyFaces

On Wed, Aug 4, 2010 at 8:42 PM, ssilv...@redhat.com wrote:
Hi guys,

Would you like to see MyFaces Core ship with JBoss AS6? If so, read
on.

If you've been around MyFaces awhile, you probably remember that
JBoass
AS
used to ship with MyFaces instead of Mojarra. It was regrettable, but
at
the time Mojarra was far ahead spec-wise and the powers that be
decided
my
time would be better spent integrating Mojarra instead of improving
MyFaces.

What's more, changing the default JSF implementation for AS6 is just a
matter of changing the defaultJSFConfig property in an XML file.

I've talked internally at JBoss about adding MyFaces to the JBoss AS
community distribution. Some were for it, and some were very, very
for
it.
Nobody so far is against it.

The good part is that I don't think it's a lot of work. It's probably
just
three or four classes that implement SPI's that I'm guessing MyFaces
already
has.

So this is where the MyFaces Dev group comes in. MyFaces Core 2.0
will
run
OK on JBoss AS6 right now. However, there is some integration work
that
is
needed for full JEE5 and JEE6 compliance. We need:
* An injection provider SPI similar to Mojarra's
com.sun.faces.spi.InjectionProvider.
* The JBoss/MyFaces implementation of the SPI. I expect this will be
very
similar to

org.jboss.web.jsf.integration.injection.JBossDelegatingInjectionProvider.

* An AnnotationProvider SPI similar to Mojarra's
com.sun.faces.spi.AnnotationProvider.
* A JBoss/MyFaces implementation of the SPI similar to
org.jboss.web.jsf.integration.config.JBossAnnotationProvider.
* A ServletContextListener class to call for initialization. I expect
this
will extend from MyFacesServletContextListener and be very similar to
org.jboss.web.jsf.integration.config.JBossMojarra20ConfigureListener.

If MyFaces Dev decides to take this on, then the code will probably
live
at
Apache and I'll bring it into JBoss AS using Maven. I don't have time
to
write and maintain the code myself but I'm happy to help out with
guidance
and to do some refactoring of my code to make this easier. BTW, the
JBoss/Mojarra integration code lives here:

Re: MyFaces shipping with JBoss AS6?

2010-08-05 Thread Leonardo Uribe

Hi

2010/8/4 ssilv...@redhat.com

 Hi guys,

 Would you like to see MyFaces Core ship with JBoss AS6?  If so, read on.


This is top priority for me.


 If you've been around MyFaces awhile, you probably remember that JBoass AS
 used to ship with MyFaces instead of Mojarra.  It was regrettable, but at
 the time Mojarra was far ahead spec-wise and the powers that be decided my
 time would be better spent integrating Mojarra instead of improving MyFaces.

 However, with JBoss AS6 M4, this is no longer an either or proposition.
  Both MyFaces and Mojarra can live side-by-side.  The application can decide
 which implementation to use: http://community.jboss.org/wiki/JSFonJBossAS6

 What's more, changing the default JSF implementation for AS6 is just a
 matter of changing the defaultJSFConfig property in an XML file.

 I've talked internally at JBoss about adding MyFaces to the JBoss AS
 community distribution.  Some were for it, and some were very, very for it.
  Nobody so far is against it.

 The good part is that I don't think it's a lot of work.  It's probably just
 three or four classes that implement SPI's that I'm guessing MyFaces already
 has.

 So this is where the MyFaces Dev group comes in.  MyFaces Core 2.0 will run
 OK on JBoss AS6 right now.  However, there is some integration work that is
 needed for full JEE5 and JEE6 compliance.  We need:
 * An injection provider SPI similar to Mojarra's
 com.sun.faces.spi.InjectionProvider.
 * The JBoss/MyFaces implementation of the SPI.  I expect this will be very
 similar to
 org.jboss.web.jsf.integration.injection.JBossDelegatingInjectionProvider.


In myfaces we have a factory called
org.apache.myfaces.config.annotation.LifecycleProviderFactory. We have also
an interface called LifecycleProvider2 with these methods:

/**
 * Create an object of the class with the supplied name, inject
dependencies as appropriate,
 * and call a postContruct method as appropriate.
 *
 * @param className name of the class of the desired object
 * @return a fully constructed, dependency-injected, and initialized
object.
 */
Object newInstance(String className) throws ClassNotFoundException,
IllegalAccessException, InstantiationException, NamingException,
InvocationTargetException;

/**
 * Take whatever steps are needed to shut down the object, including
calling a preDestroy method.
 *
 * @param o object to shut down.
 */
void destroyInstance(Object o) throws IllegalAccessException,
InvocationTargetException;

/**
 * Call a postConstruct method as appropriate.
 *
 * @param o object to initialize
 */
void postConstruct(Object o) throws IllegalAccessException,
InvocationTargetException;

Checking com.sun.faces.spi package, it is similar to InjectionProvider. Note
com.sun.faces.spi has a method called:

public  void inject(Object managedBean) throws
InjectionProviderException

but myfaces has:

public Object newInstance(String className)


 * An AnnotationProvider SPI similar to Mojarra's
 com.sun.faces.spi.AnnotationProvider.

* A JBoss/MyFaces implementation of the SPI similar to
 org.jboss.web.jsf.integration.config.JBossAnnotationProvider.


We don't have anything similar to AnnotationProvider. I'll create an issue
for this one.


 * A ServletContextListener class to call for initialization.  I expect this
 will extend from MyFacesServletContextListener and be very similar to
 org.jboss.web.jsf.integration.config.JBossMojarra20ConfigureListener.


The class you are looking for is
org.apache.myfaces.webapp.StartupServletContextListener

regards,

Leonardo Uribe


 If MyFaces Dev decides to take this on, then the code will probably live at
 Apache and I'll bring it into JBoss AS using Maven.  I don't have time to
 write and maintain the code myself but I'm happy to help out with guidance
 and to do some refactoring of my code to make this easier.  BTW, the
 JBoss/Mojarra integration code lives here:
 http://anonsvn.jboss.org/repos/jbossas/projects/jboss-jsf-int/trunk/jboss-faces/

 Lastly, let me say that I can't make hard promises right now.  I don't know
 if someone at JBoss/RedHat will come along and nix the idea.  However, even
 if we can't ship MyFaces you will have all the integration points ready and
 have an easy way to drop in MyFaces whenever you want to use it with JBoss
 AS.


WDYT??

[jira] Created: (MYFACES-2860) Provide AnnotationScanner interface

Provide AnnotationScanner interface
---

 Key: MYFACES-2860
 URL: https://issues.apache.org/jira/browse/MYFACES-2860
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-314
Affects Versions: 2.0.1
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Looking integration of myfaces with JBoss AS6, it was notice myfaces does not 
have a way to override the annotation configurator.

Ri has a class called AnnotationProvider with this methods:

public AnnotationProvider(ServletContext sc) 

abstract public Map? getAnnotatedClasses(SetURL urls)

the documentation says it is possible to override using this type of 
constructor.

public AnnotationProvider(ServletContext sc, AnnotationProvider parent)

We should provide something similar (let's call it AnnotationScanner because 
its objective is scan for annotations).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: MyFaces shipping with JBoss AS6?

2010-08-05 Thread ssilvert

Quoting David Jencks david_jen...@yahoo.com:

I haven't and wont look at the mojarra code but I think you are looking for

org.apache.myfaces.config.annotation.LifecycleProvider

Looks like that takes care of spec section 5.4 (injection,
@PreDestroy, @PostConstruct).

How do you deal with section 11.5? This is for finding resource
annotations like @ManagedBean or @FacesValidator. I'm assuming that
MyFaces does this on its own, but if so it would mean that a lot of
stuff gets scanned multiple times by various components like Tomcat.

Stan

Geronimo has been trying to get everyone to standardize on this
style of interface as it lets the implementor support constructor
injection transparently.

Geronimo's implementations of this use xbean-reflect which provides
a handy way to stuff in all the properties and get a fully
configured object back.

thanks
david jencks

On Aug 5, 2010, at 5:12 AM, Matthias Wessendorf wrote:

Somehow I think there was already work/discussion about it, based on a
Tomcat interface.
It for sure does bring back some fragile memory. Let me think...

On Thu, Aug 5, 2010 at 2:09 PM, Matthias Wessendorf
mat...@apache.org wrote:

Well, looking at the RI is for sure not OK.

I didn't see a problem with the previous provided links (the JBoss
code), however
I have not opened any of the provided links yet.

-Matthias

On Thu, Aug 5, 2010 at 1:54 PM, ssilv...@redhat.com wrote:
That's OK. I guess I can do the SPI implementations on my end
but it might

not make it into JBoss AS6 GA. Let's concentrate on the MyFaces SPI's for
now. How does MyFaces handle the SPI's like Mojarra has? I'm
sure it's OK

to look at Mojarra code since it's GPL2, right? If not, you can look at
JavaDoc. We need something similar to:

com.sun.faces.spi.InjectionProvider
https://mojarra.dev.java.net/source/browse/mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/spi/InjectionProvider.java

com.sun.faces.spi.AnnotationProvider
https://mojarra.dev.java.net/source/browse/mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/spi/AnnotationProvider.java

Stan

Quoting Matthias Wessendorf mat...@apache.org:

At Apache we can not have code that contains (L)GPL code; or depends on
it.

We had discussion(s) about this in the past. The below link contains
references
to other (Apache) documents:

http://markmail.org/message/qtc4g6vsracgzbok

-Matthias

On Thu, Aug 5, 2010 at 9:55 AM, Jan-Kees van Andel
jankeesvanan...@gmail.com wrote:

Hi,

some things more efficient by plugging into the JBoss infrastructure.
Just
thinking out loud... :)

One thing about the JBoss SVN link Stan sent. I took a quick peek at the
license header in a Java file and saw that it's LGPL licensed. AFAIK,
this
is not compatible with ASL, so I suggest to not look at the code while
implementing the stuff Stan asked for.

WDYT?

Regards,
Jan-Kees

2010/8/5 Matthias Wessendorf mat...@apache.org

Hello Stan,

welcome back. We do understand that you can not make any
promise on that

topic.
The fact that some folks at JBoss are thinking about shipping MyFaces
(as an alternative option)
is a good news for this entire community here. Especially it is a
great motivation for the
folks that did the main work on ensuring Apache MyFaces 2.x is a great
success.

On the missing pieces: I am sure that there will be some interested in
working on them.

Thanks,
Matthias Wessendorf
PMC Chair Apache MyFaces

On Wed, Aug 4, 2010 at 8:42 PM, ssilv...@redhat.com wrote:

Hi guys,

Would you like to see MyFaces Core ship with JBoss AS6? If so, read
on.

If you've been around MyFaces awhile, you probably remember that
JBoass
AS
used to ship with MyFaces instead of Mojarra. It was regrettable, but
at
the time Mojarra was far ahead spec-wise and the powers that be
decided
my
time would be better spent integrating Mojarra instead of improving
MyFaces.

What's more, changing the default JSF implementation for AS6 is just a
matter of changing the defaultJSFConfig property in an XML file.

I've talked internally at JBoss about adding MyFaces to the JBoss AS
community distribution. Some were for it, and some were very, very
for
it.
Nobody so far is against it.

The good part is that I don't think it's a lot of work. It's probably
just
three or four classes that implement SPI's that I'm guessing MyFaces
already
has.

So this is where the MyFaces Dev group comes in. MyFaces Core 2.0
will
run
OK on JBoss AS6 right now. However, there is some integration work
that
is
needed for full JEE5 and JEE6

[jira] Created: (PORTLETBRIDGE-161) Portlet 2.0 Bridge doesn't properly encode portlet:resource syntax to a faces View

Portlet 2.0 Bridge doesn't properly encode portlet:resource syntax to a faces 
View
--

 Key: PORTLETBRIDGE-161
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-161
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-beta
Reporter: Michael Freedman
Assignee: Michael Freedman


the special QS params for ViewId and ViewPath only work for subsequent 
action/render URLs -- in case of resources it doesn't currently look for/at 
these.  Maybe it should?  In any case -- just need to fix up the imp to 
properly encode a resource URL to a faces view using this syntax.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: MyFaces shipping with JBoss AS6?

2010-08-05 Thread Jan-Kees van Andel

MyFaces has an AnnotationConfigurator [1] which scans the classpath using a
simple bytecode scanning mechanism [2] (comparable with the one in
Javassist). It's pretty fast, but it's true that classes might be scanned
twice.

Regards,
Jan-Kees

[1]
http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/config/annotation/AnnotationConfigurator.java
[2]
http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/config/annotation/_ClassByteCodeAnnotationFilter.java

2010/8/5 ssilv...@redhat.com

Quoting David Jencks david_jen...@yahoo.com:

I haven't and wont look at the mojarra code but I think you are looking
for

org.apache.myfaces.config.annotation.LifecycleProvider

Looks like that takes care of spec section 5.4 (injection, @PreDestroy,
@PostConstruct).

How do you deal with section 11.5? This is for finding resource
annotations like @ManagedBean or @FacesValidator. I'm assuming that MyFaces
does this on its own, but if so it would mean that a lot of stuff gets
scanned multiple times by various components like Tomcat.

Stan

Geronimo has been trying to get everyone to standardize on this style of
interface as it lets the implementor support constructor injection
transparently.

Geronimo's implementations of this use xbean-reflect which provides a
handy way to stuff in all the properties and get a fully configured object
back.

thanks
david jencks

On Aug 5, 2010, at 5:12 AM, Matthias Wessendorf wrote:

Somehow I think there was already work/discussion about it, based on a
Tomcat interface.
It for sure does bring back some fragile memory. Let me think...

On Thu, Aug 5, 2010 at 2:09 PM, Matthias Wessendorf mat...@apache.org
wrote:

Well, looking at the RI is for sure not OK.

I didn't see a problem with the previous provided links (the JBoss
code), however
I have not opened any of the provided links yet.

-Matthias

On Thu, Aug 5, 2010 at 1:54 PM, ssilv...@redhat.com wrote:

That's OK. I guess I can do the SPI implementations on my end but it
might
not make it into JBoss AS6 GA. Let's concentrate on the MyFaces SPI's
for
now. How does MyFaces handle the SPI's like Mojarra has? I'm sure
it's OK
to look at Mojarra code since it's GPL2, right? If not, you can look
at
JavaDoc. We need something similar to:

com.sun.faces.spi.InjectionProvider

https://mojarra.dev.java.net/source/browse/mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/spi/InjectionProvider.java

com.sun.faces.spi.AnnotationProvider

https://mojarra.dev.java.net/source/browse/mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/spi/AnnotationProvider.java

Stan

Quoting Matthias Wessendorf mat...@apache.org:

At Apache we can not have code that contains (L)GPL code; or depends
on
it.

We had discussion(s) about this in the past. The below link contains
references
to other (Apache) documents:

http://markmail.org/message/qtc4g6vsracgzbok

-Matthias

On Thu, Aug 5, 2010 at 9:55 AM, Jan-Kees van Andel
jankeesvanan...@gmail.com wrote:

Hi,

Great news! It would be very nice if JBoss ships with MyFaces 2. This
also
opens up possibilities to do some enhancements to increase developer
productivity in JBoss, like better resource reloading and so on. Or
doing
some things more efficient by plugging into the JBoss infrastructure.
Just
thinking out loud... :)

One thing about the JBoss SVN link Stan sent. I took a quick peek at
the
license header in a Java file and saw that it's LGPL licensed. AFAIK,
this
is not compatible with ASL, so I suggest to not look at the code
while
implementing the stuff Stan asked for.

WDYT?

Regards,
Jan-Kees

2010/8/5 Matthias Wessendorf mat...@apache.org

Hello Stan,

welcome back. We do understand that you can not make any promise on
that
topic.
The fact that some folks at JBoss are thinking about shipping
MyFaces
(as an alternative option)
is a good news for this entire community here. Especially it is a
great motivation for the
folks that did the main work on ensuring Apache MyFaces 2.x is a
great
success.

On the missing pieces: I am sure that there will be some interested
in
working on them.

Thanks,
Matthias Wessendorf
PMC Chair Apache MyFaces

On Wed, Aug 4, 2010 at 8:42 PM, ssilv...@redhat.com wrote:

Hi guys,

Would you like to see MyFaces Core ship with JBoss AS6? If so,
read
on.

If you've been around MyFaces awhile, you probably remember that
JBoass
AS
used to ship with MyFaces instead of Mojarra. It was regrettable,
but
at
the time Mojarra was far ahead spec-wise and the powers that be
decided
my
time would be better spent integrating Mojarra instead of improving
MyFaces.

However, with JBoss AS6 M4, this is no longer an either or
proposition.
Both MyFaces and Mojarra can live side-by-side. The application
can
decide
which implementation to use:
http://community.jboss.org/wiki/JSFonJBossAS6

What's more,

[jira] Resolved: (MYFACES-2861) Remove commons-discovery dependency


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

Leonardo Uribe resolved MYFACES-2861.
-

Fix Version/s: 2.0.2-SNAPSHOT
   Resolution: Fixed

 Remove commons-discovery dependency
 ---

 Key: MYFACES-2861
 URL: https://issues.apache.org/jira/browse/MYFACES-2861
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-314
Affects Versions: 2.0.1
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Fix For: 2.0.2-SNAPSHOT


 Commons-discovery has a dependency to commons-logging. That cause a 
 transitive dependency to myfaces-impl. To prevent this dependency, we need to 
 move that code into our codebase and refactor it so it uses jul instead.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (MYFACES-2862) Improve efficiency of Application.createComponent(FacesContext,Resource) in production

2010-08-05 Thread JIRA

Improve efficiency of Application.createComponent(FacesContext,Resource) in 
production
--

 Key: MYFACES-2862
 URL: https://issues.apache.org/jira/browse/MYFACES-2862
 Project: MyFaces Core
  Issue Type: Improvement
  Components: General
Affects Versions: 2.0.2-SNAPSHOT
 Environment: myfaces trunk
Reporter: Martin Kočí


Profiler marks as hot spot method ClassUtils.classForName(fqcn) which is called 
from Application.createComponent(FacesContext,Resource)  during  restore view 
phase.

The reason is that in tested view are composite components and for each usage 
of them CompositeComponentResourceTagHandler
calls Application.createComponent(FacesContext,Resource) during VDL.buildView. 
Invocation of ClassUtils.classForName calls loadClass method on ClassLoader 
(Tomcat's WebappClassLoader.findResourceInternal in my case) and that is an 
expensive operation.


Something or maybe whole result of Application.createComponent should be cached 
in production mode. I did a simple cache attept and it saves ~15 ms in my test 
case with 6 composite components.






-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Myfaces vs. mojarra restore view performance

2010-08-05 Thread Martin Koci

Hi,

success!

myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70 ms in restore view
phase. It was *750 ms* before.

Thanks,

Martin Kočí

Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
 Hi
 
 I implemented a proposal for this one on MYFACES-2854-2.patch using
 the suggestion
 proposed (do not apply ResourceDependency if it was already
 processed). I hope that 
 patch solve the problem.
 
 regards,
 
 Leonardo

[jira] Updated: (MYFACES-2854) Processing @ResourceDependency on each component instance takes too long


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

Leonardo Uribe updated MYFACES-2854:


   Status: Resolved  (was: Patch Available)
 Assignee: Leonardo Uribe
Fix Version/s: 2.0.2-SNAPSHOT
   Resolution: Fixed

 Processing @ResourceDependency on each component instance takes too long
 

 Key: MYFACES-2854
 URL: https://issues.apache.org/jira/browse/MYFACES-2854
 Project: MyFaces Core
  Issue Type: Improvement
  Components: General
Affects Versions: 2.0.2-SNAPSHOT
 Environment: myfaces current trunk
Reporter: Martin Kočí
Assignee: Leonardo Uribe
 Fix For: 2.0.2-SNAPSHOT

 Attachments: MYFACES-2854-1.patch, MYFACES-2854-2.patch


 Consider custom renderer with @ResourceDependencies (and many 
 @ResourceDependency here). If a view has 500 UIComponent with this custom 
 renderer, ApplicationImpl._handleAnnotations process the same set of 
 ResourceDependecies again and again.
 With my test scenario, VDL.buildView takes therefore  750ms. After small 
 modification in ApplicationImpl _handleAnnotations it takes only 70 ms. 
 The modification can be like:
 Class? inspectedClass = inspected.getClass();
  
 // Process annotation only if this is the first creation of 
 component(renderer,validator, converter) of particular type in this 
 request/response
 if (! context.getAttributes().containsKey(inspectedClass.getName())) 
 { 
 _handleListenerForAnnotations(context, inspected, inspectedClass, 
 component, isProduction);
 _handleResourceDependencyAnnotations(context, inspectedClass, 
 component, isProduction);
 // Remeber here that this class and it's dependencies are in 
 viewRoot.componentResources 
 context.getAttributes().put(inspectedClass.getName(), 
 Boolean.TRUE);
 }
 ;
 But I'm not sure what specification says about this processing.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Myfaces vs. mojarra restore view performance

2010-08-05 Thread Leonardo Uribe

Hi

Ok, good to know that. I closed MYFACES-2854. Maybe on MYFACES-2862 we can
use FacesContext.isProjectStage(ProjectStage).

regards,

Leonardo

2010/8/5 Martin Koci martin.k...@aura.cz

 Hi,

 success!

 myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70 ms in restore view
 phase. It was *750 ms* before.

 Thanks,

 Martin Kočí

 Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
  Hi
 
  I implemented a proposal for this one on MYFACES-2854-2.patch using
  the suggestion
  proposed (do not apply ResourceDependency if it was already
  processed). I hope that
  patch solve the problem.
 
  regards,
 
  Leonardo

[jira] Created: (PORTLETBRIDGE-162) Portlet 2.0 Bridge: Resource as source of iFrame doesn't render in Pluto

Portlet 2.0 Bridge: Resource as source of iFrame doesn't render in Pluto


 Key: PORTLETBRIDGE-162
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-162
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-beta
Reporter: Michael Freedman
Assignee: Michael Freedman


If the resource target for the above is a Face view, the bridge runs 
through/executesd the normal Faces lifecycle to render the resource.  It 
dispatches to the view JSP using forward.  In the regular case (nonResource) 
this is actually translated by Pluto into a servlet include simulating the 
forward.  However for a resource its an actual servlet forward.  Tomcat closes 
the response and flushes the markup (from it) at the end of the forward.  So 
unless the response is wrapped/buffered Faces can't write after the forward.

So the solution is to be sure the response is always wrapped/buffered (similar 
to the base Faces implementation).  Do this for all requests (render and 
resource) as we don't know how the portlet container we are running on may be 
working 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (PORTLETBRIDGE-163) Portlet 2.0 Bridge should establish child request scopes if rendering a resource from a different view (in an iFrame)

Portlet 2.0 Bridge should establish child request scopes if rendering a 
resource from a different view (in an iFrame)
-

 Key: PORTLETBRIDGE-163
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-163
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-beta
Reporter: Michael Freedman
Assignee: Michael Freedman


Currently the Portlet 2.0 Bridge runs the resource lifecycle (when targeting a 
Faces view to provide the resource) using the same scope as the view which 
generated the resource target.  (Use case:  A Faces view that has JSP/Java code 
that generates an iFrame with a source (target)  of a Faces viewId).  In doing 
so the resource view overwrites the main Views scope.  Since things like the 
ViewStateParam are held here -- on a subsequent redisplay the outer view 
displays the results of view that was in the iFrame (and the frame is lost).  
To avoid this the bridge should recognize that the Faces view that is the 
target of the resource is different from the one in scope/used to rener the 
portlet main view and establish a new separate scope for use.  This scope 
should be managed as a child of the main scope ensuring it can be cleaned up if 
the main scope goes away.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (PORTLETBRIDGE-164) Bridge shouldn't notify (bridge) request scope attrbiutes that they are being destroyed if only updating the scope at the end of a request

Bridge shouldn't notify (bridge) request scope attrbiutes that they are being 
destroyed if only updating the scope at the end of a request
--

 Key: PORTLETBRIDGE-164
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-164
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0-beta, 1.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman


The request scope is maintained in a Map of (key, Map) pairs where key is the 
scopeId and Map is the scopeMap -- a Map containing all the current request 
attributes managed in the bridge request scope.  The bridge shouldn't notify 
attributes in this scopeMap merely because the Map is being replaced/updated -- 
as the bridge does this at the end of every request.  (I.e. the bridge lifecyle 
restores the real request scope from this Map at the beginning of the request 
and then creates a new Map of the request scope at the end of the request which 
it pushes back.  As this new Map really is just an updated version of the 
original -- release notification isn't desired/shouldn't be done.  But it is.  
So fix it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (PORTLETBRIDGE-165) Birdge explicit scope removal doesn't cause its attributes to be notified but should

Birdge explicit scope removal doesn't cause its attributes to be notified but 
should 
-

 Key: PORTLETBRIDGE-165
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-165
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
Affects Versions: 2.0.0-beta, 1.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman


When the bridge explicitly removes a scope atrtibutes in that scope should be 
notified they are being destroyed.  The LRUMap used by the bridge to manage the 
scopes correctly does this notify if/when its remove method is called.  
Unfortunately, the bridge removes the scope/map by calling iterator.remove () 
once it locate an entry in the iterator that matches the scope to be removed.  
Unfortunately, though iterator.remove() does remove the entry from the base 
Map, it does so after casting the base Map object into a superclass.  I.e. 
remove() is called but because its on an object that is cast to a superclass, 
our method isn't called/triggered.  Instead we must explictly use map.remove(). 
 This means the bridge code must copy the scopes to be removed when in the 
iteration and then iterate over this list afterwards to directly remove them.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-17) Need to support mapping icons via -tr-rule-ref like we do with styles.

2010-08-05 Thread Jeanne Waldman (JIRA)


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

Jeanne Waldman resolved TRINIDAD-17.


 Assignee: Jeanne Waldman
Fix Version/s: 2.0.0.3-core
   Resolution: Fixed

TRINIDAD-17 Need to support mapping icons via -tr-rule-ref like we do with 
styles.
Now -tr-rule-ref works for icons.
This checkin contains a FINEST message if we think it is an icon, but it gets 
written to the stylesheet.
The code would be a little more complicated to know for sure if it was an icon 
so I did not add it.
That would involve: 1. if we can't find a selector, look for it in the 'icon' 
selector list. If we find it there, resolve to see if it has a content. It's 
too much code for this unusual usecase. I'll rely on the Design Time to warn 
the user.

 Need to support mapping icons via -tr-rule-ref like we do with styles.
 --

 Key: TRINIDAD-17
 URL: https://issues.apache.org/jira/browse/TRINIDAD-17
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 1.2.1-core
 Environment: Windows.
Reporter: Bill Baggett
Assignee: Jeanne Waldman
 Fix For: 2.0.0.3-core


 Trinidad skinning supports mapping styles in a css file via the -tr-rule-ref. 
  But, it doesn't support mapping icons this way.  We need to support this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (MYFACES-2863) Create a new package org.apache.myfaces.spi and implement Providers for integration points with application containers