[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE

2006-01-06 Thread Mathias Broekelmann (JIRA)
[ 
http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361951 
] 

Mathias Broekelmann commented on MYFACES-985:
-

I will leave this issue open since it is working on SunĀ“s RI.

 UIData with multihierarchical children inside produces NPE
 --

  Key: MYFACES-985
  URL: http://issues.apache.org/jira/browse/MYFACES-985
  Project: MyFaces
 Type: Bug
   Components: Implementation
  Environment: Tomcat 5.0
 JDK 1.4
 Reporter: Andrew Kharchenko 
 Assignee: Mathias Broekelmann
  Attachments: UIData NPE Sample.rar

 I've found incorrect UIData behaviour under MyFaces which produces 
 NullPointerException on runtime and which works fine under Sun implementation.
 Here it is:
 I have a custom component which is extentor from UIInput. This component has 
 UIPanel extentor component as child which is added to children list of 
 UIInput component on rendering. 
 For one's turn, UIPanel extentor has one more UIInput extentor component as 
 child which is added to children list of UIPanel component on rendering.
 This component works fine standalone, but when it is added to UIData, I have 
 NPE on runtime. Here is the part of listing:
 java.lang.NullPointerException
  at 
 javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223)
  at 
 javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235)
  at 
 javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235)
  at 
 javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235)
  at javax.faces.component.UIData.setRowIndex(UIData.java:178)
 I will also attach sample component's classes, definitions and test page if 
 it will be granted after issue creation.

-- 
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-985) UIData with multihierarchical children inside produces NPE

2006-01-06 Thread Mathias Broekelmann (JIRA)
[ 
http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361950 
] 

Mathias Broekelmann commented on MYFACES-985:
-

You could also use the rendered attribute to switch on or off rendering a 
component. 

 UIData with multihierarchical children inside produces NPE
 --

  Key: MYFACES-985
  URL: http://issues.apache.org/jira/browse/MYFACES-985
  Project: MyFaces
 Type: Bug
   Components: Implementation
  Environment: Tomcat 5.0
 JDK 1.4
 Reporter: Andrew Kharchenko 
 Assignee: Mathias Broekelmann
  Attachments: UIData NPE Sample.rar

 I've found incorrect UIData behaviour under MyFaces which produces 
 NullPointerException on runtime and which works fine under Sun implementation.
 Here it is:
 I have a custom component which is extentor from UIInput. This component has 
 UIPanel extentor component as child which is added to children list of 
 UIInput component on rendering. 
 For one's turn, UIPanel extentor has one more UIInput extentor component as 
 child which is added to children list of UIPanel component on rendering.
 This component works fine standalone, but when it is added to UIData, I have 
 NPE on runtime. Here is the part of listing:
 java.lang.NullPointerException
  at 
 javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223)
  at 
 javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235)
  at 
 javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235)
  at 
 javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235)
  at javax.faces.component.UIData.setRowIndex(UIData.java:178)
 I will also attach sample component's classes, definitions and test page if 
 it will be granted after issue creation.

-- 
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-985) UIData with multihierarchical children inside produces NPE

2006-01-06 Thread Andrew Kharchenko (JIRA)
[ 
http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361953 
] 

Andrew Kharchenko  commented on MYFACES-985:


OK. Thanx for advice.

 UIData with multihierarchical children inside produces NPE
 --

  Key: MYFACES-985
  URL: http://issues.apache.org/jira/browse/MYFACES-985
  Project: MyFaces
 Type: Bug
   Components: Implementation
  Environment: Tomcat 5.0
 JDK 1.4
 Reporter: Andrew Kharchenko 
 Assignee: Mathias Broekelmann
  Attachments: UIData NPE Sample.rar

 I've found incorrect UIData behaviour under MyFaces which produces 
 NullPointerException on runtime and which works fine under Sun implementation.
 Here it is:
 I have a custom component which is extentor from UIInput. This component has 
 UIPanel extentor component as child which is added to children list of 
 UIInput component on rendering. 
 For one's turn, UIPanel extentor has one more UIInput extentor component as 
 child which is added to children list of UIPanel component on rendering.
 This component works fine standalone, but when it is added to UIData, I have 
 NPE on runtime. Here is the part of listing:
 java.lang.NullPointerException
  at 
 javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223)
  at 
 javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235)
  at 
 javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235)
  at 
 javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235)
  at javax.faces.component.UIData.setRowIndex(UIData.java:178)
 I will also attach sample component's classes, definitions and test page if 
 it will be granted after issue creation.

