You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@visi.com> on 2009/03/03 22:10:55 UTC
Re: Flushing out validation
As another approach to going through the spec, here's a list of the
annotations we support:
- javax.annotation.PostConstruct
- javax.annotation.PreDestroy
- javax.annotation.Resource
- javax.annotation.Resources
- javax.annotation.security.DeclareRoles
- javax.annotation.security.DenyAll
- javax.annotation.security.PermitAll
- javax.annotation.security.RolesAllowed
- javax.annotation.security.RunAs
- javax.ejb.ApplicationException
- javax.ejb.ConcurrencyManagement
- javax.ejb.DependsOn
- javax.ejb.EJB
- javax.ejb.EJBs
- javax.ejb.Init
- javax.ejb.Local
- javax.ejb.LocalHome
- javax.ejb.MessageDriven
- javax.ejb.PostActivate
- javax.ejb.PrePassivate
- javax.ejb.Remote
- javax.ejb.RemoteHome
- javax.ejb.Remove
- javax.ejb.Singleton
- javax.ejb.Startup
- javax.ejb.Stateful
- javax.ejb.Stateless
- javax.ejb.TransactionAttribute
- javax.ejb.TransactionManagement
- javax.interceptor.ExcludeClassInterceptors
- javax.interceptor.ExcludeDefaultInterceptors
- javax.interceptor.Interceptors
- javax.jws.HandlerChain
- javax.jws.WebService
- javax.persistence.PersistenceContext
- javax.persistence.PersistenceContexts
- javax.persistence.PersistenceUnit
- javax.persistence.PersistenceUnits
- javax.xml.ws.WebServiceProvider
- javax.xml.ws.WebServiceRefs
Off the top of my head I know that we don't have checks for the
security related annotations. I guess the one that jumps out the most
is that @DenyAll, @PermitAll, and @RolesAllowed are all mutually
exclusive. It's an error if they use any more than one of those on a
specific class as they would contradict each other.
I'm not sure if I added it but also there are some new Singleton only
annotations and the user should be warned that these annotations are
ignored when used on other types of beans. These annotations are:
- javax.ejb.DependsOn
- javax.ejb.Startup
Some web services stuff comes to mind as well. @Stateless and
@Singleton beans can be web services, but @Stateful and @MessageDriven
beans cannot, so the usage of any of these annotations at the class
level is ignored:
- javax.jws.HandlerChain
- javax.jws.WebService
Using @PersistenceContext(EXTENDED) on anything but an @Stateful bean
is illegal and should result in a validation failure. Not sure if we
cover that one for all non-stateful bean types and servlets.
Likely some more I'm missing. Chime in if you see one.
Oh, if @Interceptors lists an abstract class or interface, that's also
illegal. Probably some rules or mistakes on @HanlderChain we should
check for.
-David
On Feb 1, 2009, at 3:22 AM, Mohammad Nour El-Din wrote:
> Here is what I am going to do, I will read the specs 3.0 and 3.1 and
> write down the points we should validate on, check JIRA for any of
> these points implemented before, and add and implement the missing
> ones. But just to let you know according to my available time I will
> not be able to do that as quick as possible, it will take me sometime.
>
> On Thu, Jan 29, 2009 at 12:16 PM, Mohammad Nour El-Din
> <no...@gmail.com> wrote:
>> Hi David...
>>
>> As I have not been so active lately, I really would like to go and
>> help into this area. Any directions other than the ones you mentioned
>> in your mail ?
>>
>> On Wed, Jan 28, 2009 at 11:46 PM, David Blevins <david.blevins@visi.com
>> > wrote:
>>> I just did some work in the validation area and it occurs to me
>>> how much
>>> work has yet to be done. It is definitely one of our most
>>> critical features
>>> that users go "ooh" and "ahh" over.
>>>
>>> Code wise, its's one of those areas where the hardest part is
>>> being as
>>> thorough as possible. I personally haven't been very thorough in
>>> my work
>>> there and have just been adding validations as they occur to me
>>> and most
>>> often without tests. Definitely shame on me.
>>>
>>> I just added a new class, ValidationAssertions, which will check the
>>> ValidationFailedException failed exception thrown from the
>>> ConfigurationFactory on depoy. It makes sure all the expected
>>> validation
>>> issues were spotted, that there are i18n messages for each message
>>> key, that
>>> there are the required three levels of messages, and that when
>>> formatted
>>> there are no unfilled "{0}" sections. We get bit by that last one
>>> a lot.
>>>
>>> We really should add tests for all the checks/messages we have.
>>>
>>> There are also likely a ton of validations we don't do and
>>> should. We
>>> should also get a list of all the annotations and make sure we have
>>> validations for each of them and add the ones where we don't.
>>>
>>> Thoughts? Volunteers?
>>>
>>>
>>> -David
>>>
>>>
>>
>>
>>
>> --
>> ----
>> Thanks
>> - Mohammad Nour
>> - LinkedIn: http://www.linkedin.com/in/mnour
>> ----
>> "Life is like riding a bicycle. To keep your balance you must keep
>> moving"
>> - Albert Einstein
>>
>
>
>
> --
> ----
> Thanks
> - Mohammad Nour
> - LinkedIn: http://www.linkedin.com/in/mnour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep
> moving"
> - Albert Einstein
>
Re: Flushing out validation
Posted by Mohammad Nour El-Din <no...@gmail.com>.
I agree with you. WAS has the same feature called "Enhanced EAR" which
can contain everything you want including creation of resources you
use in your application. And most people advice not to use this
feature in production environments.
Would you please open a JIRA with it and I will try to finish it by
the end of this week :-).
On Wed, Mar 18, 2009 at 10:55 AM, Jean-Louis MONTEIRO
<je...@atosorigin.com> wrote:
>
> Hi,
>
> Something came to my mind.
> As a useful feature, OpenEJB performs a lot of automatic actions (creating
> queues, datasources, adapting datasources, ....) which is fine for
> development and testing.
>
> But it can be very dramatic when putting OpenEJB in production (the real
> life ;-)).
> From my point of view, it would be nice to add a property to disable such a
> feature. In production, we must be sure the datasource used in the
> persistence.xml file exists. If not, deployment must fail !
>
> Do you agree ?
>
> Jean-Louis
> --
> View this message in context: http://www.nabble.com/Flushing-out-validation-tp21715750p22574912.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
>
--
----
Thanks
- Mohammad Nour
- LinkedIn: http://www.linkedin.com/in/mnour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Re: Flushing out validation
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
Hi,
Something came to my mind.
As a useful feature, OpenEJB performs a lot of automatic actions (creating
queues, datasources, adapting datasources, ....) which is fine for
development and testing.
But it can be very dramatic when putting OpenEJB in production (the real
life ;-)).
>From my point of view, it would be nice to add a property to disable such a
feature. In production, we must be sure the datasource used in the
persistence.xml file exists. If not, deployment must fail !
Do you agree ?
Jean-Louis
--
View this message in context: http://www.nabble.com/Flushing-out-validation-tp21715750p22574912.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Flushing out validation
Posted by Mohammad Nour El-Din <no...@gmail.com>.
You have a great memory David :D.
On Tue, Mar 3, 2009 at 11:10 PM, David Blevins <da...@visi.com> wrote:
> As another approach to going through the spec, here's a list of the
> annotations we support:
>
> - javax.annotation.PostConstruct
> - javax.annotation.PreDestroy
> - javax.annotation.Resource
> - javax.annotation.Resources
> - javax.annotation.security.DeclareRoles
> - javax.annotation.security.DenyAll
> - javax.annotation.security.PermitAll
> - javax.annotation.security.RolesAllowed
> - javax.annotation.security.RunAs
> - javax.ejb.ApplicationException
> - javax.ejb.ConcurrencyManagement
> - javax.ejb.DependsOn
> - javax.ejb.EJB
> - javax.ejb.EJBs
> - javax.ejb.Init
> - javax.ejb.Local
> - javax.ejb.LocalHome
> - javax.ejb.MessageDriven
> - javax.ejb.PostActivate
> - javax.ejb.PrePassivate
> - javax.ejb.Remote
> - javax.ejb.RemoteHome
> - javax.ejb.Remove
> - javax.ejb.Singleton
> - javax.ejb.Startup
> - javax.ejb.Stateful
> - javax.ejb.Stateless
> - javax.ejb.TransactionAttribute
> - javax.ejb.TransactionManagement
> - javax.interceptor.ExcludeClassInterceptors
> - javax.interceptor.ExcludeDefaultInterceptors
> - javax.interceptor.Interceptors
> - javax.jws.HandlerChain
> - javax.jws.WebService
> - javax.persistence.PersistenceContext
> - javax.persistence.PersistenceContexts
> - javax.persistence.PersistenceUnit
> - javax.persistence.PersistenceUnits
> - javax.xml.ws.WebServiceProvider
> - javax.xml.ws.WebServiceRefs
>
> Off the top of my head I know that we don't have checks for the security
> related annotations. I guess the one that jumps out the most is that
> @DenyAll, @PermitAll, and @RolesAllowed are all mutually exclusive. It's an
> error if they use any more than one of those on a specific class as they
> would contradict each other.
>
> I'm not sure if I added it but also there are some new Singleton only
> annotations and the user should be warned that these annotations are ignored
> when used on other types of beans. These annotations are:
> - javax.ejb.DependsOn
> - javax.ejb.Startup
>
> Some web services stuff comes to mind as well. @Stateless and @Singleton
> beans can be web services, but @Stateful and @MessageDriven beans cannot, so
> the usage of any of these annotations at the class level is ignored:
> - javax.jws.HandlerChain
> - javax.jws.WebService
>
> Using @PersistenceContext(EXTENDED) on anything but an @Stateful bean is
> illegal and should result in a validation failure. Not sure if we cover
> that one for all non-stateful bean types and servlets.
>
> Likely some more I'm missing. Chime in if you see one.
>
> Oh, if @Interceptors lists an abstract class or interface, that's also
> illegal. Probably some rules or mistakes on @HanlderChain we should check
> for.
>
> -David
>
> On Feb 1, 2009, at 3:22 AM, Mohammad Nour El-Din wrote:
>
>> Here is what I am going to do, I will read the specs 3.0 and 3.1 and
>> write down the points we should validate on, check JIRA for any of
>> these points implemented before, and add and implement the missing
>> ones. But just to let you know according to my available time I will
>> not be able to do that as quick as possible, it will take me sometime.
>>
>> On Thu, Jan 29, 2009 at 12:16 PM, Mohammad Nour El-Din
>> <no...@gmail.com> wrote:
>>>
>>> Hi David...
>>>
>>> As I have not been so active lately, I really would like to go and
>>> help into this area. Any directions other than the ones you mentioned
>>> in your mail ?
>>>
>>> On Wed, Jan 28, 2009 at 11:46 PM, David Blevins <da...@visi.com>
>>> wrote:
>>>>
>>>> I just did some work in the validation area and it occurs to me how much
>>>> work has yet to be done. It is definitely one of our most critical
>>>> features
>>>> that users go "ooh" and "ahh" over.
>>>>
>>>> Code wise, its's one of those areas where the hardest part is being as
>>>> thorough as possible. I personally haven't been very thorough in my
>>>> work
>>>> there and have just been adding validations as they occur to me and most
>>>> often without tests. Definitely shame on me.
>>>>
>>>> I just added a new class, ValidationAssertions, which will check the
>>>> ValidationFailedException failed exception thrown from the
>>>> ConfigurationFactory on depoy. It makes sure all the expected
>>>> validation
>>>> issues were spotted, that there are i18n messages for each message key,
>>>> that
>>>> there are the required three levels of messages, and that when formatted
>>>> there are no unfilled "{0}" sections. We get bit by that last one a
>>>> lot.
>>>>
>>>> We really should add tests for all the checks/messages we have.
>>>>
>>>> There are also likely a ton of validations we don't do and should. We
>>>> should also get a list of all the annotations and make sure we have
>>>> validations for each of them and add the ones where we don't.
>>>>
>>>> Thoughts? Volunteers?
>>>>
>>>>
>>>> -David
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> ----
>>> Thanks
>>> - Mohammad Nour
>>> - LinkedIn: http://www.linkedin.com/in/mnour
>>> ----
>>> "Life is like riding a bicycle. To keep your balance you must keep
>>> moving"
>>> - Albert Einstein
>>>
>>
>>
>>
>> --
>> ----
>> Thanks
>> - Mohammad Nour
>> - LinkedIn: http://www.linkedin.com/in/mnour
>> ----
>> "Life is like riding a bicycle. To keep your balance you must keep moving"
>> - Albert Einstein
>>
>
>
--
----
Thanks
- Mohammad Nour
- LinkedIn: http://www.linkedin.com/in/mnour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein