date:20060221

[jira] Commented: (MYFACES-1146) Impossible to hide footer in dataTable

2006-02-21 Thread Guy Bashan (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1146?page=comments#action_12367158 
] 

Guy Bashan commented on MYFACES-1146:
-

This is exactly what I did (well . . .   in one of my tryings . . . .).

MyFaces still creates an empty row (footer row). This row has no values, so it 
is not shown in explorer, but fire fox treats empty rows differently and still 
shows the empty row.

 Impossible to hide footer in dataTable
 --

  Key: MYFACES-1146
  URL: http://issues.apache.org/jira/browse/MYFACES-1146
  Project: MyFaces Core
 Type: Bug
   Components: Tomahawk
 Versions: 1.1.1
 Reporter: Guy Bashan
 Priority: Trivial


 It is impossible to hide the footer in a dataTable. There are cases in which 
 the same table should sometimes show the footer and in other cases do not 
 show it. For example:
   t:dataTable id=results value=#{analyze.rows} var=row
width=100% 
cellpadding=0 
cellspacing=0 
border=0
styleClass=reportTable 
headerClass=reportTitle
footerClass=reportTableTotal
rowClasses=reportRowLight,reportRowDark
rowOnMouseOver=selectedRow = this.className; 
 this.className='reportRowOver'
rowOnMouseOut=this.className = selectedRow
 t:columns value=#{analyze.columnHeaders} var=column
styleClass=#{analyze.styleClass} 
 style=text-align:#{column.alignment}
   f:facet name=header
 t:htmlTag value=nobrh:outputText value=#{column.title} 
 escape=false//t:htmlTag
   /f:facet
   h:outputText value=#{analyze.columnValue} escape=false /
   
   f:facet name=footer
   h:outputText value=#{analyze.colFooter.title} 
 escape=false/
   t:htmlTag value=b
 h:outputText value=#{analyze.colFooter.total}/
   /t:htmlTag
   /f:facet
 /t:columns
   /t:dataTable
 I tried hiding the footer with: f:subview wrapping the footer and as a footer 
 child, but both seems to be not working.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-1146) Impossible to hide footer in dataTable

2006-02-21 Thread Mario Ivankovits (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1146?page=comments#action_12367159 
] 

Mario Ivankovits commented on MYFACES-1146:
---

You could also try to do:
footerClass=#{analyze.footerClass} 

where you return the footer class or a class which will display:hide it.

But ok, this is only a workaround.

The question is still valid, should we add a
renderFooter=true|false
renderHeader=true|false

attribute?

 Impossible to hide footer in dataTable
 --

  Key: MYFACES-1146
  URL: http://issues.apache.org/jira/browse/MYFACES-1146
  Project: MyFaces Core
 Type: Bug
   Components: Tomahawk
 Versions: 1.1.1
 Reporter: Guy Bashan
 Priority: Trivial


 It is impossible to hide the footer in a dataTable. There are cases in which 
 the same table should sometimes show the footer and in other cases do not 
 show it. For example:
   t:dataTable id=results value=#{analyze.rows} var=row
width=100% 
cellpadding=0 
cellspacing=0 
border=0
styleClass=reportTable 
headerClass=reportTitle
footerClass=reportTableTotal
rowClasses=reportRowLight,reportRowDark
rowOnMouseOver=selectedRow = this.className; 
 this.className='reportRowOver'
rowOnMouseOut=this.className = selectedRow
 t:columns value=#{analyze.columnHeaders} var=column
styleClass=#{analyze.styleClass} 
 style=text-align:#{column.alignment}
   f:facet name=header
 t:htmlTag value=nobrh:outputText value=#{column.title} 
 escape=false//t:htmlTag
   /f:facet
   h:outputText value=#{analyze.columnValue} escape=false /
   
   f:facet name=footer
   h:outputText value=#{analyze.colFooter.title} 
 escape=false/
   t:htmlTag value=b
 h:outputText value=#{analyze.colFooter.total}/
   /t:htmlTag
   /f:facet
 /t:columns
   /t:dataTable
 I tried hiding the footer with: f:subview wrapping the footer and as a footer 
 child, but both seems to be not working.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-1146) Impossible to hide footer in dataTable

2006-02-21 Thread Guy Bashan (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1146?page=comments#action_12367160 
] 

Guy Bashan commented on MYFACES-1146:
-

I have alreay done this workaround, but it seems to me not a neat solution. I 
can leave with this solution, but I think that in the long term it is 
preferable solving this problem with a property as you suggested.

 Impossible to hide footer in dataTable
 --

  Key: MYFACES-1146
  URL: http://issues.apache.org/jira/browse/MYFACES-1146
  Project: MyFaces Core
 Type: Bug
   Components: Tomahawk
 Versions: 1.1.1
 Reporter: Guy Bashan
 Priority: Trivial


 It is impossible to hide the footer in a dataTable. There are cases in which 
 the same table should sometimes show the footer and in other cases do not 
 show it. For example:
   t:dataTable id=results value=#{analyze.rows} var=row
width=100% 
cellpadding=0 
cellspacing=0 
border=0
styleClass=reportTable 
headerClass=reportTitle
footerClass=reportTableTotal
rowClasses=reportRowLight,reportRowDark
rowOnMouseOver=selectedRow = this.className; 
 this.className='reportRowOver'
rowOnMouseOut=this.className = selectedRow
 t:columns value=#{analyze.columnHeaders} var=column
styleClass=#{analyze.styleClass} 
 style=text-align:#{column.alignment}
   f:facet name=header
 t:htmlTag value=nobrh:outputText value=#{column.title} 
 escape=false//t:htmlTag
   /f:facet
   h:outputText value=#{analyze.columnValue} escape=false /
   
   f:facet name=footer
   h:outputText value=#{analyze.colFooter.title} 
 escape=false/
   t:htmlTag value=b
 h:outputText value=#{analyze.colFooter.total}/
   /t:htmlTag
   /f:facet
 /t:columns
   /t:dataTable
 I tried hiding the footer with: f:subview wrapping the footer and as a footer 
 child, but both seems to be not working.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-1146) Impossible to hide footer in dataTable

2006-02-21 Thread Guy Bashan (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1146?page=comments#action_12367162 
] 

Guy Bashan commented on MYFACES-1146:
-

leave --  live   ;-)

 Impossible to hide footer in dataTable
 --

  Key: MYFACES-1146
  URL: http://issues.apache.org/jira/browse/MYFACES-1146
  Project: MyFaces Core
 Type: Bug
   Components: Tomahawk
 Versions: 1.1.1
 Reporter: Guy Bashan
 Priority: Trivial


 It is impossible to hide the footer in a dataTable. There are cases in which 
 the same table should sometimes show the footer and in other cases do not 
 show it. For example:
   t:dataTable id=results value=#{analyze.rows} var=row
width=100% 
cellpadding=0 
cellspacing=0 
border=0
styleClass=reportTable 
headerClass=reportTitle
footerClass=reportTableTotal
rowClasses=reportRowLight,reportRowDark
rowOnMouseOver=selectedRow = this.className; 
 this.className='reportRowOver'
rowOnMouseOut=this.className = selectedRow
 t:columns value=#{analyze.columnHeaders} var=column
styleClass=#{analyze.styleClass} 
 style=text-align:#{column.alignment}
   f:facet name=header
 t:htmlTag value=nobrh:outputText value=#{column.title} 
 escape=false//t:htmlTag
   /f:facet
   h:outputText value=#{analyze.columnValue} escape=false /
   
   f:facet name=footer
   h:outputText value=#{analyze.colFooter.title} 
 escape=false/
   t:htmlTag value=b
 h:outputText value=#{analyze.colFooter.total}/
   /t:htmlTag
   /f:facet
 /t:columns
   /t:dataTable
 I tried hiding the footer with: f:subview wrapping the footer and as a footer 
 child, but both seems to be not working.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: svn commit: r378805 - /myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/application/ApplicationFactoryImpl.java

2006-02-21 Thread Simon Kitching

On Mon, 2006-02-20 at 21:47 -0800, Craig McClanahan wrote:
 No, I was not aware of that change ... but does it actually work?
 Declaring something Serializable is not by itself sufficient if there
 are transient variables inside the implementation.  (On a separate
 thread on commons-dev, I recommended that there be unit tests to
 validate this behavior:  use a Log instance, serialize it, deserialize
 it, and use it some more). 

I believe Serializable is correctly implemented for all standard
adapters except possibly AvalonLog [will follow that up on commons-dev].
The deserialized objects correctly locate a fresh underlying log
object to forward calls to.

Yes there need to be unit tests for this; I'll look for them and add
some if not already present. 

 
 
 The 1.0.4 release occurred around June 2004 so perhaps there
 are a few
 containers out there capable of running MyFaces but which are
 still on 
 JCL 1.0.3. In addition there might be a few custom Log
 adapters around
 which *might* not implement Serializable.
 
 However in view of the complicated/ugly workaround for
 non-serializable
 Log implementations, it seems ok to me for MyFaces to just
 declare a 
 dependency on JCL 1.0.4. If people don't comply then there is
 a very
 obvious NotSerializableException: logAdapterClassName
 message
 generated. The fix is then to upgrade to 1.0.4 (which is
 binary
 compatible with earlier releases) or a later release. 
 
 Comments/Opinions?
 
 +1 on declaring a dependency on Commons Logging 1.0.4 ... anything
 prior to that is just asking for trouble.  I use 1.0.4 exclusively for
 eveything that has a C-L dependency ... works fine, lasts a long
 time :-). 

So the conclusion seems to be that if/when using commons-logging in
MyFaces, use:
  private Log foo = LogFactory.getLog(foo);
everywhere except in short-lived and frequently-created objects. In
those cases, either call LogFactory.getLog as needed or have some
longer-lived object store the Log object.

For StateHolder classes, things just work; the logger isn't saved in
saveState; it gets recreated in the new component and that works.

For Serializable classes, the Log object handles its own serialization
correctly. No need for transient, no need for any other special hacks.

MyFaces does need to declare a dependency on commons-logging 1.0.4 (not
earlier versions) in order for things to work this simply. Release 1.0.4
was in June 2004.

Do NOT use static Log anywhere.

Is this all ok?

Cheers,

Simon

[jira] Reopened: (MYFACES-1146) Impossible to hide footer in dataTable

