What about @Exclude?
Cheers,
Arne
-Ursprüngliche Nachricht-
Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
Gesendet: Freitag, 23. Dezember 2011 21:28
An: deltaspike-dev@incubator.apache.org
Betreff: Re: [DISCUSS] [DELTASPIKE-8] @Veto
+0.5 for @Skip
as mentioned in the
@Exclude could be used in a sentence:
@Exclude(inProjectStage=Production.class)
@Exclude(notInProjectStage=UnitTest.class)
@Exclude(onExpression=...)
-Ursprüngliche Nachricht-
Von: Pete Muir [mailto:pm...@redhat.com]
Gesendet: Dienstag, 3. Januar 2012 20:26
An:
Hi,
+1 for providing a ready-to-use security implementation (i.e. supporting
authentication and @RolesAllowed), but
-1 for not providing integration for other frameworks. At least we should
provide a rich set of extension points for them. There are so many parts of
security that we should not
Hi Pete,
At least that sounds like that what I am thinking of ;-)
-Ursprüngliche Nachricht-
Von: Pete Muir [mailto:pm...@redhat.com]
Gesendet: Montag, 30. Januar 2012 13:58
An: deltaspike-dev@incubator.apache.org
Cc: Shane Bryzak
Betreff: Re: supporting different approaches,...
I think
So basically there are two things to decide:
1. IF we provide an implementation for a certain part (i.e. authorization)
2. if that part is default and can be overridden by alternatives OR if there is
no default and that part is just a module that can be enabled via putting it
into the classpath.
Hi,
My first objection when I saw the CODI feature the first time, was that it
maybe is too basic: When I have to implement the Voter anyway (or my
security-framework of choice delivers it), why should I use @Secured at all? I
mean, what is the REAL benefit of using @Secured over a custom
Hi Shane,
I like that. I guess, it is possible to inject the InjectionPoint into the
@Secures method?
Cheers,
Arne
-Ursprüngliche Nachricht-
Von: Shane Bryzak [mailto:sbry...@redhat.com]
Gesendet: Dienstag, 31. Januar 2012 13:25
An: deltaspike-dev@incubator.apache.org
Cc: Gerhard
-error-view concept (as mentioned in the
ticket we will postpone this part).
furthermore it's used by codi-scopes to avoid a different expiration
behaviour of beans cause by a security check (see the mentioned
AccessDecisionVoterContext).
regards,
gerhard
2012/1/31 Arne Limburg
it on their own.)
regards,
gerhard
2012/2/1 Arne Limburg arne.limb...@openknowledge.de
Basically we are discussing, if the access control logic goes into a
class that implements an interface (which is AccessDecisionVoter) or
into a method that is annotated with @Secures.
Note that both
the EntitaManagers. This needs some exploration how we
can do it.
David
Blevins and Arne Limburg are pretty good into this
stuff. I'm
dreaming
of
kind of the features of EJB standard transations, but
NOT just for
an
EJB
invocation, but @RequestScoped! The first invocation
starts
OK,
but do we really need a container-independent way for JNDI-DataSources? What's
the use case for it?
The user always knows his container and thus his specific JNDI-name.
I think we need an easy way for users to configure different JNDI-DataSources
for different deployment scenarios, like
- a
An: deltaspike-dev@incubator.apache.org
Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
How do you manage it from persistence.xml if you dont repackage your archive as
Mark said?
Personally i agree ;)
- Romain
Le 6 mai 2012 15:06, Arne Limburg arne.limb...@openknowledge.de a écrit :
OK
module features
Not sure it works in a jee container.
- Romain
Le 6 mai 2012 15:26, Arne Limburg arne.limb...@openknowledge.de a écrit :
You could configure your production jta-datasource in the
persistence.xml and add the following bean to your test deployment:
@Exclude(exceptIfProjectStage
-jpa module features
The container will scan persistencecontext annotation with no link with cdi.
Le 6 mai 2012 15:46, Arne Limburg arne.limb...@openknowledge.de a écrit :
If so, what would be the semantic of such definition?
Btw. that classes would only become CDI beans when the deployment
An: deltaspike-dev@incubator.apache.org
Betreff: Re: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
It tomee we create the entitymanagerfactory associated.
Le 6 mai 2012 15:53, Arne Limburg arne.limb...@openknowledge.de a écrit :
OK and the meaning of this annotation at class-level would
: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Yep but an em needs an emf ;)
Le 6 mai 2012 16:05, Arne Limburg arne.limb...@openknowledge.de a écrit :
OK, I think, this is not correct since it expresses a dependency to an
EntityManager and not to an EntityManagerFactory
environment gives a damn about CDI atm :(
LieGrue,
strub
- Original Message -
From: Arne Limburg arne.limb...@openknowledge.de
To: deltaspike-dev@incubator.apache.org
deltaspike-dev@incubator.apache.org
Cc:
Sent: Sunday, May 6, 2012 4:19 PM
Subject: AW: AW: AW: AW: AW: AW: AW
We can think about very basic conversion support, i.e.
Conversion from Object to String: Use toString()
Conversion from String to Object: Use the Constructor that has only one
argument of type String, if available (we would get Support for Integer, Long,
Double, Float, even java.io.File,
Hi Mark,
I can take a look at the XA stuff this week, so that we can add that feature in
the next release.
For me a release in two weeks is fine.
Cheers,
Arne
-Ursprüngliche Nachricht-
Von: Mark Struberg [mailto:strub...@yahoo.de]
Gesendet: Montag, 2. Juli 2012 08:42
An: deltaspike
+1 for 3 columns
-Ursprüngliche Nachricht-
Von: Charles Moulliard [mailto:cmoulli...@gmail.com]
Gesendet: Mittwoch, 4. Juli 2012 09:09
An: deltaspike-dev@incubator.apache.org
Betreff: [suggestion] - DeltaSpike look'n'feel
Hi,
Yesterday night, a interesting and vibrant discussion took
is pretty close to resource local from a tx management point of
view.
- Romain
2012/7/5 Arne Limburg arne.limb...@openknowledge.de
That would come out of the box, when JTA UserTransaction is used or am
I wrong?
Cheers,
Arne
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau
-175] [DELTASPIKE-219] @Transactional
what about resource adapters?
- Romain
2012/7/5 Arne Limburg arne.limb...@openknowledge.de
Ok, you are talking about javax.transaction.TransactionManager and
javax.transaction.Transaction?
The problem with this is, that the way to receive them is very
: Donnerstag, 5. Juli 2012 12:02
An: deltaspike-dev@incubator.apache.org
Betreff: Re: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] @Transactional
So you forget the usage of @Transactional on CMT?
- Romain
2012/7/5 Arne Limburg arne.limb...@openknowledge.de
This stuff is all supported when we use
Hibernate)
* allowed the user to override and specify one strategy
In Seam 3 we did the same.
So I like option 1.
On 5 Jul 2012, at 10:03, Arne Limburg wrote:
Hi,
yesterday I startet working on the JTA support for @Transactional.
My current approach is to implement
An: deltaspike-dev@incubator.apache.org; Mark Struberg
Betreff: Re: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] @Transactional
+1
- Romain
2012/7/8 Mark Struberg strub...@yahoo.de
+1 for JTA module.
LieGrue,
strub
- Original Message -
From: Arne Limburg arne.limb
it.
wdyt?
- Romain
2012/7/8 Arne Limburg arne.limb...@openknowledge.de
OK, but I am still not sure where to split it. While implementing
this, I got the feeling, that the @Transactional stuff should
completely move out of the JPA module. It feeled quite strange that
the JTA module depends
-
From: Arne Limburg arne.limb...@openknowledge.de
To: deltaspike-dev@incubator.apache.org
deltaspike-dev@incubator.apache.org
Cc:
Sent: Sunday, July 8, 2012 8:39 PM
Subject: AW: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]
@Transactional
Yes, sounds good.
The impl of that module
invocationContext.proceed() we
just use
the EJB:
ejbTransaction.invokeTransactional(invocationContext);
Since the EJB will open the transaction for us, we are basically
done ...
Wdyt?
LieGrue,
strub
- Original Message -
From: Arne Limburg
: Re: DS-175 using EJB Transactions for CDI beans in a portable way
yes but not the cmt case
- Romain
2012/7/9 Arne Limburg arne.limb...@openknowledge.de
OK, but I just want to detect if we are in an EJB environment to use
the EjbTransactionHelper...
And if someone puts an EJBContext
Transactions for CDI beans in a portable way
as said earlier ut should often be fine so let's try this way ;)
- Romain
2012/7/9 Arne Limburg arne.limb...@openknowledge.de
OK, you mean the rollback case. We can try it, and if it does not
work, we just have to rely on the container-behavior
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Montag, 9. Juli 2012 21:33
An: deltaspike-dev@incubator.apache.org
Betreff: Re: AW: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] @Transactional
+1 for the last
- Romain
2012/7/9 Arne Limburg arne.limb
harder about what we will finally end up
with.
Will we have a api which has any EE dependency finally? If not it might be
enough to have tx-api + jpa-impl + jta-impl
LieGrue,
strub
- Original Message -
From: Arne Limburg arne.limb...@openknowledge.de
To: deltaspike-dev
Hi,
The license is at least questionable:
http://classroomclipart.com/CRCLcopyright.htm
I cannot see a sentence stating that we may use it for a logo of an open
source framework.
And: We may not remove the watermark!
Cheers,
Arne
Am 09.08.12 09:29 schrieb Charles Moulliard unter
+1 from me, too
Am 11.08.12 17:01 schrieb Mark Struberg unter strub...@yahoo.de:
Hi!
Is it really necessary to have this suppress annotation in all of our
sources?
This stuff is most times even IDE specific, and I honestly see no reason
for having it.
If someone doesn't like the warnings in
Hi,
I think, all this EntityManager(Factory)Producers should be obsolete with
DeltaSpike.
Instead we should provide a deltaspike-way to configure the EntityManager.
The way Seam-Persistence does this, seems a quite good solution:
@Produces
@DeltaSpikeManaged
@RequestScoped
private EntityManager
Hi Mark, all,
Do we need a third module spi for this?
Cheers,
Arne
Am 28.09.12 10:38 schrieb Mark Struberg unter strub...@yahoo.de:
Hi folks!
see DELTASPIKE-274 [1]
Where should I put those helpers?
Is it a good fit for core-api? e.g. in a
org.apache.deltaspike.core.api.util.context
Hi,
Some ideas from my side, too ([1] and [2]). Unfortunately it is in german.
But everyone of you can read the code. We used an advanced version of that
code to build a Spring-CDI-Bridge in a large project. Unfortunately
meanwhile the project is completely migrated to CDI and the code is lost
in
Limburg
Assignee: Arne Limburg
The following beans lead to the following exception:
org.apache.deltaspike.security.api.authorization.SecurityDefinitionExcept
ion: Ambiguous authorizers found for security binding type
@ApplicationScoped
public class SecuredBean
that is the smarter solution
Cheers,
Arne
Am 21.11.12 09:04 schrieb Arne Limburg unter
arne.limb...@openknowledge.de:
Hi Shane,
Hi all,
We should move this discussion over to the list to get more opinions.
The current implementation of our @SecurityBindingType in combination with
@SecurityParameterBinding has
Mark Struberg strub...@yahoo.de
+1
--
Arne Limburg schrieb am Mi., 12. Dez 2012 23:38 PST:
Hi,
What do you think of supporting post-method-authorization (see [1]) in
addition to our current pre-method-authorization?
I just started coding
the
information.
So we where only able to determine if the user was allowed to read the
person information after we had read it frmo the database and matched
the
category.
So
+1
Regards
Rudy
On 13 December 2012 09:26, Arne Limburg arne.limb...@openknowledge.de
wrote:
Hi Jean-Louis
://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/13 Arne Limburg arne.limb...@openknowledge.de:
Feel free to make a suggestion.
What about
@SecuredResult
or
@SecuredReturnValue
?
Am 13.12.12 10:50 schrieb Gerhard
explicit
but i wouldn't something not symmetrical
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/13 Arne Limburg arne.limb...@openknowledge.de:
@Secures sounds cool
/rmannibucau
2012/12/13 Arne Limburg arne.limb...@openknowledge.de:
Btw. are we talking about another name for @Secures or for @Result?
Thinking about @Secures it should not be too confusing (talking with
myself here ;-) ), since the developer knows, if he needs the result for
evaluation
...@yahoo.de:
what about @Secures and @SecuresResult?
These are 2 different inteceptors, right?
A method could also have both
@Secures and
@SecuresResult
LieGrue,
strub
From: Arne Limburg arne.limb...@openknowledge.de
To: deltaspike-dev@incubator.apache.org
the method and
afterwards
see that he doesn't has access (group 1 )
regards
Rudy
On 13 December 2012 12:23, Arne Limburg
arne.limb...@openknowledge.dewrote:
I would have put it into the same interceptor, but that is an
implementation detail.
And it makes no sense to make the same authorizer
and @SecuresResult?
These are 2 different inteceptors, right?
A method could also have both
@Secures and
@SecuresResult
LieGrue,
strub
From: Arne Limburg arne.limb...@openknowledge.de
To: deltaspike-dev@incubator.apache.org
deltaspike
) and second the other
solution has the word Result twice in the declaration: once in the
method annotation and once in the parameter annotation.
Cheers,
Arne
Am 13.12.12 21:09 schrieb Arne Limburg unter
arne.limb...@openknowledge.de:
Hi Mark,
I have coded a gist to lookup an address from
together, i.e. The word Result in the
method-level annotation AND the parameter-level annotation looks ugly.
Cheers,
Arne
Am 14.12.12 18:15 schrieb Gerhard Petracek unter
gerhard.petra...@gmail.com:
-1 for @Result (as a name), because the name is too generic.
regards,
gerhard
2012/12/14 Arne Limburg
://github.com/rmannibucau
2012/12/15 Arne Limburg arne.limb...@openknowledge.de:
You mean to the second list?
I like that, because it contains the java keyword return
With this I would feel comfortable with 1.C
What do the others think?
Am 15.12.12 21:51 schrieb Gerhard Petracek unter
...@gmail.com:
+1 for @SecuredOnReturn or @SecuredResult as an additional annotation (-
no api changes for @Secures).
regards,
gerhard
2012/12/15 Arne Limburg arne.limb...@openknowledge.de
I've updated the gist [1] (see ReadingAuthorizer0) to see how it works
out.
If we leave out
-method authorization should
take place or post-method invocation.
Am 15.12.12 22:44 schrieb Gerhard Petracek unter
gerhard.petra...@gmail.com:
hi arne,
adding a value to @Secures (e.g. AFTER_INVOCATION) would be such a change.
regards,
gerhard
2012/12/15 Arne Limburg arne.limb
mention backward compatibility at all.
(imo changing the api of @Secures for this feature is just not needed...)
regards,
gerhard
2012/12/15 Arne Limburg arne.limb...@openknowledge.de
Hence I supposted to use BEFORE_INVOCATION as default value such that
existing applications would continue
from my iPhone
On Dec 15, 2012, at 14:29, Gerhard Petracek gerhard.petra...@gmail.com
wrote:
+1 for @SecuredOnReturn or @SecuredResult as an additional annotation
(-
no api changes for @Secures).
regards,
gerhard
2012/12/15 Arne Limburg arne.limb...@openknowledge.de
I've updated
:)
Sent from my iPhone
On Dec 15, 2012, at 15:13, Arne Limburg arne.limb...@openknowledge.de
wrote:
Hi Jason,
We are checking the return value and if the user is not allowed to see
it,
we reject it, so basically we ARE securing the return valueŠ
About your objections for the void method
During the discussion about DELTASPIKE-298 on irc we (basically Mark, Romain
and me, as I remember) found two other features to be useful:
The first feature is EL-based security rules via annotations (see [1]) and the
second is collection filtering(see [2]). Any objections that I implement this
2012/12/19 Arne Limburg arne.limb...@openknowledge.de:
Did you notice that Spring-Data ships with a CDI extension?
So if we want to implement this, the core question for me is, how does
our
implementation distinguish from spring-data?
Cheers,
Arne
Am 19.12.12 23:33 schrieb Gerhard Petracek
support for
interceptors and decorators for CDI-annotated classes, but not for
BeanT which get added via extensions nor even producer methods and
fields :/
Of course OWB does it, but it would be not portable...
LieGrue,
strub
- Original Message -
From: Arne Limburg arne.limb
producer methods and
fields :/
Of course OWB does it, but it would be not portable...
LieGrue,
strub
- Original Message -
From: Arne Limburg arne.limb...@openknowledge.de
To: deltaspike-dev@incubator.apache.org
deltaspike-dev@incubator.apache.org
Cc:
Sent: Thursday
Hi Hantsy,
In general you could write an extension that modifies the AnnotatedType to
remove the annotation that declares the interceptor binding.
@all We should think about supporting @BypassInterceptors in Deltaspike,
wdyt?
Not that I like this feature of Seam 2 that much (imho it works
case
for it, then we can consider it, but I don't want to start adding
things to
DeltaSpike without clearly defined use cases.
On Sat, Dec 29, 2012 at 3:13 AM, Arne Limburg
arne.limb...@openknowledge.de
wrote:
Hi Hantsy,
In general you could write an extension that modifies
+1
Am 01.01.13 20:49 schrieb Mark Struberg unter strub...@yahoo.de:
+1
LieGrue,
strub
- Original Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Tuesday, January 1, 2013 7:15 PM
Subject: Re: Deltaspike Web site -
+1 for repository, from me too
Gesendet mit meinem HTC
- Reply message -
Von: Thomas Andraschko andraschko.tho...@gmail.com
An: deltaspike-dev@incubator.apache.org deltaspike-dev@incubator.apache.org
Betreff: cdi-query, no news?
Datum: Di., Mär. 12, 2013 20:38
+1 repository! :) Query
Imho when we think about JSF validation we don't need to mimic existing
features of JSF 2, but we have to see where features are missing.
I.e. BVAL 1.1 will contain method-validation, but JSF completely missed to
integrate it. This is where we should fill the gap.
I am thinking about something
[
https://issues.apache.org/jira/browse/DELTASPIKE-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arne Limburg updated DELTASPIKE-175:
Summary: @Transactional for EntityTransaction (was: @Transactional
Arne Limburg created DELTASPIKE-219:
---
Summary: @Transactional for JTA UserTransaction
Key: DELTASPIKE-219
URL: https://issues.apache.org/jira/browse/DELTASPIKE-219
Project: DeltaSpike
[
https://issues.apache.org/jira/browse/DELTASPIKE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arne Limburg resolved DELTASPIKE-291.
-
Resolution: Duplicate
@SecurityBindings don't respect parameter types
[
https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arne Limburg updated DELTASPIKE-292:
Issue Type: Improvement (was: Bug)
@SecurityBindings don't respect parameter
[
https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501752#comment-13501752
]
Arne Limburg commented on DELTASPIKE-292:
-
In my scenario
[
https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503430#comment-13503430
]
Arne Limburg commented on DELTASPIKE-292:
-
So, Shane, which concrete
Arne Limburg created DELTASPIKE-298:
---
Summary: Post-Method-Authorizer
Key: DELTASPIKE-298
URL: https://issues.apache.org/jira/browse/DELTASPIKE-298
Project: DeltaSpike
Issue Type
Arne Limburg created DELTASPIKE-305:
---
Summary: Support @Filters in addition to @Secures
Key: DELTASPIKE-305
URL: https://issues.apache.org/jira/browse/DELTASPIKE-305
Project: DeltaSpike
[
https://issues.apache.org/jira/browse/DELTASPIKE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580873#comment-13580873
]
Arne Limburg commented on DELTASPIKE-315:
-
Imho we should work on a more
[
https://issues.apache.org/jira/browse/DELTASPIKE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581478#comment-13581478
]
Arne Limburg commented on DELTASPIKE-315:
-
In addition we need the ability
[
https://issues.apache.org/jira/browse/DELTASPIKE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13584123#comment-13584123
]
Arne Limburg commented on DELTASPIKE-315:
-
About the implementation: It seems
[
https://issues.apache.org/jira/browse/DELTASPIKE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13584153#comment-13584153
]
Arne Limburg commented on DELTASPIKE-315:
-
We collect all the qualifiers
76 matches
Mail list logo
