springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Type 3 IoC support

[Colin S. <col...@ex...>]

Thanks Juergen. I actually did not have time to look at the Spring code 
yesterday, but just assumed the List to String[] match would work, since 
the DTD (explicitly) said a List to array conversion would be done 
automatically. Of course, conversion once matched, and the matching 
itself (in the new code) are not quie the same thing :-)

I'll give the code a try later...


jürgen höller [werk3AT] wrote:

>Colin,
> 
>The problem is that you tried to pass a <list> into a String[] constructor. The generic constructor argument matcher did not recognize that as compatible, therefore it continued with the next constructor. If you explicitly specified an index, the matching was not by type and therefore worked.
> 
>I've just added a check to match an array argument with a List value, and also a unit test that instantiates a parent and child ClassPathXmlApplicationContext (without explicit indexes specified).
> 
>The exception "2 constructor arguments specified but just constructor with 1 argument found" was a bit misleading, as it rather indicates "no matching constructor found" (with at least the given number of arguments). I've already changed its wording.
> 
>So please grab the latest CVS snapshot and happily instantiate ClassPathXmlApplicationContexts for whatever reason :-)
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Fr 14.11.2003 23:55
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Type 3 IoC support
>
>
>
>There is definitely an issue. When trying to use the two argument
>constructor, of which there is only one, I get
>
>; nested exception is:
>    org.springframework.beans.factory.BeanDefinitionStoreException: 2
>constructor arguments specified but just constructor with 1 arguments
>found in bean 'packaging-context'
>org.springframework.beans.factory.BeanDefinitionStoreException: 2
>constructor arguments specified but just constructor with 1 arguments
>found in bean 'packaging-context'
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.autowireConstructor(AbstractBeanFactory.java:444)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:352)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.getSharedInstance(AbstractBeanFactory.java:274)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:203)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.resolveReference(AbstractBeanFactory.java:717)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.resolveValueIfNecessary(AbstractBeanFactory.java:688)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.autowireConstructor(AbstractBeanFactory.java:418)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:352)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.getSharedInstance(AbstractBeanFactory.java:274)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:203)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.resolveReference(AbstractBeanFactory.java:717)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.resolveValueIfNecessary(AbstractBeanFactory.java:688)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.autowireConstructor(AbstractBeanFactory.java:418)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:352)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.getSharedInstance(AbstractBeanFactory.java:274)
>    at
>org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:203)
>    at
>org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:468)
>    at
>org.springframework.context.support.AbstractApplicationContext.preInstantiateSingletons(AbstractApplicationContext.java:354)
>    at
>org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:240)
>
>However, if I add index="0" and index="1" respectively, to the two
>constructor arguments, then it has no problem constructing it. Now my
>understanding is that the indexes shouldn't be necessary in this
>(non-ambiguous) case.
>
>Again, I'll probably be able to look at this on Mon. or Tues. if nobody
>else has by then.
>
>Regards,
>Colin
>
>
>Colin Sampaleanu wrote:
>
>  
>
>>Juergen,
>>
>>I think the constructor resolution may not be quite right. The
>>following bean entry fails:
>> <bean id="data-access-context"
>>        
>>class="org.springframework.context.support.ClassPathXmlApplicationContext">
>>
>>   <constructor-arg>
>>     <list><value>/data-access-applicationContext.xml</value></list>
>>      </constructor-arg>
>> </bean>
>>with
>>       ...
>>      
>>org.springframework.beans.factory.UnsatisfiedDependencyException: Bean w
>>ith name 'data-access-context' has an unsatisfied dependency expressed
>>through c
>>onstructor argument with index 0 of type [java.lang.String]
>>
>>Where it should be able to resolve to the constructor which takes an
>>array of Strings. Now I will probably look into this myself later, but
>>wanted to give you a heads up in case you know offhand what the
>>problem is. For the time being, I am in a hurry, and will just feed
>>the one string I need to the constructor which takes one string.
>>
>>As to why I am trying to construct a context inside a context, I am
>>doing some interesting coding; we can get into that later when
>>everything is working :-)
>>    
>>

RE: [Springframework-developer] AOP API finalization

[Kopylenko, D. <dko...@ac...>]

+1 for Advised despite potential JBoss "legal threat" :-)))

Dmitriy.

-----Original Message-----
From: Rod Johnson
To: spr...@li...
Cc: Bob Lee; renaud
Sent: 11/14/2003 5:54 PM
Subject: [Springframework-developer] AOP API finalization

All,

I've made all the proposed changes (although not committed them) and I'm
very happy with how it looks. Ah, the wondering of refactoring tools. 5
years ago I would have spent the best part of a day doing that. And
probably
not have had comprehensive tests to prove that I was done.

One last issue and I promise I'll shut up about AOP...

The ProxyConfig interface. I wonder whether it might be nicer and more
consistent to rename it Advised. (Now that it holds multiple advisors.)

Pros:

- More elegant and consistent with core interfaces(?)


Cons:

- JBoss uses this name too, which may be a bit confusing. (Or may cause
them
to threaten us with a lawsuit...[joke]).

PLEASE feedback if you want to influence that decision. Otherwise I will
decide, and I'm feeling about 50/50 about it. I guess no feedback would
make
me more likely to leave it alone.

Regards,
Rod




-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Type 3 IoC support

[<jue...@we...>]

Colin,
=20
The problem is that you tried to pass a <list> into a String[] =
constructor. The generic constructor argument matcher did not recognize =
that as compatible, therefore it continued with the next constructor. If =
you explicitly specified an index, the matching was not by type and =
therefore worked.
=20
I've just added a check to match an array argument with a List value, =
and also a unit test that instantiates a parent and child =
ClassPathXmlApplicationContext (without explicit indexes specified).
=20
The exception "2 constructor arguments specified but just constructor =
with 1 argument found" was a bit misleading, as it rather indicates "no =
matching constructor found" (with at least the given number of =
arguments). I've already changed its wording.
=20
So please grab the latest CVS snapshot and happily instantiate =
ClassPathXmlApplicationContexts for whatever reason :-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Fr 14.11.2003 23:55
An: spr...@li...
Betreff: Re: [Springframework-developer] Type 3 IoC support



There is definitely an issue. When trying to use the two argument
constructor, of which there is only one, I get

; nested exception is:
    org.springframework.beans.factory.BeanDefinitionStoreException: 2
constructor arguments specified but just constructor with 1 arguments
found in bean 'packaging-context'
org.springframework.beans.factory.BeanDefinitionStoreException: 2
constructor arguments specified but just constructor with 1 arguments
found in bean 'packaging-context'
    at
org.springframework.beans.factory.support.AbstractBeanFactory.autowireCon=
structor(AbstractBeanFactory.java:444)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(=
AbstractBeanFactory.java:352)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getSharedIn=
stance(AbstractBeanFactory.java:274)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs=
tractBeanFactory.java:203)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.resolveRefe=
rence(AbstractBeanFactory.java:717)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.resolveValu=
eIfNecessary(AbstractBeanFactory.java:688)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.autowireCon=
structor(AbstractBeanFactory.java:418)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(=
AbstractBeanFactory.java:352)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getSharedIn=
stance(AbstractBeanFactory.java:274)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs=
tractBeanFactory.java:203)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.resolveRefe=
rence(AbstractBeanFactory.java:717)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.resolveValu=
eIfNecessary(AbstractBeanFactory.java:688)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.autowireCon=
structor(AbstractBeanFactory.java:418)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(=
AbstractBeanFactory.java:352)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getSharedIn=
stance(AbstractBeanFactory.java:274)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs=
tractBeanFactory.java:203)
    at
org.springframework.context.support.AbstractApplicationContext.getBean(Ab=
stractApplicationContext.java:468)
    at
org.springframework.context.support.AbstractApplicationContext.preInstant=
iateSingletons(AbstractApplicationContext.java:354)
    at
org.springframework.context.support.AbstractApplicationContext.refresh(Ab=
stractApplicationContext.java:240)

However, if I add index=3D"0" and index=3D"1" respectively, to the two
constructor arguments, then it has no problem constructing it. Now my
understanding is that the indexes shouldn't be necessary in this
(non-ambiguous) case.

Again, I'll probably be able to look at this on Mon. or Tues. if nobody
else has by then.

Regards,
Colin


Colin Sampaleanu wrote:

> Juergen,
>
> I think the constructor resolution may not be quite right. The
> following bean entry fails:
>  <bean id=3D"data-access-context"
>        =20
> =
class=3D"org.springframework.context.support.ClassPathXmlApplicationConte=
xt">
>
>    <constructor-arg>
>      <list><value>/data-access-applicationContext.xml</value></list>
>       </constructor-arg>
>  </bean>
> with
>        ...
>      =20
> org.springframework.beans.factory.UnsatisfiedDependencyException: Bean =
w
> ith name 'data-access-context' has an unsatisfied dependency expressed
> through c
> onstructor argument with index 0 of type [java.lang.String]
>
> Where it should be able to resolve to the constructor which takes an
> array of Strings. Now I will probably look into this myself later, but
> wanted to give you a heads up in case you know offhand what the
> problem is. For the time being, I am in a hurry, and will just feed
> the one string I need to the constructor which takes one string.
>
> As to why I am trying to construct a context inside a context, I am
> doing some interesting coding; we can get into that later when
> everything is working :-)

[Springframework-developer] Test (please ignore)

[Bob L. <cra...@cr...>]

Test.

Re: [Springframework-developer] Type 3 IoC support

[Colin S. <col...@ex...>]

There is definitely an issue. When trying to use the two argument 
constructor, of which there is only one, I get

; nested exception is:
    org.springframework.beans.factory.BeanDefinitionStoreException: 2 
constructor arguments specified but just constructor with 1 arguments 
found in bean 'packaging-context'
org.springframework.beans.factory.BeanDefinitionStoreException: 2 
constructor arguments specified but just constructor with 1 arguments 
found in bean 'packaging-context'
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.autowireConstructor(AbstractBeanFactory.java:444)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:352)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.getSharedInstance(AbstractBeanFactory.java:274)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:203)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.resolveReference(AbstractBeanFactory.java:717)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.resolveValueIfNecessary(AbstractBeanFactory.java:688)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.autowireConstructor(AbstractBeanFactory.java:418)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:352)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.getSharedInstance(AbstractBeanFactory.java:274)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:203)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.resolveReference(AbstractBeanFactory.java:717)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.resolveValueIfNecessary(AbstractBeanFactory.java:688)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.autowireConstructor(AbstractBeanFactory.java:418)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:352)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.getSharedInstance(AbstractBeanFactory.java:274)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:203)
    at 
org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:468)
    at 
org.springframework.context.support.AbstractApplicationContext.preInstantiateSingletons(AbstractApplicationContext.java:354)
    at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:240)

However, if I add index="0" and index="1" respectively, to the two 
constructor arguments, then it has no problem constructing it. Now my 
understanding is that the indexes shouldn't be necessary in this 
(non-ambiguous) case.

Again, I'll probably be able to look at this on Mon. or Tues. if nobody 
else has by then.

Regards,
Colin


Colin Sampaleanu wrote:

> Juergen,
>
> I think the constructor resolution may not be quite right. The 
> following bean entry fails:
>  <bean id="data-access-context"
>          
> class="org.springframework.context.support.ClassPathXmlApplicationContext"> 
>
>    <constructor-arg>
>      <list><value>/data-access-applicationContext.xml</value></list>
>       </constructor-arg>
>  </bean>
> with
>        ...
>        
> org.springframework.beans.factory.UnsatisfiedDependencyException: Bean w
> ith name 'data-access-context' has an unsatisfied dependency expressed 
> through c
> onstructor argument with index 0 of type [java.lang.String]
>
> Where it should be able to resolve to the constructor which takes an 
> array of Strings. Now I will probably look into this myself later, but 
> wanted to give you a heads up in case you know offhand what the 
> problem is. For the time being, I am in a hurry, and will just feed 
> the one string I need to the constructor which takes one string.
>
> As to why I am trying to construct a context inside a context, I am 
> doing some interesting coding; we can get into that later when 
> everything is working :-)
>
>
>
>
> jürgen höller [werk3AT] wrote:
>
>> Due to popular demand ;-), I've just added a constructor detection 
>> algorithm that replaces the former single-constructor requirement. It 
>> works similar to Pico's constructor resolution: It starts with the 
>> "greediest" constructor, i.e. the one with the most arguments, and 
>> then falls back to the next one in the greediness order if it can't 
>> resolve all dependencies. If there are multiple constructors with the 
>> same number of arguments, all of them are tried; the first one that 
>> can be satisfied will be used.
>>
>> Of course, all "constructor-arg" hints will be applied in any case; 
>> autowire="constructor" will just resolve all remaining arguments. A 
>> few sanity checks are performed, like only resolving a constructor 
>> that has at least as many arguments as there are "constructor-arg" tags.
>>
>> This should be sufficiently powerful to be able to address *any* 
>> constructor. For example, if there are constructors 
>> (DataSource,TestBean) and (TestBean,DataSource), autowiring or 
>> generic "constructor-arg" tags with a DataSource and a TestBean will 
>> use an undetermined one of the two (generally, the first one 
>> according to the order of Class.getConstructors, which can vary from 
>> JVM to JVM). If you need a specific one, use "constructor-arg" with 
>> corresponding "index" attributes.
>>
>> If multiple constructors with the same number and position of 
>> arguments match, like (DataSource,TestBean) and (DataSource,Object), 
>> a type difference weight algorithm will kick in. It will determine a 
>> weight for the difference between the argument types and the actual 
>> arguments, prefering more exact matches - (DataSource,TestBean) in 
>> case of DataSource and TestBean args, in the above case.
>>
>> BTW, Rob, Pico still advocates the single constructor paradigm. Their 
>> introduction (http://www.picocontainer.org/introduction.html) still 
>> states that Pico components need to have one single constructor, 
>> while their FAQ talk about resolving an appropriate constructor 
>> (http://www.picocontainer.org/faq.html#many-constructors) - so much 
>> for documentation consistency.
>>
>> I consider our Type 3 IoC support now more capable than Pico's: We 
>> also support arrays, lists, and maps of components or parameters 
>> going into constructor arguments, just like we do with bean 
>> properties. Effectively, bean-style Type 2 IoC vs constructor-style 
>> Type 3 IoC is now the application developer's choice when using a 
>> Spring bean factory. Note that the Pico guys have already stated that 
>> they will *not* support Type 2 IoC any time soon but just their 
>> flavour of Type 3.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On Behalf
>> Of Rob Butler
>> Sent: Sunday, November 09, 2003 11:47 PM
>> To: spr...@li...
>> Subject: [[W3-SPAM]] - Re: [Springframework-developer] Type 3 IoC
>> support - Email found in subject
>>
>>
>> I would agree this is very good stuff!  This is especially useful if you
>> want to use a third party api but they do not conform to javabean style
>> no-arg contructors.  However by limiting the implementation to only 
>> support
>> classes that have a single constructor you are all but defeating its
>> usefulness.
>>
>> The only reason you would be forced to use / need this kind of a 
>> feature is
>> if you don't have access to the code to implement a no-arg 
>> constructor.  For
>> that same reason, you cannot modify the code to only have 1 
>> constructor. I
>> would wager that most classes that do provide a constructor which 
>> takes args
>> also supply variations that take more / less args.  So if multiple
>> constructors are not supported, it's probably not going to be very 
>> useful.
>>
>> Spring is already amazing, and you guys just keep making it better.  
>> Good
>> work!
>>
>> Later
>> Rob
>>  
>>
>>>> The only limitation is that constructor-wired components are just 
>>>> allowed
>>>>     
>>>
>> to have one single constructor. This is also what Pico recommends, 
>> although
>> they have some heuristic kind of constructor choice in case of multiple
>> constructors now. I guess we can limit this to one single constructor 
>> for
>> the time being. Of course, standard beans defined without
>> autowire="constructor" or "constructor-arg" tags can still have any 
>> number
>> of constructors, the only requirement being that they must provide a 
>> no-arg
>> constructor.
>>  
>>
>>>>     
>>>
>>> One way you could do it (which you probably thought of) is by allowing
>>> the deployer to specify, in the case of the indexed variant, an 
>>> optional
>>> 'type' attribute which specifies the real type (in the receiving 
>>> object)
>>> of that constructor argument. This would allow the appropriate
>>> constructor to be picked without any ambiguity. I don't know if this is
>>> worth doing or not, but on the other hand, if you are going to support
>>> constructors at all, it's somewhat arbitrary to stop at 1 if you can
>>> figure out a relatively simple (albeit wordy) way to support the
>>> multiple case.
>>>
>>> Even if that is not done, maybe it is worth it supporting the special
>>> case of classes which have a no-arg constructor, and one other
>>> constructor with one or more args. That's also a pretty common case, 
>>> and
>>> easy to support.
>>>
>>> Regards,
>>> Colin
>>>    
>>

[Springframework-developer] AOP API finalization

[Rod J. <rod...@in...>]

All,

I've made all the proposed changes (although not committed them) and I'm
very happy with how it looks. Ah, the wondering of refactoring tools. 5
years ago I would have spent the best part of a day doing that. And probably
not have had comprehensive tests to prove that I was done.

One last issue and I promise I'll shut up about AOP...

The ProxyConfig interface. I wonder whether it might be nicer and more
consistent to rename it Advised. (Now that it holds multiple advisors.)

Pros:

- More elegant and consistent with core interfaces(?)


Cons:

- JBoss uses this name too, which may be a bit confusing. (Or may cause them
to threaten us with a lawsuit...[joke]).

PLEASE feedback if you want to influence that decision. Otherwise I will
decide, and I'm feeling about 50/50 about it. I guess no feedback would make
me more likely to leave it alone.

Regards,
Rod

Re: [Springframework-developer] AOP API finalization

[Rod J. <rod...@in...>]

I'm just making these changes now, although I won't check them in
immediately in case there are any objections.

It seems that there should be one minor naming change:

InterceptionAdvisor --> InterceptionAroundAdvisor

It's a bit of a mouthful, but it it is necessary information I think if
we're going to accommodate different modes of advice in future.

There will be an interface called InterceptionAdvisor, a new superclass that
identifies any advisor that works through interception. (Mainly for
implementation reasons, rather than for application developers.) My proposal
below of making InterceptionAroundAdvisor the superclass of
InterceptionAdvisor was questionable because the superclass should have a
more specific name.

Regards,
Rod


----- Original Message ----- 
From: "Rod Johnson" <rod...@in...>
To: <spr...@li...>
Cc: "renaud" <re...@ao...>; "Bob Lee" <cra...@cr...>
Sent: Friday, November 14, 2003 4:52 PM
Subject: Re: [Springframework-developer] AOP API finalization


> All,
>
> Let me begin with an apology for those of you who may be getting a bit
bored
> with arcane debates about AOP... Spring will continue to provide
declarative
> transaction management in the present simple way, without the need to work
> with the AOP interfaces and framework directly. And we will provide even
> easier .NET style automatic "enterprise services" for transactions etc. in
> the future. So most users likely won't need to work with this lower level
> stuff. However, it's still important to get it right.
>
>
> Now the AOP code is committed and no one has screamed about it (which I
take
> to mean that everyone who's interested agrees it's on the right track :-),
I
> think the hard work has been done. What I'm talking about there is
> essentially minor refactoring that doesn't change the way things work.
>
> However, I think there are a few things still to do before we go to final:
>
> 1. I think Renaud is right regarding Advice --> Advisor. (See the rest of
> this email for the discussion.) So I propose that we rename anything with
> the suffix Advice to Advisor. (Affects interfaces and advice
superclasses.)
>
> PLEASE feedback your views on this--particularly, if you object strongly.
>
> 2. I think it's important that we're not tied into interception.
> Interception is one way of implementing around advice. However, it's been
> taken in Nanning, Spring and JBoss as being "the way to do AOP." Around
> advice is not always the best programming model for application
developers,
> as Gregor points out. Pre and Post advice is also important, and we should
> be able to support that as well. It may be possible to implement more
> efficiently than intercepted around advice, also. E.g. it doesn't require
an
> interceptor chain: ie there's no need for a MethodInvocation object
because
> there's no need to have a "proceed" concept (the advice doesn't take
control
> and get to decide whether to proceed to the joinpoint.)
>
> We should also be able to support any kind of advice: e.g. "call an
> arbitrary method via reflection before this method." (Of course the
> arbitrary code wouldn't have knowledge of the joinpoint, but that mightn't
> matter in situations where the pointcut was sufficient to determine
whether
> something should happen or not.)
>
> I think we're a lot of the way towards generalizing the API support in
> Spring but we still need to go a bit farther:
>
> a. IntroductionAdvice --> InterceptionIntroductionAdvisor (to allow the
> possibility of introduction other than by interception around advice)
>
> b. Possible new superinterface InterceptionAroundAdvisor for
> InterceptionAdvisor and InterceptionIntroductionAdvisor. This wouldn't be
> used by end users, so might be added at any time to help the
implementation
> be more efficient.
>
> These small changes now could allow different types of advice and
additional
> implementation strategies in the future, in a backward compatible way.
>
> Regards,
> Rod
>
> ----- Original Message ----- 
> From: "renaud" <re...@ao...>
> To: <spr...@li...>
> Cc: "'Colin Sampaleanu'" <col...@ex...>; "'Bob Lee'"
> <cra...@cr...>
> Sent: Tuesday, November 11, 2003 3:23 PM
> Subject: RE: [Springframework-developer] Revised AOP API proposal
>
>
> >
> >
> > Yes. Actually I do not like the fact that in AspectJ an advice in
defined
> > regarding a pointcut.
> > I've found it very unclear what is exactly the advice in the AspectJ
> > semantics.
> >
> > <AspectJDoc>
> > A join point is a well-defined point in the program flow. Pointcuts
select
> > certain join points and values at those points. Advice defines code that
> is
> > executed when a pointcut is reached. These are, then, the dynamic parts
of
> > AspectJ.
> > </AspectJDoc>
> >
> > By reading this, you can really think that the advice and the pointcut
are
> > orthogonal and defined independently. Indeed, it seems not flexible at
all
> > to define at the same place the code to be executed and where it is
> > executed.
> >
> > But, later in the same doc:
> >
> > <AspectJDoc>
> > Pointcuts are used in the definition of advice.
> > </AspectJDoc>
> >
> > To me it is confusing. Moreover, lots of work on AOP have pointed out
the
> > benefits of having independent structures for the both. To me AspectJ
> misses
> > something here: the ability to define independent (unlocated) advice -- 
> like
> > an interceptor does.
> >
> > So it seems to me that the concept of Advisor helps here. It sounds like
> > saying "we advise some code" and "we do not use advice concept
> specifically
> > because it is unclear and, btw, we use interceptors which are
independent
> > structures - more flexible than the advice constructs in AspectJ".
> >
> > Regards,
> > Renaud.
> >
> > ---
> > Renaud Pawlak
> > Software Engineering Department
> > Rensselaer at Hartford
> > 275 Windsor St, Hartford, CT 06120-2991
> > Work: 860-548-5358 Mobile: 860-748-5527
> > Emails: pa...@rh..., re...@ao...
> > WWW: http://www.lifl.fr/~pawlak
> >
> >
> > > -----Original Message-----
> > > From: spr...@li...
> > > [mailto:spr...@li...]
> > >  On Behalf Of Kopylenko, Dmitry
> > > Sent: Tuesday, November 11, 2003 9:52 AM
> > > To: 'renaud'; 'spr...@li...'
> > > Cc: 'Colin Sampaleanu'; 'Bob Lee'
> > > Subject: RE: [Springframework-developer] Revised AOP API proposal
> > >
> > >
> > > Advisor does not fall under "standard" AOP concepts as
> > > opposed to Advice, but I like the name better.
> > >
> > > My 2c.
> > >
> > > Dmitriy.
> > >
> > > -----Original Message-----
> > > From: renaud [mailto:re...@ao...]
> > > Sent: Tuesday, November 11, 2003 9:19 AM
> > > To: spr...@li...
> > > Cc: 'Kopylenko, Dmitry'; 'Colin Sampaleanu'; 'Bob Lee'
> > > Subject: RE: [Springframework-developer] Revised AOP API proposal
> > >
> > >
> > >
> > > Hi all,
> > >
> > > I have been working a lot these last days on a JAC
> > > refactoring in order that our two frameworks implement a
> > > simplar API (well, as much as possible). Morever this allows
> > > me to detect weaknesses of the proposed API.
> > >
> > > Rod, when do you plan to consider the API definitively fixed
> > > (so that I kown until when I can work on it)?
> > >
> > > The main problem I see for now on is about the per-instance
> > > property. In AOP, you are supposed to be able to precise if
> > > the aspect will be applied globally, or on a per-instance
> > > basis. For instance, you may want an advice to install the
> > > same interceptor for your whole pointcut, or seamlessly
> > > create a different instance for each instance cut by the pointcut.
> > >
> > > This is not difficult to solve. We can propose a method
> > > isPerInstance() on the Advice.
> > >
> > > By the way, by thinking a lot about this "Advice" interface,
> > > it turned out that the concept of advice as defined in AOP (I
> > > means theorical AOP) does not includes the pointcut. However,
> > > in AspectJ, it actually corresponds to an actual construct.
> > > So, I figured out that the best way to solve the issue was to
> > > call this construct an "Advisor". Note that it has the
> > > advantage to solve the problem of the advice plural
> > > ("Advice[] getAdvice()" is not very cool).
> > >
> > > So my intermediate proposal would be:
> > >
> > > public interface Advisor {
> > >     boolean isPerInstance();
> > > }
> > >
> > > And rename
> > > InterceptionAdvice into InterceptionAdvisor
> > > IntroductionAdvice into IntroductionAdvisor
> > >
> > > In the aspect, you will also have a getAdvisors method
> > > instead of a getAdvice method.
> > >
> > > As you can see, it is not a big deal of a change at all.
> > >
> > > Best,
> > > Renaud.
> > >
> > > ---
> > > Renaud Pawlak
> > > Software Engineering Department
> > > Rensselaer at Hartford
> > > 275 Windsor St, Hartford, CT 06120-2991
> > > Work: 860-548-5358 Mobile: 860-748-5527
> > > Emails: pa...@rh..., re...@ao...
> > > WWW: http://www.lifl.fr/~pawlak
> > >
> > >
> > > > -----Original Message-----
> > > > From: spr...@li...
> > > > [mailto:spr...@li...]
> > > >  On Behalf Of Rod Johnson
> > > > Sent: Monday, November 10, 2003 12:35 PM
> > > > To: spr...@li...
> > > > Cc: renaud; Kopylenko, Dmitry; Colin Sampaleanu; Bob Lee
> > > > Subject: [Springframework-developer] Revised AOP API proposal
> > > >
> > > >
> > > > All,
> > > >
> > > > Here's a variant on the API API which goes down the path initially
> > > > suggested by Renaud with separate class and method
> > > designators. Apart
> > > > from that it's much the same: Advice is still almost the same.
> > > >
> > > > The unit of composition is a ClassFilter or MethodMatcher. The new
> > > > Pointcut interface allows for FieldMatchers in the future.
> > > >
> > > > Abstract convenience classes could make it easy to use: for
> > > example,
> > > > the RegexpPointcut could continue to implement Pointcut,
> > > with no need
> > > > for the application developer to work with a distinct
> > > ClassFilter or
> > > > MethodMatcher. I think the only downside of this proposal
> > > is ease of
> > > > use, and convenience classes can resolve that.
> > > >
> > > > This also enables IntroductionAdvice to have only a ClassFilter, as
> > > > Bob wanted.
> > > >
> > > > Static methods are still used to "compose" pointcuts and the
> > > > finer-grained units of composition.
> > > >
> > > > Feedback please... This is an important API to get right,
> > > and time is
> > > > closing now, as we don't want this to delay M3.
> > > >
> > > > Regards,
> > > > Rod
> > > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by: ApacheCon 2003,
> > > 16-19 November in Las Vegas. Learn firsthand the latest
> > > developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV,
> > > and more! http://www.apachecon.com/
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: ApacheCon 2003,
> > 16-19 November in Las Vegas. Learn firsthand the latest
> > developments in Apache, PHP, Perl, XML, Java, MySQL,
> > WebDAV, and more! http://www.apachecon.com/
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Type 3 IoC support

[Rod J. <rod...@in...>]

> As to why I am trying to construct a context inside a context, I am 
> doing some interesting coding; we can get into that later when 
> everything is working :-)

Sounds very interesting indeed.

Regards,
Rod

Re: [Springframework-developer] Type 3 IoC support

[Colin S. <col...@ex...>]

Juergen,

I think the constructor resolution may not be quite right. The following 
bean entry fails:
  <bean id="data-access-context"
          
class="org.springframework.context.support.ClassPathXmlApplicationContext">
    <constructor-arg>
      <list><value>/data-access-applicationContext.xml</value></list>
       </constructor-arg>
  </bean>
with
        ...
        
org.springframework.beans.factory.UnsatisfiedDependencyException: Bean w
ith name 'data-access-context' has an unsatisfied dependency expressed 
through c
onstructor argument with index 0 of type [java.lang.String]