2006-02-21 Thread Mario Ivankovits (JIRA)

 [ http://issues.apache.org/jira/browse/MYFACES-1146?page=all ]
 
Mario Ivankovits reopened MYFACES-1146:
---


Add the attributes renderHeader and renderFooter

 Impossible to hide footer in dataTable
 --

  Key: MYFACES-1146
  URL: http://issues.apache.org/jira/browse/MYFACES-1146
  Project: MyFaces Core
 Type: Bug
   Components: Tomahawk
 Versions: 1.1.1
 Reporter: Guy Bashan
 Priority: Trivial


 It is impossible to hide the footer in a dataTable. There are cases in which 
 the same table should sometimes show the footer and in other cases do not 
 show it. For example:
   t:dataTable id=results value=#{analyze.rows} var=row
width=100% 
cellpadding=0 
cellspacing=0 
border=0
styleClass=reportTable 
headerClass=reportTitle
footerClass=reportTableTotal
rowClasses=reportRowLight,reportRowDark
rowOnMouseOver=selectedRow = this.className; 
 this.className='reportRowOver'
rowOnMouseOut=this.className = selectedRow
 t:columns value=#{analyze.columnHeaders} var=column
styleClass=#{analyze.styleClass} 
 style=text-align:#{column.alignment}
   f:facet name=header
 t:htmlTag value=nobrh:outputText value=#{column.title} 
 escape=false//t:htmlTag
   /f:facet
   h:outputText value=#{analyze.columnValue} escape=false /
   
   f:facet name=footer
   h:outputText value=#{analyze.colFooter.title} 
 escape=false/
   t:htmlTag value=b
 h:outputText value=#{analyze.colFooter.total}/
   /t:htmlTag
   /f:facet
 /t:columns
   /t:dataTable
 I tried hiding the footer with: f:subview wrapping the footer and as a footer 
 child, but both seems to be not working.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-1146) Impossible to hide footer in dataTable

2006-02-21 Thread Volker Weber (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1146?page=comments#action_12367167 
] 

Volker Weber commented on MYFACES-1146:
---

I prefer to check the rendered attribute of footer/header component over adding 
extra attributes to datatable.

 Impossible to hide footer in dataTable
 --

  Key: MYFACES-1146
  URL: http://issues.apache.org/jira/browse/MYFACES-1146
  Project: MyFaces Core
 Type: Bug
   Components: Tomahawk
 Versions: 1.1.1
 Reporter: Guy Bashan
 Assignee: Mario Ivankovits
 Priority: Trivial


 It is impossible to hide the footer in a dataTable. There are cases in which 
 the same table should sometimes show the footer and in other cases do not 
 show it. For example:
   t:dataTable id=results value=#{analyze.rows} var=row
width=100% 
cellpadding=0 
cellspacing=0 
border=0
styleClass=reportTable 
headerClass=reportTitle
footerClass=reportTableTotal
rowClasses=reportRowLight,reportRowDark
rowOnMouseOver=selectedRow = this.className; 
 this.className='reportRowOver'
rowOnMouseOut=this.className = selectedRow
 t:columns value=#{analyze.columnHeaders} var=column
styleClass=#{analyze.styleClass} 
 style=text-align:#{column.alignment}
   f:facet name=header
 t:htmlTag value=nobrh:outputText value=#{column.title} 
 escape=false//t:htmlTag
   /f:facet
   h:outputText value=#{analyze.columnValue} escape=false /
   
   f:facet name=footer
   h:outputText value=#{analyze.colFooter.title} 
 escape=false/
   t:htmlTag value=b
 h:outputText value=#{analyze.colFooter.total}/
   /t:htmlTag
   /f:facet
 /t:columns
   /t:dataTable
 I tried hiding the footer with: f:subview wrapping the footer and as a footer 
 child, but both seems to be not working.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Maven2 build failure with current trunk?

2006-02-21 Thread Werner Punz

Dennis Byrne schrieb:
 Most of the encryption tests have really strong cipher configurations.  These 
 levels of encryption have to be enabled for a standard JDK.  There is a brief 
 explanation in the javadocs of the tests themselves, although this does not 
 explain why they worked for you in the past.
 
Either enabled, or simply a different crypto provider has to be used.
I settled in the past for the second option (bouncycastle)

sorry, just wanted to give my 2c here, because the whole issue has been
a huge annoyance once for me in the past.

RE: New MyFaces Committer: Craig McClanahan

2006-02-21 Thread Stan Silvert

Welcome Craig!

