December 2006 - jboss-dev-forums - Jboss List Archives

[Design of EJB 3.0] - Re: java:comp.ejb3 versus java:comp

by bill.burke＠jboss.com

the logic is simple. If there is no tag on the stack, then use the context classloader. EJB containers push/pop their ENC ID on the stack. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995631#3995631 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995631

17 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: java:comp.ejb3 versus java:comp

by bill.burke＠jboss.com

Carlo, that actually will cause problems specifically when you have nested EJB 2/3 invocations View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995630#3995630 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995630

17 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: java:comp.ejb3 versus java:comp

by wolfc

I've committed a multiplexer so that java:comp now looks into both enc factories. This allows progress on TCK to continue. Note that java:comp is a global thing and I don't see how it ('s ObjectFactory) can differentiate between a call coming from web, ejb2 or ejb3. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995621#3995621 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995621

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Moving forward with the profile service mgmt api

by adrian＠jboss.org

This thread is getting too tangled. We need to spawn child threads to deal with single issues. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995618#3995618 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995618

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Moving forward with the profile service mgmt api

by adrian＠jboss.org

"charles.crouch(a)jboss.com" wrote : For Beta2 I would prefer us to concentrate on implementing and testing the simpler mapping cases first and then come back and revisit this in light of the more complicated ones. | That was my conclusion as well, if you read the last paragraph. It was Scott that brought up the issue of more complicated structures. The DataSource isn't that complicated (at least at the front end management level :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995617#3995617 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995617

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Moving forward with the profile service mgmt api

by adrian＠jboss.org

If I understand what it does from the javadoc then yes, I'd say it should be moved to the profile service api? The actual implementation would probably delegate most of the work to the deployer(s), but the deployers or managed object api don't know what a profile or version is. The deployers and managed objects api are primitives used by the profile service. It does bring up one "todo" which is to flesh out the deployment/managed object/attachment identity notions. I haven't come across anything that uses this yet, but I imagine Scott might have to deal with the issue in what he is working on? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995615#3995615 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995615

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Moving forward with the profile service mgmt api

by charles.crouch＠jboss.com

"adrian(a)jboss.org" wrote : "scott.stark(a)jboss.org" wrote : | | The missing mapping is the attachment name, and the corresponding metdata object property(s). In general a ManagedObject properties are going to map to several different metadata objects/properties. | | | | Correct, in fact I'll talk about this in a seperate thread, because this is my major stumbing block. Most of the other stuff I know how to do and it is just a case of doing it, but this requires some extra thought. | Adrian, The new thread you started: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=97767 seems aimed at the more complicated use cases for this mapping. For Beta2 I would prefer us to concentrate on implementing and testing the simpler mapping cases first and then come back and revisit this in light of the more complicated ones. I think having a working implementation out there, even for just the simple case, will help us and others to think about this problem more concretely. If that means interfaces/impls need to change between Beta2 and the next release then so be it. Does the ManagedObject to metadata object/properties mapping for DataSources fall into the "trivial" category? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995614#3995614 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995614

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Moving forward with the profile service mgmt api

by charles.crouch＠jboss.com

"adrian(a)jboss.org" wrote : "charles.crouch(a)jboss.com" wrote : | | 2) Should the org.jboss.deployers.spi.management.ManagementView be updated to use the new ManagedObject api? | | | | The ManagementView looks more like a profile service api than a deployers | or a managed object api? So are you advocating moving it or changing it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995611#3995611 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995611

17 years, 5 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Proxy Object override methods

by adrian＠jboss.org

I've fixed a problem whether the proxy factory wasn't implement equals/hashCode/toString properly when you used java.lang.Object as the parent. The changes can be most easily seen from the new methods in the ProxyTemplate code | public boolean equals(Object obj) | { | if (delegate != null) | { | if (obj != null && obj instanceof Delegate) | obj = ((Delegate) obj).getDelegate(); | return delegate.equals(obj); | } | else | return super.equals(obj); | } | | public int hashCode() | { | if (delegate != null) | return delegate.hashCode(); | else | return super.hashCode(); | } | | public String toString() | { | if (delegate != null) | return delegate.toString(); | else | return super.toString(); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995605#3995605 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995605

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Moving forward with the profile service mgmt api

by adrian＠jboss.org

Further to the FYI, I've updated the ManagedObject api to implement the AOP skeleton. So it should be possible for Scott to intercept changes to the ManagedObject and persist them according to whatever required. e.g. * Persist on every change (simple) * Persist when the user clicks "apply" (implemented a bit like transactions in JavaEE) * Versioning (create a new version on every change or more lazily, e.g. only when the user chooses to save the changes) * etc. In fact, I have a feeling that some of the simpler processing has a lot in common with what POJO Cache does in terms of intercepting changes and allowing atomic updates/rollbacks? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995600#3995600 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995600

17 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums December 2006