For api it's fine,
and then we have two impl modules, JPA and JTA?
Cheers,
Arne
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Sonntag, 8. Juli 2012 21:37
An: deltaspike-dev@incubator.apache.org; Mark Struberg
Betreff: Re: AW: AW: [DISCUSS]
@ mark:
that's more or less what we discussed at [1].
regards,
gerhard
[1] http://s.apache.org/3pO
2012/7/9 Arne Limburg arne.limb...@openknowledge.de
For api it's fine,
and then we have two impl modules, JPA and JTA?
Cheers,
Arne
-Ursprüngliche Nachricht-
Von: Romain
We're hardly starting from scratch, much of the DeltaSpike security
design is an improved re-visiting of Seam Security, which has been
actively developed and improved for a number of years. I've also taken
a look at Shiro and while it has many cool features, it also seems to be
missing some
@ romain:
it was part of [1]
regards,
gerhard
[1] http://s.apache.org/P00
2012/7/9 Romain Manni-Bucau rmannibu...@gmail.com
Hi,
maybe i missed some discussion but here is the question: why not using an
existing framework? i particularly think of Shiro which is really fine and
simply
On Jul 9, 2012, at 2:50 AM, Shane Bryzak wrote:
As far as Identity Management related features are concerned, I've
purposefully kept that separate except for the minimal overlap in the
identity model classes. Bolek is holding the reigns for IDM and I'm certain
we'll be discussing it in
well, why i asked was to get started with shiro is 5mn, to get started
with current security module is a bit longer and not always relevant.
Side note: with the existing API (last release) plugging shiro was not so
obvious and integrating shiro with CDI was really more efficient and
simpler than
Sorry for late reply - didn't have much time to look last week. Few comments:
1) I like the approach you took with Query and would like to improve it in
similar direction.
2) I'm not convinced that everything should extend IdmObject. The only benefit
is to reduce number of methods however in
I think there will be few more frameworks to integrate with. JSR 351 is another
example of something that should be consumed.
Bolek
On Jul 9, 2012, at 9:29 AM, Romain Manni-Bucau wrote:
well, why i asked was to get started with shiro is 5mn, to get started
with current security module is a
JSR 351 was mentioned few times in previous discussions as something that we
should keep an eye on. Therefore I would like to let you know that source code
repository related to this effort is now public.
Here is the API draft:
http://java.net/projects/identity-api-spec/sources/git/show
Here
[
https://issues.apache.org/jira/browse/DELTASPIKE-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13409244#comment-13409244
]
Thomas Herzog commented on DELTASPIKE-222:
--
Thank you for implementing it.
:)
[
https://issues.apache.org/jira/browse/DELTASPIKE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13409245#comment-13409245
]
Thomas Herzog commented on DELTASPIKE-230:
--
Thank you, will take a look.
+1 to adding it from me.
XML config is probably the feature (as opposed to enhancement to existing
feature or bug fix) most requested for CDI. I think we need something like
this in DeltaSpike, in order to fulfil our goals.
A non compiled format such as XML (or YAML or ...) makes a lot of
As Romain said, I would expect you to need to turn this on somehow (e.g. enable
extension). If we think a separate module is the easiest way to turn it on,
then I think that makes sense.
On 9 Jul 2012, at 10:20, Mark Struberg wrote:
The main reason why I would prefer a separate module is that
for me a separate module sounds logical but nothing blocks to make it part
of the core since each extension can be activated using
configsourceproviders of DS
- Romain
2012/7/9 Pete Muir pm...@redhat.com
As Romain said, I would expect you to need to turn this on somehow (e.g.
enable
I don't see any problem with doing that, we can just make the idm module
a dependency of the core security module and perhaps use shading to
create a jar that contains all the security libs.
On 09/07/12 23:36, Anil Saldhana wrote:
Was there any thought on the suggestion to split the security
Looks alright. It would probably be good to align with this eventually, but
I have the feeling it won't be final for some time.
On Mon, Jul 9, 2012 at 1:41 AM, Boleslaw Dawidowicz
boleslaw.dawidow...@gmail.com wrote:
JSR 351 was mentioned few times in previous discussions as something that
we
well, we could push it a bit :)
They might be interested to have some connectors as well...
LieGrue,
strub
- Original Message -
From: Jason Porter lightguard...@gmail.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Monday, July 9, 2012 7:19 PM
Subject: Re: JSR 351 Java
back to the original problem about how to integrate with container management.
I found a solution which hopefully works for managing CDI beans with EJB CMT -
even in a 100% portable way.
Please first take a look what I've done in TransactionHelper. The same could
basically be done _inside_ a
this way you'll not control the Tx
- Romain
2012/7/9 Mark Struberg strub...@yahoo.de
Well this should be a candidate for a PersistenceStrategy of @Transactional
The question is how to pickup the right Strategy. This needs some
brainpower still...
LieGrue,
strub
Dough, I do!
As our EjbTransactionHelper is annotated @Stateless, it will have CMT which
closes the EM right after returning from the Server. All subsequently called
EJBs and CDI beans will use the EJB transaction.
Of course, you cannot control rollback and commits but must rely on the EJB
Hi Mark,
I had some other thoughts about it, that might work better, even in nested
executions: We can use JNDI lookups to detect the scenario we are in:
1. If a UserTransaction is available via java:comp/UserTransaction use it
2. If a EJBContext is available via java:comp/EJBContext and no
+1 for the last
- Romain
2012/7/9 Arne Limburg arne.limb...@openknowledge.de
Ihmo we should rename the api to deltaspike-tx-module-api and rename the
PersistenceStrategy to TransactionStrategy
Also it looks strange, the name of the impl should be left as it is. Maybe
we should add an empty
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 into the JNDI, we can believe, we are
within an EJBContainer ;-)
Do you mean, we have no SessionContext in the JNDI in the CMT case, why not?
Don't mix this up with the UserTransaction!
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Montag, 9. Juli 2012 21:44
An: deltaspike-dev@incubator.apache.org
Betreff:
i mean you get an ejbcontext but you cnt use it because it is a bmt one.
- Romain
2012/7/9 Arne Limburg arne.limb...@openknowledge.de
Do you mean, we have no SessionContext in the JNDI in the CMT case, why
not? Don't mix this up with the UserTransaction!
-Ursprüngliche Nachricht-
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 in the EjbTransactionHelper.
Cheers,
Arne
Yes, I have already coded some stuff.
I'll just commit it after the release of 0.3
Cheers,
Arne
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Montag, 9. Juli 2012 22:02
An: deltaspike-dev@incubator.apache.org
Betreff: Re: DS-175 using EJB
Just something to be aware of is that invoking this EJB actually does a fair
bit more than just start a transaction.
- Available java:comp and java:module entries may change, as it will be using
the EjbTransactionHelper JNDI namespace
- This EjbTransactionHelper may have interceptors applied
me too tha's why that's the last try ;)
- Romain
2012/7/10 Stuart Douglas sdoug...@redhat.com
Just something to be aware of is that invoking this EJB actually does a
fair bit more than just start a transaction.
- Available java:comp and java:module entries may change, as it will be
That's really only the last resort.
Regarding the Tx and Security I assume that we will add explicit declarations
on that bean.
Regarding EjbContext and TCCL: Those are freak cases and I agree with you that
they are utterly evil! But I actually do not care much. It's like invoking an
EJB in
30 matches
Mail list logo
