Re: [al] license question [was [jira] Commented: (TOMAHAWK-250) New 'Outlook Menu' type component for Sandbox]
Dennis Byrne schrieb: So what do you mean by add the license to the licenses section? There is a licenses dir under src/main/resources/ for most projects. Oh, I see, wasnt aware that this is allows, tough, even better :-) Thanks! Ciao, Mario
JIRA Issues TOMAHAWK-245 and 246
The issues pertain to exceptions while accessing the
Simple examples for Tree and PanelStack.
Both these issues are related to the Tree component
(the older one).
HtmlTreeImageCommandLinKRenderer extends
HtmlLinkRendererBase, and calls the method
'super.renderCommandLinkStart', which in turn
internally calls 'renderJavaScriptAnchorStart'.
The code in this method is as follows:
FormInfo formInfo = findNestingForm(component,
facesContext);
if (formInfo == null)
{
throw new IllegalArgumentException(Component +
clientId + must be embedded in an form);
}
This is the exception that shows up in the stack
trace.
The issues can be fixed simply, by replacing:
FormInfo formInfo = findNestingForm(component,
facesContext);
with:
FormInfo formInfo =
DummyFormUtils.findNestingForm(component,
facesContext);
The difference is that if the second method fails to
find an enclosing form, it sets a parameter informing
MyFaces to render the dummy form, and returns the
dummy form information. Many Tomahawk components
already do this check and set the necessary parameter.
HOWEVER:
The same method is also used by the core components
(HtmlCommandLink, etc) and I am assuming that they
should have no knowledge of the MyFaces dummy form.
So is it OK to go ahead with this change, or is there
a better solution?
Regards,
Sharath
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[IMPORTANT] MyFaces Core 1.1.2 and Tomahawk 1.1.1
Are there any issues with using the old tomahawk with the new core? I recall someone explaining to me that there were. This is important b/c the release is out there now and we need to put this info in the announcment in order to minimize confusion. There was already one question on the user list this morning. Sean
[jira] Closed: (MYFACES-750) Need synchronization in LifecycleImpl
[ http://issues.apache.org/jira/browse/MYFACES-750?page=all ]
sean schofield closed MYFACES-750:
--
Need synchronization in LifecycleImpl
-
Key: MYFACES-750
URL: http://issues.apache.org/jira/browse/MYFACES-750
Project: MyFaces Core
Type: Bug
Components: General
Versions: 1.1.0
Environment: Weblogic 8.1, AIX
Reporter: Sam Schneider
Assignee: Manfred Geiler
Fix For: 1.1.2
Getting this exception when removing a bean as a listener:
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:462)
at java.util.AbstractList$Itr.next(AbstractList.java:433)
at java.util.AbstractCollection.remove(AbstractCollection.java:268)
at
org.apache.myfaces.lifecycle.LifecycleImpl.removePhaseListener(LifecycleImpl.java:411)
at
com.erac.riskmgmt.ice.web.AbstractPageBean.afterPhase(AbstractPageBean.java:128)
The method call at AbstractPageBean:128 is
getLifecycle().removePhaseListener(this);
protected Lifecycle getLifecycle() {
String lifecycleId =
getExternalContext().getInitParameter(javax.faces.LIFECYCLE_ID);
if ((lifecycleId == null) || (lifecycleId.length() == 0)) {
lifecycleId = LifecycleFactory.DEFAULT_LIFECYCLE;
}
LifecycleFactory lifecycleFactory = (LifecycleFactory)
FactoryFinder.getFactory(
FactoryFinder.LIFECYCLE_FACTORY);
return lifecycleFactory.getLifecycle(lifecycleId);
}
Basically what's happening from a request perspective is that we have a
custom ViewHandler that creates the backing bean that's registered for a
given view id (custom registry using a HashMap that's created as a managed
bean and maintained manually in faces-config). When the backing bean is
created it adds itself as a listener and when the AFTER RENDER_RESPONSE is
executed the bean removes itself as a listener (as above at line 128 in
AbstractPageBean). No problems are observed in low-load situations, but when
we sent the application to benchmarking simulating ~200 concurrent users we
noticed this problem. It looks like easiest fix is to synchronize the array
list on adding and removing listeners (currently we've worked around this by
using an external lock to synchronize add/remove calls from our
AbstractPageBean).
However, It looks like there is also a potential problem with the call to
getPhaseListeners() in that it creates a cached array that's later copied
back into a *new* ArrayList in addPhaseListener(...) and
removePhaseListener(...). Since there is no synchronization if someone
called getPhaseListeners() and then two/N different threads tried to add
listeners 1..N listeners could be lost (all would check for a null
_phaseListenerList and multiple threads could potentially attempt to create a
new _phaseListenerList and add/remove the PhaseListener) -- of course the
converse problem would be that two/N different threads tried to remove phase
listeners and the 1..N listeners would not be removed (they would be recopied
in on another thread).
What would simplify this whole business greatly would be to remove the cached
list and simply synchronize on the ArrayList on the add/remove/getListeners:
public void addPhaseListener(PhaseListener phaseListener)
{
if(phaseListener == null)
{
throw new NullPointerException(PhaseListener must not be null.);
}
// create _phaseListenerList at class scope -- so no more null-checks for it
synchronized(_phaseListenerList) {
_phaseListenerList.add(phaseListener);
}
}
public void removePhaseListener(PhaseListener phaseListener)
{
synchronized(_phaseListenerList) {
_phaseListenerList.remove(phaseListener);
}
}
public PhaseListener[] getPhaseListeners()
{
synchronized(_phaseListenerList) {
return (PhaseListener[])_phaseListenerList.toArray(new
PhaseListener[_phaseListenerList.size()]);
}
}
--
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] Closed: (MYFACES-1205) JSR-252 Issue #9: Clarified the behavior of PhaseListener implementations: must guarantee that if beforePhase() is called the afterPhase() must also be called.
[ http://issues.apache.org/jira/browse/MYFACES-1205?page=all ] sean schofield closed MYFACES-1205: --- JSR-252 Issue #9: Clarified the behavior of PhaseListener implementations: must guarantee that if beforePhase() is called the afterPhase() must also be called. --- Key: MYFACES-1205 URL: http://issues.apache.org/jira/browse/MYFACES-1205 Project: MyFaces Core Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assignee: Stan Silvert Fix For: 1.1.2 Clarified the behavior of PhaseListener implementations in the following way: they must guarantee that if beforePhase() is called, then afterPhase() must also be called, regardless of any thrown exceptions. Please see Section 11.3 PhaseListener for more specifics. See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=9 -- 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] Closed: (MYFACES-1280) EvaluationException during updateModel does not invalidate the component.
[ http://issues.apache.org/jira/browse/MYFACES-1280?page=all ] sean schofield closed MYFACES-1280: --- EvaluationException during updateModel does not invalidate the component. - Key: MYFACES-1280 URL: http://issues.apache.org/jira/browse/MYFACES-1280 Project: MyFaces Core Type: Bug Components: JSR-127 Versions: 1.1.2-SNAPSHOT Reporter: sean schofield Priority: Critical Fix For: 1.1.2 Code was added to UIInput (since 1.1.1) that fails to invalidate the component when an EvaluationException occurs. -- 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: [IMPORTANT] MyFaces Core 1.1.2 and Tomahawk 1.1.1
Yes. The classes that the old tomahawk depended on in the core no longer exist -- they have been renamed to shared_tomahawk (or shared_impl depending on your perspective. I already answered the question earlier. On 4/17/06, Sean Schofield [EMAIL PROTECTED] wrote: Are there any issues with using the old tomahawk with the new core? I recall someone explaining to me that there were. This is important b/c the release is out there now and we need to put this info in the announcment in order to minimize confusion. There was already one question on the user list this morning. Sean
Re: [IMPORTANT] MyFaces Core 1.1.2 and Tomahawk 1.1.1
I think our general answer to this question should be: Before 1.1.2, tomahawk and core version must match. For 1.1.2 and beyond, tomahawk and core do not need to match. On 4/17/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Yes. The classes that the old tomahawk depended on in the core no longer exist -- they have been renamed to shared_tomahawk (or shared_impl depending on your perspective. I already answered the question earlier. On 4/17/06, Sean Schofield [EMAIL PROTECTED] wrote: Are there any issues with using the old tomahawk with the new core? I recall someone explaining to me that there were. This is important b/c the release is out there now and we need to put this info in the announcment in order to minimize confusion. There was already one question on the user list this morning. Sean
Re: [IMPORTANT] MyFaces Core 1.1.2 and Tomahawk 1.1.1
Yes. The classes that the old tomahawk depended on in the core no longer exist -- they have been renamed to shared_tomahawk (or shared_impl depending on your perspective. I already answered the question earlier. That's what I thought but I couldn't find the email. I've been a little busy lately ;-) @Martin: Let's put this info in the release announcement then. @Everyone Else: Lets get cranking on a tomahawk release.
Tomahawk Release?
Are we ready for a branch for Tomahawk? Earlier it was pointed out that there were some impl dependencies still in Sandbox. Matthias removed some of these and I think its safe to ignore the rest for now since they are in sandbox. I don't think we want to go too long without an updated tomahawk now that the old one is incompatible with the new core. Sean
Re: [IMPORTANT] MyFaces Core 1.1.2 and Tomahawk 1.1.1
Sounds good! regards, Martin On 4/17/06, Sean Schofield [EMAIL PROTECTED] wrote: Yes. The classes that the old tomahawk depended on in the core no longer exist -- they have been renamed to shared_tomahawk (or shared_impl depending on your perspective. I already answered the question earlier. That's what I thought but I couldn't find the email. I've been a little busy lately ;-) @Martin: Let's put this info in the release announcement then. @Everyone Else: Lets get cranking on a tomahawk release. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [IMPORTANT] MyFaces Core 1.1.2 and Tomahawk 1.1.1
On 4/17/06, Mike Kienenberger [EMAIL PROTECTED] wrote: I already answered the question earlier. On 4/17/06, Sean Schofield [EMAIL PROTECTED] wrote: That's what I thought but I couldn't find the email. I've been a little busy lately ;-) Sorry, I wasn't clear enough. :) I didn't mean I answered the question already -- quit asking! I meant I also posted to the user list a few minutes ago and took care of the user who was asking earlier
Re: Tomahawk Release?
On 4/17/06, Sean Schofield [EMAIL PROTECTED] wrote: Are we ready for a branch for Tomahawk? Earlier it was pointed out that there were some impl dependencies still in Sandbox. Matthias removed some of these and I think its safe to ignore the rest for now since they are in sandbox. Actually, Matthias took the time to go through and fix every single remaining dependency issue! Thanks! Let's release Tomahawk to reduce user confusion. After that, we can release as desired, including minor bug fixes.
Upgrading MyFaces dependency in a project's Maven2 pom.xml?
I am currently using MyFaces 1.1.1 in a project that is built via Maven 2.x. Below are the dependency entries in pom.xml related to MyFaces. How do they need to change for 1.1.2? dependency groupIdmyfaces/groupId artifactIdmyfaces-impl/artifactId version1.1.1/version /dependency dependency groupIdmyfaces/groupId artifactIdtomahawk/artifactId version1.1.1/version /dependency In general I rely on Maven to download any dependencies need for a specific application, thus I may not download the distribution. The Upgrading and Getting Started sections of the documentation should address Maven dependencies. I would also like to thank the MyFaces developers for their work. Paul Spencer
Re: Upgrading MyFaces dependency in a project's Maven2 pom.xml?
Agreed on the documentation. Its on my short term todo list. We are waiting on the maven people to publish the dependencies to ibiblio. They should be available in a few days. We are working as fast as we can. Sean On 4/17/06, Paul Spencer [EMAIL PROTECTED] wrote: I am currently using MyFaces 1.1.1 in a project that is built via Maven 2.x. Below are the dependency entries in pom.xml related to MyFaces. How do they need to change for 1.1.2? dependency groupIdmyfaces/groupId artifactIdmyfaces-impl/artifactId version1.1.1/version /dependency dependency groupIdmyfaces/groupId artifactIdtomahawk/artifactId version1.1.1/version /dependency In general I rely on Maven to download any dependencies need for a specific application, thus I may not download the distribution. The Upgrading and Getting Started sections of the documentation should address Maven dependencies. I would also like to thank the MyFaces developers for their work. Paul Spencer
Re: Tomahawk Release?
I created shared and tomahawk branches. We need to upgrade the SNAPSHOT versions on the trunk by 1 minor revision number. We also need to fix a bunch of dependencies on the trunk that go along with that. Sean On 4/17/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 4/17/06, Sean Schofield [EMAIL PROTECTED] wrote: Are we ready for a branch for Tomahawk? Earlier it was pointed out that there were some impl dependencies still in Sandbox. Matthias removed some of these and I think its safe to ignore the rest for now since they are in sandbox. Actually, Matthias took the time to go through and fix every single remaining dependency issue! Thanks! Let's release Tomahawk to reduce user confusion. After that, we can release as desired, including minor bug fixes.
[jira] Created: (TOMAHAWK-259) t:messages detailFormat doesn't use an outputLabel's outputText
t:messages detailFormat doesn't use an outputLabel's outputText
---
Key: TOMAHAWK-259
URL: http://issues.apache.org/jira/browse/TOMAHAWK-259
Project: MyFaces Tomahawk
Type: Bug
Versions: 1.1.2-SNAPSHOT
Reporter: Dave Brondsema
Priority: Minor
I am using this:
t:messages detailFormat={1}: {0} showDetail=true showSummary=false/
And it displays nothing for the {1}. It displays the proper value for {0}. If
I change my labels to use value= instead of the nested outputText, then {1}
does work.
I am using facelets 1.0.10 and myfaces r38
My labels look like this
h:outputLabel for=currentcity
#{text['city']}span class=x-portlet-instructions*/span
/h:outputLabel
or:
h:outputLabel for=previousgpa
#{text['previousgpa']}
/h:outputLabel
--
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: JIRA Issues TOMAHAWK-245 and 246
Hello Sharath,
Thanks for taking a look at these two, I didn't know they were related. Your
just in time for the new tomahawk release ;) I won't be able to take a look at
this until the end of the week but it would really help us out if you put a
patch in JIRA.
Dennis Byrne
-Original Message-
From: sharath reddy [mailto:[EMAIL PROTECTED]
Sent: Monday, April 17, 2006 08:19 AM
To: dev@myfaces.apache.org
Subject: JIRA Issues TOMAHAWK-245 and 246
The issues pertain to exceptions while accessing the
Simple examples for Tree and PanelStack.
Both these issues are related to the Tree component
(the older one).
HtmlTreeImageCommandLinKRenderer extends
HtmlLinkRendererBase, and calls the method
'super.renderCommandLinkStart', which in turn
internally calls 'renderJavaScriptAnchorStart'.
The code in this method is as follows:
FormInfo formInfo = findNestingForm(component,
facesContext);
if (formInfo == null)
{
throw new IllegalArgumentException(Component +
clientId + must be embedded in an form);
}
This is the exception that shows up in the stack
trace.
The issues can be fixed simply, by replacing:
FormInfo formInfo = findNestingForm(component,
facesContext);
with:
FormInfo formInfo =
DummyFormUtils.findNestingForm(component,
facesContext);
The difference is that if the second method fails to
find an enclosing form, it sets a parameter informing
MyFaces to render the dummy form, and returns the
dummy form information. Many Tomahawk components
already do this check and set the necessary parameter.
HOWEVER:
The same method is also used by the core components
(HtmlCommandLink, etc) and I am assuming that they
should have no knowledge of the MyFaces dummy form.
So is it OK to go ahead with this change, or is there
a better solution?
Regards,
Sharath
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Branch merge complete -- Trunk test failure
I merged the branch stuff for shared and core. Unfortunately the unit test related to the TCK is still failing. @ Mario: Can you look at this again? (I don't think we ever successfully tested in the trunk.) Sean
Re: Tomahawk Release?
Can we get rid ot the impl dependencies in the tests? I haven't looked closely but I don't like the idea of depending on the impl for anything. I removed the depedency from the poms on my local checkout and maven won't compile. Sean On 4/17/06, Sean Schofield [EMAIL PROTECTED] wrote: I created shared and tomahawk branches. We need to upgrade the SNAPSHOT versions on the trunk by 1 minor revision number. We also need to fix a bunch of dependencies on the trunk that go along with that. Sean On 4/17/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 4/17/06, Sean Schofield [EMAIL PROTECTED] wrote: Are we ready for a branch for Tomahawk? Earlier it was pointed out that there were some impl dependencies still in Sandbox. Matthias removed some of these and I think its safe to ignore the rest for now since they are in sandbox. Actually, Matthias took the time to go through and fix every single remaining dependency issue! Thanks! Let's release Tomahawk to reduce user confusion. After that, we can release as desired, including minor bug fixes.
Re: Tomahawk Release?
Try searching for tomahawk/src/test has dependencies on MyFaces Impl from Mar 17 to Mar 20. On 4/17/06, Sean Schofield [EMAIL PROTECTED] wrote: Can we get rid ot the impl dependencies in the tests? I haven't looked closely but I don't like the idea of depending on the impl for anything. I removed the depedency from the poms on my local checkout and maven won't compile. Sean On 4/17/06, Sean Schofield [EMAIL PROTECTED] wrote: I created shared and tomahawk branches. We need to upgrade the SNAPSHOT versions on the trunk by 1 minor revision number. We also need to fix a bunch of dependencies on the trunk that go along with that. Sean On 4/17/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 4/17/06, Sean Schofield [EMAIL PROTECTED] wrote: Are we ready for a branch for Tomahawk? Earlier it was pointed out that there were some impl dependencies still in Sandbox. Matthias removed some of these and I think its safe to ignore the rest for now since they are in sandbox. Actually, Matthias took the time to go through and fix every single remaining dependency issue! Thanks! Let's release Tomahawk to reduce user confusion. After that, we can release as desired, including minor bug fixes.
Re: tomahawk/src/test has dependencies on MyFaces Impl
I'm definitely +1 for fixing these dependencies for the reasons that Mike and Craig gave. Maybe we can each change a few of them? For now lets just change things in the trunk since we're trying to get the tomahawk release finished. Sean On 3/28/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 3/28/06, Dennis Byrne [EMAIL PROTECTED] wrote: I can't get a co right now at my day job, so I can't verify this. If you make that change I am guessing sandbox wouldn't compile w/out also moving the not found class from impl to a project where sandbox could see it. Maybe shared, or maybe sandbox itself if there are no other uses for this class. Yes, it seems to be working. I just wasn't sure if there was more to it than that. In this particular case, it was easy enough to change the Exception to a FacesException. I wouldn't be suprised if there are all sorts of other problems that have crept in because of this. Oh, yeah. There's a ton of problems to fix. I'm trying to enumerate them all so I can open an issue on them. https://issues.apache.org/jira/browse/TOMAHAWK-220
[tobago] Tobago not building
I tried out mvn install on the Tobago trunk and got a javac error. Does Tobago *require* JDK 1.5? Also I got a weird warning ... --- [INFO] Building Maven Apt Plugin [INFO]task-segment: [install] [INFO] - --- [INFO] [plugin:descriptor] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [WARNING] Artifact junit:junit:jar:3.8.1:test retains local scope 'test' overriding broader scope 'compile' given by a dependency. If this is not intended, modify or remove the local scope. Sean
[jira] Closed: (MYFACES-1271) AttributeTag casts the getValue return type to String
[ http://issues.apache.org/jira/browse/MYFACES-1271?page=all ] Matthias Weßendorf closed MYFACES-1271: --- Resolution: Fixed Thanks for using MyFaces. The bug you reported has already been fixed in revision 358982 -Matthias AttributeTag casts the getValue return type to String - Key: MYFACES-1271 URL: http://issues.apache.org/jira/browse/MYFACES-1271 Project: MyFaces Core Type: Bug Components: JSR-127 Versions: 1.1.1 Reporter: Jiri Culik According the the JST-127 specification the f:attribute tag value parameter should evaluate to an Object, however the AttributeTag implementation casts the return type of AttributeTag.getValue() to String. This causes a class cast exception for any bound properties that have a type other than String. -- 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: JIRA Issues TOMAHAWK-245 and 246
+1 for the change.
regards,
Martin
On 4/17/06, Dennis Byrne [EMAIL PROTECTED] wrote:
Hello Sharath,
Thanks for taking a look at these two, I didn't know they were related. Your
just in time for the new tomahawk release ;) I won't be able to take a look
at this until the end of the week but it would really help us out if you put
a patch in JIRA.
Dennis Byrne
-Original Message-
From: sharath reddy [mailto:[EMAIL PROTECTED]
Sent: Monday, April 17, 2006 08:19 AM
To: dev@myfaces.apache.org
Subject: JIRA Issues TOMAHAWK-245 and 246
The issues pertain to exceptions while accessing the
Simple examples for Tree and PanelStack.
Both these issues are related to the Tree component
(the older one).
HtmlTreeImageCommandLinKRenderer extends
HtmlLinkRendererBase, and calls the method
'super.renderCommandLinkStart', which in turn
internally calls 'renderJavaScriptAnchorStart'.
The code in this method is as follows:
FormInfo formInfo = findNestingForm(component,
facesContext);
if (formInfo == null)
{
throw new IllegalArgumentException(Component +
clientId + must be embedded in an form);
}
This is the exception that shows up in the stack
trace.
The issues can be fixed simply, by replacing:
FormInfo formInfo = findNestingForm(component,
facesContext);
with:
FormInfo formInfo =
DummyFormUtils.findNestingForm(component,
facesContext);
The difference is that if the second method fails to
find an enclosing form, it sets a parameter informing
MyFaces to render the dummy form, and returns the
dummy form information. Many Tomahawk components
already do this check and set the necessary parameter.
HOWEVER:
The same method is also used by the core components
(HtmlCommandLink, etc) and I am assuming that they
should have no knowledge of the MyFaces dummy form.
So is it OK to go ahead with this change, or is there
a better solution?
Regards,
Sharath
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [tobago] Tobago not building
Yes, Tobago requires jdk 1.5. Tobago declares junit as a test dependency and a dependency of a dependency declares junit as a compile dependency this cause the warning. This doesn't matter. Regards Bernd Sean Schofield schrieb: I tried out mvn install on the Tobago trunk and got a javac error. Does Tobago *require* JDK 1.5? Also I got a weird warning ... --- [INFO] Building Maven Apt Plugin [INFO]task-segment: [install] [INFO] - --- [INFO] [plugin:descriptor] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [WARNING] Artifact junit:junit:jar:3.8.1:test retains local scope 'test' overriding broader scope 'compile' given by a dependency. If this is not intended, modify or remove the local scope. Sean -- 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
[jira] Closed: (MYFACES-1273) Errror in building myfaces with maven, wrong dependency
[ http://issues.apache.org/jira/browse/MYFACES-1273?page=all ] Matthias Weßendorf closed MYFACES-1273: --- Resolution: Fixed fixed in nbuild Errror in building myfaces with maven, wrong dependency --- Key: MYFACES-1273 URL: http://issues.apache.org/jira/browse/MYFACES-1273 Project: MyFaces Core Type: Bug Components: build process Versions: 1.1.2-SNAPSHOT Reporter: Juergen Melzer In file: current\tomahawk\core\pom.xml is a wrong dependency: dependency groupIdstruts/groupId artifactIdstruts/artifactId version1.2.8/version scopecompile/scope -- wrong optionaltrue/optional /dependency dependency groupIdstruts/groupId artifactIdstruts/artifactId version1.2.8/version scopecompile/scope -- correct optionalfalse/optional /dependency -- 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-1286) PanelTabbedPane: selecting tab during rendering can cause exceptions
PanelTabbedPane: selecting tab during rendering can cause exceptions
-
Key: MYFACES-1286
URL: http://issues.apache.org/jira/browse/MYFACES-1286
Project: MyFaces Core
Type: Bug
Components: General
Versions: 1.1.1
Environment: XP/JDK 1.5/Firefox and IE on Windows
Reporter: Steve Peterson
1. Create a tabbed pane layout with several tabs. Have one of the panels
include a boolean field (primitive) in the backing bean, fronted by a
SelectOneMenu. Make the panel with the boolean on it take a little while to
render.
2. Quickly move among the tabs. You will get exceptions of the form:
[[/id-barcode]] Cannot set value for expression
'#{designHandler.design.contrastOutlineText}' to null.
javax.faces.el.EvaluationException: Cannot set value for expression
'#{designHandler.design.contrastOutlineText}' to null.
at org.apache.myfaces.el.ValueBindingImpl.setValue(ValueBindingImpl.java:310)
at javax.faces.component.UIInput.updateModel(UIInput.java:287)
at javax.faces.component.UIInput.processUpdates(UIInput.java:223)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:715)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:715)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:715)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:715)
at javax.faces.component.UIForm.processUpdates(UIForm.java:87)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:715)
at javax.faces.component.UIViewRoot.processUpdates(UIViewRoot.java:158)
--
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-655) RequestMap doesn't implement putAll as it should
[ http://issues.apache.org/jira/browse/MYFACES-655?page=comments#action_12374808 ] Matthias Weßendorf commented on MYFACES-655: Craig, any updates? Thx, Matthias RequestMap doesn't implement putAll as it should Key: MYFACES-655 URL: http://issues.apache.org/jira/browse/MYFACES-655 Project: MyFaces Core Type: Bug Versions: 1.1.0 Reporter: Colin Sampaleanu Assignee: Mathias Broekelmann The JSF description of for the ExternalContext.getRequestMap() method says: Return a mutable Map representing the request scope attributes for the current application. The returned Map must implement the entire contract for a modifiable map as described in the JavaDocs for java.util.Map. Modifications made in the Map must cause the corresponding changes in the set of request scope attributes. yet MyFaces returns a RequestMap class which throws UnsupportedOperationException for both the putAll() and the clear() methods. This is a major bug which will break apps (like mine) that depend on being able to add params via putAll(), for example. -- 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: Tomahawk Release?
Sean Schofield schrieb: Are we ready for a branch for Tomahawk? Earlier it was pointed out that there were some impl dependencies still in Sandbox. Matthias removed some of these and I think its safe to ignore the rest for now since they are in sandbox. I don't think we want to go too long without an updated tomahawk now that the old one is incompatible with the new core. Actually to my knowledge all dependencies in the sandbox are gone now. at least they were yesterday.
Welcome Jurgen Lust to the team!
Hi *, The MyFaces PMC is pleased to announce that we've added Jurgen Lust to the team - Jurgen has been an active MyFaces contributor for a long time now, and it's a pleasure to have him aboard. @Jurgen: sorry for the delayed welcome mail - we somehow forgot about this. regards, Martin
Welcome Gerald Müllan to the team!
Hi *, and the MyFaces PMC is also proud to add Gerald Müllan to the MyFaces team - another very active MyFaces contributor, who is specialized on everything AJAX related. Welcome Gerald! regards, Martin
[jira] Created: (TOMAHAWK-260) Reordering of items, month format to short
Reordering of items, month format to short -- Key: TOMAHAWK-260 URL: http://issues.apache.org/jira/browse/TOMAHAWK-260 Project: MyFaces Tomahawk Type: Improvement Components: Date Versions: 1.1.1, 1.1.2-SNAPSHOT, 1.1.3-SNAPSHOT Reporter: Andrew Robinson I would like to propose new functionality: 1) be able to set the order of the input boxes per Locale/Date format. For example, US dates are shown as MM/DD/, not DD/MM/. The date control always renders day, month and then year. For different cultures this can be confusing 2) Abilty to set the month format. For example, instead of January I may want to have JAN or Jan. 3) Nice to have: Combo box for day instead of text box that lists all the days in the currently selected month and also supports leap-years for February. -- 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: (TOMAHAWK-261) Do not use document.write in popup calendars
Do not use document.write in popup calendars Key: TOMAHAWK-261 URL: http://issues.apache.org/jira/browse/TOMAHAWK-261 Project: MyFaces Tomahawk Type: Improvement Components: Calendar, Date Versions: 1.1.2-SNAPSHOT, 1.1.1, 1.1.3-SNAPSHOT Reporter: Andrew Robinson Priority: Blocker The popup calednar for the date control (and I think the calendar control) uses javascript document.write methods. Unfortunately this is not very compatible with AJAX as it is hard to write content to the document after the document is closed. Instead, can this be changed to have: A) printed hidden component (visibility: hidden; display: none) and just shown when the user clicks the popup button. or B) Use the DOM JavaScript API to add new elements to the DOM instead of document.write. Unless this is changed, these controls cannot be used with AjaxAnywhere and probably not with other AJAX solutions. -- 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
[ANNOUNCE] MyFaces 1.1.2
Hi *, the MyFaces PMC is proud to announce a new and great release of the MyFaces Core Implementation. Please pay attention to the fact that you cannot use this release of MyFaces Core with the MyFaces Tomahawk library in version 1.1.1 - it will only work with the Tomahawk library in version 1.1.2 and onward. From the release 1.1.2 on, you can use any Tomahawk release with a release number greater than 1.1.2 with any MyFaces Implementation release - we have taken special care to enable this. Find below a list of bugs that have been fixed in this release (caveat: this list contains both core and tomahawk bug items). regards, Martin P.S.: Many thanks to all the MyFaces team for enabling this release, especially to Sean Schofield, who has been working very hard on getting this done. Release Notes - MyFaces Core - Version 1.1.2 ** Bug * [MYFACES-27] - JSCookmenu cannot be used for storing data * [MYFACES-32] - Multiple browser window problem with server state saving * [MYFACES-154] - checkbox and listbox do not handler converters well * [MYFACES-210] - Undesired dependency on ApplicationImpl in FacesConfigurator * [MYFACES-290] - x:datascroller does not have the immediate attribute to by pass the validation and update model phase * [MYFACES-320] - selectOneRadio does not properly persist its value * [MYFACES-351] - [tree2] Cannot dynamically add or delete nodes * [MYFACES-394] - Using /faces/* path mapping and connectiong to faces causes stack overflow * [MYFACES-428] - InputDate(s) within dataTable submitting incorrect dates * [MYFACES-430] - inputDate (calendar) and French Locale * [MYFACES-438] - [tree2] Selected node is lost when navigating to another page * [MYFACES-443] - javax.faces.render.Renderer.encodeChildren() should encode children * [MYFACES-450] - Can't use h:outputLabel against a Tomahawk component * [MYFACES-476] - commandButton doesn't renders well the application-dependent image urls * [MYFACES-488] - Weird re-rendered in tagfiles tags inside subviews inside aliasbean inside panelgrid. * [MYFACES-543] - Problems handling simultaneous request from the same session * [MYFACES-568] - tree2 TreeState wrong after node deletion/reposition, causes Servlet Exception * [MYFACES-581] - Frames * [MYFACES-588] - JSCookMenu separator bug - phantom item * [MYFACES-589] - inputCalendar localized month names problem * [MYFACES-595] - Context Problems when using target option in commandLink * [MYFACES-599] - Potential NullPointerException from HtmlResponseWriterImpl.writeAttribute() * [MYFACES-605] - FacesContext.getResponseStream/getResponseWriter unimplemented * [MYFACES-609] - t:dataScroller fires unnecessary ScrollerActionEvents * [MYFACES-610] - Getting IllegalStateException exception when setting javax.faces.STATE_SAVING_METHOD to server * [MYFACES-618] - Tree2 Expand/Collapse Handled By Server does not work (old opened issue MYFACES-291 still here) * [MYFACES-622] - HtmlSelectManyCheckbox rendering is flawed * [MYFACES-626] - org.apache.myfaces.el.getType(Object base, int index) return null if base instanceof Object[] * [MYFACES-627] - valueChangeListener not called for elements in HtmlDataTable * [MYFACES-630] - StartupServletContextListener should ignore missing web.xml * [MYFACES-635] - Calendar popup is incorrectly positioned inside scrolling div * [MYFACES-637] - x:commandLink/ Atrribute 'value' is not rendered in combination with 'enabledOnUserRole' * [MYFACES-639] - wrong renderer for HtmlCommandSortHeader * [MYFACES-642] - t:commandSortHeader is not disabled if attribute 'enabledOnUserRole' is used and user isn't in role * [MYFACES-643] - InputSuggestAjax does not work when javax.faces.STATE_SAVING_METHOD=server * [MYFACES-644] - InputDate doesn't parses submitted seconds * [MYFACES-646] - x:inputDate accepts invalid date input * [MYFACES-649] - Possible NPE in ViewTag.setProperties * [MYFACES-651] - DigesterFacesConfigDispenserImpl.feedFacesContextFactory() broken * [MYFACES-653] - org.apache.myfaces.renderkit.html.HTML.AUTOCOMPLETE_ATTR has private visibility * [MYFACES-656] - data conversion problems??? * [MYFACES-662] - displayValueOnly property on HtmlSelectBooleanCheckbox throws ClassCastException during rendering * [MYFACES-665] - StartupServletContextListener crashes if all jars placed in webapp * [MYFACES-669] - Validation error * [MYFACES-671] - Component t:collapsiblePanel , on open action will submit the form and call validators * [MYFACES-676] - DataScroller: Wrong infos with an empty collection * [MYFACES-677] - HtmlSelectOneMenu conversion error with SelectItemGroup * [MYFACES-678] - Can't find org.apache.myfaces.Message when HtmlMessageTag.getRendererType() is invoked * [MYFACES-681] - Javascript error in x:inputCalendar component * [MYFACES-685] - Error in displaying
Welcome Dennis Byrne as a MyFaces committer!
Wow, a lot of welcome mails tonight! Welcome Dennis Byrne as a very active MyFaces contributor and now committer. Ok, he's been for a while, but can you imagine, we forgot to send out a welcome mail. So there it is. Dennis, it's great to have you aboard! regards, Martin
Re: Welcome Dennis Byrne as a MyFaces committer!
Thanks Martin, This wasn't necessary you know ;) Dennis Byrne -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 06:56 PM To: 'MyFaces Development', 'MyFaces Discussion' Subject: Welcome Dennis Byrne as a MyFaces committer! Wow, a lot of welcome mails tonight! Welcome Dennis Byrne as a very active MyFaces contributor and now committer. Ok, he's been for a while, but can you imagine, we forgot to send out a welcome mail. So there it is. Dennis, it's great to have you aboard! regards, Martin
[jira] Commented: (TOMAHAWK-261) Do not use document.write in popup calendars
[ http://issues.apache.org/jira/browse/TOMAHAWK-261?page=comments#action_12374828 ] Adam Winer commented on TOMAHAWK-261: - In addition, document.write() cannot be used in XHTML. http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite Do not use document.write in popup calendars Key: TOMAHAWK-261 URL: http://issues.apache.org/jira/browse/TOMAHAWK-261 Project: MyFaces Tomahawk Type: Improvement Components: Calendar, Date Versions: 1.1.2-SNAPSHOT, 1.1.1, 1.1.3-SNAPSHOT Reporter: Andrew Robinson Priority: Blocker The popup calednar for the date control (and I think the calendar control) uses javascript document.write methods. Unfortunately this is not very compatible with AJAX as it is hard to write content to the document after the document is closed. Instead, can this be changed to have: A) printed hidden component (visibility: hidden; display: none) and just shown when the user clicks the popup button. or B) Use the DOM JavaScript API to add new elements to the DOM instead of document.write. Unless this is changed, these controls cannot be used with AjaxAnywhere and probably not with other AJAX solutions. -- 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: Welcome Dennis Byrne as a MyFaces committer!
-Original Message- From: Dennis Byrne [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 7:02 PM To: MyFaces Development; MyFaces Discussion Subject: Re: Welcome Dennis Byrne as a MyFaces committer! Thanks Martin, This wasn't necessary you know ;) Dennis Byrne Aw sure it was. Everybody has to be properly welcomed. It's in the Apache bylaws. ;-) -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 06:56 PM To: 'MyFaces Development', 'MyFaces Discussion' Subject: Welcome Dennis Byrne as a MyFaces committer! Wow, a lot of welcome mails tonight! Welcome Dennis Byrne as a very active MyFaces contributor and now committer. Ok, he's been for a while, but can you imagine, we forgot to send out a welcome mail. So there it is. Dennis, it's great to have you aboard! regards, Martin
RE: Welcome Jurgen Lust to the team!
Welcome Jurgen! Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 6:25 PM To: MyFaces Development; MyFaces Discussion Subject: Welcome Jurgen Lust to the team! Hi *, The MyFaces PMC is pleased to announce that we've added Jurgen Lust to the team - Jurgen has been an active MyFaces contributor for a long time now, and it's a pleasure to have him aboard. @Jurgen: sorry for the delayed welcome mail - we somehow forgot about this. regards, Martin
RE: Welcome Gerald Müllan to the team!
Welcome Gerald! Good to have someone who knows about mildly abrasive household cleansers. Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 6:27 PM To: MyFaces Development; MyFaces Discussion Subject: Welcome Gerald Müllan to the team! Hi *, and the MyFaces PMC is also proud to add Gerald Müllan to the MyFaces team - another very active MyFaces contributor, who is specialized on everything AJAX related. Welcome Gerald! regards, Martin
Re: JIRA Issues TOMAHAWK-245 and 246
So DummyFormUtils has to move from tomahawk to shared or at least two
components will not work in the release ?
:(
Dennis Byrne
-Original Message-
From: Martin Marinschek [mailto:[EMAIL PROTECTED]
Sent: Monday, April 17, 2006 03:13 PM
To: 'MyFaces Development'
Subject: Re: JIRA Issues TOMAHAWK-245 and 246
+1 for the change.
regards,
Martin
On 4/17/06, Dennis Byrne [EMAIL PROTECTED] wrote:
Hello Sharath,
Thanks for taking a look at these two, I didn't know they were related.
Your just in time for the new tomahawk release ;) I won't be able to take a
look at this until the end of the week but it would really help us out if
you put a patch in JIRA.
Dennis Byrne
-Original Message-
From: sharath reddy [mailto:[EMAIL PROTECTED]
Sent: Monday, April 17, 2006 08:19 AM
To: dev@myfaces.apache.org
Subject: JIRA Issues TOMAHAWK-245 and 246
The issues pertain to exceptions while accessing the
Simple examples for Tree and PanelStack.
Both these issues are related to the Tree component
(the older one).
HtmlTreeImageCommandLinKRenderer extends
HtmlLinkRendererBase, and calls the method
'super.renderCommandLinkStart', which in turn
internally calls 'renderJavaScriptAnchorStart'.
The code in this method is as follows:
FormInfo formInfo = findNestingForm(component,
facesContext);
if (formInfo == null)
{
throw new IllegalArgumentException(Component +
clientId + must be embedded in an form);
}
This is the exception that shows up in the stack
trace.
The issues can be fixed simply, by replacing:
FormInfo formInfo = findNestingForm(component,
facesContext);
with:
FormInfo formInfo =
DummyFormUtils.findNestingForm(component,
facesContext);
The difference is that if the second method fails to
find an enclosing form, it sets a parameter informing
MyFaces to render the dummy form, and returns the
dummy form information. Many Tomahawk components
already do this check and set the necessary parameter.
HOWEVER:
The same method is also used by the core components
(HtmlCommandLink, etc) and I am assuming that they
should have no knowledge of the MyFaces dummy form.
So is it OK to go ahead with this change, or is there
a better solution?
Regards,
Sharath
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