Where it should be able to resolve to the constructor which takes an 
array of Strings. Now I will probably look into this myself later, but 
wanted to give you a heads up in case you know offhand what the problem 
is. For the time being, I am in a hurry, and will just feed the one 
string I need to the constructor which takes one string.

As to why I am trying to construct a context inside a context, I am 
doing some interesting coding; we can get into that later when 
everything is working :-)




jürgen höller [werk3AT] wrote:

>Due to popular demand ;-), I've just added a constructor detection algorithm that replaces the former single-constructor requirement. It works similar to Pico's constructor resolution: It starts with the "greediest" constructor, i.e. the one with the most arguments, and then falls back to the next one in the greediness order if it can't resolve all dependencies. If there are multiple constructors with the same number of arguments, all of them are tried; the first one that can be satisfied will be used.
>
>Of course, all "constructor-arg" hints will be applied in any case; autowire="constructor" will just resolve all remaining arguments. A few sanity checks are performed, like only resolving a constructor that has at least as many arguments as there are "constructor-arg" tags.
>
>This should be sufficiently powerful to be able to address *any* constructor. For example, if there are constructors (DataSource,TestBean) and (TestBean,DataSource), autowiring or generic "constructor-arg" tags with a DataSource and a TestBean will use an undetermined one of the two (generally, the first one according to the order of Class.getConstructors, which can vary from JVM to JVM). If you need a specific one, use "constructor-arg" with corresponding "index" attributes.
>
>If multiple constructors with the same number and position of arguments match, like (DataSource,TestBean) and (DataSource,Object), a type difference weight algorithm will kick in. It will determine a weight for the difference between the argument types and the actual arguments, prefering more exact matches - (DataSource,TestBean) in case of DataSource and TestBean args, in the above case.
>
>BTW, Rob, Pico still advocates the single constructor paradigm. Their introduction (http://www.picocontainer.org/introduction.html) still states that Pico components need to have one single constructor, while their FAQ talk about resolving an appropriate constructor (http://www.picocontainer.org/faq.html#many-constructors) - so much for documentation consistency.
>
>I consider our Type 3 IoC support now more capable than Pico's: We also support arrays, lists, and maps of components or parameters going into constructor arguments, just like we do with bean properties. Effectively, bean-style Type 2 IoC vs constructor-style Type 3 IoC is now the application developer's choice when using a Spring bean factory. Note that the Pico guys have already stated that they will *not* support Type 2 IoC any time soon but just their flavour of Type 3.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rob Butler
>Sent: Sunday, November 09, 2003 11:47 PM
>To: spr...@li...
>Subject: [[W3-SPAM]] - Re: [Springframework-developer] Type 3 IoC
>support - Email found in subject
>
>
>I would agree this is very good stuff!  This is especially useful if you
>want to use a third party api but they do not conform to javabean style
>no-arg contructors.  However by limiting the implementation to only support
>classes that have a single constructor you are all but defeating its
>usefulness.
>
>The only reason you would be forced to use / need this kind of a feature is
>if you don't have access to the code to implement a no-arg constructor.  For
>that same reason, you cannot modify the code to only have 1 constructor. I
>would wager that most classes that do provide a constructor which takes args
>also supply variations that take more / less args.  So if multiple
>constructors are not supported, it's probably not going to be very useful.
>
>Spring is already amazing, and you guys just keep making it better.  Good
>work!
>
>Later
>Rob
>  
>
>>>The only limitation is that constructor-wired components are just allowed
>>>      
>>>
>to have one single constructor. This is also what Pico recommends, although
>they have some heuristic kind of constructor choice in case of multiple
>constructors now. I guess we can limit this to one single constructor for
>the time being. Of course, standard beans defined without
>autowire="constructor" or "constructor-arg" tags can still have any number
>of constructors, the only requirement being that they must provide a no-arg
>constructor.
>  
>
>>>      
>>>
>>One way you could do it (which you probably thought of) is by allowing
>>the deployer to specify, in the case of the indexed variant, an optional
>>'type' attribute which specifies the real type (in the receiving object)
>>of that constructor argument. This would allow the appropriate
>>constructor to be picked without any ambiguity. I don't know if this is
>>worth doing or not, but on the other hand, if you are going to support
>>constructors at all, it's somewhat arbitrary to stop at 1 if you can
>>figure out a relatively simple (albeit wordy) way to support the
>>multiple case.
>>
>>Even if that is not done, maybe it is worth it supporting the special
>>case of classes which have a no-arg constructor, and one other
>>constructor with one or more args. That's also a pretty common case, and
>>easy to support.
>>
>>Regards,
>>Colin
>>    
>>

Re: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate method is not spec compliant, I am going to change it

[<tri...@tr...>]

I'd guess that is because we don't know beforehand what signatures the stateful
session bean is going to provide.  I don't think that ejbCreate() without
parameters is required for stateful session beans.

Thomas

Quoting Colin Sampaleanu <col...@ex...>:

> Ok, to allow spec compliance for the MDB, I have changed things so that
> 
>  - AbstractEnterpriseBean#loadBeanFactory throws BootstrapException, 
> not CreateException
>  - AbstractMessageDrivenBean#ejbCreate no longer throws 
> CreateException, the BootstrapException will just flow through
>  - AbstractStatelessSessionBean#ejbCreate, since it was calling 
> loadBeanFactory, it is able to catch BootStrapException, and rethrow it 
> as CreateException, to behave just as before.
>  - AbstractStatefulSessionBean#loadBeanFactory no longer throwns 
> CreateException, it will just let the BootStrapException from its super 
> flow through.
> 
> I am quite confused as to why AbstracteStatelessSessionBean has an 
> ejbCreate impl and automatically calls loadBeanFactory, while 
> AbstractStatefulSessionBean doesn't do this, simply overriding 
> loadBeanFactory to allow subclasses to call it if needed. This 
> difference between the two seems very arbitrary. Can someone explain?
> 
> 
> 
> Colin Sampaleanu wrote:
> 
> > Now the only question is what to do with loadBeanFactory in 
> > AbstractEnterpriseBean, which throws CreateException. It could either 
> > be left that way, and AbstractMessageDrivenBean could rewrap it is 
> > something derived from RuntimeException or alternately just pull out 
> > the BootstrapException and throw that. However, I think it is cleaner 
> > for loadBeanFactory to just throw BootstrapException directly, and 
> > AbstractSessionBean will itself wrap it with a CreateException, while 
> > AbstractMessageDrivenBean just lets it flow through.
> >
> >
> > Colin Sampaleanu wrote:
> >
> >> It may work in some versions of JBoss. JBoss 3.2.2 doesn't deploy the 
> >> bean at all though:
> >> ----
> >> 12:22:35,853 ERROR [MainDeployer] could not create deployment: 
> >> file:/C:/dev/jbos
> >> s-3.2.2/server/default/deploy/core-app.ear
> >> org.jboss.deployment.DeploymentException: Verification of Enterprise 
> >> Beans faile
> >> d, see above for error messages.
> >>        at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:491)
> >>        at 
> >> org.jboss.deployment.MainDeployer.create(MainDeployer.java:786)
> >>        at 
> >> org.jboss.deployment.MainDeployer.create(MainDeployer.java:778)
> >>        at 
> >> org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641)
> >>   ...
> >> 12:22:36,118 ERROR [URLDeploymentScanner] MBeanException: Exception 
> >> in MBean ope
> >> ration 'checkIncompleteDeployments()'
> >> Cause: Incomplete Deployment listing:
> >> Packages waiting for a deployer:
> >>  <none>
> >> Incompletely deployed packages:
> >> [org.jboss.deployment.DeploymentInfo@47111691 { 
> >> url=file:/C:/dev/jboss-3.2.2/ser
> >> ver/default/deploy/core-app.ear }
> >>  deployer: org.jboss.deployment.EARDeployer@4977e2
> >>  status: Deployment FAILED reason: Verification of Enterprise Beans 
> >> failed, see
> >> above for error messages.
> >>  state: FAILED
> >>  watch: file:/C:/dev/jboss-3.2.2/server/default/deploy/core-app.ear
> >>  lastDeployed: 1068830549227
> >> ----
> >>
> >> So I don't see much choice but to change it. That is, I think it 
> >> makes more sense that it's compliant and works in JBoss, and works 
> >> with compliant code in other app servers, and breaks some 
> >> non-compliant code in other app servers, than the current situation 
> >> where we force non-compliant code, which can't run on JBoss at all.
> >>
> >> Regardless of Spring, the real question is if there is an app-server 
> >> out there that breaks without the CreateException. If that's the 
> >> case, it would kill cross-server compatibility...
> >>
> >>
> >>
> >> Rod Johnson wrote:
> >>
> >>> Yes, as the bug entries say I took the decision that it is incorrect
> >>> according to the spec, but the WebLogic examples do throw 
> >>> CreateException.
> >>> And the user reported that it _did_ still work in JBoss, so I 
> >>> figured that I
> >>> didn't want to have to go test it in all EJB containers. (Ie I 
> >>> didn't have
> >>> time to retest it in WLS.)
> >>>
> >>> However, you probably should change it.
> >>>
> >>> Regards,
> >>> Rod
> >>>
> >>> ----- Original Message ----- From: "jürgen höller [werk3AT]" 
> >>> <jue...@we...>
> >>> To: <spr...@li...>
> >>> Sent: Friday, November 14, 2003 5:40 PM
> >>> Subject: Re: [Springframework-developer] AbstractMessageDrivenBean's
> >>> ejbCreate method is not spec compliant, I am going to change it
> >>>
> >>>
> >>> There's a bug entry on SourceForge for this:
> >>>
>
http://sourceforge.net/tracker/index.php?func=detail&aid=823990&group_id=73357&atid=537539
> 
> >>>
> >>>
> >>> Juergen
> >>>
> >>> ________________________________
> >>>
> >>> Von: spr...@li... im 
> >>> Auftrag von
> >>> Colin Sampaleanu
> >>> Gesendet: Fr 14.11.2003 18:41
> >>> An: spr...@li...
> >>> Betreff: [Springframework-developer] AbstractMessageDrivenBean's 
> >>> ejbCreate
> >>> method is not spec compliant, I am going to change it
> >>>
> >>>
> >>>
> >>> AbstractMessageDrivenBean currently has the following ejbCreate method:
> >>>
> >>>    /**
> >>>     * Lifecycle method required by the EJB specification but not
> >>>     * the MessageDrivenBean interface.
> >>>     * <p>This implementation loads the BeanFactory. Don't override it
> >>>     * (although it can't be made final): code your initialization in
> >>>     * onEjbCreate(), which is called when the BeanFactory is available.
> >>>     * <p>Unfortunately we can't load the BeanFactory in
> >>> setSessionContext(),
> >>>     * as ResourceManager access isn't permitted and the BeanFactory may
> >>> require it.
> >>>     */
> >>>    public void ejbCreate() throws CreateException {
> >>>        loadBeanFactory();
> >>>        onEjbCreate();
> >>>    }
> >>>
> >>> This is actually not spec compliant. If you look at the spec, section
> >>> 15.7.3, it states that MessageDrivenBeans must not throw application
> >>> exceptions. CreateException is an application exception, and in fact
> >>> JBoss, for example, will not allow an MDB with this create method to 
> >>> load.
> >>>
> >>> So I am going to change this to remove the exception, after I get back
> >>> from lunch. If anybody disagrees with me, before or after that, please
> >>> let me know.
> >>>
> >>> (lucky me, still putzin' around with legacy EJB code...)
> >>>
> >>> Regards,
> >>> Colin
> >>>
> >>>  
> >>>
> >>
> >>
> >
> >
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate method is not spec compliant, I am going to change it

[Rod J. <rod...@in...>]

>I am quite confused as to why AbstracteStatelessSessionBean has an
ejbCreate impl and automatically calls loadBeanFactory, while
AbstractStatefulSessionBean doesn't do this, simply overriding
loadBeanFactory to allow subclasses to call it if needed. This
difference between the two seems very arbitrary. Can someone explain?

Stateful session beans aren't guaranteed to have a no-arg create method:
that depends on the home interface. So a no-arg create method is not really
a special or meaningful point to hang behaviour for SFSBs.

Regards,
Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Friday, November 14, 2003 8:21 PM
Subject: Re: [Springframework-developer] AbstractMessageDrivenBean's
ejbCreate method is not spec compliant, I am going to change it


> Ok, to allow spec compliance for the MDB, I have changed things so that
>
>  - AbstractEnterpriseBean#loadBeanFactory throws BootstrapException,
> not CreateException
>  - AbstractMessageDrivenBean#ejbCreate no longer throws
> CreateException, the BootstrapException will just flow through
>  - AbstractStatelessSessionBean#ejbCreate, since it was calling
> loadBeanFactory, it is able to catch BootStrapException, and rethrow it
> as CreateException, to behave just as before.
>  - AbstractStatefulSessionBean#loadBeanFactory no longer throwns
> CreateException, it will just let the BootStrapException from its super
> flow through.
>
> I am quite confused as to why AbstracteStatelessSessionBean has an
> ejbCreate impl and automatically calls loadBeanFactory, while
> AbstractStatefulSessionBean doesn't do this, simply overriding
> loadBeanFactory to allow subclasses to call it if needed. This
> difference between the two seems very arbitrary. Can someone explain?
>
>
>
> Colin Sampaleanu wrote:
>
> > Now the only question is what to do with loadBeanFactory in
> > AbstractEnterpriseBean, which throws CreateException. It could either
> > be left that way, and AbstractMessageDrivenBean could rewrap it is
> > something derived from RuntimeException or alternately just pull out
> > the BootstrapException and throw that. However, I think it is cleaner
> > for loadBeanFactory to just throw BootstrapException directly, and
> > AbstractSessionBean will itself wrap it with a CreateException, while
> > AbstractMessageDrivenBean just lets it flow through.
> >
> >
> > Colin Sampaleanu wrote:
> >
> >> It may work in some versions of JBoss. JBoss 3.2.2 doesn't deploy the
> >> bean at all though:
> >> ----
> >> 12:22:35,853 ERROR [MainDeployer] could not create deployment:
> >> file:/C:/dev/jbos
> >> s-3.2.2/server/default/deploy/core-app.ear
> >> org.jboss.deployment.DeploymentException: Verification of Enterprise
> >> Beans faile
> >> d, see above for error messages.
> >>        at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:491)
> >>        at
> >> org.jboss.deployment.MainDeployer.create(MainDeployer.java:786)
> >>        at
> >> org.jboss.deployment.MainDeployer.create(MainDeployer.java:778)
> >>        at
> >> org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641)
> >>   ...
> >> 12:22:36,118 ERROR [URLDeploymentScanner] MBeanException: Exception
> >> in MBean ope
> >> ration 'checkIncompleteDeployments()'
> >> Cause: Incomplete Deployment listing:
> >> Packages waiting for a deployer:
> >>  <none>
> >> Incompletely deployed packages:
> >> [org.jboss.deployment.DeploymentInfo@47111691 {
> >> url=file:/C:/dev/jboss-3.2.2/ser
> >> ver/default/deploy/core-app.ear }
> >>  deployer: org.jboss.deployment.EARDeployer@4977e2
> >>  status: Deployment FAILED reason: Verification of Enterprise Beans
> >> failed, see
> >> above for error messages.
> >>  state: FAILED
> >>  watch: file:/C:/dev/jboss-3.2.2/server/default/deploy/core-app.ear
> >>  lastDeployed: 1068830549227
> >> ----
> >>
> >> So I don't see much choice but to change it. That is, I think it
> >> makes more sense that it's compliant and works in JBoss, and works
> >> with compliant code in other app servers, and breaks some
> >> non-compliant code in other app servers, than the current situation
> >> where we force non-compliant code, which can't run on JBoss at all.
> >>
> >> Regardless of Spring, the real question is if there is an app-server
> >> out there that breaks without the CreateException. If that's the
> >> case, it would kill cross-server compatibility...
> >>
> >>
> >>
> >> Rod Johnson wrote:
> >>
> >>> Yes, as the bug entries say I took the decision that it is incorrect
> >>> according to the spec, but the WebLogic examples do throw
> >>> CreateException.
> >>> And the user reported that it _did_ still work in JBoss, so I
> >>> figured that I
> >>> didn't want to have to go test it in all EJB containers. (Ie I
> >>> didn't have
> >>> time to retest it in WLS.)
> >>>
> >>> However, you probably should change it.
> >>>
> >>> Regards,
> >>> Rod
> >>>
> >>> ----- Original Message ----- From: "jürgen höller [werk3AT]"
> >>> <jue...@we...>
> >>> To: <spr...@li...>
> >>> Sent: Friday, November 14, 2003 5:40 PM
> >>> Subject: Re: [Springframework-developer] AbstractMessageDrivenBean's
> >>> ejbCreate method is not spec compliant, I am going to change it
> >>>
> >>>
> >>> There's a bug entry on SourceForge for this:
> >>>
http://sourceforge.net/tracker/index.php?func=detail&aid=823990&group_id=73357&atid=537539
> >>>
> >>>
> >>> Juergen
> >>>
> >>> ________________________________
> >>>
> >>> Von: spr...@li... im
> >>> Auftrag von
> >>> Colin Sampaleanu
> >>> Gesendet: Fr 14.11.2003 18:41
> >>> An: spr...@li...
> >>> Betreff: [Springframework-developer] AbstractMessageDrivenBean's
> >>> ejbCreate
> >>> method is not spec compliant, I am going to change it
> >>>
> >>>
> >>>
> >>> AbstractMessageDrivenBean currently has the following ejbCreate
method:
> >>>
> >>>    /**
> >>>     * Lifecycle method required by the EJB specification but not
> >>>     * the MessageDrivenBean interface.
> >>>     * <p>This implementation loads the BeanFactory. Don't override it
> >>>     * (although it can't be made final): code your initialization in
> >>>     * onEjbCreate(), which is called when the BeanFactory is
available.
> >>>     * <p>Unfortunately we can't load the BeanFactory in
> >>> setSessionContext(),
> >>>     * as ResourceManager access isn't permitted and the BeanFactory
may
> >>> require it.
> >>>     */
> >>>    public void ejbCreate() throws CreateException {
> >>>        loadBeanFactory();
> >>>        onEjbCreate();
> >>>    }
> >>>
> >>> This is actually not spec compliant. If you look at the spec, section
> >>> 15.7.3, it states that MessageDrivenBeans must not throw application
> >>> exceptions. CreateException is an application exception, and in fact
> >>> JBoss, for example, will not allow an MDB with this create method to
> >>> load.
> >>>
> >>> So I am going to change this to remove the exception, after I get back
> >>> from lunch. If anybody disagrees with me, before or after that, please
> >>> let me know.
> >>>
> >>> (lucky me, still putzin' around with legacy EJB code...)
> >>>
> >>> Regards,
> >>> Colin
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate method is not spec compliant, I am going to change it

[Colin S. <col...@ex...>]

Ok, to allow spec compliance for the MDB, I have changed things so that

 - AbstractEnterpriseBean#loadBeanFactory throws BootstrapException, 
not CreateException
 - AbstractMessageDrivenBean#ejbCreate no longer throws 
CreateException, the BootstrapException will just flow through
 - AbstractStatelessSessionBean#ejbCreate, since it was calling 
loadBeanFactory, it is able to catch BootStrapException, and rethrow it 
as CreateException, to behave just as before.
 - AbstractStatefulSessionBean#loadBeanFactory no longer throwns 
CreateException, it will just let the BootStrapException from its super 
flow through.

I am quite confused as to why AbstracteStatelessSessionBean has an 
ejbCreate impl and automatically calls loadBeanFactory, while 
AbstractStatefulSessionBean doesn't do this, simply overriding 
loadBeanFactory to allow subclasses to call it if needed. This 
difference between the two seems very arbitrary. Can someone explain?



Colin Sampaleanu wrote:

> Now the only question is what to do with loadBeanFactory in 
> AbstractEnterpriseBean, which throws CreateException. It could either 
> be left that way, and AbstractMessageDrivenBean could rewrap it is 
> something derived from RuntimeException or alternately just pull out 
> the BootstrapException and throw that. However, I think it is cleaner 
> for loadBeanFactory to just throw BootstrapException directly, and 
> AbstractSessionBean will itself wrap it with a CreateException, while 
> AbstractMessageDrivenBean just lets it flow through.
>
>
> Colin Sampaleanu wrote:
>
>> It may work in some versions of JBoss. JBoss 3.2.2 doesn't deploy the 
>> bean at all though:
>> ----
>> 12:22:35,853 ERROR [MainDeployer] could not create deployment: 
>> file:/C:/dev/jbos
>> s-3.2.2/server/default/deploy/core-app.ear
>> org.jboss.deployment.DeploymentException: Verification of Enterprise 
>> Beans faile
>> d, see above for error messages.
>>        at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:491)
>>        at 
>> org.jboss.deployment.MainDeployer.create(MainDeployer.java:786)
>>        at 
>> org.jboss.deployment.MainDeployer.create(MainDeployer.java:778)
>>        at 
>> org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641)
>>   ...
>> 12:22:36,118 ERROR [URLDeploymentScanner] MBeanException: Exception 
>> in MBean ope
>> ration 'checkIncompleteDeployments()'
>> Cause: Incomplete Deployment listing:
>> Packages waiting for a deployer:
>>  <none>
>> Incompletely deployed packages:
>> [org.jboss.deployment.DeploymentInfo@47111691 { 
>> url=file:/C:/dev/jboss-3.2.2/ser
>> ver/default/deploy/core-app.ear }
>>  deployer: org.jboss.deployment.EARDeployer@4977e2
>>  status: Deployment FAILED reason: Verification of Enterprise Beans 
>> failed, see
>> above for error messages.
>>  state: FAILED
>>  watch: file:/C:/dev/jboss-3.2.2/server/default/deploy/core-app.ear
>>  lastDeployed: 1068830549227
>> ----
>>
>> So I don't see much choice but to change it. That is, I think it 
>> makes more sense that it's compliant and works in JBoss, and works 
>> with compliant code in other app servers, and breaks some 
>> non-compliant code in other app servers, than the current situation 
>> where we force non-compliant code, which can't run on JBoss at all.
>>
>> Regardless of Spring, the real question is if there is an app-server 
>> out there that breaks without the CreateException. If that's the 
>> case, it would kill cross-server compatibility...
>>
>>
>>
>> Rod Johnson wrote:
>>
>>> Yes, as the bug entries say I took the decision that it is incorrect
>>> according to the spec, but the WebLogic examples do throw 
>>> CreateException.
>>> And the user reported that it _did_ still work in JBoss, so I 
>>> figured that I
>>> didn't want to have to go test it in all EJB containers. (Ie I 
>>> didn't have
>>> time to retest it in WLS.)
>>>
>>> However, you probably should change it.
>>>
>>> Regards,
>>> Rod
>>>
>>> ----- Original Message ----- From: "jürgen höller [werk3AT]" 
>>> <jue...@we...>
>>> To: <spr...@li...>
>>> Sent: Friday, November 14, 2003 5:40 PM
>>> Subject: Re: [Springframework-developer] AbstractMessageDrivenBean's
>>> ejbCreate method is not spec compliant, I am going to change it
>>>
>>>
>>> There's a bug entry on SourceForge for this:
>>> http://sourceforge.net/tracker/index.php?func=detail&aid=823990&group_id=73357&atid=537539 
>>>
>>>
>>> Juergen
>>>
>>> ________________________________
>>>
>>> Von: spr...@li... im 
>>> Auftrag von
>>> Colin Sampaleanu
>>> Gesendet: Fr 14.11.2003 18:41
>>> An: spr...@li...
>>> Betreff: [Springframework-developer] AbstractMessageDrivenBean's 
>>> ejbCreate
>>> method is not spec compliant, I am going to change it
>>>
>>>
>>>
>>> AbstractMessageDrivenBean currently has the following ejbCreate method:
>>>
>>>    /**
>>>     * Lifecycle method required by the EJB specification but not
>>>     * the MessageDrivenBean interface.
>>>     * <p>This implementation loads the BeanFactory. Don't override it
>>>     * (although it can't be made final): code your initialization in
>>>     * onEjbCreate(), which is called when the BeanFactory is available.
>>>     * <p>Unfortunately we can't load the BeanFactory in
>>> setSessionContext(),
>>>     * as ResourceManager access isn't permitted and the BeanFactory may
>>> require it.
>>>     */
>>>    public void ejbCreate() throws CreateException {
>>>        loadBeanFactory();
>>>        onEjbCreate();
>>>    }
>>>
>>> This is actually not spec compliant. If you look at the spec, section
>>> 15.7.3, it states that MessageDrivenBeans must not throw application
>>> exceptions. CreateException is an application exception, and in fact
>>> JBoss, for example, will not allow an MDB with this create method to 
>>> load.
>>>
>>> So I am going to change this to remove the exception, after I get back
>>> from lunch. If anybody disagrees with me, before or after that, please
>>> let me know.
>>>
>>> (lucky me, still putzin' around with legacy EJB code...)
>>>
>>> Regards,
>>> Colin
>>>
>>>  
>>>
>>
>>
>
>

Re: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate method is not spec compliant, I am going to change it

[<tri...@tr...>]

I like the last suggestion -- "for loadBeanFactory to just throw 
BootstrapException directly, and AbstractSessionBean will itself wrap it with a
CreateException, while AbstractMessageDrivenBean just lets it flow through." 

Thomas

Quoting Colin Sampaleanu <col...@ex...>:

> Now the only question is what to do with loadBeanFactory in 
> AbstractEnterpriseBean, which throws CreateException. It could either be 
> left that way, and AbstractMessageDrivenBean could rewrap it is 
> something derived from RuntimeException or alternately just pull out the 
> BootstrapException and throw that. However, I think it is cleaner for 
> loadBeanFactory to just throw BootstrapException directly, and 
> AbstractSessionBean will itself wrap it with a CreateException, while 
> AbstractMessageDrivenBean just lets it flow through.
> 
> 
> Colin Sampaleanu wrote:
> 
> > It may work in some versions of JBoss. JBoss 3.2.2 doesn't deploy the 
> > bean at all though:
> > ----
> > 12:22:35,853 ERROR [MainDeployer] could not create deployment: 
> > file:/C:/dev/jbos
> > s-3.2.2/server/default/deploy/core-app.ear
> > org.jboss.deployment.DeploymentException: Verification of Enterprise 
> > Beans faile
> > d, see above for error messages.
> >        at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:491)
> >        at org.jboss.deployment.MainDeployer.create(MainDeployer.java:786)
> >        at org.jboss.deployment.MainDeployer.create(MainDeployer.java:778)
> >        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641)
> >   ...
> > 12:22:36,118 ERROR [URLDeploymentScanner] MBeanException: Exception in 
> > MBean ope
> > ration 'checkIncompleteDeployments()'
> > Cause: Incomplete Deployment listing:
> > Packages waiting for a deployer:
> >  <none>
> > Incompletely deployed packages:
> > [org.jboss.deployment.DeploymentInfo@47111691 { 
> > url=file:/C:/dev/jboss-3.2.2/ser
> > ver/default/deploy/core-app.ear }
> >  deployer: org.jboss.deployment.EARDeployer@4977e2
> >  status: Deployment FAILED reason: Verification of Enterprise Beans 
> > failed, see
> > above for error messages.
> >  state: FAILED
> >  watch: file:/C:/dev/jboss-3.2.2/server/default/deploy/core-app.ear
> >  lastDeployed: 1068830549227
> > ----
> >
> > So I don't see much choice but to change it. That is, I think it makes 
> > more sense that it's compliant and works in JBoss, and works with 
> > compliant code in other app servers, and breaks some non-compliant 
> > code in other app servers, than the current situation where we force 
> > non-compliant code, which can't run on JBoss at all.
> >
> > Regardless of Spring, the real question is if there is an app-server 
> > out there that breaks without the CreateException. If that's the case, 
> > it would kill cross-server compatibility...
> >
> >
> >
> > Rod Johnson wrote:
> >
> >> Yes, as the bug entries say I took the decision that it is incorrect
> >> according to the spec, but the WebLogic examples do throw 
> >> CreateException.
> >> And the user reported that it _did_ still work in JBoss, so I figured 
> >> that I
> >> didn't want to have to go test it in all EJB containers. (Ie I didn't 
> >> have
> >> time to retest it in WLS.)
> >>
> >> However, you probably should change it.
> >>
> >> Regards,
> >> Rod
> >>
> >> ----- Original Message ----- From: "jürgen höller [werk3AT]" 
> >> <jue...@we...>
> >> To: <spr...@li...>
> >> Sent: Friday, November 14, 2003 5:40 PM
> >> Subject: Re: [Springframework-developer] AbstractMessageDrivenBean's
> >> ejbCreate method is not spec compliant, I am going to change it
> >>
> >>
> >> There's a bug entry on SourceForge for this:
> >>
>
http://sourceforge.net/tracker/index.php?func=detail&aid=823990&group_id=73357&atid=537539
> 
> >>
> >>
> >> Juergen
> >>
> >> ________________________________
> >>
> >> Von: spr...@li... im Auftrag 
> >> von
> >> Colin Sampaleanu
> >> Gesendet: Fr 14.11.2003 18:41
> >> An: spr...@li...
> >> Betreff: [Springframework-developer] AbstractMessageDrivenBean's 
> >> ejbCreate
> >> method is not spec compliant, I am going to change it
> >>
> >>
> >>
> >> AbstractMessageDrivenBean currently has the following ejbCreate method:
> >>
> >>    /**
> >>     * Lifecycle method required by the EJB specification but not
> >>     * the MessageDrivenBean interface.
> >>     * <p>This implementation loads the BeanFactory. Don't override it
> >>     * (although it can't be made final): code your initialization in
> >>     * onEjbCreate(), which is called when the BeanFactory is available.
> >>     * <p>Unfortunately we can't load the BeanFactory in
> >> setSessionContext(),
> >>     * as ResourceManager access isn't permitted and the BeanFactory may
> >> require it.
> >>     */
> >>    public void ejbCreate() throws CreateException {
> >>        loadBeanFactory();
> >>        onEjbCreate();
> >>    }
> >>
> >> This is actually not spec compliant. If you look at the spec, section
> >> 15.7.3, it states that MessageDrivenBeans must not throw application
> >> exceptions. CreateException is an application exception, and in fact
> >> JBoss, for example, will not allow an MDB with this create method to 
> >> load.
> >>
> >> So I am going to change this to remove the exception, after I get back
> >> from lunch. If anybody disagrees with me, before or after that, please
> >> let me know.
> >>
> >> (lucky me, still putzin' around with legacy EJB code...)
> >>
> >> Regards,
> >> Colin
> >>
> >>  
> >>
> >
> >
> 
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate method is not spec compliant, I am going to change it

[Colin S. <col...@ex...>]

Now the only question is what to do with loadBeanFactory in 
AbstractEnterpriseBean, which throws CreateException. It could either be 
left that way, and AbstractMessageDrivenBean could rewrap it is 
something derived from RuntimeException or alternately just pull out the 
BootstrapException and throw that. However, I think it is cleaner for 
loadBeanFactory to just throw BootstrapException directly, and 
AbstractSessionBean will itself wrap it with a CreateException, while 
AbstractMessageDrivenBean just lets it flow through.


Colin Sampaleanu wrote:

> It may work in some versions of JBoss. JBoss 3.2.2 doesn't deploy the 
> bean at all though:
> ----
> 12:22:35,853 ERROR [MainDeployer] could not create deployment: 
> file:/C:/dev/jbos
> s-3.2.2/server/default/deploy/core-app.ear
> org.jboss.deployment.DeploymentException: Verification of Enterprise 
> Beans faile
> d, see above for error messages.
>        at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:491)
>        at org.jboss.deployment.MainDeployer.create(MainDeployer.java:786)
>        at org.jboss.deployment.MainDeployer.create(MainDeployer.java:778)
>        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641)
>   ...
> 12:22:36,118 ERROR [URLDeploymentScanner] MBeanException: Exception in 
> MBean ope
> ration 'checkIncompleteDeployments()'
> Cause: Incomplete Deployment listing:
> Packages waiting for a deployer:
>  <none>
> Incompletely deployed packages:
> [org.jboss.deployment.DeploymentInfo@47111691 { 
> url=file:/C:/dev/jboss-3.2.2/ser
> ver/default/deploy/core-app.ear }
>  deployer: org.jboss.deployment.EARDeployer@4977e2
>  status: Deployment FAILED reason: Verification of Enterprise Beans 
> failed, see
> above for error messages.
>  state: FAILED
>  watch: file:/C:/dev/jboss-3.2.2/server/default/deploy/core-app.ear
>  lastDeployed: 1068830549227
> ----
>
> So I don't see much choice but to change it. That is, I think it makes 
> more sense that it's compliant and works in JBoss, and works with 
> compliant code in other app servers, and breaks some non-compliant 
> code in other app servers, than the current situation where we force 
> non-compliant code, which can't run on JBoss at all.
>
> Regardless of Spring, the real question is if there is an app-server 
> out there that breaks without the CreateException. If that's the case, 
> it would kill cross-server compatibility...
>
>
>
> Rod Johnson wrote:
>
>> Yes, as the bug entries say I took the decision that it is incorrect
>> according to the spec, but the WebLogic examples do throw 
>> CreateException.
>> And the user reported that it _did_ still work in JBoss, so I figured 
>> that I
>> didn't want to have to go test it in all EJB containers. (Ie I didn't 
>> have
>> time to retest it in WLS.)
>>
>> However, you probably should change it.
>>
>> Regards,
>> Rod
>>
>> ----- Original Message ----- From: "jürgen höller [werk3AT]" 
>> <jue...@we...>
>> To: <spr...@li...>
>> Sent: Friday, November 14, 2003 5:40 PM
>> Subject: Re: [Springframework-developer] AbstractMessageDrivenBean's
>> ejbCreate method is not spec compliant, I am going to change it
>>
>>
>> There's a bug entry on SourceForge for this:
>> http://sourceforge.net/tracker/index.php?func=detail&aid=823990&group_id=73357&atid=537539 
>>
>>
>> Juergen
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag 
>> von
>> Colin Sampaleanu
>> Gesendet: Fr 14.11.2003 18:41
>> An: spr...@li...
>> Betreff: [Springframework-developer] AbstractMessageDrivenBean's 
>> ejbCreate
>> method is not spec compliant, I am going to change it
>>
>>
>>
>> AbstractMessageDrivenBean currently has the following ejbCreate method:
>>
>>    /**
>>     * Lifecycle method required by the EJB specification but not
>>     * the MessageDrivenBean interface.
>>     * <p>This implementation loads the BeanFactory. Don't override it
>>     * (although it can't be made final): code your initialization in
>>     * onEjbCreate(), which is called when the BeanFactory is available.
>>     * <p>Unfortunately we can't load the BeanFactory in
>> setSessionContext(),
>>     * as ResourceManager access isn't permitted and the BeanFactory may
>> require it.
>>     */
>>    public void ejbCreate() throws CreateException {
>>        loadBeanFactory();
>>        onEjbCreate();
>>    }
>>
>> This is actually not spec compliant. If you look at the spec, section
>> 15.7.3, it states that MessageDrivenBeans must not throw application
>> exceptions. CreateException is an application exception, and in fact
>> JBoss, for example, will not allow an MDB with this create method to 
>> load.
>>
>> So I am going to change this to remove the exception, after I get back
>> from lunch. If anybody disagrees with me, before or after that, please
>> let me know.
>>
>> (lucky me, still putzin' around with legacy EJB code...)
>>
>> Regards,
>> Colin
>>
>>  
>>
>
>

Re: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate method is not spec compliant, I am going to change it

[Colin S. <col...@ex...>]

The spec is actually quite clear (i.e. look at 7.10.3 for a Session 
Bean's ejbCreate contract, where they say explicitely that application 
exceptions _may_ be thrown, including CreateException). So I think the 
people who created those examples don't know the correct spec. Probably 
those appserver which allow the throw are doing it either because the 
authors (of the appserver) didn't realize the behaviour was different, 
and just carried over their validation to be the same as for other bean 
types, or they made them allow non-compliant code in order to work with 
more user code, since this is likely to be a common error.



tri...@tr... wrote:

>+1 for removing it.
>
>It looks like you are all correct - WebLogic seems to think that CreateException
>should be thrown from the ejbCreate method - but from my experience it works
>without this throws clause.  I don't remember where I copied my generic
>messagebean implementation from, but I did not have this throws clause and
>WebLogic has never complained.
>
>
>This is from
>/bea/weblogic700/samples/server/src/examples/ejb20/message/MessageTraderBean.java
>
>  /**
>   * This method corresponds to the create method in the home interface
>   * "TraderHome.java".
>   * The parameter sets of the two methods are identical. When the client calls
>   * <code>TraderHome.create()</code>, the container allocates an instance of 
>   * the EJBean and calls <code>ejbCreate()</code>.
>   *
>   * @exception               javax.ejb.CreateException if there is
>   *                          a communications or systems failure
>   * @see                     examples.ejb11.basic.statelessMessageDriven.Trader
>   */
>  public void ejbCreate () throws CreateException {
>
>  }
>
>Also see:
>http://edocs.bea.com/wls/docs81/javadocs/weblogic/ejb/GenericMessageDrivenBean.html
>
>My take on this is that the messagebean should throw an EJBException if there is
>a communications or system failure.
>
>Thomas
>
>
>Quoting Rod Johnson <rod...@in...>:
>
>  
>
>>Yes, as the bug entries say I took the decision that it is incorrect
>>according to the spec, but the WebLogic examples do throw CreateException.
>>And the user reported that it _did_ still work in JBoss, so I figured that I
>>didn't want to have to go test it in all EJB containers. (Ie I didn't have
>>time to retest it in WLS.)
>>
>>However, you probably should change it.
>>
>>Regards,
>>Rod
>>
>>----- Original Message ----- 
>>From: "jürgen höller [werk3AT]" <jue...@we...>
>>To: <spr...@li...>
>>Sent: Friday, November 14, 2003 5:40 PM
>>Subject: Re: [Springframework-developer] AbstractMessageDrivenBean's
>>ejbCreate method is not spec compliant, I am going to change it
>>
>>
>>There's a bug entry on SourceForge for this:
>>
>>    
>>
>http://sourceforge.net/tracker/index.php?func=detail&aid=823990&group_id=73357&atid=537539
>  
>
>>Juergen
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von
>>Colin Sampaleanu
>>Gesendet: Fr 14.11.2003 18:41
>>An: spr...@li...
>>Betreff: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate
>>method is not spec compliant, I am going to change it
>>
>>
>>
>>AbstractMessageDrivenBean currently has the following ejbCreate method:
>>
>>    /**
>>     * Lifecycle method required by the EJB specification but not
>>     * the MessageDrivenBean interface.
>>     * <p>This implementation loads the BeanFactory. Don't override it
>>     * (although it can't be made final): code your initialization in
>>     * onEjbCreate(), which is called when the BeanFactory is available.
>>     * <p>Unfortunately we can't load the BeanFactory in
>>setSessionContext(),
>>     * as ResourceManager access isn't permitted and the BeanFactory may
>>require it.
>>     */
>>    public void ejbCreate() throws CreateException {
>>        loadBeanFactory();
>>        onEjbCreate();
>>    }
>>
>>This is actually not spec compliant. If you look at the spec, section
>>15.7.3, it states that MessageDrivenBeans must not throw application
>>exceptions. CreateException is an application exception, and in fact
>>JBoss, for example, will not allow an MDB with this create method to load.
>>
>>So I am going to change this to remove the exception, after I get back
>>from lunch. If anybody disagrees with me, before or after that, please
>>let me know.
>>
>>(lucky me, still putzin' around with legacy EJB code...)
>>
>>Regards,
>>Colin
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF. Net email is sponsored by: GoToMyPC
>>GoToMyPC is the fast, easy and secure way to access your computer from
>>any Web browser or wireless device. Click here to Try it Free!
>>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF. Net email is sponsored by: GoToMyPC
>>GoToMyPC is the fast, easy and secure way to access your computer from
>>any Web browser or wireless device. Click here to Try it Free!
>>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=/g22lp.tmpl
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF. Net email is sponsored by: GoToMyPC
>>GoToMyPC is the fast, easy and secure way to access your computer from
>>any Web browser or wireless device. Click here to Try it Free!
>>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>    
>>
>
>
>
>
>
>-------------------------------------------------------
>This SF. Net email is sponsored by: GoToMyPC
>GoToMyPC is the fast, easy and secure way to access your computer from
>any Web browser or wireless device. Click here to Try it Free!
>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate method is not spec compliant, I am going to change it

[Rod J. <rod...@in...>]

OK, we need to change it then.

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Friday, November 14, 2003 6:49 PM
Subject: Re: [Springframework-developer] AbstractMessageDrivenBean's
ejbCreate method is not spec compliant, I am going to change it


> It may work in some versions of JBoss. JBoss 3.2.2 doesn't deploy the
> bean at all though:
> ----
> 12:22:35,853 ERROR [MainDeployer] could not create deployment:
> file:/C:/dev/jbos
> s-3.2.2/server/default/deploy/core-app.ear
> org.jboss.deployment.DeploymentException: Verification of Enterprise
> Beans faile
> d, see above for error messages.
>         at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:491)
>         at org.jboss.deployment.MainDeployer.create(MainDeployer.java:786)
>         at org.jboss.deployment.MainDeployer.create(MainDeployer.java:778)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641)
>    ...
> 12:22:36,118 ERROR [URLDeploymentScanner] MBeanException: Exception in
> MBean ope
> ration 'checkIncompleteDeployments()'
> Cause: Incomplete Deployment listing:
> Packages waiting for a deployer:
>   <none>
> Incompletely deployed packages:
> [org.jboss.deployment.DeploymentInfo@47111691 {
> url=file:/C:/dev/jboss-3.2.2/ser
> ver/default/deploy/core-app.ear }
>   deployer: org.jboss.deployment.EARDeployer@4977e2
>   status: Deployment FAILED reason: Verification of Enterprise Beans
> failed, see
>  above for error messages.
>   state: FAILED
>   watch: file:/C:/dev/jboss-3.2.2/server/default/deploy/core-app.ear
>   lastDeployed: 1068830549227
> ----
>
> So I don't see much choice but to change it. That is, I think it makes
> more sense that it's compliant and works in JBoss, and works with
> compliant code in other app servers, and breaks some non-compliant code
> in other app servers, than the current situation where we force
> non-compliant code, which can't run on JBoss at all.
>
> Regardless of Spring, the real question is if there is an app-server out
> there that breaks without the CreateException. If that's the case, it
> would kill cross-server compatibility...
>
>
>
> Rod Johnson wrote:
>
> >Yes, as the bug entries say I took the decision that it is incorrect
> >according to the spec, but the WebLogic examples do throw
CreateException.
> >And the user reported that it _did_ still work in JBoss, so I figured
that I
> >didn't want to have to go test it in all EJB containers. (Ie I didn't
have
> >time to retest it in WLS.)
> >
> >However, you probably should change it.
> >
> >Regards,
> >Rod
> >
> >----- Original Message ----- 
> >From: "jürgen höller [werk3AT]" <jue...@we...>
> >To: <spr...@li...>
> >Sent: Friday, November 14, 2003 5:40 PM
> >Subject: Re: [Springframework-developer] AbstractMessageDrivenBean's
> >ejbCreate method is not spec compliant, I am going to change it
> >
> >
> >There's a bug entry on SourceForge for this:
>
>http://sourceforge.net/tracker/index.php?func=detail&aid=823990&group_id=73
357&atid=537539
> >
> >Juergen
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag von
> >Colin Sampaleanu
> >Gesendet: Fr 14.11.2003 18:41
> >An: spr...@li...
> >Betreff: [Springframework-developer] AbstractMessageDrivenBean's
ejbCreate
> >method is not spec compliant, I am going to change it
> >
> >
> >
> >AbstractMessageDrivenBean currently has the following ejbCreate method:
> >
> >    /**
> >     * Lifecycle method required by the EJB specification but not
> >     * the MessageDrivenBean interface.
> >     * <p>This implementation loads the BeanFactory. Don't override it
> >     * (although it can't be made final): code your initialization in
> >     * onEjbCreate(), which is called when the BeanFactory is available.
> >     * <p>Unfortunately we can't load the BeanFactory in
> >setSessionContext(),
> >     * as ResourceManager access isn't permitted and the BeanFactory may
> >require it.
> >     */
> >    public void ejbCreate() throws CreateException {
> >        loadBeanFactory();
> >        onEjbCreate();
> >    }
> >
> >This is actually not spec compliant. If you look at the spec, section
> >15.7.3, it states that MessageDrivenBeans must not throw application
> >exceptions. CreateException is an application exception, and in fact
> >JBoss, for example, will not allow an MDB with this create method to
load.
> >
> >So I am going to change this to remove the exception, after I get back
> >from lunch. If anybody disagrees with me, before or after that, please
> >let me know.
> >
> >(lucky me, still putzin' around with legacy EJB code...)
> >
> >Regards,
> >Colin
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate method is not spec compliant, I am going to change it

[Colin S. <col...@ex...>]

It may work in some versions of JBoss. JBoss 3.2.2 doesn't deploy the 
bean at all though:
----
12:22:35,853 ERROR [MainDeployer] could not create deployment: 
file:/C:/dev/jbos
s-3.2.2/server/default/deploy/core-app.ear
org.jboss.deployment.DeploymentException: Verification of Enterprise 
Beans faile
d, see above for error messages.
        at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:491)
        at org.jboss.deployment.MainDeployer.create(MainDeployer.java:786)
        at org.jboss.deployment.MainDeployer.create(MainDeployer.java:778)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641)
   ...
