Indeed, that could be a way forward. Almost forgot about it ^^
LieGrue, strub > On Monday, 9 May 2016, 21:06, Romain Manni-Bucau <[email protected]> > wrote: > > @Mark: why not using/enhancing [proxy2]? => > http://svn.apache.org/repos/asf/commons/proper/proxy/trunk/asm/src/main/java/org/apache/commons/proxy2/asm/ASMProxyFactory.java > > this is designed to be reusable compared to ds > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> | JavaEE Factory > <https://javaeefactory-rmannibucau.rhcloud.com> > > > 2016-05-09 20:42 GMT+02:00 Mark Struberg <[email protected]>: > >> Maybe I have something else in mind or the ds proxy is not yet there - or >> maybe never will be... >> >> >> I thought to use it kind like java.lang.reflect proxy. >> >> So I do not ned any BeanManager in my case. >> >> >> Let me explain a bit. >> >> I'd like to have something like java.lang.reflect Proxy but with a >> subclassing proxy and not a reflection proxy. >> >> >> The main problem arises with serialisation. >> >> The problem is that you can only have a single class with the same name >> obviously ;) >> When serialising it over, you have to either find an existing proxy class >> or create the class on the fly while de-serialising on the other side. >> Means the class name must follow a static rule or you are lost (as >> javassist which ends up trashing the ClassLoader with new classes each >> time). >> >> >> An easy way to achieve this is to work like jlr.Proxy. It always only >> creates the same proxy class bytecode for the same Set of interfaces. >> But you can use this proxy class for different behaviour, because you can >> simply use it with different InvocationHandlers. >> >> For serialisation you only have to send the list of implemented interface >> names + the InvocationHandler (which always needs to be Serializable of >> course). >> >> Having only a single proxy class per original class means that each method >> invocation must get treated the same. And all of them need to be invoked >> via the InvocationHandler. >> >> >> Another way would be to create specialised proxy classes (like OWB) for >> each InvocationHandler. BUT that would need distinct - but reproducible - >> proxy class names. >> >> In OWB we store the proxy class somewhere where you can find it again - in >> the Bean ;) >> >> >> Depending on those 2 flavours you get an API with >> >> >> 1.) a separate createProxyClass(Class, interface[]) and >> newProxyInstance(InvocationHandler handler) >> >> OR >> >> >> 2.) createProxyClass(Class, interfaces, NAME, InvocationHandler). >> >> From looking at the current DS proxy code it looks a bit like a mixture >> between both modes. >> >> >> What is the overall design goal we aim for? >> >> LieGrue, >> strub >> >> >> On Monday, 9 May 2016, 15:12, Thomas Andraschko < >> [email protected]> wrote: >> > >> > >> >1) exactly, it was designed for that purpose. Therefor we always pass >> InvocationHandler in the constructor. >> > Do you need different InvocationHandler for different methods? >> > >> >| -> We imo should split the creation of the proxy class from the >> creation of the proxy instance. >> > >> > >> > >> >It's completely splitted currently. DeltaSpikeProxyFactory contains > only >> the proxy class creation. proxy instance creation is always done outside. >> > >> > >> > >> >2) it's ok for me but please let me review before commiting > something. >> > For me it's only important that every test is working fine > (proxy >> module, partial bean, data and jsf module). >> > >> > >> >The beanManager is required to check for interceptor bindings. We must >> proxy every method if interceptors are used. Otherwise we only proxy the >> "delegate methods". >> > >> > >> >| Maybe we could introduce a new API which just exposes a native java >> subclass proxy to retain backward compat? >> > >> >What do you mean exactly? >> > >> > >> > >> > >> > >> > >> > >> > >> >2016-05-09 14:55 GMT+02:00 Mark Struberg > <[email protected]>: >> > >> >Having a really hard time to grok it right now and think we can improve >> quite a few things. >> >> >> >>1.) It atm only works with exactly a single InvocationHandler. > That's >> currently a problem in my case >> >>-> We imo should split the creation of the proxy class from the > creation >> of the proxy instance. >> >> >> >> >> >>2.) It's hard to get what is in the API and what is an impl > detail. >> >> >> >>-> We should create an interface and move the impl stuff to an > internal >> class. >> >> >> >>Any objections? >> >> >> >>How freely can I change the API? >> >>Is it only important that our internal tests and the JPA stuff is >> working fine again, or do I need to care about native usages as well? >> >> >> >> >> >>I also don't get why the current DeltaSpikeProxyFactory needs > the >> BeanManager as parameter? >> >>Maybe we could introduce a new API which just exposes a native java >> subclass proxy to retain backward compat? >> >>In any case we miss a lot of JavaDocs! >> >> >> >> >> >>LieGrue, >> >>strub >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> On Monday, 9 May 2016, 13:47, Thomas Andraschko < >> [email protected]> wrote: >> >>> > a) yup >> >>> b) if it's unused, why not ;) Should be just an old case, > it was >> refactored >> >>> many times during developed because of some AppServers / > versions. >> >>> c) yup, feel free to align it :) >> >>> >> >>> >> >>> 2016-05-09 13:30 GMT+02:00 John D. Ament > <[email protected]>: >> >>> >> >>>> On Mon, May 9, 2016 at 7:24 AM Mark Struberg >> >>> <[email protected]> >> >>>> wrote: >> >>>> >> >>>> > a.)DeltaSpikeProxyFactory totally misses docs it > sems. Or did I >> miss >> >>>> > something? >> >>>> > >> >>>> >> >>>> The current docs are a step up from about two months ago > when the >> only >> >>>> thing on the doc page was "TODO: Document the proxy > module" or >> >>> something >> >>>> along those lines. >> >>>> >> >>>> Yes, there's still stuff missing. >> >>>> >> >>>> >> >>>> > >> >>>> > b.) there are methods which are imo questionable, > e.g. >> >>>> > >> >>>> > public <T> Class<T> > getProxyClass(BeanManager beanManager, >> >>> Class<T> >> >>>> > targetClass) >> >>>> > { >> >>>> > return getProxyClass(beanManager, targetClass, >> >>>> > DummyInvocationHandler.class); >> >>>> > } >> >>>> > >> >>>> > >> >>>> > what do we need this for? Can I simply remove it? >> >>>> > The DummyInvocationHandler just returns null. > Without calling the >> >>> proxied >> >>>> > instance. It's basically a no-op impl. Why do we > need this? >> >>>> > >> >>>> >> >>>> This smells like a strangle that wasn't completed. > I'd say if it >> >>> can be >> >>>> delegated down, lets remove it. Better is if its only > used in tests. >> >>>> >> >>>> >> >>>> > >> >>>> > >> >>>> > c.) The ordering of the methods are mixed. Imo all > public methods >> >>> should >> >>>> > be on top, protected and private at the bottom. > Really hard to read >> >>> atm. >> >>>> > >> >>>> >> >>>> +1 >> >>>> >> >>>> >> >>>> > >> >>>> > Any thoughts? >> >>>> > >> >>>> > LieGrue, >> >>>> > strub >> >>>> > >> >>>> >> >>> >> >> >> > >> > >> > >> >