Stan Silvert
JBoss, Inc.
[EMAIL PROTECTED]
callto://stansilvert
 -Original Message-
 From: Sean Schofield [mailto:[EMAIL PROTECTED]
 Sent: Monday, February 20, 2006 3:30 PM
 To: MyFaces Development
 Subject: New MyFaces Committer: Craig McClanahan

 Please welcome Craig McClanahan as our newest MyFaces committer.  Most
 of you are probably familiar with Craig's work as the original author
 of Struts.  Craig was also heavily involved in the original JSF
 specification.  No matter where you live, chances are he will be
 coming to a conference in your city/country soon to promote JSF!

 Craig is also the lead architect on Sun's Java Studio Creator 2 and is
 leading the effort on Struts Shale which leverages JSF.  He has been a
 valuable contributor on our mailing list for well over a year now and
 as an ASF member, has agreed to be the mentor for the ADF incubator
 project.  He has also stated an interest in making the Tomahawk
 components compatible with Studio Creator.

 Welcome aboard Craig.  We're glad to officially have you on the team
 now.

 Sean

Re: [jira] Commented: (MYFACES-1146) Impossible to hide footer in dataTable

2006-02-21 Thread Mario Ivankovits

Hi Volker!
 [ 
 http://issues.apache.org/jira/browse/MYFACES-1146?page=comments#action_12367167
  ] 

 Volker Weber commented on MYFACES-1146:
 ---

 I prefer to check the rendered attribute of footer/header component over 
 adding extra attributes to datatable.
   

This might be complicated, if not impossible to do.
I have to check all children of all footer facets to see if the row
should be renderer or not.
Think of the following (for sure untypical, just to get the point):

f:facet name=footer
h:panelGroup
   h:outputLabel for=input
  h:outputText value=abc rendered=false/
  /h:outputLabel
  h:inputText id=input rendered=false/
/h:panelGroup
/f:facet

We can say we take the rendered state of the first/root child of the
facet tag, but this is not very intuitive, is it?

Ciao,
Mario

Re: New MyFaces Committer: Craig McClanahan

2006-02-21 Thread Mario Ivankovits

Hi Craig!

Welcome to the pleasuredome! ;-)

Ciao,
Mario
 Please welcome Craig McClanahan as our newest MyFaces committer.  Most
 of you are probably familiar with Craig's work as the original author
 of Struts.  Craig was also heavily involved in the original JSF
 specification.  No matter where you live, chances are he will be
 coming to a conference in your city/country soon to promote JSF!

 Craig is also the lead architect on Sun's Java Studio Creator 2 and is
 leading the effort on Struts Shale which leverages JSF.  He has been a
 valuable contributor on our mailing list for well over a year now and
 as an ASF member, has agreed to be the mentor for the ADF incubator
 project.  He has also stated an interest in making the Tomahawk
 components compatible with Studio Creator.

 Welcome aboard Craig.  We're glad to officially have you on the team now.

 Sean

   


-- 
mfg

Mario Ivankovits - OPS EDV Vertriebsges.m.b.H.
Software Engineering
Michael-Bernhard-Gasse 10, A-1120 Wien
Tel.: +43-1-8938810
Fax: +43-1-8938810/3700
E-Mail: [EMAIL PROTECTED]
Skype: mario_ivankovits

Re: [PROPOSAL] ADF-Faces as a new Podling

2006-02-21 Thread Manfred Geiler

On 2/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hmmm

ok - I just have seen many proposals coming in via general. Never mind!

Have you got any feedback on the proposal so far?

Njet.
-Manfred

regards,

Martin

On 2/20/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Martin,
http://incubator.apache.org/incubation/Incubation_Policy.html#Acceptance+of+Proposal+by+Sponsor
http://incubator.apache.org/incubation/Process_Description.html

;-)

Regards,
Manfred

On 2/19/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Manfred,

I think you have to send this to [EMAIL PROTECTED]

regards,

Martin

On 2/19/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Dear Incubator PMC,

We, the sponsoring members listed below, ask that you accept the
following proposal for a new project at Apache, an effort centered on
providing web application developers with a
rich set of user interface components based on the JavaServer Faces
specification.

* You can find the proposal here:
http://wiki.apache.org/myfaces/adfproposal
A snapshot of the proposal is attached to this mail for your
convenience.

* Here is a reference to the candidate acceptance vote by the MyFaces
PMC:
http://mail-archives.apache.org/mod_mbox/myfaces-dev/200602.mbox/[EMAIL
PROTECTED]

* Mentor, nominated by the Sponsor: Craig McClanahan

Regards,
Manfred Geiler
(MyFaces PMC Chair)

Proposal for ADF Faces, a MyFaces subproject 6 February 2006, The ADF
Faces Team (contributions by: Adam Winer, awiner at gmail dot com;
john dot r dot fallows at gmail dot com)

(0) rationale

Apache MyFaces strives to provide an environment where open source
developers can create new components and contribute them back to the
community.

The goal of ADF Faces is to provide web application developers with a
rich set of user interface components based on the JavaServer Faces
specification.

ADF Faces comes with very high quality components, a dialog framework,
as well as personalization and skinning capabilities. ADF Faces
features include: file upload support, client-side validation, partial
rendering of a page (AJAX-style), data tables, hierarchical tables,
color/date pickers, progress indicators, menu tabs/buttons, wizards,
internationalization and accessibility. A complete list of the ADF
Faces components is available (here.) This project starts with more
than 100 components which have already been documented and thoroughly
tested.

ADF Faces is a temporary name for this project, what it will be called
in the future is yet to be determined by the Apache MyFaces community.
ADF Faces development started in 2001. Initial development took place
outside the Apache Software Foundation, therefore the ADF Faces team
and MyFaces are applying for incubation.

(0.1) criteria

Meritocracy:

The ADF Faces project will be consensus-based using the mailing lists
and completely transparent. Developers will employ Apache conventions,
such as +1, when coming to decisions and if necessary voting will
establish the final 'will' of the community.

Community:

The MyFaces project and the ?JavaServer Faces standard hold great
promise. A rich set of UI components will significantly accelerate
their adoption. We strongly believe that ADF Faces will gather
significant momentum and enough developers to build a vibrant
community of users and contributors. We look forward to seeing more
components blossom as part of the Apache MyFaces project.

Core Developers:

ADF Faces was developed by five Oracle employees including Adam Winer
(active member of the ?JavaServer Faces expert group since day one)
and John Fallows co-author of Pro JSF and Ajax. Developers have
filed the Contribution License Agreement. Oracle has also filed the
Corporate Contribution License Agreement.

Three PMC members from the MyFaces project are currently planning to
become active ADF Faces developers, others will hopefully follow:

* Matthias Wessendorf
* Martin Marinschek
* Bruno Aranda

Alignment:

ADF Faces aligns perfectly with MyFaces and other ASF projects
utilizing J2EE infrastructure such as Tomcat. Of particular relevance
are projects such as Geronimo, Apache libraries like Jakarta Taglibs
and Apache Maven.

(0.2) warning signs

Orphaned products:

Most of the active developers would like to become ADF Faces
Committers or PMC Members and plan to remain active in the project.

Inexperience with open source:

Most ADF Faces developers have been consuming open source projects
extensively and

[jira] Commented: (MYFACES-1148) Weblogic Classloader problems during development (FactoryFinder)

2006-02-21 Thread Alexander Jesse (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12367170 
] 

Alexander Jesse commented on MYFACES-1148:
--

Seems as if the hibernate-link points to another problem.

The other MF-jira issue also seems to point in a different direction.

Having to deal  with WLS on a daily base... I think the description by Adam is 
quite accurate (WLS dropping the classloader for a class-redeploy). That the 
factories disappear in that moment seems also quite logic. I just wonder how 
Tomcat is handling this class-redeploy issue and whether it works when using 
the RI...

 Weblogic Classloader problems during development (FactoryFinder)
 

  Key: MYFACES-1148
  URL: http://issues.apache.org/jira/browse/MYFACES-1148
  Project: MyFaces Core
 Type: Bug
   Components: Implementation
 Versions: 1.1.1
  Environment: Weblogic 9.0, 8.1, etc.  Windows XP Pro sp2.
 Reporter: Adam Brod


 Like most weblogic users, our team develops using the exploded war format.  
 That means that each time we deploy a new version of a class, weblogic 
 automatically picks it up.  The way Weblogic implements this is that when it 
 detects a new class, it drops the classloader for that class, as well as the 
 Servlet and all helper classes that are loaded by the Servlet.  That means 
 FacesServlet is dropped and reloaded.
 The problem is that FactoryFinder stores the Factory classes in a Map where 
 the key is the current classloader.  That works fine until I deploy a new 
 class to my webapp.  At that point, weblogic drops the classloader and 
 creates a new one with the new class definition.  Now when 
 FacesServlet.init() calls FactoryFinder.getFactory() (in the new 
 classloader), an IllegalStateException is generated (see below) because the 
 current classloader is not a valid key for the _registeredFactoryNames Map.
 One possible solution that I can see to this is to change the key for the 
 Factory map to use the ServletContext's getServletContextName() as the key.  
 I am 95% sure this same problem exists in Weblogic 7.0, 8.1 and 9.1 since 
 they all use almost the same Servlet redeployment mechanism.  I have only 
 tried this on Weblogic 9.0.
 Feb 20, 2006 5:38:07 PM EST Error HTTP BEA-101017 [EMAIL PROTECTED] 
 - name: 'ma-web-1.0-SNAPSHOT
 ', context-path: '/ma'] Root cause of ServletException.
 java.lang.IllegalStateException: No Factories configured for this Application 
 - typically this is because a context listener is not setup in yo
 ur web.xml.
 A typical config looks like this;
 listener
   
 listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
 /listener
 at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:84)
 at javax.faces.webapp.FacesServlet.init(FacesServlet.java:84)
 at 
 weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:265)
 at 
 weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
 at 
 weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
 at 
 weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityHelper.java:61)
 at 
 weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLifecycleHelper.java:58)
 at 
 weblogic.servlet.internal.StubLifecycleHelper.init(StubLifecycleHelper.java:48)
 at 
 weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:502)
 at 
 weblogic.servlet.internal.ServletStubImpl.checkForReload(ServletStubImpl.java:429)
 at 
 weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:221)
 at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
 at 
 weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
 at 
 oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl._invokeDoFilter(AdfFacesFilterImpl.java:367)
 at 
 oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl._doFilterImpl(AdfFacesFilterImpl.java:336)
 at 
 oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl.doFilter(AdfFacesFilterImpl.java:196)
 at 
 oracle.adf.view.faces.webapp.AdfFacesFilter.doFilter(AdfFacesFilter.java:87)
 at 
 weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
 at 
 org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122)
 at 
 weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
 at 
 weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3020)
 at 
 weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
 at

Re: New MyFaces Committer: Craig McClanahan

2006-02-21 Thread Thomas Spiegl

Craig, good to have you aboard!

On 2/21/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
 Hi Craig!

 Welcome to the pleasuredome! ;-)

 Ciao,
 Mario
  Please welcome Craig McClanahan as our newest MyFaces committer.  Most
  of you are probably familiar with Craig's work as the original author
  of Struts.  Craig was also heavily involved in the original JSF
  specification.  No matter where you live, chances are he will be
  coming to a conference in your city/country soon to promote JSF!
 
  Craig is also the lead architect on Sun's Java Studio Creator 2 and is
  leading the effort on Struts Shale which leverages JSF.  He has been a
  valuable contributor on our mailing list for well over a year now and
  as an ASF member, has agreed to be the mentor for the ADF incubator
  project.  He has also stated an interest in making the Tomahawk
  components compatible with Studio Creator.
 
  Welcome aboard Craig.  We're glad to officially have you on the team now.
 
  Sean
 
 


 --
 mfg

 Mario Ivankovits - OPS EDV Vertriebsges.m.b.H.
 Software Engineering
 Michael-Bernhard-Gasse 10, A-1120 Wien
 Tel.: +43-1-8938810
 Fax: +43-1-8938810/3700
 E-Mail: [EMAIL PROTECTED]
 Skype: mario_ivankovits




--
http://www.irian.at

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

Professional Support for Apache MyFaces

[jira] Commented: (MYFACES-1148) Weblogic Classloader problems during development (FactoryFinder)

2006-02-21 Thread Alexander Jesse (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12367172 
] 

Alexander Jesse commented on MYFACES-1148:
--

Well the Sun-RI should have the same problem... This is an excerpt from their 
FactoryFinder:
/**
 * pKeys are web application class loaders.  Values are factory
 * maps for each web application./p
 *
 * pFor the nested map, the keys are the factoryName, which must
 * be one of the code*_FACTORY/code constants above.  Values are
 * one of: /p
 *
 * ol 
 *
 * lipthe actual factory class, if [EMAIL PROTECTED] getFactory} has 
been
 * called before on this factoryName/p/li
 *
 * lipAn codeArrayList/code of codeStrings/code
 * representing the configured implementations of for the
 * factoryName./p/li
 *
 * /ol
 */
private static HashMap applicationMaps = new HashMap();


 Weblogic Classloader problems during development (FactoryFinder)
 

  Key: MYFACES-1148
  URL: http://issues.apache.org/jira/browse/MYFACES-1148
  Project: MyFaces Core
 Type: Bug
   Components: Implementation
 Versions: 1.1.1
  Environment: Weblogic 9.0, 8.1, etc.  Windows XP Pro sp2.
 Reporter: Adam Brod


 Like most weblogic users, our team develops using the exploded war format.  
 That means that each time we deploy a new version of a class, weblogic 
 automatically picks it up.  The way Weblogic implements this is that when it 
 detects a new class, it drops the classloader for that class, as well as the 
 Servlet and all helper classes that are loaded by the Servlet.  That means 
 FacesServlet is dropped and reloaded.
 The problem is that FactoryFinder stores the Factory classes in a Map where 
 the key is the current classloader.  That works fine until I deploy a new 
 class to my webapp.  At that point, weblogic drops the classloader and 
 creates a new one with the new class definition.  Now when 
 FacesServlet.init() calls FactoryFinder.getFactory() (in the new 
 classloader), an IllegalStateException is generated (see below) because the 
 current classloader is not a valid key for the _registeredFactoryNames Map.
 One possible solution that I can see to this is to change the key for the 
 Factory map to use the ServletContext's getServletContextName() as the key.  
 I am 95% sure this same problem exists in Weblogic 7.0, 8.1 and 9.1 since 
 they all use almost the same Servlet redeployment mechanism.  I have only 
 tried this on Weblogic 9.0.
 Feb 20, 2006 5:38:07 PM EST Error HTTP BEA-101017 [EMAIL PROTECTED] 
 - name: 'ma-web-1.0-SNAPSHOT
 ', context-path: '/ma'] Root cause of ServletException.
 java.lang.IllegalStateException: No Factories configured for this Application 
 - typically this is because a context listener is not setup in yo
 ur web.xml.
 A typical config looks like this;
 listener
   
 listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
 /listener
 at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:84)
 at javax.faces.webapp.FacesServlet.init(FacesServlet.java:84)
 at 
 weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:265)
 at 
 weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
 at 
 weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
 at 
 weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityHelper.java:61)
 at 
 weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLifecycleHelper.java:58)
 at 
 weblogic.servlet.internal.StubLifecycleHelper.init(StubLifecycleHelper.java:48)
 at 
 weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:502)
 at 
 weblogic.servlet.internal.ServletStubImpl.checkForReload(ServletStubImpl.java:429)
 at 
 weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:221)
 at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
 at 
 weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
 at 
 oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl._invokeDoFilter(AdfFacesFilterImpl.java:367)
 at 
 oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl._doFilterImpl(AdfFacesFilterImpl.java:336)
 at 
 oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl.doFilter(AdfFacesFilterImpl.java:196)
 at 
 oracle.adf.view.faces.webapp.AdfFacesFilter.doFilter(AdfFacesFilter.java:87)
 at 
 weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
 at 
 org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122)
 at 
 weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)

Re: [jira] Commented: (MYFACES-1146) Impossible to hide footer in dataTable

2006-02-21 Thread Volker Weber

Hi Mario,

why not render a empty panelGroup, if so declared in the jsf source?

IMO it is intuitive that there *is* a empty panel rendered in your example.


Regards,
  Volker


