Hi Jason!
As it has been a few days since the last email I sent, I figured that
I would drop you a quick note to remind you about my question below.
I already answered your mail :-).
Please see:
http://mail-archives.apache.org/mod_mbox/myfaces-dev/200607.mbox/[EMAIL
PROTECTED]
Ciao,
Mario
[ http://issues.apache.org/jira/browse/TOMAHAWK-565?page=all ]
Mario Ivankovits resolved TOMAHAWK-565.
---
Fix Version/s: 1.1.5-SNAPSHOT
Resolution: Fixed
It should be fixed now, it would be great if you could check if it works.
Thanks!
Ciao
Hi Matthias!
Anybody knowing about a delay to some svn-related mail-systems at
apache`?
I figured out a delay for myfaces and trinidad... anybody noticed
something similar on struts or heard something on infra@ list ?
Did you experienced it yesterday?
Then the delay might result from approx
Hi!
I am running into this error message on popup in an SSL environment
issue with MyFaces 1.1.3. Is there a solution I can implement in my
1.1.3 environment to address this concern? The project I'm working on
has called for a code freeze on the framework jars we're using, and so
we're stuck
[ http://issues.apache.org/jira/browse/TOMAHAWK-90?page=all ]
Mario Ivankovits updated TOMAHAWK-90:
-
Status: Open (was: Patch Available)
t:panelTabbedPane breaks commandLinks
-
Key: TOMAHAWK
Hi Cagatay!
Since not the form component itself but mainly the renderer is going
to be extended and refer to the original form renderer after doing
some script rendering, I guess t:form should work with RI as well.
After a short break where I ride my bicycle I'll come up with a
different sight
Hi Martin!
I took the
time to do our homework and made tomahawk and the RI fully compatible
in all link/button/form related issues. I also added an example -
form.jsf in the sandbox root which demonstrates this.
Congratulations Martin - you tha man :-D
Now, who said we didn't take
Hi Cagatay!
It would absolutely be excellent if h:form of myfaces is allowed to
render the client validation scripts
No, this is no option, then a JSF-RI user has no chance at all to get
our stuff running.
then there is no need for a t:fom or any additinal tag.
Now, that Martin made MyFaces
Hi Martin!
moving s:form has nothing to do with RI compatibility - we remain as
compatible as before.
Does this mean we ARE compatible with RI? We behave the same way as
JSF-RI with our form/command* stuff?
So if one uses tomahawk with JSF-RI and OUR t:form then it will work?
Or do you mean
Hi!
Hi Martin!
moving s:form has nothing to do with RI compatibility - we remain as
compatible as before.
Does this mean we ARE compatible with RI? We behave the same way as
JSF-RI with our form/command* stuff?
So if one uses tomahawk with JSF-RI and OUR t:form then it will work?
Hi!
I noticed that there are only some tests for components in Tomahawk.
Wouldn't it be great to have a test-case as a requirement for
promoting a component ?
Sure, if we can decide what reasonable test cases are.
I would like to see more test-cases too, but not by using mock tests. I
think
Hi Cagatay!
Since not the form component itself but mainly the renderer is going
to be extended and refer to the original form renderer after doing
some script rendering, I guess t:form should work with RI as well.
The sandbox form renderer do not use delegation, but uses inheritance.
This
Hi!
Also, recognize that client-side validation is only half of the
picture; you
also need client-side converters.
Lets do this once needed. In fact, I hope Trinidad become a more
integral part of MyFaces so that we can use Tomahawk and Trinidad and
... together
Hi Cagatay!
By the way, these validators run only at onsubmit event of the form.
I've also implemented simple onkeypress validation that allows only
integers to be entered when there is an integeronly converter by
disabling letters, or max-min length validation when there is a length
Hi Martin!
Well, the thing is that a merge is way off on the timeline.
And Cagatay has something right now, why not take it in?
No, I didnt meant to NOT take Cagatys work now. In fact I'd love to see
it imported soon. Its just the converter stuff I was thinking about.
But now I also think we
TNT would be cooler :)
but Nobago sounds silly :)
*LOL*
---
Mario
But now I also think we should put our hands on the converter stuff,
just, as far as I can see, in Trinidad they implemented a real client
validator with getAsObject and getAsString - to say the truth, I dont
sorry, I meant a real client converter
Hi Adam!
Hmmm ok, I understand the chained validator thing.
So, even if we go the client side converter way, I would like to have a
way to define the allowed characters for the input field.
Maybe by adding a method like
InputMask getInputMask()
to the ClientConverter interface. This return
Hi Matthias!
I introduced three helper methods to shared's HtmlRenderer
(renderId(), getClientId(), shouldRender()). These methods are taken
CoreRenderer (Apache Trinidad Podling).
Great! Though, why will a renderer override the resulting clientId?
I figured out, that some Renderer's extend
Hi Cagatay!
A hot discussion we are having here,
Yes, this is great :-)
I think there is no new API here. Only thing needed is just a single
interface. As I mentioned before most of the validators do not need
any conversion before validating the input at all.
This is not necessarily true.
Hi!
Maybe I can have a look at the ClientConverter stuff?
Sure, that would be great Mario.
Here is a proposal for the client converter stuff.
http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/common/converter/
Once we approved
Hi Cagatay!
There are two method getJsFunction() and getParams() that must be
implemented by extended validators so which design seem more convenient?
* Using an IClientSideValidator which will be implemented by extended
validators marking them capable of doing validation at client side.
or
Hi Cagatay!
One more discussion topic, the client validation is turned on/off via
a context parameter, org.apache.myfaces.ENABLE_CLIENT_VALIDATION,
Do you think validators should override this global setting via an
attribute like client?
client=true|false - yes, I think this will be a nice
Hi!
For one example, what if I download
a third-party validator, and want to add client-side validation
support to it?
So, +1 for an interface.
I dont think this is the best use-case as you still have to change the
original validator code (implement the interface). To achieve this
without the
Hi Cosma!
Maybe we can do some cleanout, removing the RenderUtils.findParentForm
and making SubFormRenderer and HtmlTabbedPaneRenderer use the
_ComponentUtils method? What do you think about this?
Yes, great work.
So lets cleanup this stuff, but maybe without deleting those methods. We
have
Cosma Colanicchia schrieb:
Okay, but 1 and 4 returns an UIForm, while 2 returns an UIComponent.
Ok, I overlooked it, Sorry!
1 is in shared, so you safely can change the return type as we bundle
a renamed copy of shared with tomahawk.
and as 4 is also only used by the class itself it should be
Hi Cosma!
Please correct if I'm wrong: references to shared class must be done
using the shared package for classes in shared package itself, and
using shared_tomahawk from the external tomahawk classes?
Exactly!
Ciao,
Mario
Hi Cosma!
About RenderUtils I'm in doubt.. I changed the return type and added
the FacesContex argument, so its really a new method, I think that
it is useless to mark it as deprecated.. also because it actually does
a thin wrapping for the _ComponentUtils method, as it extracts the
[
http://issues.apache.org/jira/browse/TOMAHAWK-514?page=comments#action_12419467
]
Mario Ivankovits commented on TOMAHAWK-514:
---
Please check if ValueChangePhaseListener.afterPhase gets called.
Do you use the MyFaces JSF impl or Suns JSF RI
[
http://issues.apache.org/jira/browse/TOMAHAWK-514?page=comments#action_12419481
]
Mario Ivankovits commented on TOMAHAWK-514:
---
Do you have a h:messages in your JSF view so that you can see any
validation/converter message?
It looks like JSF
[ http://issues.apache.org/jira/browse/TOMAHAWK-514?page=all ]
Mario Ivankovits resolved TOMAHAWK-514:
---
Resolution: Invalid
Yes, thats the problem.
A validation error prevents the model from being updated. The model_update
phase
[
http://issues.apache.org/jira/browse/TOMAHAWK-514?page=comments#action_12419275
]
Mario Ivankovits commented on TOMAHAWK-514:
---
Do you use the updateActionListener tag on your page?
If so, do it point to a property which holds a list/map
Hi Cosma!
1) The class HtmlJSCookMenuRenderer tries to find the parent form
searching for an UIForm component, but the Trinidad CoreForm doesn't
extend UIForm. This cause the the dummyform stuff rendered in the
page.
2) Using either af:form or h:form, calling
addHiddenCommandParameter on
Hi Cosma!
Okey, done.
Here is the patched patch :)
Ok, fine, but, wouldnt it be best to change the
org.apache.myfaces.shared.util._ComponentUtils.findNestingForm to work
with trinidad too and use this in HtmlJSCookMenuRenderer.java? Just an idea.
Everything else looks fine to me.
Ciao,
Mario
Hi Cosma!
Thank for your review Mario,
No problem ;-)
using findNestingForm may be good, but I don't know if it is used
elsewhere. Maybe other objects rely on the component returned to be
an UIForm?
Could you please check this, e.g. a cast to UIForm will fail.
But if this is not the case, I
[
http://issues.apache.org/jira/browse/TOMAHAWK-511?page=comments#action_12419066
]
Mario Ivankovits commented on TOMAHAWK-511:
---
I already suggested the nightly stuff, but it looks like, this is no option.
Is there any error during/at the end
[
http://issues.apache.org/jira/browse/TOMAHAWK-511?page=comments#action_12419091
]
Mario Ivankovits commented on TOMAHAWK-511:
---
The latest release is 1.1.3, the 1.1.4 branch is the upcoming release (so you
can use this)
on the trunk we work
[ http://issues.apache.org/jira/browse/TOMAHAWK-511?page=all ]
Mario Ivankovits resolved TOMAHAWK-511:
---
Resolution: Fixed
You are welcome, just, next time please use the mailing list instead of jira.
Ciao,
Mario
Getting the Sandbox library
[
http://issues.apache.org/jira/browse/TOMAHAWK-514?page=comments#action_12419117
]
Mario Ivankovits commented on TOMAHAWK-514:
---
no, the lifecycle is its own element, just put it within faces-config.
Method not triggered
[
http://issues.apache.org/jira/browse/TOMAHAWK-514?page=comments#action_12419130
]
Mario Ivankovits commented on TOMAHAWK-514:
---
Thats too bad, I checked the sandbox example and there it works as expected.
Maybe you are able to kick
[ http://issues.apache.org/jira/browse/MYFACES-1351?page=all ]
Mario Ivankovits reopened MYFACES-1351:
---
Another valueChangeListener gets called in addition to the correct one
Hi!
On myfaces-user there is a request to add the following to our datatable:
* caption
* id/headers stuff
It looks like the caption thingy is fixed in JSF 1.2, though, I'll
backport it to tomahawks datatable.
The description about the id/header stuff can be found here:
Matthias Wessendorf schrieb:
can you bring that to JIRA ?
I think there is no need to bring this to jira as I already fixed this
with the commit 398003 from 28.4.2006.
Anyway Roland, good catch, though, why didnt you tried the latest source?
Sorry for the inconvenience.
Ciao,
Mario
Hey boy,
Bernd changed the pom xml
yea - tx a lot for this, however, I do not understand why my and others
local build worked without this change - however a tree times salut to
Bernd.
Ciao,
Mario
For some reason maven did not recreate the shared_* branches.
Please issue a maven clean on continuum to fix this annoying thing.
Thanks!
Mario
Hi!
/export/home/mrmaven/myfaces-nightly/tomahawk/core/src/main/java/org/apache/myfaces/component/html/util/HtmlComponentUtils.java:[63,39]
getBooleanValue(javax.faces.component.UIComponent) in
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils cannot be
applied to
Hi!
+1
However, we should adapt our form/commandLink/commandButton stuff to
make its output compatible with RI real soon.
Ciao,
Mario
Hi!
It would be better to have a context initialization parameter to
enable this behaviour.. sometimes it is expected to drop request
scoped stuff on redirects :).
Yes, when I add the number of redirects configuration I'll add this too.
BTW, nice idea..
Thanks!
Some days ago I was thinking
[
http://issues.apache.org/jira/browse/MYFACES-516?page=comments#action_12417302
]
Mario Ivankovits commented on MYFACES-516:
--
solved in tomahawk-sandbox (RedirectTracker) except for the param thing
Capture and restore saveState Beans
Hi!
As you might know, if you have a navigation rule with redirect /
configuration you'll lose all the request scoped data like:
* managed beans
* messages
* locale
I've checked in the RedirectTrackerManager into tomahawk-sandbox which
is a try to solve this problem.
You have nothing else to do
[
http://issues.apache.org/jira/browse/TOMAHAWK-402?page=comments#action_12417350
]
Mario Ivankovits commented on TOMAHAWK-402:
---
At least the error message: This page contains both secure and nonsecure
items. Do you want to display the nonsecure
[
http://issues.apache.org/jira/browse/TOMAHAWK-176?page=comments#action_12417353
]
Mario Ivankovits commented on TOMAHAWK-176:
---
this should be fixed in tomahawk svn head now - cant close this issue due to
missing version in jira
I decided
Hi!
A warm welcome to you both!
Ciao,
Mario
Hi!
I had to apply the following patch to be able to compile:
Index: shared-tomahawk/pom.xml
===
--- shared-tomahawk/pom.xml (Revision 413826)
+++ shared-tomahawk/pom.xml (Arbeitskopie)
@@ -7,7 +7,7 @@
Hi Sean,
ok, thanks, Done!
Ciao,
Mario
[ http://issues.apache.org/jira/browse/TOMAHAWK-416?page=all ]
Mario Ivankovits resolved TOMAHAWK-416:
---
Fix Version: 1.1.3
Resolution: Fixed
disabled the dummyForm feature by default
Installing Tomahawk breaks jsf-ri commandLink
[ http://issues.apache.org/jira/browse/MYFACES-1171?page=all ]
Mario Ivankovits resolved MYFACES-1171:
---
Fix Version: 1.1.3
Resolution: Fixed
from my point of view we fixed this issue by disabling the dummyForm feature by
default, so
[
http://issues.apache.org/jira/browse/MYFACES-1171?page=comments#action_12416045
]
Mario Ivankovits commented on MYFACES-1171:
---
But the t:commandLink cant work with anything else with myfaces-impl - and I
dont see the badness of it, do all
[
http://issues.apache.org/jira/browse/MYFACES-1171?page=comments#action_12416057
]
Mario Ivankovits commented on MYFACES-1171:
---
well, we can change our form handling to be RI compatible by using their
namings and logic how to do it (I dont know
Hi!
If t:commandLink is deprecated, t:commandNavigation should be
deprecated too, but then we should have an alternative or a different
implementation of commandNavigation.
After a quick look at HtmlNavigationRenderer I think it should be
possible to use delegation instead of inheritance to
[
http://issues.apache.org/jira/browse/MYFACES-949?page=comments#action_12415820
]
Mario Ivankovits commented on MYFACES-949:
--
Simon,
we still have a pain reagrding logging, no?
If I recap correctly, its still not possible to reload a servlet
Jo-o!
This is a vote to release Tomahawk 1.1.3 (and its dependencies:
MyFaces Shared 2.0.2 and MyFaces Maven 1.0.3.)
+1 for my vote
+1
Ciao,
Mario
mmm w/ RI I get some issues.
I am not sure which part of tomahawk should/will work with RI.
I do not use the RI, so I might not be much of help here.
Someone else with more insights? Are these new problems? Should this
hold the release?
Ciao,
Mario
Yeaa, lets give him fun ;-)
+1 for Doc M
Mario
+1 for Mr. M
Dennis Byrne
-Original Message-
From: Matthias Wessendorf [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 8, 2006 04:05 PM
To: 'MyFaces Development'
Subject: Re: [JSF 1.2] question
+1 on Martin.
Eventuelly I'd
Hi Sean,
myfaces/shared/branches/2_0_2/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlLinkRendererBase.java
- throw new IllegalArgumentException(Component + clientId +
must be embedded in an form);
+String path =
Yes, unhappily - I get it too:
java.lang.IllegalArgumentException: Component _idJsp3 must be embedded in an
form
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlLinkRendererBase.renderJavaScriptAnchorStart(HtmlLinkRendererBase.java:209)
Ciao,
Mario
Sorry Sean, I still get this
Hi!
+String msg = Change component/tag ' + clientId + ' from
javax.faces.*/h:tagName / +
+to org.apache.myfaces.*/t:tagName /, or embed it in a
form. This is not a bug. +
+ MyFaces core implementation no longer supports
formless
Hi Sean!
Yes we should have a Upgrading to Tomahawk 1.1.3 wiki. If someone
writes it I will be sure to link to it in the release notes.
http://wiki.apache.org/myfaces/Upgrading_to_Tomahawk_1.1.3
I changed the exception in shared accordingly.
Ciao,
Mario
Hi!
Please use some org.apache.myfaces... namespace in front of
ENABLE_CLIENT_SIDE_VALIDATION
What about integrate
http://struts.apache.org/struts-shale/features-commons-validator.html
into tomahawk?
Then a simple global configuration parameter is missing, no?
Ciao,
Mario
Hi Matthias!
You mean client/server attribute?
this is a no-no (search the mail archive)
I know about the limitations of its current approach, but I meant to
extend this library to honor a global flag too.
I remember Craig isnt against such a flag - I think its just a matter of
no time.
To me
[ http://issues.apache.org/jira/browse/TOMAHAWK-462?page=all ]
Mario Ivankovits resolved TOMAHAWK-462:
---
Fix Version: 1.1.4-SNAPSHOT
Resolution: Fixed
Ok, I think I got it.
ValueChangeNotifier now saves and restores the rowIndex of all
[
http://issues.apache.org/jira/browse/MYFACES-1167?page=comments#action_12414050
]
Mario Ivankovits commented on MYFACES-1167:
---
using commandLink without form was always an enhancement of MyFaces and never
worked with JSF-RI, though, the way we
Hi!
-fileupload or tree2 are working fine.
I wonder that you found that tree2 works fine.
Yesterday I reverted two commits in svn head as the tree was completely
broken here.
I planned to inform Sean about it, but havent found the time lately, but
now its done :-)
The commits were: r410269 and
-fileupload or tree2 are working fine.
I wonder that you found that tree2 works fine.
Ok, I checked the release creation date and those changes where
introduces before the branch.
So definitely the tree is broken, even it our examples works.
The problems were:
usage of
Sean,
please add the following snippet to the release notes regarding how to
reactive the dummyForm feature:
renderer
component-familyjavax.faces.Command/component-family
renderer-typejavax.faces.Button/renderer-type
[
http://issues.apache.org/jira/browse/MYFACES-891?page=comments#action_12414090
]
Mario Ivankovits commented on MYFACES-891:
--
I commited a number converter to tomahawk sandbox which will automatically
convert the value to the beans expected type
Hi Sean!
In the future, when there is a branch, please make your fixes on the
branch instead of the trunk. If we focus on the branch and get it
released then we can merge down soon enough.
Ok, I reverted the patch from head and fixed it on the branch now.
I have some problems to compile the
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
mfg
Mario Ivankovits - OPS EDV Vertriebsges.m.b.H.
Software Engineering
Michael-Bernhard-Gasse 10, A-1120 Wien
Tel.: +43-1-8938810
Fax: +43-1-8938810/3700
E-Mail: [EMAIL PROTECTED
Hi!
C:\projects\MyFaces1.2\jsf12tc6\coresvn info
Path: .
URL: https://svn.apache.org/repos/asf/myfaces/core/trunk
I did my commit from jsf12tc6\core. Why would this subdirectory point
to trunk?
Maybe you copied the .svn directories too?
Ciao,
Mario
[
http://issues.apache.org/jira/browse/TOMAHAWK-402?page=comments#action_12413740
]
Mario Ivankovits commented on TOMAHAWK-402:
---
Sorry, I havent found the time to fix it, but - well - we have the same problem
here, so you can be sure I WILL fix
Hi!
1) TC 5.x (or other not JSP 2.1 compliant)
and
3) TC 6 or Glassfish (or other JSP 2.1 compliant)
TC6 after the first few stable builds. If no other technique requires
ist, I am not sure if we move away from tomcat.
Its also not sure if we ever move to facelets. Especially when upcoming
jsf
Hi Sean!
It looks like the key guys are rather busy these days.
What is the current plan and what do we do for current users? Do we
need an
intermediate release that addresses things in a backwards compatible
way?
The current tomahawk head is fixed in a way, that the dummyForm stuff is
Hi!
OK so the only issue with Tomahawk head is that people need to add
h:form around there components right?
Or - if they use myfaces-impl too - to add some text to their own
faces-config.xml
Do we need a new core release or is this just tomahawk only?
I wont put my mother on it, but I guess
Hi!
+1 for branching the current trunk to a core1.1
+1 for working with jsf 1.2 tc5 on the new trunk
+1 to allow Stan to commit its work to a core1.2tc6 branch
whatever we do with this branch, we wont loose Stans work and it will be
best to have it in svn.
Whenever we decide to move our focus
Martin Marinschek wrote:
1.1 -- branch
1.2 Tomcat 6 -- branch
1.2 Tomcat 5.5. -- trunk
+1
It might be also great to have more of those current virtual
directory, say
branch11
current12tc6
current12tc5 (=current too)
I'd name both 1.2 current as sometimes in the future the tc6 stuff
will be
Hi!
I've seen a performance test which showed that the jboss serialization
isnt faster in contrast to the default serialization.
If this is the truth we should rework
http://wiki.apache.org/myfaces/Performance a little bit as there it is
shown as a performance gain.
Could someone please clarify
Hi!
Sorry.
I wont put any additional effort into the dummyForm stuff as I think
this useless stuff.
Sorry if this sounds too harsh, dont know a better english wording yet ;-)
Once we have the chance to have the view in hand before rendering e.g
like facelets, or the upcoming SoC project it is
[ http://issues.apache.org/jira/browse/MYFACES-1308?page=all ]
Mario Ivankovits resolved MYFACES-1308:
---
Fix Version: 1.1.4-SNAPSHOT
Resolution: Fixed
Ok, I think I got it. Unhappily I have no ADF around, could you please check.
Thanks
Hi!
Dummy Form is used by some of the custom navigation
menus such as NavigationMenu2, JsCookMenu, etc.
Ok, I know what DummyForm does and what its main intention is, but one
can always embed a component in an h:form.
What I dont know is, why we provided such a comfort to not require the
[
http://issues.apache.org/jira/browse/TOMAHAWK-416?page=comments#action_12412100
]
Mario Ivankovits commented on TOMAHAWK-416:
---
It should be sufficient to comment
renderer
component-familyjavax.faces.Command/component-family
Started a new topic to concentrate the post DummyForm stuff and
TOMAHAWK-416 in one place.
How can we make the DummyForm stuff RI compatible (given that we still
think we need it)
Well, we have to override the renderer, but cant count on anything else
than encodeBegin/encodeEnd/encodeChildren
[
http://issues.apache.org/jira/browse/TOMAHAWK-416?page=comments#action_12412102
]
Mario Ivankovits commented on TOMAHAWK-416:
---
please lets discuss possible solutions to still have a dummyForm functionality
even with RI on myfaces-dev. Topic
Hi Sean!
Can you be more specific on how this breaks things.
You cant easily replace renderers like commandLink/commandButton as you
do not know how their inner logic works and there are no specifications
how to name parameters and which should go to hidden fields or not and
which javascript to
Hi Martin!
so if there is no form in the parent-tree - you just render a form
around the link itself?
yes.
I really don't like the dummyForm stuff at all anymore.
+1 - so my proposed solution will provide a slow migration away from it.
At the end, I want to find a solution where we
*G*
so if there is no form in the parent-tree - you just render a form
around the link itself?
yes.
It turns out that this wont work too.
I tried to lookup the h:form renderer (through
context.getRenderKit().getRenderer) and the original link/button
renderer using reflection
Hi!
I know it's not this clear-cut, but the end result (even if it takes
some intermediate workarounds like generating wrapping form
components) should be to require these things to be inside a form.
Yes, I am completely with every who thinks we should deprecate the
dummyForm at all.
As I
*damn*
I fell like a complete idiot ... it is also not possible to intercept
the ViewHandler.
Reason: you never ever have the view in hand before it will be rendered.
Rendering and view creation happen at the same time with JSP.
So no way to change the view before it were rendered - now I think
So, for now I removed the renderer override in faces-config.xml so parts
of tomahawk should work with RI again.
If a user still wants to use the dummyForm he/she can add this [1] code
to the faces-config.xml
Its still time to rollback this change, else I'll post tomorrow
something to the user
Hi Burno!
i try to deploy the latest release of MyFaces (and tomahawk) on Weblogic 8.1
sp 5 and i have this issue :
java.lang.IllegalStateException: strict servlet API: cannot call
Are you sure, you use the latest tomahawk release, the ExtensionsFilter
class changed to
[
http://issues.apache.org/jira/browse/TOMAHAWK-416?page=comments#action_12412030
]
Mario Ivankovits commented on TOMAHAWK-416:
---
Unhappily the only chance I see is to remove the commandLink and commandButton
renderer from tomahawks faces
601 - 700 of 974 matches
Mail list logo