12:22:36,118 ERROR [URLDeploymentScanner] MBeanException: Exception in 
MBean ope
ration 'checkIncompleteDeployments()'
Cause: Incomplete Deployment listing:
Packages waiting for a deployer:
  <none>
Incompletely deployed packages:
[org.jboss.deployment.DeploymentInfo@47111691 { 
url=file:/C:/dev/jboss-3.2.2/ser
ver/default/deploy/core-app.ear }
  deployer: org.jboss.deployment.EARDeployer@4977e2
  status: Deployment FAILED reason: Verification of Enterprise Beans 
failed, see
 above for error messages.
  state: FAILED
  watch: file:/C:/dev/jboss-3.2.2/server/default/deploy/core-app.ear
  lastDeployed: 1068830549227
----

So I don't see much choice but to change it. That is, I think it makes 
more sense that it's compliant and works in JBoss, and works with 
compliant code in other app servers, and breaks some non-compliant code 
in other app servers, than the current situation where we force 
non-compliant code, which can't run on JBoss at all.

Regardless of Spring, the real question is if there is an app-server out 
there that breaks without the CreateException. If that's the case, it 
would kill cross-server compatibility...



Rod Johnson wrote:

>Yes, as the bug entries say I took the decision that it is incorrect
>according to the spec, but the WebLogic examples do throw CreateException.
>And the user reported that it _did_ still work in JBoss, so I figured that I
>didn't want to have to go test it in all EJB containers. (Ie I didn't have
>time to retest it in WLS.)
>
>However, you probably should change it.
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: "jürgen höller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Friday, November 14, 2003 5:40 PM
>Subject: Re: [Springframework-developer] AbstractMessageDrivenBean's
>ejbCreate method is not spec compliant, I am going to change it
>
>
>There's a bug entry on SourceForge for this:
>http://sourceforge.net/tracker/index.php?func=detail&aid=823990&group_id=73357&atid=537539
>
>Juergen
>
>________________________________
>
>Von: spr...@li... im Auftrag von
>Colin Sampaleanu
>Gesendet: Fr 14.11.2003 18:41
>An: spr...@li...
>Betreff: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate
>method is not spec compliant, I am going to change it
>
>
>
>AbstractMessageDrivenBean currently has the following ejbCreate method:
>
>    /**
>     * Lifecycle method required by the EJB specification but not
>     * the MessageDrivenBean interface.
>     * <p>This implementation loads the BeanFactory. Don't override it
>     * (although it can't be made final): code your initialization in
>     * onEjbCreate(), which is called when the BeanFactory is available.
>     * <p>Unfortunately we can't load the BeanFactory in
>setSessionContext(),
>     * as ResourceManager access isn't permitted and the BeanFactory may
>require it.
>     */
>    public void ejbCreate() throws CreateException {
>        loadBeanFactory();
>        onEjbCreate();
>    }
>
>This is actually not spec compliant. If you look at the spec, section
>15.7.3, it states that MessageDrivenBeans must not throw application
>exceptions. CreateException is an application exception, and in fact
>JBoss, for example, will not allow an MDB with this create method to load.
>
>So I am going to change this to remove the exception, after I get back
>from lunch. If anybody disagrees with me, before or after that, please
>let me know.
>
>(lucky me, still putzin' around with legacy EJB code...)
>
>Regards,
>Colin
>
>  
>

RE: [Springframework-developer] AOP API finalization

[Kopylenko, D. <dko...@ac...>]

+1 for Advice --> Advisor (as I said before) Also, I like the concept of
supporting different kinds of Advice (other then interception-around)

Regards,
Dmitriy.

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...] 
Sent: Friday, November 14, 2003 12:14 PM
To: spr...@li...
Subject: Re: [Springframework-developer] AOP API finalization


