[
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
[
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
[
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
[
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:
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
[ 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
--
[
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
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
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
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
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
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://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
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
[
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
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!
[
+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?
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
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
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
+1
In fact, make sure you are running mvn clean install before checkin so
you are not just relying on your IDE compile.
On 2/21/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
Hello,
don't call mvn with -Dmaven.test.skip=true if you are going to checkin
something, please.
Regards
Bernd
--
Yes I think this is unecessarily complicated. I've certainly never
contemplated anything like this before. If you think about it this
must be a fairly common problem. How many projects out there rely on
different versions of commons-collections?
My guess is that if you use maven to build
Craig,
You should be ok now. Let us know if you still have problems.
Sean
On 2/21/06, Werner Punz [EMAIL PROTECTED] wrote:
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.
Yes +1 for 1.0.4. Thanks for explaining all of this.
On 2/21/06, Manfred Geiler [EMAIL PROTECTED] wrote:
+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
On 2/21/06, Sean Schofield [EMAIL PROTECTED] wrote:
Yes I think this is unecessarily complicated. I've certainly never
contemplated anything like this before. If you think about it this
must be a fairly common problem. How many projects out there rely on
different versions of
Unusefull code
--
Key: TOMAHAWK-1
URL: http://issues.apache.org/jira/browse/TOMAHAWK-1
Project: MyFaces Tomahawk
Type: Improvement
Components: Tree
Reporter: Guillaume Doumenc
Priority: Trivial
Not sure this code is usefull in
On 2/20/06, Craig McClanahan [EMAIL PROTECTED] wrote:
I did indeed see that (thanks for the fix) ... and Sean has already checked
that change in (I see it in the trunk sources for Shale that I just checked
out), so it will be in the 20060221 nightly build. That doesn't necessarily
translate
[
http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12367193
]
Adam Brod commented on MYFACES-1148:
Dennis-
Neither of those issues is related, as far as I can tell.
Adam
Weblogic Classloader problems during development
[
http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12367194
]
Adam Brod commented on MYFACES-1148:
I gave up on the JSF-RI quite a while ago; however, I did experience the same
problem with the FactoryFinder not finding the
[
http://issues.apache.org/jira/browse/TOMAHAWK-1?page=comments#action_12367186 ]
Guillaume Doumenc commented on TOMAHAWK-1:
--
Can you cancel it.. Sorry misunderstanding the calling context..
Unusefull code
--
Key:
[ http://issues.apache.org/jira/browse/TOMAHAWK-1?page=all ]
Mario Ivankovits resolved TOMAHAWK-1:
-
Resolution: Invalid
Unusefull code
--
Key: TOMAHAWK-1
URL: http://issues.apache.org/jira/browse/TOMAHAWK-1
[ http://issues.apache.org/jira/browse/TOMAHAWK-1?page=all ]
Mario Ivankovits closed TOMAHAWK-1:
---
Unusefull code
--
Key: TOMAHAWK-1
URL: http://issues.apache.org/jira/browse/TOMAHAWK-1
Project: MyFaces
[ http://issues.apache.org/jira/browse/MYFACES-1143?page=all ]
Werner Punz closed MYFACES-1143:
Fix Version: Nightly
Resolution: Fixed
Ok I am closing it now, the dojo people have solved this one for us...
Thanks Gerald for checking it and
I have succesfully created a MyFaces Tomahawk project in JIRA. Issues
will have an id of TOMAHAWK-[issue number]. I also renamed the
existing JIRA project to MyFaces Core. The issues for that project
remain MYFACES-[issue number]. I believe we will need infra to
officially group them together
[ http://issues.apache.org/jira/browse/TOMAHAWK-7?page=all ]
sean schofield deleted TOMAHAWK-7:
--
fileupload
--
Key: TOMAHAWK-7
URL: http://issues.apache.org/jira/browse/TOMAHAWK-7
Project: MyFaces Tomahawk
[ http://issues.apache.org/jira/browse/TOMAHAWK-30?page=all ]
sean schofield updated TOMAHAWK-30:
---
Component: Tree2
(was: Other)
[tree2] Navigation icons should have @immediate=true
[ http://issues.apache.org/jira/browse/TOMAHAWK-118?page=all ]
sean schofield updated TOMAHAWK-118:
Component: Tree2
(was: Other)
Tree2 needs the pass-through html attributes
[ http://issues.apache.org/jira/browse/TOMAHAWK-35?page=all ]
sean schofield updated TOMAHAWK-35:
---
Component: Tree2
(was: Other)
Tree2 setLeaf(false) error
--
Key: TOMAHAWK-35
URL:
I didn't mean to delete this one. At some point I will readd it.
On 2/21/06, sean schofield (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/TOMAHAWK-7?page=all ]
sean schofield deleted TOMAHAWK-7:
--
fileupload
--
[ http://issues.apache.org/jira/browse/MYFACES-750?page=all ]
Manfred Geiler resolved MYFACES-750:
Fix Version: Nightly
Resolution: Fixed
Actually implemented a slightly different solution than was suggested. But
synchronized is the right
[
http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12367216
]
Adam Brod commented on MYFACES-1148:
Ok, I did some additional debugging into the Weblogic ClassLoader.
The root of the problem stems from the weblogic Weblogic drops
Wow, cool! Thank you!
I'm going to update the issue tracker URL in our POM as soon as I am home.
Regards,
Arvid
Sean Schofield wrote:
I also added a new JIRA instance for Tobago. I moved all of the
Tobago issues over from the original JIRA. I believe committers can
change the versions and
Thanks Sean!
I have moved all of the tomahawk issues (at least the ones marked
tomahawk in the original jira) to the new JIRA project. JIRA is also
smart enough to map the old issue numbers with new issue numbers. So
if you try to navigate to MYFACES-975[1], JIRA knows enough to
redirect
On 2/21/06, Sean Schofield [EMAIL PROTECTED] wrote:
Craig,You should be ok now.Let us know if you still have problems.Still have problems :-(. But now at least it is in more familiar territory. The first failure I see is in HtmlDataTableTest ... in the setUp() method, it is calling
-Dmaven.test.failure.ignore=true is another that should be avoided.
Dennis Byrne
-Original Message-
From: Bernd Bohmann [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 21, 2006 02:45 AM
To: 'MyFaces Development'
Subject: Don't disable unit tests before a checkin
Hello,
don't call mvn
Thanks Sean for the hard work,
+1 from me to put sandox under tomahawk.
Regards,
Bruno
On 2/21/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Thanks Sean!
I have moved all of the tomahawk issues (at least the ones marked
tomahawk in the original jira) to the new JIRA project. JIRA is
may be a silly question,
but how to change / move a bug to a special component
e.g. from other - tree2
Thanks,
Matthias
On 2/21/06, Bruno Aranda [EMAIL PROTECTED] wrote:
Thanks Sean for the hard work,
+1 from me to put sandox under tomahawk.
Regards,
Bruno
On 2/21/06, Matthias
Just click on Edit this issue in the sidebar under Operations and
assign a new component.
Regards,
Arvid
Matthias Wessendorf wrote:
may be a silly question,
but how to change / move a bug to a special component
e.g. from other - tree2
Thanks,
Matthias
On 2/21/06, Bruno Aranda [EMAIL
thanks
On 2/21/06, Arvid Hülsebus [EMAIL PROTECTED] wrote:
Just click on Edit this issue in the sidebar under Operations and
assign a new component.
Regards,
Arvid
Matthias Wessendorf wrote:
may be a silly question,
but how to change / move a bug to a special component
e.g. from
Is that valid for right now?
As the tree-tests are failing?
regards,
Martin
On 2/21/06, Dennis Byrne [EMAIL PROTECTED] wrote:
-Dmaven.test.failure.ignore=true is another that should be avoided.
Dennis Byrne
-Original Message-
From: Bernd Bohmann [mailto:[EMAIL PROTECTED]
Sent:
FYI we disabled email notification to the list when you edit an issue
(change the name, description, version or component.) This will cut
down on some our JIRA traffic. Also, no emails to the list when
moving an issue between projects.
The issue reporter, the assignee and watchers will still be
Sounds like issue #38294 in bugzilla that Dennis was talking about.
He has a proposed solution but I didn't commit it yet because I cannot
reproduce. It would seem to be JDK specific b/c I can build just fine
and so can our continuum server.
Sean
On 2/21/06, Craig McClanahan [EMAIL PROTECTED]
Tree tests should not be failing. Try removing the shale snapshot
from your local maven repos and try again. This worked for Dennis
(and suggests a problem with either maven or these snapshots.)
Sean
On 2/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Is that valid for right now?
As the
Thanks Sean!
regards,
Martin
On 2/21/06, Sean Schofield [EMAIL PROTECTED] wrote:
Tree tests should not be failing. Try removing the shale snapshot
from your local maven repos and try again. This worked for Dennis
(and suggests a problem with either maven or these snapshots.)
Sean
On
I had the same problem last night. Y0u are getting a classcastexception ? If
so, try deleting the shale-test dir in your local repo and doing mvn install.
@sean - see, I'm not crazy.
Dennis Byrne
-Original Message-
From: Martin Marinschek [mailto:[EMAIL PROTECTED]
Sent: Tuesday,
Ah, I see.
Thanks for the informations.
I'll help to *edit* some issues.
So for sandbox, we just create a *component* inside of TOMAHAWK and
*store* all issue under this label, right ?
-Matthias
On 2/21/06, Sean Schofield [EMAIL PROTECTED] wrote:
FYI we disabled email notification to the list
I suspect this is a maven 1 or struts snapshot issue and not a bug in maven2.
On 2/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Thanks Sean!
regards,
Martin
On 2/21/06, Sean Schofield [EMAIL PROTECTED] wrote:
Tree tests should not be failing. Try removing the shale snapshot
from
I was thinking of creating one component for each sandbox. So people
who are interested in a particular component can easily see (and maybe
fix) those issues. Perhaps a * character at the end of the component
name to remind us this is sandbox?
Sean
On 2/21/06, Matthias Wessendorf [EMAIL
Maven2 is even smarter that you might realize. :-)(see below)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 aeasier solution.Until we started down the maven path
On 2/21/06, Sean Schofield [EMAIL PROTECTED] wrote:
I was thinking of creating one component for each sandbox. So people
who are interested in a particular component can easily see (and maybe
makes sense
fix) those issues. Perhaps a * character at the end of the component
name to remind us
@sean - see, I'm not crazy.
Nobody said you were ;-) So why is the shale snapshot dependency not
updating? Maybe it has something to do with the hack to get it to
work with maven2?
Dennis Byrne
Sean
The only thing I worry about is searching on a * char. Maybe a (sbx)
or something?
On 2/21/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On 2/21/06, Sean Schofield [EMAIL PROTECTED] wrote:
I was thinking of creating one component for each sandbox. So people
who are interested in a
Nobody said you were ;-) So why is the shale snapshot dependency not
updating? Maybe it has something to do with the hack to get it to
work with maven2?
Interesting, at work we are using Maven1 and also, sometimes it looks
like maven does not update all jars...
If I have build problems,
[ http://issues.apache.org/jira/browse/TOMAHAWK-122?page=all ]
sean schofield closed TOMAHAWK-122:
---
Resolution: Duplicate
Add colspan attribute to t:column
---
Key: TOMAHAWK-122
URL:
On 2/21/06, Sean Schofield [EMAIL PROTECTED] wrote:
Sounds like issue #38294 in bugzilla that Dennis was talking about.He has a proposed solution but I didn't commit it yet because I cannotreproduce.It would seem to be JDK specific b/c I can build just fineand so can our continuum server.
Wierd.
Can you get up and running with Dennis' suggested change to shale?
On 2/21/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 2/21/06, Sean Schofield [EMAIL PROTECTED] wrote:
Sounds like issue #38294 in bugzilla that Dennis was talking about.
He has a proposed solution but I didn't commit it
The author of this issue reminded me of the outstanding patch. I
haven't worked with this area of the code lately and I'm kind of busy
with the JIRA reorg and upcoming release. Does anyone want to review
this. He has submitted a detailed set of patches and test pages. I
suggest we incorporate
On 2/21/06, Sean Schofield [EMAIL PROTECTED] wrote:
So why is the shale snapshot dependency not updating?
By default, Maven 2 only checks for new snapshots once a day. Try
using -U on the command line to force an update if you know there's a
new snapshot available.
Maybe it has something to
By default, Maven 2 only checks for new snapshots once a day. Try
using -U on the command line to force an update if you know there's a
new snapshot available.
Its been more then one day since the change was made. I believe the
snapshot from one or two days ago incorporated this fix already
I moved the sandbox stuff but I did not create the components yet.
I'll wait to see what people think about * or (sbx) or whatever.
Also, I deleted the 'other' component so most issues are now
unassigned to a component. If there is no issue that makes sense to
assign them to they can stay
On 2/21/06, Sean Schofield [EMAIL PROTECTED] wrote:
I suspect this is a maven 1 or struts snapshot issue and not a bug in maven2.It does indeed seem to be a snapshot issue ... deleting the old shale-test directory makes the build work for me.Craig
Folks,There seems to be increasing discussion lately regarding MyFaces Commons and how it relates to both MyFaces Core and MyFaces Tomahawk. Adding Tobago and ADF Faces to the discussion makes it even more critical that we come up with a useful way to share reusable code between the various
On 2/21/06, Sean Schofield [EMAIL PROTECTED] wrote:
Can you get up and running with Dennis' suggested change to shale?I was all set to try that, but didn't need it ... deleting a stale Shale Test Framework snapshot did the trick.Craig
Now that is weird. That was only supposed to help with the tree
tests. I was only expecting the ClassCastException we fixed several
days ago to go away. I was not expecting the render kit stuff to go
away.
I guess this would explain why I cannot reproduce Dennis' error.
Dennis can you try
Is it safe to say we are going to stick with commons the way it is for
the upcoming core and tomahawk release? If so, I think we should go
ahead and create the JIRA project. I'd like to do that and then issue
some announcements and documentation on our new JIRA strategy.
Sean
On 2/21/06, John
I guess this would explain why I cannot reproduce Dennis' error.
Dennis can you try forcing a new snapshot?
I way too busy w/ my day job (behind a firewall) to get this done ;) I'll try
tonight.
Dennis Byrne
[
http://issues.apache.org/jira/browse/TOMAHAWK-75?page=comments#action_12367256
]
Jurgen Lust commented on TOMAHAWK-75:
-
This appears to be an issue with Jetty 6, and not with MyFaces. It has been
fixed in the latest snapshot of the Jetty6 plugin
[ http://issues.apache.org/jira/browse/TOMAHAWK-75?page=all ]
sean schofield closed TOMAHAWK-75:
--
Resolution: Won't Fix
Closing at Jurgen's suggestion.
ExtensionsFilter results in empty response on Jetty 6
t:selectOneRadio and t:radio should do the same when check the selected item
Key: TOMAHAWK-152
URL: http://issues.apache.org/jira/browse/TOMAHAWK-152
Project: MyFaces Tomahawk
Type: Bug
I just hear from a maven guy that xslt plugin as been voted out and
they are releasing tonight. This means we are getting much closer to
a core release.
Sean
On 2/14/06, Sean Schofield [EMAIL PROTECTED] wrote:
Obviously we will need to do TCK testing also but we might as well
wait until
This is a test issue - Testing New JIRA workflow
Key: TOBAGO-39
URL: http://issues.apache.org/jira/browse/TOBAGO-39
Project: MyFaces Tobago
Type: Task
Versions: 1.0.7-SNAPSHOT
Reporter: sean schofield
I made another improvement to our JIRA setup. I added a Patch
Available state. There is now an operation called Provide Patch
that users can click once they have attached a patch. It will then
place the issue in the Patch Available state.
This way we can keep track of issues where patches have
[
http://issues.apache.org/jira/browse/TOMAHAWK-152?page=comments#action_12367282
]
Colin Sharples commented on TOMAHAWK-152:
-
This has caused me problems, so I would definitely like to see this fixed. I
managed to get round this by fiddling with
[
http://issues.apache.org/jira/browse/TOMAHAWK-152?page=comments#action_12367291
]
sean schofield commented on TOMAHAWK-152:
-
Can you help us by testing Volker's patch?
t:selectOneRadio and t:radio should do the same when check the selected item
It was developed last spring, it's been used as the foundation for EL
within the JSF RI and Glassfish's JSP impl, as far as I know, there
haven't been any bug fixes or issues and was already through the EL
verification process.
What's not stable at the moment is the JSP 2.1 implementation
[
http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12367297
]
Dennis Byrne commented on MYFACES-1148:
---
FactoryFinder behavior is defined pretty clearly by the spec, and you'll get
this w/ any implementation. I don't know what
I am unable to run the core assembly on my machine. This time I get
the following error:
[ERROR] BUILD ERROR
[INFO] -
---
[INFO] 'taglibdocjar' was specified in an execution, but not found in the plugin
[INFO]
On 2/20/06, Martin Marinschek [EMAIL PROTECTED] wrote:
one / zero = infinity ;-)you talk about the configuration of the ExtensionsFilter there, right?;)no line - no mailsone line - infinite amount of mailsPrecisely. ;-)
regards,MartinOn 2/21/06, John Fallows
[EMAIL PROTECTED] wrote: On 2/18/06,
The Tomahawk components 'inject' Javascript file references into the
head section of the response by using a filter to buffer and
post-process the response. I'm assuming ADF Faces has some mechanism for
injecting Javascript too, but I can't seem to track it down...
I've found the code that
Why should anything in commons be regarded as a public API?
I think javadoc could be added to commons to simply state that *all*
classes in that library are subject to API changes in any release [1].
These are helper classes. People who are writing portable JSF
components will not be using these
On 2/22/06, Sean Schofield [EMAIL PROTECTED] wrote:
Weird, I reran with -U and it downloaded a whole bunch of new stuff.
Then it ran fine. I haven't run maven in 24 hours so its not like
there are brand new snapshots out there that it failed to pick up.
have you told this to the maven list?
Sean Schofield schrieb:
@Bernd: Can you still reverse the change you made last month where we
took the deps out of assembly?
On the trunk and 1_1_2 branch or on the trunk only?
Bernd
Sean
On 2/21/06, Sean Schofield [EMAIL PROTECTED] wrote:
I am unable to run the core assembly on my
92 matches
Mail list logo