-- 
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] Created: (MYFACES-1007) AUTO_SCROLL not always working with IE

2006-01-06 Thread Antoine Sabot-Durand (JIRA)
AUTO_SCROLL not always working with IE
--

 Key: MYFACES-1007
 URL: http://issues.apache.org/jira/browse/MYFACES-1007
 Project: MyFaces
Type: Improvement
  Components: Implementation  
Versions: 1.1.1
 Environment: Windows XP Tomcat 5.5 et IE 6 sp2
Reporter: Antoine Sabot-Durand
Priority: Minor


In some case the autoscroll feature doesn't work in Internet explorer 6. 
Especially when the rendered HTML contains a lot of div.
This is due to a bug in Internet Explorer.

The solution I found is to modify the renderAutoScrollFunction method in 
org.apache.myfaces.renderkit.html.util class.

I changed the following line :
script.append(window.scrollTo().append(x).append(,).append(y).append();\n);
to
script.append(setTimeout('window.scrollTo().append(x).append(,).append(y).append()',1);\n);

The setTimeout let IE finish whatever it has to to get a right layout of the 
HTML elements on the page.

-- 
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: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes

2006-01-06 Thread Sean Schofield
Looks pretty good.  One minor change and a few questions.

@Martin: Any comments on this before we go ahead?  (We will keep your
resource structure for now and try to find a solution for that later.)

 The next try:

 core (org.apache.myfaces)
 [This has a own release cycle]
 
 myfaces/core/trunk/pom.xml
 myfaces/core/trunk/myfaces-api/pom.xml
 myfaces/core/trunk/myfaces-impl/pom.xml
 myfaces/core/trunk/assembly/pom.xml

 modules
modulemyfaces-api/module
modulemyfaces-impl/module
moduleassembly/module
 modules


 commons (org.apache.myfaces)
 [This has a own release cycle]
 ===
 myfaces/commons/trunk/pom.xml
 myfaces/commons/trunk/src/main
 myfaces/commons/trunk/src/test
 myfaces/commons/trunk/src/site
 [myfaces/commons/assembly/pom.xml]
 NOTE: own assembly not really needed
 if released as part of the assembly of core and tomahawk

OK.  Now I understand why you skipped assembly for this one.


 tomahawk  sandbox
 (org.apache.myfaces.tomahawk or org.apache.myfaces)
 [This has a own release cycle]
 [Sandbox is not released only in nightly build]
 ===
 myfaces/tomahawk/trunk/pom.xml
 myfaces/tomahawk/trunk/src/main
 myfaces/tomahawk/trunk/src/test
 myfaces/tomahawk/trunk/src/site
 myfaces/tomahawk/trunk/example/pom.xml
 myfaces/tomahawk/trunk/sandbox/pom.xml
 myfaces/tomahawk/trunk/sandbox/src/main
 myfaces/tomahawk/trunk/sandbox/src/test
 myfaces/tomahawk/trunk/sandbox/src/site
 myfaces/tomahawk/trunk/assembly/pom.xml

 NOTE: If tomahawk has a different groupid the pom is not inherited
 Maybe we can start which the same groupid, if it make sense we can
 change it in a future version. (The tomahawk pom is to different)

One more change ...

 myfaces/tomahawk/trunk/sandbox/example  -- add this

Sandbox examples will depend on sandbox components and the
sandbox.jar.  So they should probably be broken out separately.


 tools (org.apache.myfaces)
 [no assembly but release on a maven repository]
 =
 myfaces/tools/trunk/pom.xml
 myfaces/tools/trunk/maven-myfaces-plugin/pom.xml
 myfaces/tools/trunk/build-tools(checkstyleandpmdconfiguration)/pom.xm

 NOTE: The maven-myfaces-plugin is an archtype-plugin for maven currently
 in the test repository.

