https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=414
Can anybody pl confirm whether the above issue that is fixed in
JSF RI implementation, will be fixed in MyFaces impl
as well.
If so , is there a current MyFaces Issue tracker no for the same issue?
If not, can somebody from
ahh!
My thread has the same service bean that is in the main thread has, so I
guess both thread sharing
the same Persentent Context.
Now I need to figure out how to Create my Persitent Context in the child
thread which a little
disappointed. My goal is to use the same service bean. Is there a
Dan Tran [EMAIL PROTECTED] schrieb:
I am running into this problem that I think it is related to the present of
Orchestra.
First I have a spring service bean which spins a thread, do the long work,
then save some data to persistent in the same thread. The thread's runnable
[
https://issues.apache.org/jira/browse/TOBAGO-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volker Weber resolved TOBAGO-477.
-
Resolution: Fixed
clientside jsf-state is not updated at 304 ajax response
seam:decorate id=decorateUsername
tr:inputText id=username required=true styleClass=#{invalid ?
'error' : ''}
value=#{ user.username}
seam:validate /
/tr:inputText
/seam:decorate
tr:partialRendered for=decorateUsername partialTriggers=saveTrigger
/
tr:partialTrigger
I think there is a second dir. something like publish,
can't remember ;-)
On 9/7/07, Manfred Geiler [EMAIL PROTECTED] wrote:
I committed a new ip-clearance document a few days ago:
https://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/jsr-301-ri.xml
Well, it does
[EMAIL PROTECTED] is the right choice for this.
-M
On 9/7/07, Manfred Geiler [EMAIL PROTECTED] wrote:
Here is a direct SVN link:
https://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/jsr-301-ri.xml
--Manfred
On 9/7/07, Manfred Geiler [EMAIL PROTECTED] wrote:
I committed the ip-clearance under the name jsr-301-ri.xml 3 days ago.
But it did not show up yet. Perhaps we have to ping someone to rebuild
the incubator site?
--Manfred
On 9/1/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Yes, but I think the ruling says that the commit needs to be done by
I committed a new ip-clearance document a few days ago:
https://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/jsr-301-ri.xml
Well, it does not show up yet on the
http://incubator.apache.org/ip-clearance/ page.
Is the incubator site automatically rebuilt periodically?
Wendy,
I did the upload for md5/sha1
-M
On 9/1/07, Wendy Smoak [EMAIL PROTECTED] wrote:
On 9/1/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Should we ask on [EMAIL PROTECTED] if there is someone who wants to support
us? Shouldn't be too complicated, right? As soon as I get a link / the
[
https://issues.apache.org/jira/browse/TOMAHAWK-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525721
]
Jesper Pedersen commented on TOMAHAWK-1110:
---
The problem is properly located in t:collapsiblePanel
panelGrid header facet and jsp:include
--
Key: MYFACES-1720
URL: https://issues.apache.org/jira/browse/MYFACES-1720
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects
Hi!
Today we cleaned up the way how to configure the different scopes.
Basically this means:
* you HAVE to configure a timeout now. The default is to never timeout a
conversation on its own.
* the flash scope is now configured through the lifetime property.
Please see here an example or refer
[
https://issues.apache.org/jira/browse/TRINIDAD-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson reopened TRINIDAD-663:
--
Assignee: (was: Andrew Robinson)
Code backed out of trunk
It is now archived
Manfred,
You need to build the site (run build.xml in the Site project) and then
run svn update on people.apache.org to pull the changes from SVN into the
public site.
Lawrence
Manfred Geiler [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
09/07/2007 08:56 AM
Please respond to
[EMAIL
Why doesn't the jsp:include work? Is it simply forgetting that facets
have to be a single component?
Does this work:
h:panelGridf:facet name=headerh:panelGroupjsp:include
page=/someotherjsp.jsp/h:panelGroup/f:facet/h:panelGrid
On 9/7/07, nikolaos georgosoulos (JIRA) dev@myfaces.apache.org
Trinidad has no way to re-render components to show server validation errors or
conversion errors on a partial update
-
Key: TRINIDAD-697
URL:
All,
As per earlier discussion, I'm going to rearrange the
Trinidad SVN structure to re-unify the 1.2 and 1.1
plugins, and run all the main Trinidad code against
the 1.2 code-line of plugins.
What the repos will look like when I'm done is:
myfaces
/trinidad
/trunk
pom.xml
Adam,
To put it a little more politically correct, I think it is very
important to have the PPR/AJAX function of Trinidad viewed as
completely separate functionality from the Trinidad components. In the
same way that decisions by RichFaces developers does not limit
Ajax4JSF functionality, I don't
[
https://issues.apache.org/jira/browse/TRINIDAD-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525781
]
Andrew Robinson commented on TRINIDAD-697:
--
Way to reproduce this bug:
1) Disable client-side validation
[
https://issues.apache.org/jira/browse/TRINIDAD-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson reopened TRINIDAD-664:
--
Assignee: (was: Andrew Robinson)
Solution has been backed out
code is now
@Andrew: I value your contributions as very important to finally try
to find ways to make JSF component libraries more compatible. The
current state, and that we all agree upon, is a state we as JSF users
can't take much longer.
I will not reiterate Adam's point about discussions first -
clientside jsf-state is not updated at 304 ajax response
Key: TOBAGO-477
URL: https://issues.apache.org/jira/browse/TOBAGO-477
Project: MyFaces Tobago
Issue Type: Bug
Hi Sumathi,
please open an issue - I don't think we've looked into this so far.
regards,
Martin
On 9/6/07, sumathi gopalakrishnan [EMAIL PROTECTED] wrote:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=414
Can anybody pl confirm whether the above issue that is fixed in
JSF
Yeah, Matthias, Manfred and Wendy have gone forward - long live Open
Source communities!
;)
regards,
Martin
On 9/5/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Sorry for the unnecessary comment. Looks like Matthias already handled it.
Scott O'Bryan wrote:
:-)
Martin, I have an ICLA on
:) Yay teamwork. I'm off for one day and all my work gets done for me.
Martin Marinschek wrote:
Yeah, Matthias, Manfred and Wendy have gone forward - long live Open
Source communities!
;)
regards,
Martin
On 9/5/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Sorry for the unnecessary
Hi Dan!
My thread has the same service bean that is in the main thread has, so I
guess both thread sharing
the same Persentent Context.
Now I need to figure out how to Create my Persitent Context in the child
thread which a little
disappointed. My goal is to use the same service bean. Is
Hi Scott,
via javascript - I just add it dynamically on the client. Works for
all major browsers just fine.
regards,
Martin
On 9/4/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
How are you getting the stylesheet reference into the header now?
JSR-168 does not have a means of doing this.
Scott
Well that can always be done, namespacing or not. Trinidad has a slight
advantage on this in that our skinning system generates the ids and all
the mappings throughout the renderkit. So adding a namespace should be
pretty straight forward.
Scott
Martin Marinschek wrote:
Hi Scott,
via
Support for greater control over tr:table rows
--
Key: TRINIDAD-698
URL: https://issues.apache.org/jira/browse/TRINIDAD-698
Project: MyFaces Trinidad
Issue Type: Wish
Components:
Yes, that's true!
regards,
Martin
On 9/7/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Well that can always be done, namespacing or not. Trinidad has a slight
advantage on this in that our skinning system generates the ids and all
the mappings throughout the renderkit. So adding a namespace
[
https://issues.apache.org/jira/browse/TRINIDAD-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525823
]
Martin Marinschek commented on TRINIDAD-698:
If you'd support double-click as well, I know some people
[
https://issues.apache.org/jira/browse/TOMAHAWK-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525824
]
Martin Marinschek commented on TOMAHAWK-1105:
-
Hi Daniel,
this is not really a bug - the
Very cool, Mario. FYI, I'll be talking about Orchestra (among other things)
at JavaZone next week
(http://www4.java.no/web/show.do?page=92articleid=5276). This means I may
be asking a lot of questions over the next few days :-).
~~~
Hi Mario,
why do I have to configure a timeout? Can't the default be taken from
the session timeout?
regards,
Martin
On 9/7/07, Kito D. Mann [EMAIL PROTECTED] wrote:
Very cool, Mario. FYI, I'll be talking about Orchestra (among other things)
at JavaZone next week
Hi,
Conversations are stored in the session (indirectly). So when the http
session times out, the conversations automatically go too. The timeout
mentioned here is just in case you want conversations to time out more
quickly than the http session.
Until recently this shorter timeout was
Hi Simon,
I would suspect the default should be same as session, and that the
added value of Orchestra is that a conversation will time out if the
session keeps being used, but only these conversation scoped beans are
not used anymore. Configuration should be available, and it is good
that it is,
Martin,
I think that's what is already happening. If nothing is set - the
conversation dies with the session.
It used to be that it was hard-wired to last 30 mins.
If a specific setting is made in the config, then it supercedes the default
which = session timeout.
Cheers,
Zubin
On 9/7/07,
Hi Zubin,
Mario specifically mentions that a setting HAS to be made - so I was
wondering why we want to force users to do this, if it is not
necessary. Might as well be that I understood his mail wrongly.
regards,
Martin
On 9/8/07, Zubin Wadia [EMAIL PROTECTED] wrote:
Martin,
I think that's
On 9/7/07, Andrew Robinson [EMAIL PROTECTED] wrote:
seam:decorate id=decorateUsername
tr:inputText id=username required=true styleClass=#{invalid ?
'error' : ''}
value=#{ user.username}
seam:validate /
/tr:inputText
/seam:decorate
tr:partialRendered
On 9/7/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Adam,
To put it a little more politically correct, I think it is very
important to have the PPR/AJAX function of Trinidad viewed as
completely separate functionality from the Trinidad components. In the
same way that decisions by RichFaces
renderAlways: If you use renderAlways internally for the trinidad
messages (even though you call it a hack now), Andrew is definitely
right when he says he might want to use other message components as
well and needs the same functionality there.
I want to get rid of that hack on
What limitation of Trinidad components are limiting Trinidad PPR functionality
overall, when you've conclusively proved that you can write components on
top of the Trinidad PPR functionality that address your issues? Nothing
discussed here is about whether PPR/AJAX core functionality in
Ok, I think with my above suggestions, Andrew will conclude that he
doesn't need UIXPartialRendered - I think the partialTrigger component
will still be necessary.
Yes, I agree to that. The one advantage of the partialRendered tag
name is that it is more clear what its purpose is than using
On 9/7/07, Martin Marinschek [EMAIL PROTECTED] wrote:
renderAlways: If you use renderAlways internally for the trinidad
messages (even though you call it a hack now), Andrew is definitely
right when he says he might want to use other message components as
well and needs the same
PasswordStrength Component doesnot run correctly on IE7
---
Key: TOMAHAWK-
URL: https://issues.apache.org/jira/browse/TOMAHAWK-
Project: MyFaces Tomahawk
Issue Type: Bug
[
https://issues.apache.org/jira/browse/TOMAHAWK-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hazem Saleh updated TOMAHAWK-:
--
Status: Patch Available (was: Open)
PasswordStrength Component doesnot run correctly on
Hi all,
Please apply this patch if you have sometime.
Here is the JIRA issue url :
https://issues.apache.org/jira/browse/TOMAHAWK-
This patch contains the problem fix.
Thanks all very much.
I really appreciate your efforts.
--
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog
Toaster Component
-
Key: TOMAHAWK-1112
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1112
Project: MyFaces Tomahawk
Issue Type: New Feature
Affects Versions: 1.1.7-SNAPSHOT
Reporter: Hazem Saleh
For 663, and 664, this should be adequate, as long as DHTML is not the
solution
Sorry that sounded bad. I mean, that as long as DHTML is not the
required solution, but instead PPR is the default solution, but can
optionally be the solution for custom built renderers written on top
of the
Create a new instance using a different name and manually inject it to my
runnable solves the problem.
Now I have another concern, not related to Orchestra, where how to I create
new instance on the fly
(not thru spring configuration ) to be inject for each new thead ( yeah, I
will have
...I'd be vastly less concerned about seeing such
a component appear in a generic MyFaces PPR/AJAX library, when
we get around to that...
What about a slow start?
Could be a tag namespace of:
xmlns:tra=http://myfaces.apache.org/trinidad/ajax;
or
On 9/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: awiner
Date: Fri Sep 7 17:47:54 2007
New Revision: 573765
URL: http://svn.apache.org/viewvc?rev=573765view=rev
Log:
Update version number and SCM info
These need to be deleted and re-added in Continuum, it's trying to
'svn up'
I found the solution for it using getter injection or @Configure annotation
for non spring bean.
-Dan
Dan Tran wrote:
Create a new instance using a different name and manually inject it to my
runnable solves the problem.
Now I have another concern, not related to Orchestra, where
@Matthias, can you take care of the Continuum fix?
Wendy, the version went backwards because we used to have
two forks - 1.0.x and 1.2.x. Both were at 1.y.2 - so we had
1.0.2 and 1.2.2. I realized that the 1.2 branch was actually
kinda pointless, and that we only needed one branch. It
made
55 matches
Mail list logo