+1  - This all sounds reasonable to me.

Rod Johnson wrote:

>All,
>
>Let me begin with an apology for those of you who may be getting a bit 
>bored with arcane debates about AOP... Spring will continue to provide 
>declarative transaction management in the present simple way, without 
>the need to work with the AOP interfaces and framework directly. And we 
>will provide even easier .NET style automatic "enterprise services" for 
>transactions etc. in the future. So most users likely won't need to 
>work with this lower level stuff. However, it's still important to get 
>it right.
>
>
>Now the AOP code is committed and no one has screamed about it (which I 
>take to mean that everyone who's interested agrees it's on the right 
>track :-), I think the hard work has been done. What I'm talking about 
>there is essentially minor refactoring that doesn't change the way 
>things work.
>
>However, I think there are a few things still to do before we go to 
>final:
>
>1. I think Renaud is right regarding Advice --> Advisor. (See the rest 
>of this email for the discussion.) So I propose that we rename anything 
>with the suffix Advice to Advisor. (Affects interfaces and advice 
>superclasses.)
>
>PLEASE feedback your views on this--particularly, if you object 
>strongly.
>
>2. I think it's important that we're not tied into interception. 
>Interception is one way of implementing around advice. However, it's 
>been taken in Nanning, Spring and JBoss as being "the way to do AOP." 
>Around advice is not always the best programming model for application 
>developers, as Gregor points out. Pre and Post advice is also 
>important, and we should be able to support that as well. It may be 
>possible to implement more efficiently than intercepted around advice, 
>also. E.g. it doesn't require an interceptor chain: ie there's no need 
>for a MethodInvocation object because there's no need to have a 
>"proceed" concept (the advice doesn't take control and get to decide 
>whether to proceed to the joinpoint.)
>
>We should also be able to support any kind of advice: e.g. "call an 
>arbitrary method via reflection before this method." (Of course the 
>arbitrary code wouldn't have knowledge of the joinpoint, but that 
>mightn't matter in situations where the pointcut was sufficient to 
>determine whether something should happen or not.)
>
>I think we're a lot of the way towards generalizing the API support in 
>Spring but we still need to go a bit farther:
>
>a. IntroductionAdvice --> InterceptionIntroductionAdvisor (to allow the 
>possibility of introduction other than by interception around advice)
>
>b. Possible new superinterface InterceptionAroundAdvisor for 
>InterceptionAdvisor and InterceptionIntroductionAdvisor. This wouldn't 
>be used by end users, so might be added at any time to help the 
>implementation be more efficient.
>
>These small changes now could allow different types of advice and 
>additional implementation strategies in the future, in a backward 
>compatible way.
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "renaud" <re...@ao...>
>To: <spr...@li...>
>Cc: "'Colin Sampaleanu'" <col...@ex...>; "'Bob Lee'"
><cra...@cr...>
>Sent: Tuesday, November 11, 2003 3:23 PM
>Subject: RE: [Springframework-developer] Revised AOP API proposal
>
>
>  
>
>>Yes. Actually I do not like the fact that in AspectJ an advice in 
>>defined regarding a pointcut. I've found it very unclear what is 
>>exactly the advice in the AspectJ semantics.
>>
>><AspectJDoc>
>>A join point is a well-defined point in the program flow. Pointcuts 
>>select certain join points and values at those points. Advice defines 
>>code that
>>    
>>
>is
>  
>
>>executed when a pointcut is reached. These are, then, the dynamic 
>>parts of AspectJ. </AspectJDoc>
>>
>>By reading this, you can really think that the advice and the pointcut 
>>are orthogonal and defined independently. Indeed, it seems not 
>>flexible at all to define at the same place the code to be executed 
>>and where it is executed.
>>
>>But, later in the same doc:
>>
>><AspectJDoc>
>>Pointcuts are used in the definition of advice.
>></AspectJDoc>
>>
>>To me it is confusing. Moreover, lots of work on AOP have pointed out 
>>the benefits of having independent structures for the both. To me 
>>AspectJ
>>    
>>
>misses
>  
>
>>something here: the ability to define independent (unlocated) advice 
>>--
>>    
>>
>like
>  
>
>>an interceptor does.
>>
>>So it seems to me that the concept of Advisor helps here. It sounds 
>>like saying "we advise some code" and "we do not use advice concept
>>    
>>
>specifically
>  
>
>>because it is unclear and, btw, we use interceptors which are 
>>independent structures - more flexible than the advice constructs in 
>>AspectJ".
>>
>>Regards,
>>Renaud.
>>
>>---
>>Renaud Pawlak
>>Software Engineering Department
>>Rensselaer at Hartford
>>275 Windsor St, Hartford, CT 06120-2991
>>Work: 860-548-5358 Mobile: 860-748-5527
>>Emails: pa...@rh..., re...@ao...
>>WWW: http://www.lifl.fr/~pawlak
>>
>>
>>    
>>
>>>-----Original Message-----
>>>From: spr...@li...
>>>[mailto:spr...@li...]
>>> On Behalf Of Kopylenko, Dmitry
>>>Sent: Tuesday, November 11, 2003 9:52 AM
>>>To: 'renaud'; 'spr...@li...'
>>>Cc: 'Colin Sampaleanu'; 'Bob Lee'
>>>Subject: RE: [Springframework-developer] Revised AOP API proposal
>>>
>>>
>>>Advisor does not fall under "standard" AOP concepts as opposed to 
>>>Advice, but I like the name better.
>>>
>>>My 2c.
>>>
>>>Dmitriy.
>>>
>>>-----Original Message-----
>>>From: renaud [mailto:re...@ao...]
>>>Sent: Tuesday, November 11, 2003 9:19 AM
>>>To: spr...@li...
>>>Cc: 'Kopylenko, Dmitry'; 'Colin Sampaleanu'; 'Bob Lee'
>>>Subject: RE: [Springframework-developer] Revised AOP API proposal
>>>
>>>
>>>
>>>Hi all,
>>>
>>>I have been working a lot these last days on a JAC refactoring in 
>>>order that our two frameworks implement a simplar API (well, as much 
>>>as possible). Morever this allows me to detect weaknesses of the 
>>>proposed API.
>>>
>>>Rod, when do you plan to consider the API definitively fixed (so that 
>>>I kown until when I can work on it)?
>>>
>>>The main problem I see for now on is about the per-instance property. 
>>>In AOP, you are supposed to be able to precise if the aspect will be 
>>>applied globally, or on a per-instance basis. For instance, you may 
>>>want an advice to install the same interceptor for your whole 
>>>pointcut, or seamlessly create a different instance for each instance 
>>>cut by the pointcut.
>>>
>>>This is not difficult to solve. We can propose a method
>>>isPerInstance() on the Advice.
>>>
>>>By the way, by thinking a lot about this "Advice" interface, it 
>>>turned out that the concept of advice as defined in AOP (I means 
>>>theorical AOP) does not includes the pointcut. However, in AspectJ, 
>>>it actually corresponds to an actual construct. So, I figured out 
>>>that the best way to solve the issue was to call this construct an 
>>>"Advisor". Note that it has the advantage to solve the problem of the 
>>>advice plural ("Advice[] getAdvice()" is not very cool).
>>>
>>>So my intermediate proposal would be:
>>>
>>>public interface Advisor {
>>>    boolean isPerInstance();
>>>}
>>>
>>>And rename
>>>InterceptionAdvice into InterceptionAdvisor IntroductionAdvice into 
>>>IntroductionAdvisor
>>>
>>>In the aspect, you will also have a getAdvisors method instead of a 
>>>getAdvice method.
>>>
>>>As you can see, it is not a big deal of a change at all.
>>>
>>>Best,
>>>Renaud.
>>>
>>>---
>>>Renaud Pawlak
>>>Software Engineering Department
>>>Rensselaer at Hartford
>>>275 Windsor St, Hartford, CT 06120-2991
>>>Work: 860-548-5358 Mobile: 860-748-5527
>>>Emails: pa...@rh..., re...@ao...
>>>WWW: http://www.lifl.fr/~pawlak
>>>
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: spr...@li...
>>>>[mailto:spr...@li...]
>>>> On Behalf Of Rod Johnson
>>>>Sent: Monday, November 10, 2003 12:35 PM
>>>>To: spr...@li...
>>>>Cc: renaud; Kopylenko, Dmitry; Colin Sampaleanu; Bob Lee
>>>>Subject: [Springframework-developer] Revised AOP API proposal
>>>>
>>>>
>>>>All,
>>>>
>>>>Here's a variant on the API API which goes down the path initially 
>>>>suggested by Renaud with separate class and method
>>>>        
>>>>
>>>designators. Apart
>>>      
>>>
>>>>from that it's much the same: Advice is still almost the same.
>>>>
>>>>The unit of composition is a ClassFilter or MethodMatcher. The new 
>>>>Pointcut interface allows for FieldMatchers in the future.
>>>>
>>>>Abstract convenience classes could make it easy to use: for
>>>>        
>>>>
>>>example,
>>>      
>>>
>>>>the RegexpPointcut could continue to implement Pointcut,
>>>>        
>>>>
>>>with no need
>>>      
>>>
>>>>for the application developer to work with a distinct
>>>>        
>>>>
>>>ClassFilter or
>>>      
>>>
>>>>MethodMatcher. I think the only downside of this proposal
>>>>        
>>>>
>>>is ease of
>>>      
>>>
>>>>use, and convenience classes can resolve that.
>>>>
>>>>This also enables IntroductionAdvice to have only a ClassFilter, as 
>>>>Bob wanted.
>>>>
>>>>Static methods are still used to "compose" pointcuts and the 
>>>>finer-grained units of composition.
>>>>
>>>>Feedback please... This is an important API to get right,
>>>>        
>>>>
>>>and time is
>>>      
>>>
>>>>closing now, as we don't want this to delay M3.
>>>>
>>>>Regards,
>>>>Rod
>>>>
>>>>        
>>>>




