I am not so prejudiced to say no spring
No spring config would be an argument, but it seems, that you need no
spring config to use spring data with CDI...
And spring data seems to use a CDI-managed EntityManager, too (which could
be provided using cdi producers).
Cheers,
Arne
Am 19.12.12 23:43
Ok, was not the case last time i looked (probably too early)
So the main point will be the testing: does Spring will test against
the containers we test?
Another point (not blocking) is the fact Spring Data pre-suppose of
transaction context, even if it can be skipped if not in spring it is
sounds *almost* fine for me
@Arne: maybe i got it wrong: you link a handler with an interface?
what is nice with the annotation API is the handler doesn't know about
the interface it proxies
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn:
is it an issue for servicehandler? i don't think so
it is often used to get util classes dynamically created, it is rarely
(i never saw it) decorated directly
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github:
Mark refers to my call stack.
Out of the box this call stack would exist just in OWB, because Weld would
not apply any Interceptors or Decorators...
The question is: Should DS support Interceptors and Decorators on
InvocationHandler beans? My answer would be: yes, if our implementation
shall be
All,
So mostly ok from my perspective. One thing to note:
@InvocationHandlerBinding
public @interface Repository {}
@Repository
public interface MyRepository {
...
}
@Repository @InvocationHandler
public class MyInvocationHandler implements InvocationHandler {
...
}
Why do we have a
+1 for doing it with bindings, I wish I had done it this way the first time
around :-)
On 20 Dec 2012, at 09:36, Romain Manni-Bucau wrote:
yep this one is fine :)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn:
On 20 Dec 2012, at 12:32, John D. Ament wrote:
All,
So mostly ok from my perspective. One thing to note:
@InvocationHandlerBinding
public @interface Repository {}
@Repository
public interface MyRepository {
...
}
@Repository @InvocationHandler
public class MyInvocationHandler
Yes, decorators would be cool, since it would introduce the ability to use
decorators as mixins without having a base class.
For those who are not familiar with mixins, I have coded a gist where
mixins are used to resolve a multiple inheritance scenario [1]
The base idea of mixins is to create
if we don't need it perfect, if we need it we'll just use another name
@DSHandler, @Handler...whatever it is ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/20
If we're still calling the feature ServiceHandler then why not
@ServiceHandler?
On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
if we don't need it perfect, if we need it we'll just use another name
@DSHandler, @Handler...whatever it is ;)
Romain Manni-Bucau
+1 for @ServiceHandler
On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament john.d.am...@gmail.comwrote:
If we're still calling the feature ServiceHandler then why not
@ServiceHandler?
On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
if we don't need it
Hi all,
So just to summarize the current proposal:
- Create a new annotation @ServiceHandlerBinding (in core/api) which will
be placed on on the interface that defines points of the
- Create a new annotation @ServiceHandler (in core/api) (I think based on
below this isn't needed since we have
13 matches
Mail list logo
