Hi David,
Thanks for enlightening me on that. Only
RetentionPolicy.RUNTIME annotations need the classes at runtime. From
this I understand that I have to read up more on annotations. Will do
that right away :)
Thanks
Manu
On 1/24/07, David Blevins <[EMAIL PROTECTED]> wrote:
On Jan 23, 2007, at 10:33 PM, Manu George wrote:
> Hi,
> I have a question on this. Is having annotations for container
> specific properties advisable? Won't this encourage developers to add
> annotations for everything and during porting to another container the
> container specific ones will need to be removed from the code?
Well that's part of the magic of annotations. The annotation classes
have to be there at compile time, but at run time when the class is
loaded if some of the annotation classes are not present the class
will simply load without those annotations and they won't be visible
to the running system.
I'm not sure we want to be adding OpenEJB-specific annotations just
yet (our descriptors are still heavily in flux), but if we did it'd
likely be one that allows the bean to specify which container it
would like to be deployed into.
-David
>
> Regards
> Manu
>
>
> On 1/24/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>> Right...so XML is immediately doable...excellent. But I am concerned
>> about the annotation only case which is a direction many are going
>> towards. We may wish to address this.
>>
>> Jeff
>>
>> David Blevins wrote:
>> >
>> > On Jan 23, 2007, at 5:22 PM, Jeff Genender wrote:
>> >
>> >> Any thoughts on a Clustered annotation for openejb? I need to
>> know, (or
>> >> any clustering solution) needs to know, which session beans
>> need to get
>> >> clustered...and an annotation and a flag/attribute on a per
>> bean basis
>> >> in the openejb-jar.xml would probably be appropriate. Thoughts?
>> >
>> > That's certainly something we can do at some point.
>> >
>> > For the here and now, there is already a general solution for
>> this. You
>> > can have as many containers as you want (including none at all),
>> each
>> > having it's own QoSs (such as clustering or not clustering) and
>> each
>> > bean can say which container it wants in it's openejb-jar.xml.
>> >
>> > I.e.
>> >
>> > <Container id="Default Stateful Container" ctype="STATEFUL">
>> > TimeOut 20
>> > PoolSize 100
>> > BulkPassivate 50
>> > </Container>
>> >
>> > <Container id="Default Stateful Container" ctype="STATEFUL">
>> > InstanceManager
>> > org.apache.openejb.core.stateful.ClusteredInstanceManager
>> > # any other properties you want
>> > </Container>
>> >
>> > then in your openejb-jar.xml
>> >
>> > <ejb-deployment ejb-name="FooBean" deployment-id="Foo"
>> > container-id="Default Stateful Container"/>
>> > <ejb-deployment ejb-name="BarBean" deployment-id="Bar"
>> > container-id="Clustered Stateful Container"/>
>> > <ejb-deployment ejb-name="BazBean" deployment-id="Baz"
>> > container-id="Clustered Stateful Container"/>
>> >
>> > The BarBean and BazBean would get deployed into the Clustered
>> Stateful
>> > Container and receive any QoSs that that container provides
>> (clustering
>> > and anything else it wants) and the FooBean would go into the
>> Default
>> > Stateful Container and not be clustered.
>> >
>> > You can do this exact thing via the Geronimo plan files. One
>> plan can
>> > add the default containers (if you want them) and you can have an
>> > entirely different plan add clusterable containers. And some
>> other plan
>> > in the future can add an even different set of containers if it
>> chooses
>> > and people will be able to deploy into them getting their QoSs.
>> >
>> > -David
>>
>