-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from any
Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate method is not spec compliant, I am going to change it

[<tri...@tr...>]

+1 for removing it.

It looks like you are all correct - WebLogic seems to think that CreateException
should be thrown from the ejbCreate method - but from my experience it works
without this throws clause.  I don't remember where I copied my generic
messagebean implementation from, but I did not have this throws clause and
WebLogic has never complained.


This is from
/bea/weblogic700/samples/server/src/examples/ejb20/message/MessageTraderBean.java

  /**
   * This method corresponds to the create method in the home interface
   * "TraderHome.java".
   * The parameter sets of the two methods are identical. When the client calls
   * <code>TraderHome.create()</code>, the container allocates an instance of 
   * the EJBean and calls <code>ejbCreate()</code>.
   *
   * @exception               javax.ejb.CreateException if there is
   *                          a communications or systems failure
   * @see                     examples.ejb11.basic.statelessMessageDriven.Trader
   */
  public void ejbCreate () throws CreateException {

  }

Also see:
http://edocs.bea.com/wls/docs81/javadocs/weblogic/ejb/GenericMessageDrivenBean.html

My take on this is that the messagebean should throw an EJBException if there is
a communications or system failure.

Thomas


Quoting Rod Johnson <rod...@in...>:

> Yes, as the bug entries say I took the decision that it is incorrect
> according to the spec, but the WebLogic examples do throw CreateException.
> And the user reported that it _did_ still work in JBoss, so I figured that I
> didn't want to have to go test it in all EJB containers. (Ie I didn't have
> time to retest it in WLS.)
> 
> However, you probably should change it.
> 
> Regards,
> Rod
> 
> ----- Original Message ----- 
> From: "jürgen höller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Friday, November 14, 2003 5:40 PM
> Subject: Re: [Springframework-developer] AbstractMessageDrivenBean's
> ejbCreate method is not spec compliant, I am going to change it
> 
> 
> There's a bug entry on SourceForge for this:
>
http://sourceforge.net/tracker/index.php?func=detail&aid=823990&group_id=73357&atid=537539
> 
> Juergen
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von
> Colin Sampaleanu
> Gesendet: Fr 14.11.2003 18:41
> An: spr...@li...
> Betreff: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate
> method is not spec compliant, I am going to change it
> 
> 
> 
> AbstractMessageDrivenBean currently has the following ejbCreate method:
> 
>     /**
>      * Lifecycle method required by the EJB specification but not
>      * the MessageDrivenBean interface.
>      * <p>This implementation loads the BeanFactory. Don't override it
>      * (although it can't be made final): code your initialization in
>      * onEjbCreate(), which is called when the BeanFactory is available.
>      * <p>Unfortunately we can't load the BeanFactory in
> setSessionContext(),
>      * as ResourceManager access isn't permitted and the BeanFactory may
> require it.
>      */
>     public void ejbCreate() throws CreateException {
>         loadBeanFactory();
>         onEjbCreate();
>     }
> 
> This is actually not spec compliant. If you look at the spec, section
> 15.7.3, it states that MessageDrivenBeans must not throw application
> exceptions. CreateException is an application exception, and in fact
> JBoss, for example, will not allow an MDB with this create method to load.
> 
> So I am going to change this to remove the exception, after I get back
> from lunch. If anybody disagrees with me, before or after that, please
> let me know.
> 
> (lucky me, still putzin' around with legacy EJB code...)
> 
> Regards,
> Colin
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=/g22lp.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate method is not spec compliant, I am going to change it

[Rod J. <rod...@in...>]

Yes, as the bug entries say I took the decision that it is incorrect
according to the spec, but the WebLogic examples do throw CreateException.
And the user reported that it _did_ still work in JBoss, so I figured that I
didn't want to have to go test it in all EJB containers. (Ie I didn't have
time to retest it in WLS.)