Oh yes Bruno's archtype plugin.  Yes that should go there.

 site (org.apache.myfaces)
 [never released only for publishing the main site and the content of the
 main site]
 =
 myfaces/site/trunk/pom.xml
 NOTE: The main site can be part of core

It could be part of core but I think your initial idea (as its own top
level) is better.  The site is for everything (not just core.)


 Process for updateing the site and publishing the nightly build and the
 snapshots:
 This is done by spezial task from the continuum server or by some
 scripts invoked on the myfaces.zone.apache.org server?

I was thinking chron script on the zone.

 The idea is: We call some maven goals on some poms.
 mvn site:deploy in the site trunk for the main site
 mvn site:deploy in the core, commons and tomahawk trunk

Sounds good.  The one thing is that I would like links in the top
level site for the module sites (and also in the reverse direction.) 
Do we just add those manually to the nav contents of each of the
sites?  Is there a way to do this in Maven?

 mvn deploy:deploy on all trunks for the shapshots

And this will make the snapshots available to our own projects as well
as those of our users right?  Sounds good.

 mvn assembly:assembly for the nightly build on core and tomahawk

Right.  And maybe also for the official release?

 NOTE: I don't expect one spezial pom for this.

I guess you're right.  There isn't anything in Maven that will pull it
all together for you.

 TODO find a better name for assembly

We can try ;-)  Build is already taken.  Maybe publish?

 TODO setup solaris zone

Its been setup.  Nothing has been done with it yet.  Once we get the
builds working that will be the next step.

 TODO setup continuum
 TODO define a snapshot repository
 TODO define the process for updating the site and nightly buid

Yes.  This looks great Bernd.  I like what we are settling on.


 Best Regards

 Bernd


Sean


Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes

2006-01-06 Thread Adam Winer
On 1/5/06, Sean Schofield [EMAIL PROTECTED] wrote:

  There are transitive dependencies between commons and impl, or commons
  and tomahawk.

 Tomahawk actually has a dependency on api (a compile time one.)  If
 you were to build tomahawk using maven you would need it.  If you were
 to use tomahawk with your own project you would not need it.  I'm
 thinking the provided scope would help us here?

Yep, provided would be a good fit here.

Anything that's a compile time dependency of library Foo
where a user of Foo is responsible for supplying that dependency
should be declared provided.

-- Adam


Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes

2006-01-06 Thread Bernd Bohmann

The next round

core (org.apache.myfaces)
[This has a own release cycle]

myfaces/core/trunk/pom.xml
myfaces/core/trunk/myfaces-api/pom.xml
myfaces/core/trunk/myfaces-impl/pom.xml
myfaces/core/trunk/assembly/pom.xml

modules
   modulemyfaces-api/module
   modulemyfaces-impl/module
   moduleassembly/module
modules


commons (org.apache.myfaces)
[This has a own release cycle]
===
myfaces/commons/trunk/pom.xml
myfaces/commons/trunk/src/main
myfaces/commons/trunk/src/test
myfaces/commons/trunk/src/site
[myfaces/commons/assembly/pom.xml]

NOTE: own assembly not really needed
if released as part of the assembly of core and tomahawk


tomahawk  sandbox
(org.apache.myfaces.tomahawk or org.apache.myfaces)
[This has a own release cycle]
[Sandbox is not released only in nightly build]
===
myfaces/tomahawk/trunk/pom.xml
myfaces/tomahawk/trunk/src/main
myfaces/tomahawk/trunk/src/test
myfaces/tomahawk/trunk/src/site
myfaces/tomahawk/trunk/example/pom.xml
myfaces/tomahawk/trunk/sandbox/pom.xml
myfaces/tomahawk/trunk/sandbox/src/main
myfaces/tomahawk/trunk/sandbox/src/test
myfaces/tomahawk/trunk/sandbox/src/site
myfaces/tomahawk/trunk/sandbox/example/pom.xml
myfaces/tomahawk/trunk/assembly/pom.xml

NOTE: If tomahawk has a different groupid the pom is not inherited
Maybe we can start which the same groupid, if it makes sense we can
change it in a future version. (When the tomahawk pom is to different)


tools (org.apache.myfaces)
[no assembly but release on a maven repository]
=
myfaces/tools/trunk/pom.xml
myfaces/tools/trunk/myfaces-archetype-plugin/pom.xml
myfaces/tools/trunk/build-tools(checkstyleandpmdconfiguration)/pom.xm

NOTE: The myfaces-archetype-plugin is an archetype-plugin for maven 
currently in the test repository.


site (org.apache.myfaces)
[never released only for publishing the main site and the content of the
main site]
=
myfaces/site/trunk/pom.xml

NOTE: The main site can be part of core but the site is for everything 
not just for core



Process for updating the site and publishing the nightly builds and the
snapshots:
===
This is done by special task from the continuum server or by some
chron scripts invoked on the myfaces.zone.apache.org server?

The idea is:
We call some maven goals on some poms.
mvn site:deploy in the site trunk for the main site
mvn site:deploy in the core, commons and tomahawk trunk

NOTE: The links between the the top level site and the subprojects are 
added manually in the site.xml. The svn version of the site plugin is 
reactor aware(Then not all links between the subprojects must defined).


mvn deploy:deploy on all trunks for deploying all artifacts to the 
snapshot repository


mvn assembly:assembly for the nightly build on core and tomahawk

NOTE: A release need some more steps, but maven has a plugin for this 
and a best practice.



TODO find a better name for assembly (dist|build|bin)?
TODO use the myfaces solaris zone for publish the site, nightly build, 
continuum..

TODO setup continuum
TODO define a snapshot repository
TODO define the process for updating the site and nightly build

Best Regards

Bernd


Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes

2006-01-06 Thread Bernd Bohmann

I don't think provided would be a good idea.

If someone don't use tomahawk with myfaces-api and myfaces-impl.
It would be easier to exclude myfaces-api and myfaces-impl and add a 
dependency to the RI. On the other side it would be painful for the 
normal user, the normal user would expect a compile dependency to 
myfaces-imp and myfaces-api.


Adam Winer schrieb:

On 1/5/06, Sean Schofield [EMAIL PROTECTED] wrote:



There are transitive dependencies between commons and impl, or commons
and tomahawk.


Tomahawk actually has a dependency on api (a compile time one.)  If
you were to build tomahawk using maven you would need it.  If you were
to use tomahawk with your own project you would not need it.  I'm
thinking the provided scope would help us here?



Yep, provided would be a good fit here.

Anything that's a compile time dependency of library Foo
where a user of Foo is responsible for supplying that dependency
should be declared provided.

-- Adam



--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333


Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes

2006-01-06 Thread Wendy Smoak
On 1/6/06, Adam Winer [EMAIL PROTECTED] wrote:

 Anything that's a compile time dependency of library Foo
 where a user of Foo is responsible for supplying that dependency
 should be declared provided.

The Maven team usually puts it as ... can reasonably be expected to
be provided at runtime.  But Maven 2.0 doesn't have anything in place
to deal with the choice of implementations situation, and so
'provided' is probably the best bet.

This will put the responsibility of choosing an implementation on the
user-- either by declaring a dependency or installing it in the
container.  (Or, I suppose, by using a container that already provides
it.)  I think that's reasonable.

--
Wendy


Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes

2006-01-06 Thread Adam Winer
And, once we get to JSF 1.2, provided is a clear
winner because web containers will need to provide a JSF
implementation.

-- Adam


On 1/6/06, Wendy Smoak [EMAIL PROTECTED] wrote:
 On 1/6/06, Adam Winer [EMAIL PROTECTED] wrote:

  Anything that's a compile time dependency of library Foo
  where a user of Foo is responsible for supplying that dependency
  should be declared provided.

 The Maven team usually puts it as ... can reasonably be expected to
 be provided at runtime.  But Maven 2.0 doesn't have anything in place
 to deal with the choice of implementations situation, and so
 'provided' is probably the best bet.

 This will put the responsibility of choosing an implementation on the
 user-- either by declaring a dependency or installing it in the
 container.  (Or, I suppose, by using a container that already provides
 it.)  I think that's reasonable.

 --
 Wendy



Re: searching for component

2006-01-06 Thread Mike Kienenberger
I'd go with vertical/horizontal or page/line.  normal/reverse don't
carry any meaning on what to expect.   You should probably keep any
further discussion to the mailing list (dev makes the most sense for
this topic) as others might have better suggestions.

Yes, definitely open a JIRA issue and attach your patches.   It's
certainly useful!

Thanks for improving MyFaces!

-Mike

On 1/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 If I add an orientation parameter to the newspaperTable component,
 say orientation = normal (default) or reverse
 (or do you have a better idea?)
 should I contribute my change to myfaces? Via JIRA?
 Or is it useful enough?

 -Original Message-
 From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
 Sent: Friday, January 06, 2006 12:37 PM
 To: [EMAIL PROTECTED]
 Subject: Re: searching for component

 On 1/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  Thanks, but this goes vertical then horizontal, right?
  Can I make it go horizontal, then vertical?

 Hmm.  You're right.   I don't think the orientation is configurable at
 present.
 If you're considering creating a new component, I'd recommend looking at
 adding an orientation parameter to the newspaperTable component instead.

 I'd think you'd need to update the renderer for the component.

 Or you could look at using t:dataTable with a simple layout, and manually
 constructing the layout elements.

 You might also be able to do this using t:dataTable and t:columns and have
 the columns object break your list up into smaller lists.

 I suppose if you're using facelets you could manually construct the elements
 using c:forEach and stick them in an h:panelGrid.

 Can't think of any other options -- I'd probably go with adding orientation
 to newspaperTable if it were me, reversing the rows and columns.

  -Original Message-
  From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
  Sent: Friday, January 06, 2006 12:19 PM
  To: MyFaces Discussion; [EMAIL PROTECTED]
  Subject: Re: searching for component
 
  http://myfaces.apache.org/tomahawk/newspaperTable.html probably does
  what you need.
 
  On 1/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   Does anyone know of an existing component that would allow a list
   (or array, collection, whatever) of h:panelGroup to be added to a
   h:panelGrid?
   That is, the backing bean has an ArrayList of objects
   (beans) to place in the cells, continuously in a table, left to
   right, then starting a new row when necessary.
   Sort of like the h:datatable has a list of rows.
   The List is fixed, so I could hard code the objects in the jsp, but
   there are 45 of them, so I'd rather not.
   I looked in the jsfcentral list of components, but couldn't find
   anything.
   If not, would this component be difficult to write?
  
   Thanks,
   Lance
  
  
  
  
 
 




ADF Source drop is available!

2006-01-06 Thread Adam Winer
Well, we've finally gotten there and done it.   A public drop
of the ADF Faces source code is now available:

http://homepage.mac.com/awiner/FileSharing.html

Ted Husted will be copying this over to a people.apache.org
site, at which point I'll take it down from mac.com so
my bandwidth limit doesn't get completely clobbered.

This should be (nearly) a fully buildable Maven 2.0 project,
including a separate project of custom Maven 2 plugins (
which are also part of the contribution.)  There's an Apache 2.0
LICENSE.txt at the root of the distribution, and to save people
the work of building it, we've included the JARs and our
demo WAR.

John and I have spent most of this week cleaning up the
codebase to eliminate compile and build dependencies on
anything Oracle proprietary or non-ASF compatible.  I'd say
we're 99.9% of the way there - the remaining points being:

  - the lack (AFAIK) of a JSF impl in the public maven
   repository - obviously, we can trivially point that to
   MyFaces api and impl
 - Our tests use a Mock JSF impl that's just a mockmaker
   run over jsf-api - but that's not totally ASF-legit.
   We've included that jar in this distribution, but this needs
   to be redone the right way.

Looking forward to all of your comments!

Best regards,
John and Adam


[jira] Created: (MYFACES-1008) security bug of myfaces

2006-01-06 Thread lantian (JIRA)
security  bug of myfaces


 Key: MYFACES-1008
 URL: http://issues.apache.org/jira/browse/MYFACES-1008
 Project: MyFaces
Type: Bug
  Components: Tomahawk  
Versions: 1.1.1
 Environment: windows 2000 ;
SUN JDK1.4.0.3 ;
Tomcat 5.0.28

Reporter: lantian
Priority: Critical


FACES SERVLET  is not secure when useing prefix mapping such as/faces/* .
users can access any contents in  WEB-INF directory.

try following in your faces website  :

http://localhost/mywebsite/faces/WEB-INF/web.xml
http://localhost/mywebsite/faces/WEB-INF/lib/



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