Hi!
Its again me ... somewhat angry, so sorry *g* I CANT SET A
BREAKPOINT IN SHARED ANY MORE - or I have to do it twice in shared_impl
and shared_tomahawk.
Please lets discuss again why this refactoring is needed - PLEASE !!!
Now I propose to get rid of all those class.getName() (or
Mario Ivankovits schrieb:
Hi!
Its again me ... somewhat angry, so sorry *g* I CANT SET A
BREAKPOINT IN SHARED ANY MORE - or I have to do it twice in shared_impl
and shared_tomahawk.
Please lets discuss again why this refactoring is needed - PLEASE !!!
Now I propose to get rid of all
Hi!
java.lang.ClassCastException:
org.apache.myfaces.shared_impl.renderkit.html.util.DummyFormRequestInfo
at
org.apache.myfaces.shared_tomahawk.renderkit.html.util.DummyFormUtils.getDummyFormParameters(DummyFormUtils.java:121)
at
Mario Ivankovits schrieb:
Hi!
Ok, who would like the one to get the glory for implementing an ajaxed
datatable like the stuff you can see on m$ new search site: www.live.com
You simply scroll up or down while it refetch the data from the server.
Happy coding. - Werner? :-)
Well if you
On Thu, 2006-03-09 at 09:58 +0100, Werner Punz wrote:
Mario Ivankovits schrieb:
Hi!
Its again me ... somewhat angry, so sorry *g* I CANT SET A
BREAKPOINT IN SHARED ANY MORE - or I have to do it twice in shared_impl
and shared_tomahawk.
Please lets discuss again why this
Hi!
I'm still very much in favour of *not* shipping a common jar used by
both core and tomahawk (and maybe tobago, ADF, etc); the versioning
issues related to that are nasty.
Why? Once the shared api is stable this should not be a big issue, no?
I've already moved stuff to tomahawk to reach
O-k.
the question is - do we need and want it in impl?
regards,
Martin
On 3/9/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
java.lang.ClassCastException:
org.apache.myfaces.shared_impl.renderkit.html.util.DummyFormRequestInfo
at
Mario Ivankovits schrieb:
And - IMHO the killer, the shared is not interoperable, means it cant
put stuff in the request and use it again if called from another package
as they are different classes - different package names.
See my other thread regarding ExtensionsFilter and Dummyform.
Why? Can you explain reasons to do so?
I don't think so, exept for some special reasons (javascript access
etc.) there is IMO no sense have ids on all those components.
Regards,
Volker
Apache Wiki wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Myfaces Wiki
Mario,
As mentioned earlier, yes, there is some pain with the new shared
structure. But my feeling is that most of the pain is due to the fact
that we have to break with some (bad) habits.
Please think of the two libs shared_impl and shared_tomahawk as two
*different* things. This affects
Simon Kitching schrieb:
What I had in mind when this was being discussed was not a compilation
pre-processor but instead a tool based on ASM that would post-process a
jarfile to rename all classes from package X to package Y, and change
all references to stuff in package X to the new package
Hi Martin!
the question is - do we need and want it in impl?
I dont need it there - but it only moves the problem away FOR NOW, it
will arise again - I bet. The interoperability is still broken.
I can refactor (again) to put the dummyForm stuff into tomahawk - Who
needs this nasty dummyForm
Hi guys,
where things are breaking right now is exactly where we have been too
lenient in the beginning and have made tomahawk to be based on impl
where it shouldn't.
regards,
Martin
On 3/9/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Mario,
As mentioned earlier, yes, there is some pain with
On 3/9/06, Werner Punz [EMAIL PROTECTED] wrote:
Mario Ivankovits schrieb:
And - IMHO the killer, the shared is not interoperable, means it cant
put stuff in the request and use it again if called from another package
as they are different classes - different package names.
See my other
Hi Martin!
where things are breaking right now is exactly where we have been too
lenient in the beginning and have made tomahawk to be based on impl
where it shouldn't.
Ok, but then, lets make it clean NOW. On the trunk - once we are
finished we can restart with the release.
Ciao,
Mario
DummyForm was a special feature of MyFaces, that was wrongly put into
the implementation - it should have been put into tomahawk, where it
belongs to.
Right?
As for what that means for the release, I'd say we should get as much
of this refactoring into the release as possible, and if that means
Martin Marinschek schrieb:
Hi guys,
where things are breaking right now is exactly where we have been too
lenient in the beginning and have made tomahawk to be based on impl
where it shouldn't.
regards,
I do not see it that way, the problem is, that pure JSF is very verbose
in what it
DummyForm was a special feature of MyFaces, that was wrongly put into
the implementation - it should have been put into tomahawk, where it
belongs to.
Right?
+1
As for what that means for the release, I'd say we should get as much
of this refactoring into the release as possible, and
On 3/9/06, Simon Kitching [EMAIL PROTECTED] wrote:
On Thu, 2006-03-09 at 09:58 +0100, Werner Punz wrote:
Mario Ivankovits schrieb:
Hi!
Its again me ... somewhat angry, so sorry *g* I CANT SET A
BREAKPOINT IN SHARED ANY MORE - or I have to do it twice in shared_impl
and
Manfred Geiler schrieb:
On 3/9/06, Werner Punz [EMAIL PROTECTED] wrote:
Mario Ivankovits schrieb:
And - IMHO the killer, the shared is not interoperable, means it cant
put stuff in the request and use it again if called from another package
as they are different classes - different package
Manfred Geiler schrieb:
Please think of the two libs shared_impl and shared_tomahawk as two
*different* things.
OK, I'll restart my brain and try again ;-)
Let's look at the
key of the problem here: Why is it an issue when shared_impl and
shared_tomahawk have different FQN-Strings during
Hi!
I just want to collect what should be done to make shared clean:
I think the following should be moved to tomahawk:
JavascriptUtils
DummyForm*
MyfacesConfig
What else?
---
Mario
On 3/9/06, Werner Punz [EMAIL PROTECTED] wrote:
Manfred Geiler schrieb:
On 3/9/06, Werner Punz [EMAIL PROTECTED] wrote:
Mario Ivankovits schrieb:
And - IMHO the killer, the shared is not interoperable, means it cant
put stuff in the request and use it again if called from another
On 3/9/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
DummyForm was a special feature of MyFaces, that was wrongly put into
the implementation - it should have been put into tomahawk, where it
belongs to.
Right?
No, DummyForm is a *feature* of the MyFaces impl. There is nothing in
the
The tabbedPane do not call valuechangelistner on document
-
Key: MYFACES-1169
URL: http://issues.apache.org/jira/browse/MYFACES-1169
Project: MyFaces Core
Type: Bug
Versions: 1.1.1
Environment: MyFaces
[
http://issues.apache.org/jira/browse/MYFACES-1169?page=comments#action_12369630
]
Dyego Souza Dantas Leal commented on MYFACES-1169:
--
I try to change the immediate , but does't work , i try change the
valuechangelister with refresh
@ Wendy: Thanks. You are a lifesaver!
@ Others: Lets wait the two weeks for me to come back into country
before we release. In the meantime Stan can fix his urgent issue and
the Shale mock stuff with a crucial bug fix can get released.
Instead of removing the idea plugin from the branch I
Hi Sean!
NOTE: Crucial fixes should go on the *branches* only. I will merge
them down to the trunk later. The worst thing you can do is fix them
on both.
And here we are again ;-)
As you might have read we still have serious problems with the structure
of shared and have to refactor
If the fix is *crucial* on the trunk then it can be fixed in both
places. You just need to be very careful in what you are doing.
Basically you need to change only on the branch and then immediately
merge down all changes since the last merge back to the trunk.
There is a trick to SVN merging.
Somone should force a build on continuum? Bernd can you help out?
Eventually we need to upgrade continuum since there seem to be some
issues with this.
Sean
On 3/9/06, Dennis Byrne [EMAIL PROTECTED] wrote:
The mod date for myfaces-core-1.1.2-SNAPSHOT-bin.zip at
[
http://issues.apache.org/jira/browse/MYFACES-434?page=comments#action_12369645
]
Andreas Wiesauer commented on MYFACES-434:
--
Hello Shinsuke,
I need FileUpload for my MyFaces Portlet Application on Jetspeed 2.0 FINAL and
I tried your
On 3/9/06, Sean Schofield [EMAIL PROTECTED] wrote:
Realistically I think we're talking every 2 months. Especially if you
factor in the time to do separate Tomahawk and Tobago releases every
so often also.
We either need to start releasing more frequently (at least once a
month so long as we
In general terms,
If a feature of MyFaces can be implemented in a JSF-independent way,
put it in tomahawk so everyone can take advantage of it.
If a feature of MyFaces requires special code in impl so that it
cannot be used elsewhere, then it should be configurable, and the
feature should
On 3/9/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
In general terms,
If a feature of MyFaces can be implemented in a JSF-independent way,
put it in tomahawk so everyone can take advantage of it.
If a feature of MyFaces requires special code in impl so that it
cannot be used elsewhere,
I'm completely +1 for what Manfred is saying here. I don't think
there's ever been a clearer explanation of what we're doing and why
with the current setup. In fact, I never completely understood the
details until this mesage.
Note that I'm probably the most-adversely-affected person by this
The problem with merging up to the branch is that you can end up
adding a bunch of experimental stuff into the about to be released
branch. Its much easier to merge the entire branch down to the trunk
instead of merging bits and pieces up to the branch. Either way the
urgent fixes need to be
Hey Sean, I know you're getting on a plane, but think about this while
you're on there :)
If a patch is critical enough that it has to be put into a release
branch, then someone needs to make the time to insure it's merged
correctly -- and this hopefully is the exception rather than the rule.
Hi!
If a patch is critical enough that it has to be put into a release
branch, then someone needs to make the time to insure it's merged
correctly -- and this hopefully is the exception rather than the rule.
Either that, or a new branch is needed.
Branches should be static once created so
One thing I'd like to get in gear right now : is there a utility
out there that can do batch replacing of license files for .java
and .xml files? I'd like to get the per-file license done before
checking in the new drop and I'm dreading doing this manually.
-- Adam
On 3/9/06, Martin
On 3/9/06, Adam Winer [EMAIL PROTECTED] wrote:
One thing I'd like to get in gear right now :is there a utilityout there that can do batch replacing of license files for .javaand .xml files?I'd like to get the per-file license done beforechecking in the new drop and I'm dreading doing this
This is fantastic!
Craig, thank you for helping out on this one! I owe you a beer at J1 :)
There were more developers that initially wanted to help out. I'll see
if I can find them in the archives.
Thanks,
Jonas
Martin Marinschek wrote:
;)
Yes, I thought they had voted on that.
Never
Hi All,
Its getting close to JavaOne and it is time to add the MyFaces JavaOne
Party to your calendar.
As we did last year, there is no set date this early on, but we need to
know now how many are interested in coming to a MyFaces night out
during JavaOne (May 16th - 19th, 2006). With this
Hi,
I have seen this feature in the rico framework under:
http://openrico.org/rico/livegrid.page
but actually could not find it in dojo. Since we are getting closer to
the dojo framework, we have to wait for such a support. But correct me
werner if i am on the wrong way and dojo has already
[ http://issues.apache.org/jira/browse/TOMAHAWK-183?page=all ]
Carsten Stiller resolved TOMAHAWK-183:
--
Resolution: Invalid
Was caused by some local jar-file-jams. ;-) Works quite well.
s:autoUpdateDataTable: javaScript-Error
[
http://issues.apache.org/jira/browse/TOMAHAWK-184?page=comments#action_12369688
]
Pedro Roson Fernandez commented on TOMAHAWK-184:
More specifically, the backing bean method is called as many times as the
number of tree nodes of the kind
[ http://issues.apache.org/jira/browse/TOMAHAWK-183?page=all ]
Carsten Stiller closed TOMAHAWK-183:
s:autoUpdateDataTable: javaScript-Error
document.getElementById(jsf_tree_64) has no properties
-- Forwarded message --
From: Martin Marinschek [EMAIL PROTECTED]
Date: Mar 9, 2006 7:46 PM
Subject: Re: ADF faces proposal
To: general@incubator.apache.org
Definitely, yes.
Sorry for the omission.
We'll update that.
regards,
Martin
On 3/9/06, Justin Erenkrantz [EMAIL
Yes and the DummyForm feature *can* be used with any JSF impl - at
least theoretically ;-). But if people want to use this feature (ie.
having commandlinks without an enclosing form) they should do so by
relying on tomahawk not on the myfaces impl.
Manfred
On 3/9/06, Mike Kienenberger [EMAIL
On 3/9/06, Stan Silvert [EMAIL PROTECTED] wrote:
I assume this was all discussed before, but I'm glad the discussion has
been raised again. I have also been having trouble understanding what
is going on and why.
My current understanding is as follows:
1) There is some common code that both
You can definitely count me in :-).
~~~Kito
D. Mann ([EMAIL PROTECTED])Principal Consultant, Virtua, Inc. (http://www.virtua.com)Author, JavaServer
Faces in Actionhttp://www.JSFCentral.com - JavaServer
Faces FAQ, news, and
I know that dojo hjas something planned along the lines of a good table
control, since I am knee deep into the html editor and dialog I have not
looked into this issue...
:-(
Gerald Müllan schrieb:
Hi,
I have seen this feature in the rico framework under:
time will come! :)
regards,
Gerald
On 3/9/06, Werner Punz [EMAIL PROTECTED] wrote:
I know that dojo hjas something planned along the lines of a good table
control, since I am knee deep into the html editor and dialog I have not
looked into this issue...
:-(
Gerald Müllan schrieb:
Hi,
On Thu, 2006-03-09 at 11:28 +0100, Manfred Geiler wrote:
On 3/9/06, Simon Kitching [EMAIL PROTECTED] wrote:
Personally I don't use breakpoints much; logging works better for me for
debugging.
Maybe you are kind of biased? :-)
Actually, it's the other way around. I work on commons-logging
On Thu, 2006-03-09 at 11:38 -0600, Stan Silvert wrote:
I assume this was all discussed before, but I'm glad the discussion has
been raised again. I have also been having trouble understanding what
is going on and why.
My current understanding is as follows:
1) There is some common code
Add one more.
regards,
Martin
On 3/9/06, Kito D. Mann [EMAIL PROTECTED] wrote:
You can definitely count me in :-).
~~~
Kito D. Mann ([EMAIL PROTECTED])
Principal Consultant, Virtua, Inc. (http://www.virtua.com)
Author,
Another thing I was wondering. Why not make a clean break right
now?
That is, let each project have its own version of the common source
that
gets checked in today? Then they can be maintained independently.
DRY principle! (don't repeat yourself)
We should not have redundant code in
Dunno, I rather suspect I am getting ulcers on it instead of glory
Martin Marinschek schrieb:
Ha!
Werner is getting his glory for creating the
hyper-spellchecker-html-editor super component right now.
regards,
Martin
On 3/8/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Don't see what
If you put stuff like this in the impl proper, you give people a false
impression of security - which is not good.
regards,
Martin
On 3/9/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Yes and the DummyForm feature *can* be used with any JSF impl - at
least theoretically ;-). But if people want
On Thu, 2006-03-09 at 14:01 -0600, Stan Silvert wrote:
Another thing I was wondering. Why not make a clean break right
now?
That is, let each project have its own version of the common source
that
gets checked in today? Then they can be maintained independently.
DRY principle!
Yes, I agree.
We apparently made the false assumption that shared is already stable
enough to freeze and start releasing. Mario is right I think. Perhaps
we should postpone the release process and work in trunk until we
really have a stable state.
Manfred
On 3/9/06, Mario Ivankovits [EMAIL
Count me in, too.
Looking forward to meeting you all again.
Regards,
Manfred
On 3/9/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Add one more.
regards,
Martin
On 3/9/06, Kito D. Mann [EMAIL PROTECTED] wrote:
You can definitely count me in :-).
As you know, JSF 1.2 is fast drawing to a close and the scope is such
that we can't get any new big features in.
However, Sun's and Apache's JSF 1.1 impls are open source, so there is
room for us to make defacto standards if both of us provide the same
interface to the user.
One thing I wanted
enough to freeze and start releasing. Mario is right I think. Perhaps
we should postpone the release process and work in trunk until we
really have a stable state.
Manfred
+1
Dennis Byrne
I get this error when I click on either link. This happens even
after I log in... (mkienenb2 if it matters).
http://forum.java.sun.com/thread.jspa?threadID=692386
http://forum.java.sun.com/forum.jspa?forumID=530
Error: you do not have permission to view the requested forum or category.
On
saveBean stuff seems pretty straight forward, I'm for adding this to the spec
with the same rules as StateHolders and storing it within the attribute map of
the UIViewRoot.
// pseudo
if (obj instanceof StateHolder) {
} else if (obj instanceof Serializable) {
} else { throw new
Hello Sean,
you have to duplicate all projects with the branch in continuum. I can
do it but not this night. At the weekend I have some time for this.
Bernd
Sean Schofield schrieb:
Somone should force a build on continuum? Bernd can you help out?
Eventually we need to upgrade continuum
For a minium nighly build of the 1.1.2 version we need a 1.1.2 branch of
the build-world.sh script. Or a build-world-1.1.2.sh script.
Bernd
Bernd Bohmann schrieb:
Hello Sean,
you have to duplicate all projects with the branch in continuum. I can
do it but not this night. At the weekend I
Ill be there!
From: Jonas Jacobi [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 09, 2006
9:55 AM
To: MyFaces Development; MyFaces
Discussion
Subject: The annual MyFaces
JavaOne party/dinner
Hi All,
Its getting close to JavaOne and it is time to add the MyFaces JavaOne
I have very mixed emotions about rushing into any standards here,
de-facto or otherwise. There's a lot of different ideas here,
and I don't want to latch into any one just yet. Let's
take our time to get this right.
-- Adam
On 3/9/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
saveBean stuff
And you know I wouldn't miss it!
-- Adam
On 3/9/06, Abrams, Howard A [EMAIL PROTECTED] wrote:
I'll be there!
From: Jonas Jacobi [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 09, 2006 9:55 AM
To: MyFaces Development; MyFaces Discussion
Subject:
Can RI guys come? ;-)
Adam Winer wrote:
And you know I wouldn't miss it!
-- Adam
On 3/9/06, Abrams, Howard A [EMAIL PROTECTED] wrote:
I'll be there!
From: Jonas Jacobi [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 09, 2006 9:55 AM
To: MyFaces
Most of 'em sure, but Jacob can put away too much beer.
I say we specifically don't let him come. :) (Unless he
gets Facelets and javax.el in a maven repos, then he's
allowed.)
-- Adam
On 3/9/06, Jacob Hookom [EMAIL PROTECTED] wrote:
Can RI guys come? ;-)
Adam Winer wrote:
And you know I
Count me in - it was great fun last year!tc,-john.On 3/9/06, Jonas Jacobi [EMAIL PROTECTED]
wrote:
Hi All,
Its getting close to JavaOne and it is time to add the MyFaces JavaOne
Party to your calendar.
As we did last year, there is no set date this early on, but we need to
know now how
On 3/9/06, John Fallows [EMAIL PROTECTED] wrote:
Count me in - it was great fun last year!
I want to be there, but need to know which night to protect as quickly
as possible, so my schedule doesn't get trumped like it did last year
:-).
tc,-john.
Craig
On 3/9/06, Jonas Jacobi [EMAIL PROTECTED]
See you there ;)
Dennis Byrne
-Original Message-
From: Manfred Geiler [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 9, 2006 03:28 PM
To: 'MyFaces Development'
Subject: Re: The annual MyFaces JavaOne party/dinner
Count me in, too.
Looking forward to meeting you all again.
Regards,
Ping?On 3/2/06, John Fallows [EMAIL PROTECTED] wrote:
On 3/1/06, Manfred Geiler [EMAIL PROTECTED]
wrote:
On 3/1/06, John Fallows [EMAIL PROTECTED] wrote:
We need to define the meaning of with more caution.Terms for future commons utils and helpers:
* stable API+1. :-)
* downward
No one?
I just want to collect what should be done to make shared clean:
I think the following should be moved to tomahawk:
JavascriptUtils
DummyForm*
MyfacesConfig
What else?
I see a problem with moving DummyForm out, though, it cant stay there.
Actually the dummyForm stuff works
ClassCastException using panelTabbedPane in nightly build
-
Key: TOMAHAWK-187
URL: http://issues.apache.org/jira/browse/TOMAHAWK-187
Project: MyFaces Tomahawk
Type: Bug
Components: Tabbed Pane
Versions:
78 matches
Mail list logo