However, you probably should change it.

Regards,
Rod

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, November 14, 2003 5:40 PM
Subject: Re: [Springframework-developer] AbstractMessageDrivenBean's
ejbCreate method is not spec compliant, I am going to change it


There's a bug entry on SourceForge for this:
http://sourceforge.net/tracker/index.php?func=detail&aid=823990&group_id=73357&atid=537539

Juergen

________________________________

Von: spr...@li... im Auftrag von
Colin Sampaleanu
Gesendet: Fr 14.11.2003 18:41
An: spr...@li...
Betreff: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate
method is not spec compliant, I am going to change it



AbstractMessageDrivenBean currently has the following ejbCreate method:

    /**
     * Lifecycle method required by the EJB specification but not
     * the MessageDrivenBean interface.
     * <p>This implementation loads the BeanFactory. Don't override it
     * (although it can't be made final): code your initialization in
     * onEjbCreate(), which is called when the BeanFactory is available.
     * <p>Unfortunately we can't load the BeanFactory in
setSessionContext(),
     * as ResourceManager access isn't permitted and the BeanFactory may
require it.
     */
    public void ejbCreate() throws CreateException {
        loadBeanFactory();
        onEjbCreate();
    }

This is actually not spec compliant. If you look at the spec, section
15.7.3, it states that MessageDrivenBeans must not throw application
exceptions. CreateException is an application exception, and in fact
JBoss, for example, will not allow an MDB with this create method to load.

So I am going to change this to remove the exception, after I get back
from lunch. If anybody disagrees with me, before or after that, please
let me know.

(lucky me, still putzin' around with legacy EJB code...)

Regards,
Colin





-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=/g22lp.tmpl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] AbstractMessageDrivenBean's ejbCreate method is not spec compliant, I am going to change it

[<jue...@we...>]

There's a bug entry on SourceForge for this: =
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D823990&group=
_id=3D73357&atid=3D537539
=20
Juergen

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Fr 14.11.2003 18:41
An: spr...@li...
Betreff: [Springframework-developer] AbstractMessageDrivenBean's =
ejbCreate method is not spec compliant, I am going to change it



AbstractMessageDrivenBean currently has the following ejbCreate method:

    /**
     * Lifecycle method required by the EJB specification but not
     * the MessageDrivenBean interface.
     * <p>This implementation loads the BeanFactory. Don't override it
     * (although it can't be made final): code your initialization in
     * onEjbCreate(), which is called when the BeanFactory is available.
     * <p>Unfortunately we can't load the BeanFactory in
setSessionContext(),
     * as ResourceManager access isn't permitted and the BeanFactory may
require it.
     */
    public void ejbCreate() throws CreateException {
        loadBeanFactory();
        onEjbCreate();
    }

This is actually not spec compliant. If you look at the spec, section
15.7.3, it states that MessageDrivenBeans must not throw application
exceptions. CreateException is an application exception, and in fact
JBoss, for example, will not allow an MDB with this create method to =
load.

So I am going to change this to remove the exception, after I get back
from lunch. If anybody disagrees with me, before or after that, please
let me know.

(lucky me, still putzin' around with legacy EJB code...)

Regards,
Colin





-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3Dmm/g22lp.tmp=
l
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] AbstractMessageDrivenBean's ejbCreate method is not spec compliant, I am going to change it

[Colin S. <col...@ex...>]

AbstractMessageDrivenBean currently has the following ejbCreate method:

    /**
     * Lifecycle method required by the EJB specification but not
     * the MessageDrivenBean interface.
     * <p>This implementation loads the BeanFactory. Don't override it
     * (although it can't be made final): code your initialization in
     * onEjbCreate(), which is called when the BeanFactory is available.
     * <p>Unfortunately we can't load the BeanFactory in 
setSessionContext(),
     * as ResourceManager access isn't permitted and the BeanFactory may 
require it.
     */
    public void ejbCreate() throws CreateException {
        loadBeanFactory();
        onEjbCreate();
    }

This is actually not spec compliant. If you look at the spec, section 
15.7.3, it states that MessageDrivenBeans must not throw application 
exceptions. CreateException is an application exception, and in fact 
JBoss, for example, will not allow an MDB with this create method to load.

So I am going to change this to remove the exception, after I get back 
from lunch. If anybody disagrees with me, before or after that, please 
let me know.

(lucky me, still putzin' around with legacy EJB code...)

Regards,
Colin

Re: [Springframework-developer] AOP API finalization

[Colin S. <col...@ex...>]

+1  - This all sounds reasonable to me.

Rod Johnson wrote:

>All,
>
>Let me begin with an apology for those of you who may be getting a bit bored
>with arcane debates about AOP... Spring will continue to provide declarative
>transaction management in the present simple way, without the need to work
>with the AOP interfaces and framework directly. And we will provide even
>easier .NET style automatic "enterprise services" for transactions etc. in
>the future. So most users likely won't need to work with this lower level
>stuff. However, it's still important to get it right.
>
>
>Now the AOP code is committed and no one has screamed about it (which I take
>to mean that everyone who's interested agrees it's on the right track :-), I
>think the hard work has been done. What I'm talking about there is
>essentially minor refactoring that doesn't change the way things work.
>
>However, I think there are a few things still to do before we go to final:
>
>1. I think Renaud is right regarding Advice --> Advisor. (See the rest of
>this email for the discussion.) So I propose that we rename anything with
>the suffix Advice to Advisor. (Affects interfaces and advice superclasses.)
>
>PLEASE feedback your views on this--particularly, if you object strongly.
>
>2. I think it's important that we're not tied into interception.
>Interception is one way of implementing around advice. However, it's been
>taken in Nanning, Spring and JBoss as being "the way to do AOP." Around
>advice is not always the best programming model for application developers,
>as Gregor points out. Pre and Post advice is also important, and we should
>be able to support that as well. It may be possible to implement more
>efficiently than intercepted around advice, also. E.g. it doesn't require an
>interceptor chain: ie there's no need for a MethodInvocation object because
>there's no need to have a "proceed" concept (the advice doesn't take control
>and get to decide whether to proceed to the joinpoint.)
>
>We should also be able to support any kind of advice: e.g. "call an
>arbitrary method via reflection before this method." (Of course the
>arbitrary code wouldn't have knowledge of the joinpoint, but that mightn't
>matter in situations where the pointcut was sufficient to determine whether
>something should happen or not.)
>
>I think we're a lot of the way towards generalizing the API support in
>Spring but we still need to go a bit farther:
>
>a. IntroductionAdvice --> InterceptionIntroductionAdvisor (to allow the
>possibility of introduction other than by interception around advice)
>
>b. Possible new superinterface InterceptionAroundAdvisor for
>InterceptionAdvisor and InterceptionIntroductionAdvisor. This wouldn't be
>used by end users, so might be added at any time to help the implementation
>be more efficient.
>
>These small changes now could allow different types of advice and additional
>implementation strategies in the future, in a backward compatible way.
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: "renaud" <re...@ao...>
>To: <spr...@li...>
>Cc: "'Colin Sampaleanu'" <col...@ex...>; "'Bob Lee'"
><cra...@cr...>
>Sent: Tuesday, November 11, 2003 3:23 PM
>Subject: RE: [Springframework-developer] Revised AOP API proposal
>
>
>  
>
>>Yes. Actually I do not like the fact that in AspectJ an advice in defined
>>regarding a pointcut.
>>I've found it very unclear what is exactly the advice in the AspectJ
>>semantics.
>>
>><AspectJDoc>
>>A join point is a well-defined point in the program flow. Pointcuts select
>>certain join points and values at those points. Advice defines code that
>>    
>>
>is
>  
>
>>executed when a pointcut is reached. These are, then, the dynamic parts of
>>AspectJ.
>></AspectJDoc>
>>
>>By reading this, you can really think that the advice and the pointcut are
>>orthogonal and defined independently. Indeed, it seems not flexible at all
>>to define at the same place the code to be executed and where it is
>>executed.
>>
>>But, later in the same doc:
>>
>><AspectJDoc>
>>Pointcuts are used in the definition of advice.
>></AspectJDoc>
>>
>>To me it is confusing. Moreover, lots of work on AOP have pointed out the
>>benefits of having independent structures for the both. To me AspectJ
>>    
>>
>misses
>  
>
>>something here: the ability to define independent (unlocated) advice -- 
>>    
>>
>like
>  
>
>>an interceptor does.
>>
>>So it seems to me that the concept of Advisor helps here. It sounds like
>>saying "we advise some code" and "we do not use advice concept
>>    
>>
>specifically
>  
>
>>because it is unclear and, btw, we use interceptors which are independent
>>structures - more flexible than the advice constructs in AspectJ".
>>
>>Regards,
>>Renaud.
>>
>>---
>>Renaud Pawlak
>>Software Engineering Department
>>Rensselaer at Hartford
>>275 Windsor St, Hartford, CT 06120-2991
>>Work: 860-548-5358 Mobile: 860-748-5527
>>Emails: pa...@rh..., re...@ao...
>>WWW: http://www.lifl.fr/~pawlak
>>
>>
>>    
>>
>>>-----Original Message-----
>>>From: spr...@li...
>>>[mailto:spr...@li...]
>>> On Behalf Of Kopylenko, Dmitry
>>>Sent: Tuesday, November 11, 2003 9:52 AM
>>>To: 'renaud'; 'spr...@li...'
>>>Cc: 'Colin Sampaleanu'; 'Bob Lee'
>>>Subject: RE: [Springframework-developer] Revised AOP API proposal
>>>
>>>
>>>Advisor does not fall under "standard" AOP concepts as
>>>opposed to Advice, but I like the name better.
>>>
>>>My 2c.
>>>
>>>Dmitriy.
>>>
>>>-----Original Message-----
>>>From: renaud [mailto:re...@ao...]
>>>Sent: Tuesday, November 11, 2003 9:19 AM
>>>To: spr...@li...
>>>Cc: 'Kopylenko, Dmitry'; 'Colin Sampaleanu'; 'Bob Lee'
>>>Subject: RE: [Springframework-developer] Revised AOP API proposal
>>>
>>>
>>>
>>>Hi all,
>>>
>>>I have been working a lot these last days on a JAC
>>>refactoring in order that our two frameworks implement a
>>>simplar API (well, as much as possible). Morever this allows
>>>me to detect weaknesses of the proposed API.
>>>
>>>Rod, when do you plan to consider the API definitively fixed
>>>(so that I kown until when I can work on it)?
>>>
>>>The main problem I see for now on is about the per-instance
>>>property. In AOP, you are supposed to be able to precise if
>>>the aspect will be applied globally, or on a per-instance
>>>basis. For instance, you may want an advice to install the
>>>same interceptor for your whole pointcut, or seamlessly
>>>create a different instance for each instance cut by the pointcut.
>>>
>>>This is not difficult to solve. We can propose a method
>>>isPerInstance() on the Advice.
>>>
>>>By the way, by thinking a lot about this "Advice" interface,
>>>it turned out that the concept of advice as defined in AOP (I
>>>means theorical AOP) does not includes the pointcut. However,
>>>in AspectJ, it actually corresponds to an actual construct.
>>>So, I figured out that the best way to solve the issue was to
>>>call this construct an "Advisor". Note that it has the
>>>advantage to solve the problem of the advice plural
>>>("Advice[] getAdvice()" is not very cool).
>>>
>>>So my intermediate proposal would be:
>>>
>>>public interface Advisor {
>>>    boolean isPerInstance();
>>>}
>>>
>>>And rename
>>>InterceptionAdvice into InterceptionAdvisor
>>>IntroductionAdvice into IntroductionAdvisor
>>>
>>>In the aspect, you will also have a getAdvisors method
>>>instead of a getAdvice method.
>>>
>>>As you can see, it is not a big deal of a change at all.
>>>
>>>Best,
>>>Renaud.
>>>
>>>---
>>>Renaud Pawlak
>>>Software Engineering Department
>>>Rensselaer at Hartford
>>>275 Windsor St, Hartford, CT 06120-2991
>>>Work: 860-548-5358 Mobile: 860-748-5527
>>>Emails: pa...@rh..., re...@ao...
>>>WWW: http://www.lifl.fr/~pawlak
>>>
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: spr...@li...
>>>>[mailto:spr...@li...]
>>>> On Behalf Of Rod Johnson
>>>>Sent: Monday, November 10, 2003 12:35 PM
>>>>To: spr...@li...
>>>>Cc: renaud; Kopylenko, Dmitry; Colin Sampaleanu; Bob Lee
>>>>Subject: [Springframework-developer] Revised AOP API proposal
>>>>
>>>>
>>>>All,
>>>>
>>>>Here's a variant on the API API which goes down the path initially
>>>>suggested by Renaud with separate class and method
>>>>        
>>>>
>>>designators. Apart
>>>      
>>>
>>>>from that it's much the same: Advice is still almost the same.
>>>>
>>>>The unit of composition is a ClassFilter or MethodMatcher. The new
>>>>Pointcut interface allows for FieldMatchers in the future.
>>>>
>>>>Abstract convenience classes could make it easy to use: for
>>>>        
>>>>
>>>example,
>>>      
>>>
>>>>the RegexpPointcut could continue to implement Pointcut,
>>>>        
>>>>
>>>with no need
>>>      
>>>
>>>>for the application developer to work with a distinct
>>>>        
>>>>
>>>ClassFilter or
>>>      
>>>
>>>>MethodMatcher. I think the only downside of this proposal
>>>>        
>>>>
>>>is ease of
>>>      
>>>
>>>>use, and convenience classes can resolve that.
>>>>
>>>>This also enables IntroductionAdvice to have only a ClassFilter, as
>>>>Bob wanted.
>>>>
>>>>Static methods are still used to "compose" pointcuts and the
>>>>finer-grained units of composition.
>>>>
>>>>Feedback please... This is an important API to get right,
>>>>        
>>>>
>>>and time is
>>>      
>>>
>>>>closing now, as we don't want this to delay M3.
>>>>
>>>>Regards,
>>>>Rod
>>>>
>>>>        
>>>>