Mario Ivankovits wrote:
 Hi Volker!
 
[ 
 http://issues.apache.org/jira/browse/MYFACES-1146?page=comments#action_12367167
  ] 

Volker Weber commented on MYFACES-1146:
---

I prefer to check the rendered attribute of footer/header component over 
adding extra attributes to datatable.
  
 
 
 This might be complicated, if not impossible to do.
 I have to check all children of all footer facets to see if the row
 should be renderer or not.
 Think of the following (for sure untypical, just to get the point):
 
 f:facet name=footer
 h:panelGroup
h:outputLabel for=input
   h:outputText value=abc rendered=false/
   /h:outputLabel
   h:inputText id=input rendered=false/
 /h:panelGroup
 /f:facet
 
 We can say we take the rendered state of the first/root child of the
 facet tag, but this is not very intuitive, is it?
 
 Ciao,
 Mario
 

-- 
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.

Re: svn commit: r378805 - /myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/application/ApplicationFactoryImpl.java

2006-02-21 Thread Manfred Geiler

+1 for dependency on commons-logging 1.0.4

BTW, Stan (Silvert), how do you solve these logging issues in JBoss?
AFAIK, JBoss has only one central log4j configuration. However, is
there a way to config logging per eapp or webapp? If yes, how does
JBoss address those issues with shared classes?

Thanks,
Manfred



On 2/21/06, Simon Kitching [EMAIL PROTECTED] wrote:
 On Mon, 2006-02-20 at 21:47 -0800, Craig McClanahan wrote:
  No, I was not aware of that change ... but does it actually work?
  Declaring something Serializable is not by itself sufficient if there
  are transient variables inside the implementation.  (On a separate
  thread on commons-dev, I recommended that there be unit tests to
  validate this behavior:  use a Log instance, serialize it, deserialize
  it, and use it some more).

 I believe Serializable is correctly implemented for all standard
 adapters except possibly AvalonLog [will follow that up on commons-dev].
 The deserialized objects correctly locate a fresh underlying log
 object to forward calls to.

 Yes there need to be unit tests for this; I'll look for them and add
 some if not already present.

 
 
  The 1.0.4 release occurred around June 2004 so perhaps there
  are a few
  containers out there capable of running MyFaces but which are
  still on
  JCL 1.0.3. In addition there might be a few custom Log
  adapters around
  which *might* not implement Serializable.
 
  However in view of the complicated/ugly workaround for
  non-serializable
  Log implementations, it seems ok to me for MyFaces to just
  declare a
  dependency on JCL 1.0.4. If people don't comply then there is
  a very
  obvious NotSerializableException: logAdapterClassName
  message
  generated. The fix is then to upgrade to 1.0.4 (which is
  binary
  compatible with earlier releases) or a later release.
 
  Comments/Opinions?
 
  +1 on declaring a dependency on Commons Logging 1.0.4 ... anything
  prior to that is just asking for trouble.  I use 1.0.4 exclusively for
  eveything that has a C-L dependency ... works fine, lasts a long
  time :-).

 So the conclusion seems to be that if/when using commons-logging in
 MyFaces, use:
   private Log foo = LogFactory.getLog(foo);
 everywhere except in short-lived and frequently-created objects. In
 those cases, either call LogFactory.getLog as needed or have some
 longer-lived object store the Log object.

 For StateHolder classes, things just work; the logger isn't saved in
 saveState; it gets recreated in the new component and that works.

 For Serializable classes, the Log object handles its own serialization
 correctly. No need for transient, no need for any other special hacks.

 MyFaces does need to declare a dependency on commons-logging 1.0.4 (not
 earlier versions) in order for things to work this simply. Release 1.0.4
 was in June 2004.

 Do NOT use static Log anywhere.

 Is this all ok?

 Cheers,

 Simon

Re: [jira] Commented: (MYFACES-1146) Impossible to hide footer in dataTable

2006-02-21 Thread Mario Ivankovits

Hi!
 why not render a empty panelGroup, if so declared in the jsf source?
 IMO it is intuitive that there *is* a empty panel rendered in your example.
   
So I'll check the rendered attribute of the facet child and if none of
the facets are going to be rendered I'll suppress the footer (header) at
all.

---
Mario

 This might be complicated, if not impossible to do.
 I have to check all children of all footer facets to see if the row
 should be renderer or not.
 Think of the following (for sure untypical, just to get the point):

 f:facet name=footer
 h:panelGroup
h:outputLabel for=input
   h:outputText value=abc rendered=false/
   /h:outputLabel
   h:inputText id=input rendered=false/
 /h:panelGroup
 /f:facet

 We can say we take the rendered state of the first/root child of the
 facet tag, but this is not very intuitive, is it?

Re: [jira] Commented: (MYFACES-1146) Impossible to hide footer in dataTable

2006-02-21 Thread Martin Marinschek

Of course, this leads to additional evaluations of the rendered attribute.

Well, sounds good.

regards,

Martin

On 2/21/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
 Hi!
  why not render a empty panelGroup, if so declared in the jsf source?
  IMO it is intuitive that there *is* a empty panel rendered in your example.
 
 So I'll check the rendered attribute of the facet child and if none of
 the facets are going to be rendered I'll suppress the footer (header) at
 all.

 ---
 Mario

  This might be complicated, if not impossible to do.
  I have to check all children of all footer facets to see if the row
  should be renderer or not.
  Think of the following (for sure untypical, just to get the point):
 
  f:facet name=footer
  h:panelGroup
 h:outputLabel for=input
h:outputText value=abc rendered=false/
/h:outputLabel
h:inputText id=input rendered=false/
  /h:panelGroup
  /f:facet
 
  We can say we take the rendered state of the first/root child of the
  facet tag, but this is not very intuitive, is it?
 




--

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: Refactor Commons to org.apache.myfaces.commons ?

2006-02-21 Thread Manfred Geiler

On 2/20/06, Sean Schofield [EMAIL PROTECTED] wrote:
 Wow that seems really complicated.  I have serious concerns about last
 minute search and replace on the source code.  There's got to be a
 easier solution.  Until we started down the maven path we were fine
 with the way it is.  Lets re-examine why we are considering this in
 the first place.

 Manfred's scenario ...

 Scenario:

 1. We release commons-1.1.2 + core 1.1.2 (core 1.1.2 depends on commons-1.1.2)
 2. days go by...
 3. We release commons-1.1.3 (because there where significant changes)
 + tomahawk 1.1.3 (which depends on commons-1.1.3)

 So, there are now the following official releases out there:

 commons-1.1.2
 commons-1.1.3
 core-1.1.2
 tomahawk-1.1.3

 User happy starts his brandnew Maven project unlucky, decides to
 use the latest stable releases of everything and defines the following
 dependencies:

 XY depends on myfaces-api 1.1.2 (scope compile)
 XY depends on myfaces-impl 1.1.2 (scope runtime)
 XY depends on tomahawk 1.1.3 (scope compile)

 Now he builds the WAR. Guess what he ends up with?
 WEB-INF/lib/myfaces-api-1.1.2.jar
 WEB-INF/lib/myfaces-commons-1.1.2.jar
 WEB-INF/lib/myfaces-commons-1.1.3.jar
 WEB-INF/lib/myfaces-impl-1.1.2.jar
 WEB-INF/lib/myfaces-tomahawk-1.1.3.jar

 I think we can solve this usecase without resorting to last minute
 code refactoring by maven, or even worse, changing bytecode around.  I
 just don't think those solutions are necessary.

 One solution could be is that we make the scope of the commons
 dependency in core and tomahawk to be provided.  That way its not
 transitive and you don't end up with two versions of the commons jar
 in your WAR.  What that means is that you need to declare explicitly a
 commons dependency in your project as well as core and/or tomahawk.

Yes, this sounds reasonable. If we decide against this auto-repackage
thingy, this is probably the right setting for our dependencies.

Manfred




 In this case you would just say your project depends on commons
 version 1.1.3.  Everything will be fine as long as 1.1.3 does not
 break backwards compatability with an earlier version of the core.  We
 can easily test this when we release tomahawk and if it does break
 backwards compatability, we can release a newer version of the core as
 well.

 Its not ideal but its much better then the other alternatives we are
 considering.  I think we carefully document and explain this on the
 website and include instructions and considerations for those building
 with maven or using myfaces implementation in their J2EE containers.

 Sean




 On 2/18/06, Manfred Geiler [EMAIL PROTECTED] wrote:
  As Martin already has mentioned, I'm more and more convinced too, that
  repackaging commons for impl is the only solution that will make as
  carefree in the long run.
 
  Though, I do not agree that it is necessary or advantageous to
  repackage commons for all component libs (tomahawk, tobago, adffaces).
  This would bring commons far away from the original idea of having a
  Jakarta commons like JSF library with goodies and convenient base
  classes for custom components. Yes, people will probably have
  conflicts. But the release cycles of our component libs should be fast
  enough and commons should become stable enough, so that this is no
  longer a problem.
 
  MyFaces-Core (ie. impl) is different insofar as
   * we want to keep release cycles at a minimum
   * it will become integrated part of containers (already shipped with
  JBoss 4.x), or
   * people make them part of their containers by sharing
  myfaces-api.jar and myfaces-impl.jar in the containers common/lib or
  shared/lib dir.
  The last two points also will have influence on how people will
  configure their own Maven projects: provided dependency on
  myfaces-api.jar and myfaces-impl.jar of the version that was shipped
  with (or is integrated in) the container. People will behave
  conservative in changing their container environment and behave
  liberal when using the newest component lib.
  However, as soon as we have a repackaging solution, it is easy enough
  to use it not only for impl. So, let's discuss repackaging in general
  first and postpone the question of using repackaged commons lib for
  tomahawk et al. for a while, ok?
 
  Here is my idea for a (not-so-high-sophisticated but) easy repackaging 
  solution:
  1. First of all we refactor Commons to org.apache.myfaces.commons.*
  (we already have an agreement on this)
 
  2. Next we create a sub-project in commons. Working title
  intermediate-commons-impl.
 
  = This project's outcome will be the intermediate-commons-impl.jar
  file with all commons classes auto-repackaged to
  org.apache.myfaces.commons.impl.* (like proposed by Simon).
 
  = This jar file will not be shipped or included in any assembly
  (therefore intermediate). It only serves as the Maven-way medium to
  transport the repackaged commons classes to the impl module. The
  repackaged class files will

92 matches

Mail list logo