melloware commented on pull request #222:
URL: https://github.com/apache/myfaces/pull/222#issuecomment-916852675
@cristiand85 before submitting a PR you should make sure your branch is even
with master first so it doesn't crowd your PR with noise from other commits.
--
This is an
tandraschko commented on pull request #222:
URL: https://github.com/apache/myfaces/pull/222#issuecomment-916716187
Please create a jira issue and provide a reproducer
This PR looks quite weird
--
This is an automated message from the Apache Git Service.
To respond to the message,
tandraschko closed pull request #222:
URL: https://github.com/apache/myfaces/pull/222
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail:
wing error
```
An Error Occurred:
Bean Validation is not present
viewId = / product.xhtml
location = null
phaseId = PROCESS_VALIDATIONS (3)
Caused by:
javax.faces.FacesException - Bean Validation is not present
at javax.faces.validator.BeanValidator.createValida
Hi Tomas!
Yes, I tried it with older MyFaces versions and they fail as well.
And then I figured why: my bean variable was an Integer, but the getter
returned int ^^ ;)
So MyFaces is perfectly fine, and I'm the one to blame ;)
All fine, all saved!
txs and LieGrue,
strub
> Am 02.06.2019 um
No idea curently but i would assume that
1) viewParam must be assigned first before execute validation
2) it should not throw an npe, also If your int is null
Please dig a bit deeper and also try 2.3.1 e.g.
We also released 2.3.4, which fixes a bug related to deltaspike
Mark Struberg schrieb am
Hi folks!
I'm pretty rusty in JSF, but came back to it for a smallish application.
I'm using MyFaces-2.3.3 via TomEE-8.0-M3.
I have a pate ballotDetail.xhtml which should be bookmarkable. Invocation is
http://localhost:8080/voting/ballotDetail.xhtml?dswid=-3043=1
dswid is from DeltaSpike
Available)
> Classloader issue with a serializable object when using whole bean validation
> feature
> -
>
> Key: MYFACES-4136
> URL: https://issues.apache.org/jira/b
sue with a serializable object when using whole bean validation
> feature
> -
>
> Key: MYFACES-4136
> URL: https://issues.apache.org/jira/browse/MYFACES-4136
>
this patch.
> Classloader issue with a serializable object when using whole bean validation
> feature
> -
>
> Key: MYFACES-4136
> URL: https://issues.apache.org/j
hen using whole bean validation
> feature
> -
>
> Key: MYFACES-4136
> URL: https://issues.apache.org/jira/browse/MYFACES-4136
> Project: MyFaces Core
Eduardo Breijo created MYFACES-4136:
---
Summary: Classloader issue with a serializable object when using
whole bean validation feature
Key: MYFACES-4136
URL: https://issues.apache.org/jira/browse/MYFACES-4136
://myfaces.apache.org/wiki/core/committer-and-pmc-guide/myfaces-project-management.html
If the is issue is still important for you, please reopen and attach a patch.
> More error logging when Bean Validation throws an exception at star
determines 'if a JSF 303 engine is present' by
doing...
Class.forName( javax.validation.Validation )
...in javax.faces.validator._ExternalSpecifications
Programmatically generated components do not register with Bean Validation
Leonardo Uribe created MYFACES-3573:
---
Summary: Log only once unified EL / bean validation presence
Key: MYFACES-3573
URL: https://issues.apache.org/jira/browse/MYFACES-3573
Project: MyFaces Core
once unified EL / bean validation presence
---
Key: MYFACES-3573
URL: https://issues.apache.org/jira/browse/MYFACES-3573
Project: MyFaces Core
Issue Type: Improvement
Components: JSR
[perf] do not store default validationGroups for bean validation
Key: MYFACES-3495
URL: https://issues.apache.org/jira/browse/MYFACES-3495
Project: MyFaces Core
Issue Type
not store default validationGroups for bean validation
Key: MYFACES-3495
URL: https://issues.apache.org/jira/browse/MYFACES-3495
Project: MyFaces Core
Issue Type: Improvement
log message when bean validation code throws exception
--
Key: TRINIDAD-2207
URL: https://issues.apache.org/jira/browse/TRINIDAD-2207
Project: MyFaces Trinidad
Issue Type: Bug
Affects
validation be bound to programatically added
components. It is responsibility (at least theorically) of the developer to
check the conditions and add bean validation in this case. I don't see how to
solve it in other way.
Programmatically generated components do not register with Bean Validation
. Thanks for your clarification.
Can you please elaborate on 'check the conditions'? I believe JSF adds Bean
Validation implicitly to components 'if a JSR 303 engine is present'. But how
is that determined? Is there a JSF API? Or does MyFaces look for a specific JSR
303 class?
Programmatically
Programmatically generated components do not register with Bean Validation
--
Key: MYFACES-3299
URL: https://issues.apache.org/jira/browse/MYFACES-3299
Project: MyFaces Core
Bean Validation doesn't work with Glassfish el-impl-2.2
---
Key: MYFACES-3049
URL: https://issues.apache.org/jira/browse/MYFACES-3049
Project: MyFaces Core
Issue Type: Bug
bug!
However, we can maybe implement a fallback to the legacy el-1.0 mechanism
(via dummy el-resolver) if el-2.2 returns null..
Bean Validation doesn't work with Glassfish el-impl-2.2
---
Key: MYFACES-3049
this. You added a null-check already to prevent BV to
validate for example Collections. So adding this fallback will probably break
this, right?
Bean Validation doesn't work with Glassfish el-impl-2.2
---
Key: MYFACES-3049
. This check would just come after the fallback.
Bean Validation doesn't work with Glassfish el-impl-2.2
---
Key: MYFACES-3049
URL: https://issues.apache.org/jira/browse/MYFACES-3049
Project: MyFaces Core
guess we should log a warning (maybe once, to prevent
trashing the log) to show the user that something is wrong with the
configuration (b/c it also hurts performance).
Bean Validation doesn't work with Glassfish el-impl-2.2
[
https://issues.apache.org/jira/browse/MYFACES-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997360#comment-12997360
]
Jakob Korherr commented on MYFACES-3049:
+1 !
Bean Validation doesn't work
, fallback and warning as discussed with Jakob.
Bean Validation doesn't work with Glassfish el-impl-2.2
---
Key: MYFACES-3049
URL: https://issues.apache.org/jira/browse/MYFACES-3049
Project: MyFaces
More error logging when Bean Validation throws an exception at startup
--
Key: MYFACES-2932
URL: https://issues.apache.org/jira/browse/MYFACES-2932
Project: MyFaces Core
(trinidad + bean-validation) required initialization
Key: EXTVAL-98
URL: https://issues.apache.org/jira/browse/EXTVAL-98
Project: MyFaces Extensions Validator
Issue Type: Bug
-SNAPSHOT
Resolution: Fixed
(trinidad + bean-validation) required initialization
Key: EXTVAL-98
URL: https://issues.apache.org/jira/browse/EXTVAL-98
Project: MyFaces Extensions Validator
[
https://issues.apache.org/jira/browse/EXTCDI-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek resolved EXTCDI-8.
---
Resolution: Fixed
producers for bean-validation artifacts
(if the openwebbeans-resource is in
the classpath).
Will ask JBoss guys whether this is also available if weld is used with native
tomcat/jetty
producers for bean-validation artifacts
---
Key: EXTCDI-8
URL: https://issues.apache.org
the Validator and ValidatorFactory
from JNDI.
producers for bean-validation artifacts
---
Key: EXTCDI-8
URL: https://issues.apache.org/jira/browse/EXTCDI-8
Project: MyFaces CODI
Issue Type: New Feature
in the view-layer.
so we could solve it via the @Jsf qualifier to get a special version (which is
cached in the application scope of jsf).
producers for bean-validation artifacts
---
Key: EXTCDI-8
URL: https
producers for bean-validation artifacts
---
Key: EXTCDI-8
URL: https://issues.apache.org/jira/browse/EXTCDI-8
Project: MyFaces CODI
Issue Type: New Feature
Reporter: Gerhard Petracek
in jee
BeanValidator should not be installed if bean validation is not available
-
Key: MYFACES-2518
URL: https://issues.apache.org/jira/browse/MYFACES-2518
Project: MyFaces Core
not be installed if bean validation is not available
-
Key: MYFACES-2518
URL: https://issues.apache.org/jira/browse/MYFACES-2518
Project: MyFaces Core
Issue Type: Task
Affects
Myfaces should be able to gracefully handle a runtime with the bean validation
API on the classpath but no impl
---
Key: MYFACES-2498
URL: https
to gracefully handle a runtime with the bean
validation API on the classpath but no impl
---
Key: MYFACES-2498
URL: https://issues.apache.org/jira/browse
We have an initial draft proposal to create a JSR-303 Bean Validation
implementation at Apache as an incubator podling.
Take a look at the proposal [1] and feel free to ask questions about it
on the d...@commons list and volunteer to be an initial committer if you
have time and interests
On Tue, 27 Oct 2009 18:06:04 -0700, Matthias Wessendorf
mat...@apache.org said:
MW Hi Jan-Kees,
MW thanks for creating this ticket. I'd like to see something like this.
MW Sounds (to me) very useful...
Note that there is a precedent for doing this kind of discovery without
requiring a Java
On Tue, Nov 3, 2009 at 4:24 PM, Ed Burns ed.bu...@sun.com wrote:
On Tue, 27 Oct 2009 18:06:04 -0700, Matthias Wessendorf
mat...@apache.org said:
MW Hi Jan-Kees,
MW thanks for creating this ticket. I'd like to see something like this.
MW Sounds (to me) very useful...
Note that there is a
On Tue, 03 Nov 2009 16:29:22 +0100, Matthias Wessendorf
mat...@apache.org said:
MW On Tue, Nov 3, 2009 at 4:24 PM, Ed Burns ed.bu...@sun.com wrote:
On Tue, 27 Oct 2009 18:06:04 -0700, Matthias Wessendorf
mat...@apache.org said:
MW Hi Jan-Kees,
MW thanks for creating this ticket. I'd like
/show_bug.cgi?id=657
/JK
2009/10/27 Ryan Lubke ryan.lu...@sun.com:
On 10/25/09 10:57 AM, Jan-Kees van Andel wrote:
Hey (CC MyFaces Dev),
For MyFaces, I have implemented the first version of Bean Validation
support. But my implementation had a TCK issue, because I had some
non-specified public fields
of Bean Validation
support. But my implementation had a TCK issue, because I had some
non-specified public fields. These fields indicated the runtime
availability of some libraries.
See: http://issues.apache.org/jira/browse/MYFACES-2386 for the issue.
To fix it, I've moved the public fields
, but not with an implementation I'm very proud of. I think the
specification needs to standardize this class, so we can make it public and
avoid code duplication.
Refactor Bean Validation constants to package-private class
-
Key: MYFACES
Hey (CC MyFaces Dev),
For MyFaces, I have implemented the first version of Bean Validation
support. But my implementation had a TCK issue, because I had some
non-specified public fields. These fields indicated the runtime
availability of some libraries.
See: http://issues.apache.org/jira/browse
Refactor Bean Validation constants to package-private class
-
Key: MYFACES-2386
URL: https://issues.apache.org/jira/browse/MYFACES-2386
Project: MyFaces Core
Issue Type: Bug
Hi Leonardo -
On Mon, Sep 21, 2009 at 11:28 PM, Leonardo Uribe lu4...@gmail.com wrote:
In jsf 2.0 spec section 3.5.3 Validation Registration says this:
The default validators are appended after any locally defined
validators once the EditableValueHolder is populated and added to the
Leonardo Uribe schrieb:
I haven't found that part on the spec yet, but it seems you're right.
Looking the spec, f:validateBean is not mentioned on chapter 9
Integration with JSP, but it is on chapter 10 Facelets and its use in
Web Applications. Anyway, there is an error on ri jsp taglibdoc
Yes Werner, I saw this statement in JSF specs ED2.
On Tue, Sep 22, 2009 at 10:11 AM, Werner Punz werner.p...@gmail.com wrote:
Leonardo Uribe schrieb:
I haven't found that part on the spec yet, but it seems you're right.
Looking the spec, f:validateBean is not mentioned on chapter 9
Hi
Checking some stuff on the spec and reading some javadoc I have notice that
it is not possible to make bean validation api available on jsp world,
because there is no integration point where the default validators are
created and set to every EditableValueHolder instance.
In jsf 2.0 spec
Leonardo Uribe schrieb:
Hi
Checking some stuff on the spec and reading some javadoc I have notice
that it is not possible to make bean validation api available on jsp
world, because there is no integration point where the default
validators are created and set to every EditableValueHolder
around creating
a Validator2 release [1], which implements the upcoming JSR-303 Bean
Validation spec [2] and [3]. Since JSR-303 is now a required component of
Java EE 6 application servers and must be supported by JSR-314 JSF2 and
JSR-317 JPA2, there is growing interest in the Apache Geronimo
Discussion thread on d...@commons [1] about starting a JSR-303
implementation at Apache.
[1]
http://www.nabble.com/-VALIDATOR--Proposal-for-a-JSR-303-Bean-Validation-Implementation-td25295595.html
-Donald
Original Message
Subject: Re: [VALIDATOR] Proposal for a JSR-303
it is added in JSF
2.0.
I base my beanval-exists-check on a
Class.forName(javax.validation.Validator). It may exist in your
environment, while an implementation is not available. But since there
is no official Bean Validation release yet, this should not be
possible. When it gets released though
beanval-exists-check on a
Class.forName(javax.validation.Validator). It may exist in your
environment, while an implementation is not available. But since there
is no official Bean Validation release yet, this should not be
possible. When it gets released though, this may happen, so I'm gonna
try
). It may exist in your
environment, while an implementation is not available. But since there
is no official Bean Validation release yet, this should not be
possible. When it gets released though, this may happen, so I'm gonna
try to modify the code so that it does a more thorough check.
When it's
|I was doing a quick reqression test on the myfaces-example-simple app, and I
hit the exception below trying to run sample1. Looks to be introduced
by the recent drop for the bean validation work.
I haven't worked with the validation APIs before so its very possible I've
missed a step
is not available. But since there
is no official Bean Validation release yet, this should not be
possible. When it gets released though, this may happen, so I'm gonna
try to modify the code so that it does a more thorough check.
When it's committed, I'll let you know.
/JK
Ps. Mike: It looks like you're my
-exists-check on a
Class.forName(javax.validation.Validator). It may exist in your
environment, while an implementation is not available. But since there
is no official Bean Validation release yet, this should not be
possible. When it gets released though, this may happen, so I'm gonna
try to modify
Excellent, thanks a lot Jan
Werner
Jan-Kees van Andel schrieb:
Hey,
I've just committed the first part of the Bean Validation code.
For this, I needed to add the Bean Validation API to the MyFaces API pom.
And since it is not yet listed in any central Maven repo, I've also
added
Hey,
I've just committed the first part of the Bean Validation code.
For this, I needed to add the Bean Validation API to the MyFaces API pom.
And since it is not yet listed in any central Maven repo, I've also
added the JBoss repository to the pom.
I hope it immediately works for everyone
Hey guys,
I've almost finished the Bean Validation integration. I have a working
test webapp with so simple validations working.
But before commit, I would like to know which Bean Validation API
we're going to depend on.
I'm currently using the JBoss Bean Validation binaries:
http
On Fri, Aug 7, 2009 at 10:18 AM, Jan-Kees van
Andeljankeesvanan...@gmail.com wrote:
Hey guys,
I've almost finished the Bean Validation integration. I have a working
test webapp with so simple validations working.
But before commit, I would like to know which Bean Validation API
we're going
That's great. Also good that Web Beans gets ASL2 licensed, since we're
going to depend on that one too!
2009/8/7 Matthias Wessendorf mat...@apache.org:
On Fri, Aug 7, 2009 at 10:18 AM, Jan-Kees van
Andeljankeesvanan...@gmail.com wrote:
Hey guys,
I've almost finished the Bean Validation
-Kees van
Andeljankeesvanan...@gmail.com wrote:
Hey guys,
I've almost finished the Bean Validation integration. I have a working
test webapp with so simple validations working.
But before commit, I would like to know which Bean Validation API
we're going to depend on.
I'm currently using
about WebBeans; I strongly recommend to use the bits
from the OWB effort, under incubation now...
-M
2009/8/7 Matthias Wessendorf mat...@apache.org:
On Fri, Aug 7, 2009 at 10:18 AM, Jan-Kees van
Andeljankeesvanan...@gmail.com wrote:
Hey guys,
I've almost finished the Bean Validation
Yes indeed, I dont have any gripes with jboss, unless they dont use our
implementation ;-)
Werner
Matthias Wessendorf schrieb:
On Fri, Aug 7, 2009 at 10:18 AM, Jan-Kees van
Andeljankeesvanan...@gmail.com wrote:
Hey guys,
I've almost finished the Bean Validation integration. I have
, under incubation now...
-M
2009/8/7 Matthias Wessendorf mat...@apache.org:
On Fri, Aug 7, 2009 at 10:18 AM, Jan-Kees van
Andeljankeesvanan...@gmail.com wrote:
Hey guys,
I've almost finished the Bean Validation integration. I have a working
test webapp with so simple validations working
Implement Bean Validation
-
Key: MYFACES-2288
URL: https://issues.apache.org/jira/browse/MYFACES-2288
Project: MyFaces Core
Issue Type: New Feature
Components: JSR-314
Reporter: Jan-Kees van
1.2.3-SNAPSHOT
the basic integration is done. this task continues as independent validation
module.
bean validation integration
---
Key: EXTVAL-33
URL: https://issues.apache.org/jira/browse/EXTVAL-33
Project
.
When I'm reading the PDF, it says that when Bean Validation is
enabled, during the RENDER RESPONSE phase, every UIInput gets a
javax.faces.Bean Validator attached to it.
Then, on the other hand, when I read the JavaDocs for
UIInput.validateValue(), I see the validation process with regards
Hey,
I'm currently implementing the JSF 2.0 changes in
UIInput.validateValue() for MyFaces, but the descriptions in the spec
seem odd.
When I'm reading the PDF, it says that when Bean Validation is
enabled, during the RENDER RESPONSE phase, every UIInput gets a
javax.faces.Bean Validator
seem odd.
When I'm reading the PDF, it says that when Bean Validation is
enabled, during the RENDER RESPONSE phase, every UIInput gets a
javax.faces.Bean Validator attached to it.
Then, on the other hand, when I read the JavaDocs for
UIInput.validateValue(), I see the validation process
van Andel jankeesvanan...@gmail.com
Hey,
I'm currently implementing the JSF 2.0 changes in
UIInput.validateValue() for MyFaces, but the descriptions in the spec
seem odd.
When I'm reading the PDF, it says that when Bean Validation is
enabled, during the RENDER RESPONSE phase, every UIInput
van Andel jankeesvanan...@gmail.com
Hey,
I'm currently implementing the JSF 2.0 changes in
UIInput.validateValue() for MyFaces, but the descriptions in the spec
seem odd.
When I'm reading the PDF, it says that when Bean Validation is
enabled, during the RENDER RESPONSE phase, every
of the symbolic constant VALIDATE_EMPTY_FIELDS_PARAM_NAME. If there is
no value under that key, use the same key and look in the application
map from the ExternalContext. If the value is null or equal to the
string “auto” (without the quotes) take appropriate action to
determine if Bean Validation
in
UIInput.validateValue() for MyFaces, but the descriptions in the
spec
seem odd.
When I'm reading the PDF, it says that when Bean Validation is
enabled, during the RENDER RESPONSE phase, every UIInput gets a
javax.faces.Bean Validator attached to it.
Then, on the other hand, when I read the JavaDocs
2009/7/9 Matthias Wessendorf mwessend...@gmail.com:
Feel free to add better javadoc for myfaces ;)
Documentation? :-)
But yeah, I'm for sure gonna try!
/JK
in
UIInput.validateValue() for MyFaces, but the descriptions in the spec
seem odd.
When I'm reading the PDF, it says that when Bean Validation is
enabled, during the RENDER RESPONSE phase, every UIInput gets a
javax.faces.Bean Validator attached to it.
Then, on the other hand, when I read the JavaDocs
bean validation integration
---
Key: EXTVAL-33
URL: https://issues.apache.org/jira/browse/EXTVAL-33
Project: MyFaces Extensions Validator
Issue Type: Task
Reporter: Gerhard Petracek
--
This message
84 matches
Mail list logo