Re: [Springframework-developer] AOP API finalization

[Rod J. <rod...@in...>]

All,

Let me begin with an apology for those of you who may be getting a bit bored
with arcane debates about AOP... Spring will continue to provide declarative
transaction management in the present simple way, without the need to work
with the AOP interfaces and framework directly. And we will provide even
easier .NET style automatic "enterprise services" for transactions etc. in
the future. So most users likely won't need to work with this lower level
stuff. However, it's still important to get it right.


Now the AOP code is committed and no one has screamed about it (which I take
to mean that everyone who's interested agrees it's on the right track :-), I
think the hard work has been done. What I'm talking about there is
essentially minor refactoring that doesn't change the way things work.

However, I think there are a few things still to do before we go to final:

1. I think Renaud is right regarding Advice --> Advisor. (See the rest of
this email for the discussion.) So I propose that we rename anything with
the suffix Advice to Advisor. (Affects interfaces and advice superclasses.)

PLEASE feedback your views on this--particularly, if you object strongly.

2. I think it's important that we're not tied into interception.
Interception is one way of implementing around advice. However, it's been
taken in Nanning, Spring and JBoss as being "the way to do AOP." Around
advice is not always the best programming model for application developers,
as Gregor points out. Pre and Post advice is also important, and we should
be able to support that as well. It may be possible to implement more
efficiently than intercepted around advice, also. E.g. it doesn't require an
interceptor chain: ie there's no need for a MethodInvocation object because
there's no need to have a "proceed" concept (the advice doesn't take control
and get to decide whether to proceed to the joinpoint.)

We should also be able to support any kind of advice: e.g. "call an
arbitrary method via reflection before this method." (Of course the
arbitrary code wouldn't have knowledge of the joinpoint, but that mightn't
matter in situations where the pointcut was sufficient to determine whether
something should happen or not.)

I think we're a lot of the way towards generalizing the API support in
Spring but we still need to go a bit farther:

a. IntroductionAdvice --> InterceptionIntroductionAdvisor (to allow the
possibility of introduction other than by interception around advice)

b. Possible new superinterface InterceptionAroundAdvisor for
InterceptionAdvisor and InterceptionIntroductionAdvisor. This wouldn't be
used by end users, so might be added at any time to help the implementation
be more efficient.

These small changes now could allow different types of advice and additional
implementation strategies in the future, in a backward compatible way.

Regards,
Rod

----- Original Message ----- 
From: "renaud" <re...@ao...>
To: <spr...@li...>
Cc: "'Colin Sampaleanu'" <col...@ex...>; "'Bob Lee'"
<cra...@cr...>
Sent: Tuesday, November 11, 2003 3:23 PM
Subject: RE: [Springframework-developer] Revised AOP API proposal


>
>
> Yes. Actually I do not like the fact that in AspectJ an advice in defined
> regarding a pointcut.
> I've found it very unclear what is exactly the advice in the AspectJ
> semantics.
>
> <AspectJDoc>
> A join point is a well-defined point in the program flow. Pointcuts select
> certain join points and values at those points. Advice defines code that
is
> executed when a pointcut is reached. These are, then, the dynamic parts of
> AspectJ.
> </AspectJDoc>
>
> By reading this, you can really think that the advice and the pointcut are
> orthogonal and defined independently. Indeed, it seems not flexible at all
> to define at the same place the code to be executed and where it is
> executed.
>
> But, later in the same doc:
>
> <AspectJDoc>
> Pointcuts are used in the definition of advice.
> </AspectJDoc>
>
> To me it is confusing. Moreover, lots of work on AOP have pointed out the
> benefits of having independent structures for the both. To me AspectJ
misses
> something here: the ability to define independent (unlocated) advice -- 
like
> an interceptor does.
>
> So it seems to me that the concept of Advisor helps here. It sounds like
> saying "we advise some code" and "we do not use advice concept
specifically
> because it is unclear and, btw, we use interceptors which are independent
> structures - more flexible than the advice constructs in AspectJ".
>
> Regards,
> Renaud.
>
> ---
> Renaud Pawlak
> Software Engineering Department
> Rensselaer at Hartford
> 275 Windsor St, Hartford, CT 06120-2991
> Work: 860-548-5358 Mobile: 860-748-5527
> Emails: pa...@rh..., re...@ao...
> WWW: http://www.lifl.fr/~pawlak
>
>
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]
> >  On Behalf Of Kopylenko, Dmitry
> > Sent: Tuesday, November 11, 2003 9:52 AM
> > To: 'renaud'; 'spr...@li...'
> > Cc: 'Colin Sampaleanu'; 'Bob Lee'
> > Subject: RE: [Springframework-developer] Revised AOP API proposal
> >
> >
> > Advisor does not fall under "standard" AOP concepts as
> > opposed to Advice, but I like the name better.
> >
> > My 2c.
> >
> > Dmitriy.
> >
> > -----Original Message-----
> > From: renaud [mailto:re...@ao...]
> > Sent: Tuesday, November 11, 2003 9:19 AM
> > To: spr...@li...
> > Cc: 'Kopylenko, Dmitry'; 'Colin Sampaleanu'; 'Bob Lee'
> > Subject: RE: [Springframework-developer] Revised AOP API proposal
> >
> >
> >
> > Hi all,
> >
> > I have been working a lot these last days on a JAC
> > refactoring in order that our two frameworks implement a
> > simplar API (well, as much as possible). Morever this allows
> > me to detect weaknesses of the proposed API.
> >
> > Rod, when do you plan to consider the API definitively fixed
> > (so that I kown until when I can work on it)?
> >
> > The main problem I see for now on is about the per-instance
> > property. In AOP, you are supposed to be able to precise if
> > the aspect will be applied globally, or on a per-instance
> > basis. For instance, you may want an advice to install the
> > same interceptor for your whole pointcut, or seamlessly
> > create a different instance for each instance cut by the pointcut.
> >
> > This is not difficult to solve. We can propose a method
> > isPerInstance() on the Advice.
> >
> > By the way, by thinking a lot about this "Advice" interface,
> > it turned out that the concept of advice as defined in AOP (I
> > means theorical AOP) does not includes the pointcut. However,
> > in AspectJ, it actually corresponds to an actual construct.
> > So, I figured out that the best way to solve the issue was to
> > call this construct an "Advisor". Note that it has the
> > advantage to solve the problem of the advice plural
> > ("Advice[] getAdvice()" is not very cool).
> >
> > So my intermediate proposal would be:
> >
> > public interface Advisor {
> >     boolean isPerInstance();
> > }
> >
> > And rename
> > InterceptionAdvice into InterceptionAdvisor
> > IntroductionAdvice into IntroductionAdvisor
> >
> > In the aspect, you will also have a getAdvisors method
> > instead of a getAdvice method.
> >
> > As you can see, it is not a big deal of a change at all.
> >
> > Best,
> > Renaud.
> >
> > ---
> > Renaud Pawlak
> > Software Engineering Department
> > Rensselaer at Hartford
> > 275 Windsor St, Hartford, CT 06120-2991
> > Work: 860-548-5358 Mobile: 860-748-5527
> > Emails: pa...@rh..., re...@ao...
> > WWW: http://www.lifl.fr/~pawlak
> >
> >
> > > -----Original Message-----
> > > From: spr...@li...
> > > [mailto:spr...@li...]
> > >  On Behalf Of Rod Johnson
> > > Sent: Monday, November 10, 2003 12:35 PM
> > > To: spr...@li...
> > > Cc: renaud; Kopylenko, Dmitry; Colin Sampaleanu; Bob Lee
> > > Subject: [Springframework-developer] Revised AOP API proposal
> > >
> > >
> > > All,
> > >
> > > Here's a variant on the API API which goes down the path initially
> > > suggested by Renaud with separate class and method
> > designators. Apart
> > > from that it's much the same: Advice is still almost the same.
> > >
> > > The unit of composition is a ClassFilter or MethodMatcher. The new
> > > Pointcut interface allows for FieldMatchers in the future.
> > >
> > > Abstract convenience classes could make it easy to use: for
> > example,
> > > the RegexpPointcut could continue to implement Pointcut,
> > with no need
> > > for the application developer to work with a distinct
> > ClassFilter or
> > > MethodMatcher. I think the only downside of this proposal
> > is ease of
> > > use, and convenience classes can resolve that.
> > >
> > > This also enables IntroductionAdvice to have only a ClassFilter, as
> > > Bob wanted.
> > >
> > > Static methods are still used to "compose" pointcuts and the
> > > finer-grained units of composition.
> > >
> > > Feedback please... This is an important API to get right,
> > and time is
> > > closing now, as we don't want this to delay M3.
> > >
> > > Regards,
> > > Rod
> > >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: ApacheCon 2003,
> > 16-19 November in Las Vegas. Learn firsthand the latest
> > developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV,
> > and more! http://www.apachecon.com/
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Copy paste error ?

[Rod J. <rod...@in...>]

Mark,

Can you look at AttributeWriterTests please.

I'll look at the MethodMatcher tests now.
Regards,
Rod

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, November 14, 2003 10:08 AM
Subject: Re: [Springframework-developer] Copy paste error ?


MethodMatchersTests fails in the current CVS version. So does
AttributeWriterTests - still.

Juergen

________________________________

Von: spr...@li... im Auftrag von
Rod Johnson
Gesendet: Mi 12.11.2003 16:37
An: spr...@li...
Cc: Kopylenko, Dmitry
Betreff: Re: [Springframework-developer] Copy paste error ?



Hang on. It's only possible to ascertain the intersection at runtime. If
it's an AND, the runtime evaluation will never happen, which will mean that
the part of the intersection that was dynamic won't ever be evaluated and
the intersection will be bigger than it should be.

So I think it's correct. This does mean that there's a cost involved in
intersections with dynamic method matchers, which are inherently expensive.

However, we really need to write a lot more test cases for Pointcut and
MethodMatcher unions and intersections. I'm pretty sure there are some bugs
in the present composition implementation, but I was keen to put the
framework in place first.

Regards,
Rod

----- Original Message -----
From: "Dmitriy Kopylenko" <dko...@ru...>
To: <spr...@li...>
Sent: Wednesday, November 12, 2003 3:27 PM
Subject: RE: [Springframework-developer] Copy paste error ?


> I'll fix that.
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
Of
> roger holbrook
> Sent: Wednesday, November 12, 2003 10:21 AM
> To: spr...@li...
> Subject: [Springframework-developer] Copy paste error ?
>
>
>
> The following code in MethodMatchers.IntersectionMethodMatcher
> looks like a candidate:
>
>     public boolean isRuntime() {
> -        return a.isRuntime() || b.isRuntime();
> +       return a.isRuntime() && b.isRuntime();
>     }
>
> Roger
>
>
>
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest developments in
> Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more!
> http://www.apachecon.com/ _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer