springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Scheduler update #2

[Trevor C. <pr...@se...>]

>> RECOMMENDATION
>> --------------
>> 1. The scheduler's persistence mechanism should be part of the scheduler
>> configuration rather than as seperate methods (similiar to Quartz).  This
>> would mean that Chronos would need to be changed to set this
configuration.
>
>   The problem here is that, for example, CronScheduler supports both
>   persistent and non-persistent tasks at the same time.
>
>   But it's easy to change CronScheduler (by adding a configuration
>   option) to treat all tasks as persistent.
>
>   We can't support both methods at the same time with Quartz, can we?

No, Quartz does it at configuration time.  From a really high level, it's
basically "2 schedulers, 1 scheduling method" vs. "1 scheduler, 2 scheduling
methods".  From a user view, 2 methods means choosing persistence mechanism
in the use case, while 2 schedulers means the use case  uses a single
generic method and doesn't care about the type of scheduler (which can be
configured in Spring's context).  While both are effective and work, I think
the latter allows more flexibility and is closer to Spring's abstraction
model.


>> 4. Naming of jobs should be allowed but not required (allowing "simple"
>> usage").
>
>   Agreed. Would Quartz wrapper autogenerate names then?
Quartz doesn't, but I think Spring's "quartz-wrapper" should.  Complicating
"Chronos" doesn't make sense, and the overloaded method which will accept a
name will still allow implicit naming.


Trevor



--
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Scheduler update #2

[Ivan R. <iv...@we...>]

Trevor Cook wrote:

> Ivan, while you're working on the unit tests, would it be possible to post
> your current source (probably just as a zip in this thread) for comparing
> with how to reconcile it with Quartz.

   Sure. I don't have it with me at the moment. I'll send it later,
   when I get home.


> COMPARISON
> ----------
> Chronos is create explicitly as a cron scheduler.
> Quartz is created as a "generic" scheduler, using different trigger types to
> control scheduling type (SimpleTrigger vs CronTrigger).

   Chronos works like Quartz here. The only difference is that each
   scheduler supports a utility method to convert a textual
   representation of a schedule ("*/2 * * * *") into an instance of
   a class implementing Schedule.

   Internally, scheduler uses instances of Schedule (which is basically
   a trigger in the Quartz naming scheme). Any Schedule implementation
   can be used with any Scheduler implementation.


> Chronos allows a single parameter to be added to the job during creation,
> and does not appear to have a method of passing additional information when
> the task is actually run.

   When used with a wrapper Chronos calls methods, and you can send as
   many parameters as needed.



> RECOMMENDATION
> --------------
> 1. The scheduler's persistence mechanism should be part of the scheduler
> configuration rather than as seperate methods (similiar to Quartz).  This
> would mean that Chronos would need to be changed to set this configuration.

   The problem here is that, for example, CronScheduler supports both
   persistent and non-persistent tasks at the same time.

   But it's easy to change CronScheduler (by adding a configuration
   option) to treat all tasks as persistent.

   We can't support both methods at the same time with Quartz, can we?


> 2. The scheduling mechansim should use a task/trigger mechansim (similiar to
> Quartz).  Chronos could still provide a single type of trigger (Cron), but
> this would change the scheduling mechanism.

   OK (already there, as above).


> 3. No special interface should be required thus allowing any POJO to
> function as a job (similiar to Chronos).  I'm also thinking that Spring's
> bean handling could be used to mask any parameters passed to the job so that
> a map could be converted to actual objects (especially for Quartz where
> you're bascially doing "(cast)map.get(x)" for all parameters).

   Yes.


> 4. Naming of jobs should be allowed but not required (allowing "simple"
> usage").

   Agreed. Would Quartz wrapper autogenerate names then?

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

RE: [Springframework-developer] Scheduler update #2

[Trevor C. <pr...@se...>]

Ivan, while you're working on the unit tests, would it be possible to post
your current source (probably just as a zip in this thread) for comparing
with how to reconcile it with Quartz.

My early findings are based on assumptions I'm making about "Chronos".  If
any of my assumptions are incorrect, please let me know (I should be more
accurate once I can examine the source).


COMPARISON
----------
Chronos is create explicitly as a cron scheduler.
Quartz is created as a "generic" scheduler, using different trigger types to
control scheduling type (SimpleTrigger vs CronTrigger).

Chronos uses 2 different methods for creating tasks, one for "in-memory" and
one for "persistent".
Quartz uses a single scheduling mechanism.  The underlying store (ram or
jdbc) is determined by the schedulers configuration.

Chronos allows any POJO to be turned into a task by wrapping it.
Quartz requires objects to implement "Job" which contains a single method
"execute(JobExecutionContext context)".

Chronos allows a single parameter to be added to the job during creation,
and does not appear to have a method of passing additional information when
the task is actually run.
Quartz stores parameters with the Job, and also allows modifying the
"JobExecutionContext" just before execution through the use of a
"JobListener".

Quartz uses names for the tasks (and also has groups). Chronos does not
appear to have any naming for it's tasks.


RECOMMENDATION
--------------
1. The scheduler's persistence mechanism should be part of the scheduler
configuration rather than as seperate methods (similiar to Quartz).  This
would mean that Chronos would need to be changed to set this configuration.

2. The scheduling mechansim should use a task/trigger mechansim (similiar to
Quartz).  Chronos could still provide a single type of trigger (Cron), but
this would change the scheduling mechanism.

3. No special interface should be required thus allowing any POJO to
function as a job (similiar to Chronos).  I'm also thinking that Spring's
bean handling could be used to mask any parameters passed to the job so that
a map could be converted to actual objects (especially for Quartz where
you're bascially doing "(cast)map.get(x)" for all parameters).

4. Naming of jobs should be allowed but not required (allowing "simple"
usage").


Once I get the Chronos source-code, I'll try to make a few concrete
examples.  If there are no objections, I'll put the examples, initial Spring
scheduling interfaces, and Chronos code into the sandbox so everyone can see
it and make comments.  This will also require adding Quartz to Spring,
although this will only affect developer/cvs downloads (I won't be adding it
to the distribution build scripts).  Any objections?

Trevor

RE: [Springframework-developer] Scheduler update #2

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

+1 for a light-weight solution

Regards,
Dmitriy.

-----Original Message-----
From: Trevor Cook [mailto:pr...@se...] 
Sent: Monday, November 03, 2003 9:05 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Scheduler update #2


Thanks Ivan.  I've taken a quick look at the manual, and it looks pretty
good.  I think Rod covered all the things necessary for Spring, so assuming
those are met, I'd vote to have the simple scheduler (yours) inside Spring
("out-of-the-box"), with a Quartz wrapper available.

I'll dig a little deeper today and compare it to what might be needed for
Quartz (since that's what I use, and what everyone seems to be asking for).
However, a really light-weight option like yours is definately good for
Spring.

Trevor


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Ivan Ristic
Sent: November 3, 2003 6:59 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Scheduler update #2



> I don't think Spring should attempt to include a full-featured 
> scheduler.

   I agree with that, except that I wouldn't consider this scheduler to
   be full-featured :) Chronos is an attempt at a small library to
   satisfy the needs of most people so that they don't have to go out
   and learn more complex libraries.

   If you don't think that it should be a part of Spring I have no
   problem with that.


> However, there is an argument for including a convenient, readily
available,
> implementation of a scheduler abstraction. This gives the user the
benefits
> of pluggability in good Spring fashion.

   We'll see whether someone will come forward. Or, we may attempt to
   contact the Quartz people and seek their help/opinion.

--
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does
SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does
SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Scheduler update #2

[Trevor C. <pr...@se...>]

Thanks Ivan.  I've taken a quick look at the manual, and it looks pretty
good.  I think Rod covered all the things necessary for Spring, so assuming
those are met, I'd vote to have the simple scheduler (yours) inside Spring
("out-of-the-box"), with a Quartz wrapper available.

I'll dig a little deeper today and compare it to what might be needed for
Quartz (since that's what I use, and what everyone seems to be asking for).
However, a really light-weight option like yours is definately good for
Spring.

Trevor


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Ivan Ristic
Sent: November 3, 2003 6:59 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Scheduler update #2



> I don't think Spring should attempt to include a full-featured scheduler.

   I agree with that, except that I wouldn't consider this scheduler to
   be full-featured :) Chronos is an attempt at a small library to
   satisfy the needs of most people so that they don't have to go out
   and learn more complex libraries.

   If you don't think that it should be a part of Spring I have no
   problem with that.


> However, there is an argument for including a convenient, readily
available,
> implementation of a scheduler abstraction. This gives the user the
benefits
> of pluggability in good Spring fashion.

   We'll see whether someone will come forward. Or, we may attempt to
   contact the Quartz people and seek their help/opinion.

--
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Scheduler update #2

[Ivan R. <iv...@we...>]

Rod Johnson wrote:

> I meant that Chronos was small, not a "full-featured scheduler", and that is
> good. Therefore it could potentially be part of Spring.

   Oh, right. Sorry about that, I'll try to pay more attention to what
   you're actually saying :)

   I'll work to finish it by the end of the week and then we'll see how
   it fares.

   But I too wouldn't include it without a Quartz support.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [Springframework-developer] Scheduler update #2

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

Ivan,

I meant that Chronos was small, not a "full-featured scheduler", and that is
good. Therefore it could potentially be part of Spring.

Regards,
Rod

----- Original Message ----- 
From: "Ivan Ristic" <iv...@we...>
To: <spr...@li...>
Sent: Monday, November 03, 2003 11:59 AM
Subject: Re: [Springframework-developer] Scheduler update #2


>
> > I don't think Spring should attempt to include a full-featured
scheduler.
>
>    I agree with that, except that I wouldn't consider this scheduler to
>    be full-featured :) Chronos is an attempt at a small library to
>    satisfy the needs of most people so that they don't have to go out
>    and learn more complex libraries.
>
>    If you don't think that it should be a part of Spring I have no
>    problem with that.
>
>
> > However, there is an argument for including a convenient, readily
available,
> > implementation of a scheduler abstraction. This gives the user the
benefits
> > of pluggability in good Spring fashion.
>
>    We'll see whether someone will come forward. Or, we may attempt to
>    contact the Quartz people and seek their help/opinion.
>
> -- 
> ModSecurity (http://www.modsecurity.org)
> [ Open source IDS for Web applications ]
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Scheduler update #2

[Cameron B. <ca...@da...>]

At first I was thinking that the better approach was to include an 
'out-of-the-box' plugin for quartz, since it is a system that I have 
used before.

though after reading the Chronos manual, I think that something really 
simple like that may be a very good idea.

I would still like to see spring provide support for Quartz :)

Cameron.

Ivan Ristic wrote:

>
>> I don't think Spring should attempt to include a full-featured 
>> scheduler.
>
>
>   I agree with that, except that I wouldn't consider this scheduler to
>   be full-featured :) Chronos is an attempt at a small library to
>   satisfy the needs of most people so that they don't have to go out
>   and learn more complex libraries.
>
>   If you don't think that it should be a part of Spring I have no
>   problem with that.
>
>
>> However, there is an argument for including a convenient, readily 
>> available,
>> implementation of a scheduler abstraction. This gives the user the 
>> benefits
>> of pluggability in good Spring fashion.
>
>
>   We'll see whether someone will come forward. Or, we may attempt to
>   contact the Quartz people and seek their help/opinion.
>


-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]

Re: [Springframework-developer] Scheduler update #2

[Ivan R. <iv...@we...>]

> I don't think Spring should attempt to include a full-featured scheduler.

   I agree with that, except that I wouldn't consider this scheduler to
   be full-featured :) Chronos is an attempt at a small library to
   satisfy the needs of most people so that they don't have to go out
   and learn more complex libraries.

   If you don't think that it should be a part of Spring I have no
   problem with that.


> However, there is an argument for including a convenient, readily available,
> implementation of a scheduler abstraction. This gives the user the benefits
> of pluggability in good Spring fashion.

   We'll see whether someone will come forward. Or, we may attempt to
   contact the Quartz people and seek their help/opinion.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[Springframework-developer] How to use the ProxyFactory to enhance an instance

[Cameron B. <ca...@da...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
I was experimenting with generating AOP proxies.<br>
<br>
I want to create a proxy that is a superclass of an action, to allow me
to add transactional interceptors.<br>
<br>
I tried using <br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Object action = createAction();<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ProxyFactory proxyFactory = new ProxyFactory(action);<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; proxyFactory.addInterceptor(.. my interceptor ...);<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; return proxyFactory.getProxy();<br>
<br>
though this uses a J2SE proxy, which only works on the defined
interfaces.<br>
<br>
I tried to get the aop proxy factory to use cblib by doing this :<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Object action = createAction();<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ProxyFactory proxyFactory = new ProxyFactory(action);<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; proxyFactory.setInterfaces(new Class[]{});<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; proxyFactory.addInterceptor(transactionInterceptor);<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; proxyFactory.addInterceptor(new InvokerInterceptor(action));<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; return proxyFactory.getProxy();<br>
<br>
to create a proxy that has a target, but I need to remove the
interfaces otherwise a J2SE proxy will be created.<br>
<br>
This works ok, except for the fact that I am using an instance of the
action for the target, and cglib creates a new instance from the call
to enhance<br>
<br>
Enhancer.enhance(config.getTarget().getClass(),
config.getProxiedInterfaces(), ...)<br>
<br>
Is there any way that the proxy factory can be rigged to allow
specification of a target class, without an instance, then instead of
me creating an instance, cglib can create it for me ?<br>
<br>
Something like<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Class actionClazz = getActionClass()<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ProxyFactory proxyFactory = new ProxyFactory(actionClazz);&nbsp; <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; proxyFactory.addInterceptor(transactionInterceptor);<br>
&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; proxyFactory.addInterceptor(new
ProxyTargetInvokerInterceptor());<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; return proxyFactory.getProxy();<br>
<br>
Though I don't know how the invoker interceptor will work, since there
is no actual target external to the proxy.<br>
Maybe a new ProxyTargetInvokerInterceptor() could be added.&nbsp; Without
it, invocations on the proxy would be exhibit the same behaviour as if
an&nbsp; InvokerInterceptor didn't exist at all.<br>
<br>
I dunno if I have made this very clear.. I am new to the AOP
terminoligy .<br>
<br>
Cameron.
<style type="text/css"><!--code { font-family: Courier New, Courier; font-size: 10pt; margin: 0px; }-->
  </style><!-- ======================================================== -->
<!-- = Java Sourcecode to HTML automatically converted code = --><!-- =   Java to HTML Converter V3.2 2003 by Markus Gebhard  ma...@ja...   = -->
<!-- =     Further information: http://www.java2html.de     = -->
<center> </center>
<br>
<pre cols="72" class="moz-signature">-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler <a class="moz-txt-link-freetext" href="http://www.martinfowler.com/distributedComputing/refactoring.pdf">http://www.martinfowler.com/distributedComputing/refactoring.pdf</a>]</pre>
</body>
</html>

Re: [Springframework-developer] Scheduler update #2

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

Ivan,

The fact that it has a clear scope and is intended to be lightweight makes
it a good candidate to be the "out-of-the-box" implementation of any Spring
scheduler interface.

I don't think Spring should attempt to include a full-featured scheduler.
However, there is an argument for including a convenient, readily available,
implementation of a scheduler abstraction. This gives the user the benefits
of pluggability in good Spring fashion.

Regards,
Rod

----- Original Message ----- 
From: "Ivan Ristic" <iv...@we...>
To: <spr...@li...>
Sent: Monday, November 03, 2003 10:15 AM
Subject: Re: [Springframework-developer] Scheduler update #2


>
> > I would probably make it a separate project and download within Spring,
> > spring-scheduler, dependent on the main codebase.
>
>    Why not in the main project? Having that functionality out of the
>    box is very convenient.
>
>
> > - Volume of code. If there's lots of code, it's a stronger argument for
> > putting it outside the main codebase.
>
>    It's actually rather small in size. Compiled classes are around
>    30K at the moment.
>
>
> > - Any dependencies it introduces.
>
>    None (not counting commons-logging).
>
>
> > - Unit test coverage. As our target is to go above 80% for 1.0 RC1, new
code
> > must have this kind of level of test coverage, verified via Clover.
>
>    I'll look into that, add tests to the scheduler and come back later.
>
>
> > - Your commitment to maintaining it, providing forum/list support etc.
>
>    No problem. But I do plan *not* to expand its functionality
>    significantly. It exists only to be lightweight, and those who need
>    more should look at more capable projects (eg Quartz).
>
> -- 
> ModSecurity (http://www.modsecurity.org)
> [ Open source IDS for Web applications ]
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Scheduler update #2

[Ivan R. <iv...@we...>]

> I would probably make it a separate project and download within Spring,
> spring-scheduler, dependent on the main codebase.

   Why not in the main project? Having that functionality out of the
   box is very convenient.


> - Volume of code. If there's lots of code, it's a stronger argument for
> putting it outside the main codebase.

   It's actually rather small in size. Compiled classes are around
   30K at the moment.


> - Any dependencies it introduces.

   None (not counting commons-logging).


> - Unit test coverage. As our target is to go above 80% for 1.0 RC1, new code
> must have this kind of level of test coverage, verified via Clover.

   I'll look into that, add tests to the scheduler and come back later.


> - Your commitment to maintaining it, providing forum/list support etc.

   No problem. But I do plan *not* to expand its functionality
   significantly. It exists only to be lightweight, and those who need
   more should look at more capable projects (eg Quartz).

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [Springframework-developer] Scheduler update #2

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

Ivan,

Thanks for the update.

> Will the scheduler be accepted as a part of Spring?

We should probably take a vote on this.

I would probably make it a separate project and download within Spring,
spring-scheduler, dependent on the main codebase. Other crucial things are:

- Code review.
- Volume of code. If there's lots of code, it's a stronger argument for
putting it outside the main codebase.
- Any dependencies it introduces.
- Unit test coverage. As our target is to go above 80% for 1.0 RC1, new code
must have this kind of level of test coverage, verified via Clover.
- Your commitment to maintaining it, providing forum/list support etc.

> I am all for having pluggable scheduler, so people can choose the one
> they like. Is anyone willing to contribute a Quartz wrapper? Now would
> be a very good time to get the abstraction interfaces right.
+1

I think abstraction interfaces are very important, and consistent with
Spring's approach in general.

Providing a default scheduler implementation as standard might flow from
that.

Regards,
Rod

[Springframework-developer] maven project.xml

[dan l. <dan...@ya...>]

Hi,
I'm using spring, &did a checkout.
project.xml doesn't seem to list these dependencies:
      <id>commons-fileupload</id>
      <id>commons-pool</id>
      <id>cos</id>
      <id>qdox</id>
      <id>ant</id>
Also, it gets hibernate-2.0-final, which isn't recent
enough to contain
net.sf.hibernate.tool.hbm2ddl.DatabaseMetadata, see:
org.springframework.orm.hibernate.LocalSessionFactoryBean

Also, it gets easymock-0.8, which isn't recent enough
to accomodate 
the usage in:
org.springframework.jdbc.core.JdbcTemplaceTestSuite

Dan 

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

[Springframework-developer] Re: Autowiring and dependency checks

[roger h. <apo...@sn...>]

Hi Juergen

As I've just been looking at the code in AbstractApplicationContext, I
noticed where the new method that you mentioned, getBeansOfType(), is called
in refreshListeners() - & I am wondering if on occasions it might be useful
to be able to refine the collection of instances it returns, rather than the
eager result of anything it can find - singleton, prototype, FactoryBean
generated or not ?

In the case of registering ApplicationListeners, I presume the net
effect will be that any prototype instances returned and registered,
will then just get lost to the GC, since no application code will ever get
to reference them.  But in other situations it may be more important to be
able to discriminate - perhaps using:

getBeansOfType(Class type, boolean singletons)

or even:

getBeansOfType(Class type, boolean singletons, boolean factoryBeanObjects)

Just a thought.

Btw, as this appears to be the only reference to addListener() within
AbstractApplicationContext, what's the rational for registering eligible
singleton beans as listeners, but not prototypes ?

Roger




"jürgen höller [werk3AT]" <jue...@we...> wrote in message
news:420...@ma......
> I've committed all of the changes, except the optional object dependencies
docu stuff. FactoryBean has a getObjectType method now, returning an advance
guess on which type getObject will return (or null if not known). That is
particularly useful for prototype FactoryBeans that create new instances on
each getObject call; autowiring will still work if they implement
getObjectType correctly.
>
> For singleton FactoryBeans, autowiring will check the created singletons
themselves if getObjectType returns null, as singletons are assumed to be
created on initialization anyway -- checking them on autowiring will not
incur an inefficiency. That way, DataSource dependencies will automatically
get resolved with a JndiObjectFactoryBean, even though the type is not known
in advance with the latter. Note that getObjectType will be invoked on the
fully configured FactoryBean, it can therefore rely on initialization.
>
> Everyone who's interested, please it give this stuff a try -- it works
pretty nicely with one of our werk3AT apps (although we won't use autowiring
in the end as we believe in the value of explicit associations; we will use
dependency checks though). Note that you can still set explicit associations
for dependencies that autowire can't resolve; autowire will then just
address all remaining dependencies. And as already suggested, it will ignore
dependencies where no matching bean is found, allowing for optional
dependencies. Add dependency-check="objects" for strict autowiring that
requires all dependencies to be satisfied.
>
> Juergen
>
>
> -----Ursprüngliche Nachricht-----
> Von: Rod Johnson [mailto:rod...@in...]
> Gesendet: Do 30.10.2003 11:31
> An: spr...@li...
> Cc:
> Betreff: Re: [Springframework-developer] Autowiring and dependency checks
>
>
>
> Juergen,
>
> I basically agree with your points.
>
> > So as a summary, I propose the following changes:
> > 1. "default-dependency-check" and "default-autowire" (already done but
not
> committed yet)
> Yes.
>
> > 2. ignore certain dependency types for autowiring, BeanFactory and
> ApplicationContext in particular (done too)
> Yes.
>
> > 3. explicitly document optional object dependencies in framework beans
to
> ease dependency check settings
>
> We may be able to do better than rely on docs.
>
> Some kind of metadata could be provided to autowiring specifying what's
> optional and what's not. This might make sense for framework components.
> Options:
> 1. Attach metadata attributes to properties with something like
> @OptionalProperty. We could compile this metadata in with Spring if our
> metadata support came on far enough so that our runtime information would
> find it. If there was no available metadata it would just assume that all
> properties were optional or required. This would have the advantage of
> defining a powerful way for users to specify whether or not their
properties
> were required.
> 2. Add BeanInfo like classes (checking whether there are any features we
can
> use from the JavaBeans BeanInfo stuff, which I think was painful to use)
> 3. Use XML or properties metadata packaged along with the classes.
>
> > 4. redefine autowiring to not complain if no matching bean found
(promote
> additional "objects" dependency check as an option)
>
> Yes.
>
> > 5. introduce a ListableBeanFactory.getBeansOfType(Class type) method and
> build autowire-by-type on it
> Yes, a getBeansOfType() method would be useful. And the FactoryBean type
> issue is overdue for clarification. Should the FactoryBean have a
getType()
> method on it, to return null if it can't know (as with JNDI)? Or a
> subinterface, TypedFactoryBean? This would enable most factory beans to
work
> with getBeanNamesOfType() as well. Of course even with JNDI the user could
> specify a type like javax.sql.DataSource and it would give the FactoryBean
a
> way of checking that the value in finds in JNDI makes sense.
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> NHYX?uw+m> xZ?*m ?+?j z?y!DD? P)brA?m?q ?z v

[Springframework-developer] Re: Plug'nPlay for AbstractApplicationContext & ListableBeanFactory

[roger h. <apo...@sn...>]

Hi Juergen

Many thanks for the explanation about
AbstractApplicationContext.getBeanFactory.

Just to check I've got it straight - would the following be an accurate
summary:
- ListableBeanFactory & ApplicationContext are client facing interfaces
designed to hide all things related to implementation.
- ListableBeanFactoryImpl & AbstractApplicationContext provide consistent
out-of-the-box BeanFactory implementations that are considered of essential
importance.
- Currently the linkage between these 2 default implementations happens to
be that one acts as a delegate class for the other, ie. the return type in
question.

The reworking of JdbcBeanFactory as a subclass of ListableBeanFactoryImpl,
obviously solves the wiring problem in this particular case - but it does
nothing for the general case of Plug'nPlay.  With the current arrangement,
the one thing I cannot do is achieve effective easy reuse of all that highly
crafted functionality that is so intricately wired up in AbstractBeanFactory
and ListableBeanFactoryImpl - I cannot wrap and delegate !

Aside from the implied name conflict, could you not preserve the original
intention of making the linkage between the two an internal interface:

interface ListableBeanFactoryImp extends ListableBeanFactory {

    public void ignoreDependencyType(Class type)

    public void addBeanPostProcessor(BeanPostProcessor beanPostProcessor)

    public final void destroySingletons()

}

The example that is actually motivating my thinking, is related to the AOP
stuff.  If I want try to add functionality to a BeanFactory so that it can
be aware of ProxyFactoryBean's for example, then the most simple approach
would be to use an XmlBeanFactory to read the bean definitions, but then to
wrap and delegate to this, from within an AOP aware BeanFactory.  The latter
could initialise itself via a BeanFactoryPostProcessor, and then provide
useful implementation support within the AOP module, ie it would again be
extending a ListableBeanFactoryImp interface, rather than anything client
facing.

As you say, all this can obviously be achieved by building BeanFactory's &
ApplicationContext's from scratch, but it seems a great shame not to be able
to reuse the ListableBeanFactoryImpl class - it has so much to offer ;)

Anyway, I am sure the you get the sense of what I am on about - I just hope
I am not missing something fundamental to the whole issue ;)

Roger


"jürgen höller [werk3AT]" <jue...@we...> wrote in message
news:420...@ma......
> First of all, thanks for your kind words, Roger -- I appreciate them! :-)
>
> Regarding AbstractApplicationContext.getBeanFactory: I've indeed changed
its return value from ListableBeanFactory to ListableBeanFactoryImpl a while
ago, reason being that AbstractApplicationContext needs some configuration
stuff that AbstractBeanFactory and ListableBeanFactoryImpl offer. The
BeanFactory and ListableBeanFactory interfaces are intended for client
applications that access beans, they do not and should not include any
factory configuration or lifecycle methods.
>
> In detail, AbstractApplicationContext needs to invoke the following bean
factory implementation methods:
>
> - ignoreDependencyType: to register ApplicationContext as dependency type
to ignore on autowiring (as it is set by the ApplicationContextAware
interface, not by a property value).
>
> - addBeanPostProcessor: to register BeanPostProcessors, both
ApplicationContextAwareProcessor and custom ones, before creating
application beans from the bean definitions.
>
> - destroySingletons: to destroy singleton instances on application context
shutdown; particularly important for resource holders like a BasicDataSource
or a LocalSessionFactoryBean.
>
> - Furthermore, the postProcessBeanFactory method in the
BeanFactoryPostProcessor interface declares a ListableBeanFactoryImpl
parameter to allow for access to all these bean factory configuration
methods. A ListableBeanFactory interface would be meaningless for this, as
you can't do any post-processing of bean definitions without access to them
and means to manipulate them.
>
> Let's not forget that is always possible to write an own
ApplicationContext implementation with any kind of bean factory underneath,
or a direct implementation of bean factory functionality instead of a
delegate, by not deriving from AbstractApplicationContext. The latter is
specifically intended for ListableBeanFactoryImpl delegates, providing rich
configuration functionality on top of them.
>
> Regarding JdbcBeanFactory: This one used a delegate
ListableBeanFactoryImpl underneath to be able to perform on-demand
refreshing. This is somewhat inconsistent with XmlBeanFactory's
implementation style: The latter derives from ListableBeanFactoryImpl and
adds various XML-related registerBeanDefinitions methods, leaving refresh
functionality to application contexts. IMO, that's a clear separation of
responsibilities: A BeanFactory is a low-level implementation; an
ApplicationContext builds higher-level functionality on top of it.
>
> Thus, I've changed JdbcBeanFactory to extend ListableBeanFactoryImpl and
provide a registerBeanDefinitions(sql) method. Of course, it still has the
former (dataSource,sql) constructor as a convenience. I don't think that
anyone used JdbcBeanFactory's on-demand refresh anyway (or even loading
beans from a database in the first place), so that change shouldn't hurt. So
you can use JdbcBeanFactory with AbstractApplicationContext too, as it is a
ListableBeanFactoryImpl now :-)
>
> Rod, do you agree with the rationale? I believe it's straightforward and
consistent, particularly now that JdbcBeanFactory has adopted
XmlBeanFactory's implementation style. I hope you don't object to
JdbcBeanFactory being a ListableBeanFactoryImpl; as I've said, I believe it
is important to provide consistent out-of-the-box BeanFactory
implementations (i.e. no refresh in bean factories but just in application
contexts).
>
> Juergen
>
>
> -----Ursprüngliche Nachricht-----
> Von: Rod Johnson [mailto:rod...@in...]
> Gesendet: Sa 01.11.2003 17:32
> An: spr...@li...
> Cc:
> Betreff: Re: [Springframework-developer] Plug'nPlay for
AbstractApplicationContext & ListableBeanFactory
>
>
>
> Roger,
>
> > I've been lurking about for a fair while, being thoroughly impressed by
> > Springframework - the conception, the code, this excellent list, Rod's
> book,
> > in short the whole shebang - it seems quite a while since I encountered
a
> > project that more than anything, just seems to make me smile ;)  Many
> > thanks.
>
> Thanks. Made me smile :-)
>
> > First up is the subject line & the method
> > AbstractApplicationContext.getBeanFactory()
> > I am wondering if the signature for this method might have been changed
> > inadvertently ?  Prior to the introduction of support for
> > BeanFactoryPostProcessor's, the method was returning the
> ListableBeanFactory
> > interface, but thereafter it has been ListableBeanFactoryImpl.  As the
> > latter comes with a final modifier on each of the methods implementing
> that
> > interface, the opportunity for Plug'nPlay appears to have gone
missing...
> &
> > if I'm not mistaken, a first casualty would be the loss of a
> JdbcBeanFactory
> > within an AbstractApplicationContext.  Can someone shed some
> > light - am I just missing something ?
>
> I'll leave this one to Juergen, but I did notice it in passing and
> wondered...
>
> >
> > By the way, on my wanderings I noticed the following typo in
> > AbstractBeanDefinition.equals()
>
> Thanks, fixed it. Ah, the beauty of open source. That code isn't currently
> used btw, it was intended to allow for dynamic reconfiguration eventually.
> There would have been an argument for zapping it for now, actually.
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> NHY??X'u?w+m?$>  xZ+? *.m?k +?^? j?z^?y! DD??i ^P)brA?m?q ?z v

[Springframework-developer] Scheduler update #2

[Ivan R. <iv...@we...>]

I've attached a rough user manual for the scheduler I have been working 
on, and I have allocated certain amount of time to finish it. The manual
should should give you an idea of how will the schedule be used.

Any comments before I go and finish this?

Also:

Will the scheduler be accepted as a part of Spring?

I am all for having pluggable scheduler, so people can choose the one
they like. Is anyone willing to contribute a Quartz wrapper? Now would
be a very good time to get the abstraction interfaces right.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [Springframework-developer] Plug'nPlay for AbstractApplicationContext & ListableBeanFactory

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

Rmlyc3Qgb2YgYWxsLCB0aGFua3MgZm9yIHlvdXIga2luZCB3b3JkcywgUm9nZXIgLS0gSSBhcHBy
ZWNpYXRlIHRoZW0hIDotKQ0KIA0KUmVnYXJkaW5nIEFic3RyYWN0QXBwbGljYXRpb25Db250ZXh0
LmdldEJlYW5GYWN0b3J5OiBJJ3ZlIGluZGVlZCBjaGFuZ2VkIGl0cyByZXR1cm4gdmFsdWUgZnJv
bSBMaXN0YWJsZUJlYW5GYWN0b3J5IHRvIExpc3RhYmxlQmVhbkZhY3RvcnlJbXBsIGEgd2hpbGUg
YWdvLCByZWFzb24gYmVpbmcgdGhhdCBBYnN0cmFjdEFwcGxpY2F0aW9uQ29udGV4dCBuZWVkcyBz
b21lIGNvbmZpZ3VyYXRpb24gc3R1ZmYgdGhhdCBBYnN0cmFjdEJlYW5GYWN0b3J5IGFuZCBMaXN0
YWJsZUJlYW5GYWN0b3J5SW1wbCBvZmZlci4gVGhlIEJlYW5GYWN0b3J5IGFuZCBMaXN0YWJsZUJl
YW5GYWN0b3J5IGludGVyZmFjZXMgYXJlIGludGVuZGVkIGZvciBjbGllbnQgYXBwbGljYXRpb25z
IHRoYXQgYWNjZXNzIGJlYW5zLCB0aGV5IGRvIG5vdCBhbmQgc2hvdWxkIG5vdCBpbmNsdWRlIGFu
eSBmYWN0b3J5IGNvbmZpZ3VyYXRpb24gb3IgbGlmZWN5Y2xlIG1ldGhvZHMuDQogDQpJbiBkZXRh
aWwsIEFic3RyYWN0QXBwbGljYXRpb25Db250ZXh0IG5lZWRzIHRvIGludm9rZSB0aGUgZm9sbG93
aW5nIGJlYW4gZmFjdG9yeSBpbXBsZW1lbnRhdGlvbiBtZXRob2RzOg0KIA0KLSBpZ25vcmVEZXBl
bmRlbmN5VHlwZTogdG8gcmVnaXN0ZXIgQXBwbGljYXRpb25Db250ZXh0IGFzIGRlcGVuZGVuY3kg
dHlwZSB0byBpZ25vcmUgb24gYXV0b3dpcmluZyAoYXMgaXQgaXMgc2V0IGJ5IHRoZSBBcHBsaWNh
dGlvbkNvbnRleHRBd2FyZSBpbnRlcmZhY2UsIG5vdCBieSBhIHByb3BlcnR5IHZhbHVlKS4NCiAN
Ci0gYWRkQmVhblBvc3RQcm9jZXNzb3I6IHRvIHJlZ2lzdGVyIEJlYW5Qb3N0UHJvY2Vzc29ycywg
Ym90aCBBcHBsaWNhdGlvbkNvbnRleHRBd2FyZVByb2Nlc3NvciBhbmQgY3VzdG9tIG9uZXMsIGJl
Zm9yZSBjcmVhdGluZyBhcHBsaWNhdGlvbiBiZWFucyBmcm9tIHRoZSBiZWFuIGRlZmluaXRpb25z
Lg0KIA0KLSBkZXN0cm95U2luZ2xldG9uczogdG8gZGVzdHJveSBzaW5nbGV0b24gaW5zdGFuY2Vz
IG9uIGFwcGxpY2F0aW9uIGNvbnRleHQgc2h1dGRvd247IHBhcnRpY3VsYXJseSBpbXBvcnRhbnQg
Zm9yIHJlc291cmNlIGhvbGRlcnMgbGlrZSBhIEJhc2ljRGF0YVNvdXJjZSBvciBhIExvY2FsU2Vz
c2lvbkZhY3RvcnlCZWFuLg0KIA0KLSBGdXJ0aGVybW9yZSwgdGhlIHBvc3RQcm9jZXNzQmVhbkZh
Y3RvcnkgbWV0aG9kIGluIHRoZSBCZWFuRmFjdG9yeVBvc3RQcm9jZXNzb3IgaW50ZXJmYWNlIGRl
Y2xhcmVzIGEgTGlzdGFibGVCZWFuRmFjdG9yeUltcGwgcGFyYW1ldGVyIHRvIGFsbG93IGZvciBh
Y2Nlc3MgdG8gYWxsIHRoZXNlIGJlYW4gZmFjdG9yeSBjb25maWd1cmF0aW9uIG1ldGhvZHMuIEEg
TGlzdGFibGVCZWFuRmFjdG9yeSBpbnRlcmZhY2Ugd291bGQgYmUgbWVhbmluZ2xlc3MgZm9yIHRo
aXMsIGFzIHlvdSBjYW4ndCBkbyBhbnkgcG9zdC1wcm9jZXNzaW5nIG9mIGJlYW4gZGVmaW5pdGlv
bnMgd2l0aG91dCBhY2Nlc3MgdG8gdGhlbSBhbmQgbWVhbnMgdG8gbWFuaXB1bGF0ZSB0aGVtLg0K
IA0KTGV0J3Mgbm90IGZvcmdldCB0aGF0IGlzIGFsd2F5cyBwb3NzaWJsZSB0byB3cml0ZSBhbiBv
d24gQXBwbGljYXRpb25Db250ZXh0IGltcGxlbWVudGF0aW9uIHdpdGggYW55IGtpbmQgb2YgYmVh
biBmYWN0b3J5IHVuZGVybmVhdGgsIG9yIGEgZGlyZWN0IGltcGxlbWVudGF0aW9uIG9mIGJlYW4g
ZmFjdG9yeSBmdW5jdGlvbmFsaXR5IGluc3RlYWQgb2YgYSBkZWxlZ2F0ZSwgYnkgbm90IGRlcml2
aW5nIGZyb20gQWJzdHJhY3RBcHBsaWNhdGlvbkNvbnRleHQuIFRoZSBsYXR0ZXIgaXMgc3BlY2lm
aWNhbGx5IGludGVuZGVkIGZvciBMaXN0YWJsZUJlYW5GYWN0b3J5SW1wbCBkZWxlZ2F0ZXMsIHBy
b3ZpZGluZyByaWNoIGNvbmZpZ3VyYXRpb24gZnVuY3Rpb25hbGl0eSBvbiB0b3Agb2YgdGhlbS4N
CiANClJlZ2FyZGluZyBKZGJjQmVhbkZhY3Rvcnk6IFRoaXMgb25lIHVzZWQgYSBkZWxlZ2F0ZSBM
aXN0YWJsZUJlYW5GYWN0b3J5SW1wbCB1bmRlcm5lYXRoIHRvIGJlIGFibGUgdG8gcGVyZm9ybSBv
bi1kZW1hbmQgcmVmcmVzaGluZy4gVGhpcyBpcyBzb21ld2hhdCBpbmNvbnNpc3RlbnQgd2l0aCBY
bWxCZWFuRmFjdG9yeSdzIGltcGxlbWVudGF0aW9uIHN0eWxlOiBUaGUgbGF0dGVyIGRlcml2ZXMg
ZnJvbSBMaXN0YWJsZUJlYW5GYWN0b3J5SW1wbCBhbmQgYWRkcyB2YXJpb3VzIFhNTC1yZWxhdGVk
IHJlZ2lzdGVyQmVhbkRlZmluaXRpb25zIG1ldGhvZHMsIGxlYXZpbmcgcmVmcmVzaCBmdW5jdGlv
bmFsaXR5IHRvIGFwcGxpY2F0aW9uIGNvbnRleHRzLiBJTU8sIHRoYXQncyBhIGNsZWFyIHNlcGFy
YXRpb24gb2YgcmVzcG9uc2liaWxpdGllczogQSBCZWFuRmFjdG9yeSBpcyBhIGxvdy1sZXZlbCBp
bXBsZW1lbnRhdGlvbjsgYW4gQXBwbGljYXRpb25Db250ZXh0IGJ1aWxkcyBoaWdoZXItbGV2ZWwg
ZnVuY3Rpb25hbGl0eSBvbiB0b3Agb2YgaXQuDQogDQpUaHVzLCBJJ3ZlIGNoYW5nZWQgSmRiY0Jl
YW5GYWN0b3J5IHRvIGV4dGVuZCBMaXN0YWJsZUJlYW5GYWN0b3J5SW1wbCBhbmQgcHJvdmlkZSBh
IHJlZ2lzdGVyQmVhbkRlZmluaXRpb25zKHNxbCkgbWV0aG9kLiBPZiBjb3Vyc2UsIGl0IHN0aWxs
IGhhcyB0aGUgZm9ybWVyIChkYXRhU291cmNlLHNxbCkgY29uc3RydWN0b3IgYXMgYSBjb252ZW5p
ZW5jZS4gSSBkb24ndCB0aGluayB0aGF0IGFueW9uZSB1c2VkIEpkYmNCZWFuRmFjdG9yeSdzIG9u
LWRlbWFuZCByZWZyZXNoIGFueXdheSAob3IgZXZlbiBsb2FkaW5nIGJlYW5zIGZyb20gYSBkYXRh
YmFzZSBpbiB0aGUgZmlyc3QgcGxhY2UpLCBzbyB0aGF0IGNoYW5nZSBzaG91bGRuJ3QgaHVydC4g
U28geW91IGNhbiB1c2UgSmRiY0JlYW5GYWN0b3J5IHdpdGggQWJzdHJhY3RBcHBsaWNhdGlvbkNv
bnRleHQgdG9vLCBhcyBpdCBpcyBhIExpc3RhYmxlQmVhbkZhY3RvcnlJbXBsIG5vdyA6LSkNCiAN
ClJvZCwgZG8geW91IGFncmVlIHdpdGggdGhlIHJhdGlvbmFsZT8gSSBiZWxpZXZlIGl0J3Mgc3Ry
YWlnaHRmb3J3YXJkIGFuZCBjb25zaXN0ZW50LCBwYXJ0aWN1bGFybHkgbm93IHRoYXQgSmRiY0Jl
YW5GYWN0b3J5IGhhcyBhZG9wdGVkIFhtbEJlYW5GYWN0b3J5J3MgaW1wbGVtZW50YXRpb24gc3R5
bGUuIEkgaG9wZSB5b3UgZG9uJ3Qgb2JqZWN0IHRvIEpkYmNCZWFuRmFjdG9yeSBiZWluZyBhIExp
c3RhYmxlQmVhbkZhY3RvcnlJbXBsOyBhcyBJJ3ZlIHNhaWQsIEkgYmVsaWV2ZSBpdCBpcyBpbXBv
cnRhbnQgdG8gcHJvdmlkZSBjb25zaXN0ZW50IG91dC1vZi10aGUtYm94IEJlYW5GYWN0b3J5IGlt
cGxlbWVudGF0aW9ucyAoaS5lLiBubyByZWZyZXNoIGluIGJlYW4gZmFjdG9yaWVzIGJ1dCBqdXN0
IGluIGFwcGxpY2F0aW9uIGNvbnRleHRzKS4NCiANCkp1ZXJnZW4NCiANCg0KCS0tLS0tVXJzcHLD
vG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBSb2QgSm9obnNvbiBbbWFpbHRvOnJvZC5q
b2huc29uQGludGVyZmFjZTIxLmNvbV0gDQoJR2VzZW5kZXQ6IFNhIDAxLjExLjIwMDMgMTc6MzIg
DQoJQW46IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0K
CUNjOiANCglCZXRyZWZmOiBSZTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIFBsdWcnblBs
YXkgZm9yIEFic3RyYWN0QXBwbGljYXRpb25Db250ZXh0ICYgTGlzdGFibGVCZWFuRmFjdG9yeQ0K
CQ0KCQ0KDQoJUm9nZXIsDQoJDQoJPiBJJ3ZlIGJlZW4gbHVya2luZyBhYm91dCBmb3IgYSBmYWly
IHdoaWxlLCBiZWluZyB0aG9yb3VnaGx5IGltcHJlc3NlZCBieQ0KCT4gU3ByaW5nZnJhbWV3b3Jr
IC0gdGhlIGNvbmNlcHRpb24sIHRoZSBjb2RlLCB0aGlzIGV4Y2VsbGVudCBsaXN0LCBSb2Qncw0K
CWJvb2ssDQoJPiBpbiBzaG9ydCB0aGUgd2hvbGUgc2hlYmFuZyAtIGl0IHNlZW1zIHF1aXRlIGEg
d2hpbGUgc2luY2UgSSBlbmNvdW50ZXJlZCBhDQoJPiBwcm9qZWN0IHRoYXQgbW9yZSB0aGFuIGFu
eXRoaW5nLCBqdXN0IHNlZW1zIHRvIG1ha2UgbWUgc21pbGUgOykgIE1hbnkNCgk+IHRoYW5rcy4N
CgkNCglUaGFua3MuIE1hZGUgbWUgc21pbGUgOi0pDQoJDQoJPiBGaXJzdCB1cCBpcyB0aGUgc3Vi
amVjdCBsaW5lICYgdGhlIG1ldGhvZA0KCT4gQWJzdHJhY3RBcHBsaWNhdGlvbkNvbnRleHQuZ2V0
QmVhbkZhY3RvcnkoKQ0KCT4gSSBhbSB3b25kZXJpbmcgaWYgdGhlIHNpZ25hdHVyZSBmb3IgdGhp
cyBtZXRob2QgbWlnaHQgaGF2ZSBiZWVuIGNoYW5nZWQNCgk+IGluYWR2ZXJ0ZW50bHkgPyAgUHJp
b3IgdG8gdGhlIGludHJvZHVjdGlvbiBvZiBzdXBwb3J0IGZvcg0KCT4gQmVhbkZhY3RvcnlQb3N0
UHJvY2Vzc29yJ3MsIHRoZSBtZXRob2Qgd2FzIHJldHVybmluZyB0aGUNCglMaXN0YWJsZUJlYW5G
YWN0b3J5DQoJPiBpbnRlcmZhY2UsIGJ1dCB0aGVyZWFmdGVyIGl0IGhhcyBiZWVuIExpc3RhYmxl
QmVhbkZhY3RvcnlJbXBsLiAgQXMgdGhlDQoJPiBsYXR0ZXIgY29tZXMgd2l0aCBhIGZpbmFsIG1v
ZGlmaWVyIG9uIGVhY2ggb2YgdGhlIG1ldGhvZHMgaW1wbGVtZW50aW5nDQoJdGhhdA0KCT4gaW50
ZXJmYWNlLCB0aGUgb3Bwb3J0dW5pdHkgZm9yIFBsdWcnblBsYXkgYXBwZWFycyB0byBoYXZlIGdv
bmUgbWlzc2luZy4uLg0KCSYNCgk+IGlmIEknbSBub3QgbWlzdGFrZW4sIGEgZmlyc3QgY2FzdWFs
dHkgd291bGQgYmUgdGhlIGxvc3Mgb2YgYQ0KCUpkYmNCZWFuRmFjdG9yeQ0KCT4gd2l0aGluIGFu
IEFic3RyYWN0QXBwbGljYXRpb25Db250ZXh0LiAgQ2FuIHNvbWVvbmUgc2hlZCBzb21lDQoJPiBs
aWdodCAtIGFtIEkganVzdCBtaXNzaW5nIHNvbWV0aGluZyA/DQoJDQoJSSdsbCBsZWF2ZSB0aGlz
IG9uZSB0byBKdWVyZ2VuLCBidXQgSSBkaWQgbm90aWNlIGl0IGluIHBhc3NpbmcgYW5kDQoJd29u
ZGVyZWQuLi4NCgkNCgk+DQoJPiBCeSB0aGUgd2F5LCBvbiBteSB3YW5kZXJpbmdzIEkgbm90aWNl
ZCB0aGUgZm9sbG93aW5nIHR5cG8gaW4NCgk+IEFic3RyYWN0QmVhbkRlZmluaXRpb24uZXF1YWxz
KCkNCgkNCglUaGFua3MsIGZpeGVkIGl0LiBBaCwgdGhlIGJlYXV0eSBvZiBvcGVuIHNvdXJjZS4g
VGhhdCBjb2RlIGlzbid0IGN1cnJlbnRseQ0KCXVzZWQgYnR3LCBpdCB3YXMgaW50ZW5kZWQgdG8g
YWxsb3cgZm9yIGR5bmFtaWMgcmVjb25maWd1cmF0aW9uIGV2ZW50dWFsbHkuDQoJVGhlcmUgd291
bGQgaGF2ZSBiZWVuIGFuIGFyZ3VtZW50IGZvciB6YXBwaW5nIGl0IGZvciBub3csIGFjdHVhbGx5
Lg0KCQ0KCVJlZ2FyZHMsDQoJUm9kDQoJDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YubmV0IGVtYWlsIGlz
IHNwb25zb3JlZCBieTogU0YubmV0IEdpdmViYWNrIFByb2dyYW0uDQoJRG9lcyBTb3VyY2VGb3Jn
ZS5uZXQgaGVscCB5b3UgYmUgbW9yZSBwcm9kdWN0aXZlPyAgRG9lcyBpdA0KCWhlbHAgeW91IGNy
ZWF0ZSBiZXR0ZXIgY29kZT8gICBTSEFSRSBUSEUgTE9WRSwgYW5kIGhlbHAgdXMgaGVscA0KCVlP
VSEgIENsaWNrIEhlcmU6IGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvZG9uYXRlLw0KCV9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJU3ByaW5nZnJhbWV3b3Jr
LWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3Rz
LnNvdXJjZWZvcmdlLm5ldA0KCWh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xp
c3RpbmZvL3NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXINCgkNCg0K

Re: [Springframework-developer] Bean factory getting access to its bean id

[Cameron B. <ca...@da...>]

Thanks .. see inline response.

jürgen höller [werk3AT] wrote:

>Cameron,
> 
>Good points. I've repeatedly considered relaxing that XML id requirement myself, BTW, to ease BeanNameUrlHandlerMapping-mapped controllers definitions with Spring's web MVC.
> 
>So I've just implemented the following changes:
> 
>- There's a BeanNameAware interface now, with a setBeanName method that gets called on initialization. BTW, the BeanFactory interface calls the canonical name "name" and alias names "aliases", while the XML bean definition format adopts the XML style of an id attribute, allowing for multiple aliases via a delimited "name" attribute.
> 
>  
>
Sounds good.

>- The "id" attribute is no longer required in the XML bean definition format. If no id is specified, the first name in the "name" attribute will be used as canonical name (all others as aliases). If no id and no name specified, an exception will get thrown. Note that you need to use the generic <ref bean=".../> syntax to reference any bean name, as the more restrictive <ref local="..."/> will be validated against local XML ids. In general, if you don't need to rely on XML id validation, always use <ref bean="..."/>.
> 
>  
>
Excellent.

>- Spring already had a PropertiesFactoryBean class for making a properties file in the class path available as Properties bean in the bean factory. I've reworked this to also support local properties via a "properties" bean property (to be filled via "<props>" in the XML case). It can also merge properties from a file with locally defined ones. You should be able to use that instead of your own PropertiesFactoryBean implementation. There's also a ResourcePropertiesFactoryBean that loads a properties file as application context resource (via ApplicationContext.getResourceByPath).
> 
>  
>
Thanks, that is a better idea.

>If noone objects, I will commit these changes to CVS tomorrow. I guess the "id" relaxation is debatable, but I'm strongly for it as my colleagues at werk3AT tend to use BeanNameUrlHandlerMapping a lot and have repeatedly complained about the need for an additional id attribute. Cameron faces a similar use case for WebWork actions; we should ease such stuff, even if XML ids are still recommended for normal beans.
> 
>  
>
I could live with it either way. Though I thaink that the ID should be 
optional since it isn't required in all cases.

>Juergen
> 
>
>	-----Ursprüngliche Nachricht----- 
>	Von: Cameron Braid [mailto:ca...@da...] 
>	Gesendet: Sa 01.11.2003 13:20 
>	An: spr...@li... 
>	Cc: 
>	Betreff: [[W3-SPAM]] - [Springframework-developer] Bean factory getting access to its bean id - Email found in subject
>	
>	
>
>	Is there any way that I can allow a bean factory to find out its id
>	attribute from the applicationContext.xml
>	
>	i.e. I am trying to get a grip on how spring works, and therefore I am
>	trying to write a little integration layer to make spring an action
>	factory for xwork, to allow me to use spring components and
>	interceptors.  I want to try and avoid repetition of configuration
>	wherever possible.
>	
>	I have it at the stage where I have a bean declaration like this :
>	
>	    <bean id="defaultActionTransactionAttributes"
>	class="com.datacodex.spring.beans.PropertiesFactoryBean">
>	        <property name="properties">
>	            <props>
>	                <prop key="execute">PROPAGATION_REQUIRED</prop>
>	            </props>
>	        </property>
>	    </bean>
>	
>	    <bean id="admin.SpringAdminAction" class="WebworkActionFactoryBean">
>	        <property
>	name="action"><value>/admin/SpringAdminAction</value></property>
>	        <property name="transactionManager"><ref
>	local="transactionManager"/></property>
>	        <property name="transactionAttributes"><ref
>	local="defaultActionTransactionAttributes"/></property>
>	    </bean>
>	
>	I would like to be able to access the id="admin.SpringAdminAction" value
>	(or the bean name attribute) from within the WebworkActionFactoryBean
>	therefore removing the need to have the extra 'action' property
>	<property name="action"><value>/admin/SpringAdminAction</value></property>.
>	
>	Idealy I would like to use the /admin/SpringAdminAction as the bean id
>	to make mapping from WebWork seamless, and without needing the
>	conversion to '.' style.
>	Therefore - is there any way that the bean id can be changed to allow
>	any valid xml string ?  Currently I am receiving an exception, from the
>	xml validator.  Can the id atttribuet be changed to be a
>	
>	[22:12:29]INFO [XmlBeanFactory] Loading XmlBeanFactory from InputStream
>	[[ReadStream com.caucho.vfs.FileReadStream@190a0d6]]
>	[22:12:29]ERROR[ContextLoader] Failed to initialize beans in application
>	context: Line 44 in XML document is invalid; nested exception is:
>	    org.xml.sax.SAXParseException: Attribute value
>	"/admin/SpringAdminAction" of type ID must be a name.
>	org.xml.sax.SAXParseException: Attribute value
>	"/admin/SpringAdminAction" of type ID must be a name.
>	    at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
>	    at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
>	    at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:76)
>	
>	The dtd states that it myst be a valid XML ID, and to use the optional
>	name attribute if you want an illegal name.  Though this will require
>	two identifyers for the bean, which I think is pointless.  Does the ID
>	have to be mandatory.  Can't a validation be implemented in java to
>	check that atleast the name or the id is supplied ?  Then the same for
>	the <!ATTLIST ref local IDREF #IMPLIED>  this could be a CDATA with java
>	based validation.
>	
>	Cheers,
>	
>	Cameron
>	
>	--
>	Any damn fool can write code that a computer can understand...
>	The trick is to write code that humans can understand.
>	[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]
>	
>	
>	
>	
>	
>	-------------------------------------------------------
>	This SF.net email is sponsored by: SF.net Giveback Program.
>	Does SourceForge.net help you be more productive?  Does it
>	help you create better code?   SHARE THE LOVE, and help us help
>	YOU!  Click Here: http://sourceforge.net/donate/
>	_______________________________________________
>	Springframework-developer mailing list
>	Spr...@li...
>	https://lists.sourceforge.net/lists/listinfo/springframework-developer
>	
>
>N?HY޵隊X???'???u??w?+?m?$>? ????????xZ+??޶??*.m騭?k?ۜ?+?????^??????jכz?^??y!?DD????݅?i??^??P)brAޭ?m??????q???z?ݢv?{?)?~??{
>+?ׯzZ)z???X??X??*k?x???Š?u?ޖ?^?X???(??~??zw???i????l???q???z???l?X??)ߣ?)?)?~??{
>+?ׯzZ)er==
>


-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]

[Springframework-developer] Singleton pre-instantiation, and general bean instantiation strategy

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

I was wondering about the rationale for (always) pre-instantiating 
singletons. Since most beans in my contexts are singletons, in practice, 
I find that this brings in the kitchen sink, even when a good portion of 
the stuff in the context will not be used. Now it is true that the more 
heavy-weight stuff, like the Hibernate session factory, is always used.

Have people found on-demand instantiation for singletons problematic in 
the past?  Once issue I can see is the fact that you get feedback on 
config problems much later, but this is manageable in a lot of cases 
(i.e by initially running in a pre-instantiation mode, and switching to 
on-demand later, etc.).

I was contrasting this strategy, and the general strategy for bean 
instantiation, with HiveMind's, where HiveMind create services 
completely on demand. That is, when you ask HiveMind for a service, what 
it gives you back is (always) just a proxy. The initial use of that 
service will force HiveMind to actually create it. If a service in 
HiveMind is created, and it's properties are populated with other 
services, those services will never actually be created until used. Of 
course in Spring, if you get a bean from the factory, any other beans it 
references as properties will also be created (unless you get into some 
custom usage of interceptors in a context). Both valid approaches, but I 
am just wondering if there is a use-case for supporting the HiveMind 
model as well?

Regards,
Colin

Re: [Springframework-developer] Plug'nPlay for AbstractApplicationContext & ListableBeanFactory

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

Roger,

> I've been lurking about for a fair while, being thoroughly impressed by
> Springframework - the conception, the code, this excellent list, Rod's
book,
> in short the whole shebang - it seems quite a while since I encountered a
> project that more than anything, just seems to make me smile ;)  Many
> thanks.

Thanks. Made me smile :-)

> First up is the subject line & the method
> AbstractApplicationContext.getBeanFactory()
> I am wondering if the signature for this method might have been changed
> inadvertently ?  Prior to the introduction of support for
> BeanFactoryPostProcessor's, the method was returning the
ListableBeanFactory
> interface, but thereafter it has been ListableBeanFactoryImpl.  As the
> latter comes with a final modifier on each of the methods implementing
that
> interface, the opportunity for Plug'nPlay appears to have gone missing...
&
> if I'm not mistaken, a first casualty would be the loss of a
JdbcBeanFactory
> within an AbstractApplicationContext.  Can someone shed some
> light - am I just missing something ?

I'll leave this one to Juergen, but I did notice it in passing and
wondered...

>
> By the way, on my wanderings I noticed the following typo in
> AbstractBeanDefinition.equals()

Thanks, fixed it. Ah, the beauty of open source. That code isn't currently
used btw, it was intended to allow for dynamic reconfiguration eventually.
There would have been an argument for zapping it for now, actually.

Regards,
Rod

Re: [Springframework-developer] Bean factory getting access to its bean id

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

Sounds reasonable. Thanks Juergen.

Please disregard my previous email...

Regards,
Rod

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Saturday, November 01, 2003 4:05 PM
Subject: Re: [Springframework-developer] Bean factory getting access to its
bean id


> Cameron,
>
> Good points. I've repeatedly considered relaxing that XML id requirement
myself, BTW, to ease BeanNameUrlHandlerMapping-mapped controllers
definitions with Spring's web MVC.
>
> So I've just implemented the following changes:
>
> - There's a BeanNameAware interface now, with a setBeanName method that
gets called on initialization. BTW, the BeanFactory interface calls the
canonical name "name" and alias names "aliases", while the XML bean
definition format adopts the XML style of an id attribute, allowing for
multiple aliases via a delimited "name" attribute.
>
> - The "id" attribute is no longer required in the XML bean definition
format. If no id is specified, the first name in the "name" attribute will
be used as canonical name (all others as aliases). If no id and no name
specified, an exception will get thrown. Note that you need to use the
generic <ref bean=".../> syntax to reference any bean name, as the more
restrictive <ref local="..."/> will be validated against local XML ids. In
general, if you don't need to rely on XML id validation, always use <ref
bean="..."/>.
>
> - Spring already had a PropertiesFactoryBean class for making a properties
file in the class path available as Properties bean in the bean factory.
I've reworked this to also support local properties via a "properties" bean
property (to be filled via "<props>" in the XML case). It can also merge
properties from a file with locally defined ones. You should be able to use
that instead of your own PropertiesFactoryBean implementation. There's also
a ResourcePropertiesFactoryBean that loads a properties file as application
context resource (via ApplicationContext.getResourceByPath).
>
> If noone objects, I will commit these changes to CVS tomorrow. I guess the
"id" relaxation is debatable, but I'm strongly for it as my colleagues at
werk3AT tend to use BeanNameUrlHandlerMapping a lot and have repeatedly
complained about the need for an additional id attribute. Cameron faces a
similar use case for WebWork actions; we should ease such stuff, even if XML
ids are still recommended for normal beans.
>
> Juergen
>
>
> -----Ursprüngliche Nachricht----- 
> Von: Cameron Braid [mailto:ca...@da...]
> Gesendet: Sa 01.11.2003 13:20
> An: spr...@li...
> Cc:
> Betreff: [[W3-SPAM]] - [Springframework-developer] Bean factory getting
access to its bean id - Email found in subject
>
>
>
> Is there any way that I can allow a bean factory to find out its id
> attribute from the applicationContext.xml
>
> i.e. I am trying to get a grip on how spring works, and therefore I am
> trying to write a little integration layer to make spring an action
> factory for xwork, to allow me to use spring components and
> interceptors.  I want to try and avoid repetition of configuration
> wherever possible.
>
> I have it at the stage where I have a bean declaration like this :
>
>     <bean id="defaultActionTransactionAttributes"
> class="com.datacodex.spring.beans.PropertiesFactoryBean">
>         <property name="properties">
>             <props>
>                 <prop key="execute">PROPAGATION_REQUIRED</prop>
>             </props>
>         </property>
>     </bean>
>
>     <bean id="admin.SpringAdminAction" class="WebworkActionFactoryBean">
>         <property
> name="action"><value>/admin/SpringAdminAction</value></property>
>         <property name="transactionManager"><ref
> local="transactionManager"/></property>
>         <property name="transactionAttributes"><ref
> local="defaultActionTransactionAttributes"/></property>
>     </bean>
>
> I would like to be able to access the id="admin.SpringAdminAction" value
> (or the bean name attribute) from within the WebworkActionFactoryBean
> therefore removing the need to have the extra 'action' property
> <property
name="action"><value>/admin/SpringAdminAction</value></property>.
>
> Idealy I would like to use the /admin/SpringAdminAction as the bean id
> to make mapping from WebWork seamless, and without needing the
> conversion to '.' style.
> Therefore - is there any way that the bean id can be changed to allow
> any valid xml string ?  Currently I am receiving an exception, from the
> xml validator.  Can the id atttribuet be changed to be a
>
> [22:12:29]INFO [XmlBeanFactory] Loading XmlBeanFactory from InputStream
> [[ReadStream com.caucho.vfs.FileReadStream@190a0d6]]
> [22:12:29]ERROR[ContextLoader] Failed to initialize beans in application
> context: Line 44 in XML document is invalid; nested exception is:
>     org.xml.sax.SAXParseException: Attribute value
> "/admin/SpringAdminAction" of type ID must be a name.
> org.xml.sax.SAXParseException: Attribute value
> "/admin/SpringAdminAction" of type ID must be a name.
>     at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
>     at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
>     at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:76)
>
> The dtd states that it myst be a valid XML ID, and to use the optional
> name attribute if you want an illegal name.  Though this will require
> two identifyers for the bean, which I think is pointless.  Does the ID
> have to be mandatory.  Can't a validation be implemented in java to
> check that atleast the name or the id is supplied ?  Then the same for
> the <!ATTLIST ref local IDREF #IMPLIED>  this could be a CDATA with java
> based validation.
>
> Cheers,
>
> Cameron
>
> --
> Any damn fool can write code that a computer can understand...
> The trick is to write code that humans can understand.
> [Martin Fowler
http://www.martinfowler.com/distributedComputing/refactoring.pdf]
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> NHum>xmjzyDPrqz{~{zzu–~zqz~{z

Re: [Springframework-developer] Bean factory getting access to its bean id

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

Cameron,

I see you've now found the alias mechanism. You can define an alias upfront
in the bean definition.

Interesting. The BeanDefinition was originally meant to be a SPI. In fact I
wanted to make it package-protected at one point. A BeanFactory is a pretty
simple thing, and whether or not it uses a BeanDefinition is really down to
the implementation. If we make user code dependent on that it means that
implementors of BeanFactory and ListableBeanFactory have an implicit
contract, which worries me.

However, I guess there are legitimate issues here. A BeanIdAware interface
might be better; however, it would also need to consider aliases. I did once
consider it, but was able to solve the problem in hand another way. Of
course multiple prototype instances might have the same id, so it couldn't
be used as an equality check.

Juergen, what do you think?

Regards,
Rod

----- Original Message ----- 
From: "Cameron Braid" <ca...@da...>
To: <spr...@li...>
Sent: Saturday, November 01, 2003 12:40 PM
Subject: Re: [Springframework-developer] Bean factory getting access to its
bean id


> I just wanted to add that I for the second part of my question
> (obtaining the bean ID for the current bean) I would implement
> BeanFactoryAware and iterate through all of the bean names, calling
> getBean(name) and checking for object identity.
>
> Does it make sense to add the ID and aliases into the
> AbstractBeanDefinition and then to create a BeanDefinitionAware
> interface that allows the bean to become aware ?
>
> Thanks again,
>
> Cameron
>
> Cameron Braid wrote:
>
> > Is there any way that I can allow a bean factory to find out its id
> > attribute from the applicationContext.xml
> >
> > i.e. I am trying to get a grip on how spring works, and therefore I am
> > trying to write a little integration layer to make spring an action
> > factory for xwork, to allow me to use spring components and
> > interceptors.  I want to try and avoid repetition of configuration
> > wherever possible.
> >
> > I have it at the stage where I have a bean declaration like this :
> >
> >    <bean id="defaultActionTransactionAttributes"
> > class="com.datacodex.spring.beans.PropertiesFactoryBean">
> >        <property name="properties">
> >            <props>
> >                <prop key="execute">PROPAGATION_REQUIRED</prop>
> >            </props>
> >        </property>
> >    </bean>
> >
> >    <bean id="admin.SpringAdminAction" class="WebworkActionFactoryBean">
> >        <property
> > name="action"><value>/admin/SpringAdminAction</value></property>
> >        <property name="transactionManager"><ref
> > local="transactionManager"/></property>
> >        <property name="transactionAttributes"><ref
> > local="defaultActionTransactionAttributes"/></property>
> >    </bean>
> >
> > I would like to be able to access the id="admin.SpringAdminAction"
> > value (or the bean name attribute) from within the
> > WebworkActionFactoryBean therefore removing the need to have the extra
> > 'action' property <property
> > name="action"><value>/admin/SpringAdminAction</value></property>.
> >
> > Idealy I would like to use the /admin/SpringAdminAction as the bean id
> > to make mapping from WebWork seamless, and without needing the
> > conversion to '.' style.
> > Therefore - is there any way that the bean id can be changed to allow
> > any valid xml string ?  Currently I am receiving an exception, from
> > the xml validator.  Can the id atttribuet be changed to be a
> >
> > [22:12:29]INFO [XmlBeanFactory] Loading XmlBeanFactory from
> > InputStream [[ReadStream com.caucho.vfs.FileReadStream@190a0d6]]
> > [22:12:29]ERROR[ContextLoader] Failed to initialize beans in
> > application context: Line 44 in XML document is invalid; nested
> > exception is:
> >    org.xml.sax.SAXParseException: Attribute value
> > "/admin/SpringAdminAction" of type ID must be a name.
> > org.xml.sax.SAXParseException: Attribute value
> > "/admin/SpringAdminAction" of type ID must be a name.
> >    at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
> >    at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
> >    at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:76)
> >
> > The dtd states that it myst be a valid XML ID, and to use the optional
> > name attribute if you want an illegal name.  Though this will require
> > two identifyers for the bean, which I think is pointless.  Does the ID
> > have to be mandatory.  Can't a validation be implemented in java to
> > check that atleast the name or the id is supplied ?  Then the same for
> > the <!ATTLIST ref local IDREF #IMPLIED>  this could be a CDATA with
> > java based validation.
> >
> > Cheers,
> >
> > Cameron
> >
>
>
> -- 
> Any damn fool can write code that a computer can understand...
> The trick is to write code that humans can understand.
> [Martin Fowler
http://www.martinfowler.com/distributedComputing/refactoring.pdf]
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] JIRA

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

KzEsIEkndmUgYWxyZWFkeSBjb25zaWRlcmVkIHN3aXRjaGluZyBmcm9tIHRoZSBTb3VyY2VGb3Jn
ZSBidWcgdHJhY2tlciB0byBKSVJBIGJlZm9yZSAtLSBzbyBNaWtlLCB0aGFua3MgZnJvbSBtZSB0
b28gOi0pDQogDQpKdWVyZ2VuDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0t
LS0tIA0KCVZvbjogUm9kIEpvaG5zb24gW21haWx0bzpyb2Quam9obnNvbkBpbnRlcmZhY2UyMS5j
b21dIA0KCUdlc2VuZGV0OiBTYSAwMS4xMS4yMDAzIDE3OjAxIA0KCUFuOiBzcHJpbmdmcmFtZXdv
cmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCglDYzogDQoJQmV0cmVmZjogUmU6
IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBKSVJBDQoJDQoJDQoNCglJJ20gaGFwcHkgd2l0
aCBKaXJhIGFuZCBBdGxhc3NpYW4uIFRoYW5rcyBNaWtlIQ0KCQ0KCQ0KCS0tLS0tIE9yaWdpbmFs
IE1lc3NhZ2UgLS0tLS0NCglGcm9tOiAiQWxlZiBBcmVuZHNlbiAoSlRlYW0pIiA8YWxlZkBqdGVh
bS5ubD4NCglUbzogPHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2Uu
bmV0Pg0KCVNlbnQ6IFNhdHVyZGF5LCBOb3ZlbWJlciAwMSwgMjAwMyAzOjI2IFBNDQoJU3ViamVj
dDogUkU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBKSVJBDQoJDQoJDQoJPiBXaWxsLCBJ
IHRoaW5rIHRoZSBtYWpvcml0eSBsaWtlcyBKaXJhIGFuZCBBdGxhc3NpYW4gKE1pa2UNCgk+IENh
bm5vbi1Ccm9va2VzKSBoYXMgYWxyZWFkeSBvZmZlcmVkIHRvIGxvb2sgaW50byBob3N0aW5nIGl0
IGF0IHRoZWlyDQoJPiBwbGFjZSwgc28gYXMgZmFyIGFzIEknbSBjb25jZXJuZWQsIHdlIGNvdWxk
IGdvIGFoZWFkLi4uDQoJPg0KCT4gUm9kLCBKdWVyZ2VuLCBldmVyeWJvZHkgZWxzZSBhZ3JlZXM/
DQoJPg0KCT4gQWxlZg0KCT4NCgk+ID4gLS0tLS1Pb3JzcHJvbmtlbGlqayBiZXJpY2h0LS0tLS0N
Cgk+ID4gVmFuOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyLWFkbWluQGxpc3RzLnNvdXJjZWZv
cmdlLm5ldA0KCT4gPiBbbWFpbHRvOnNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXItYWRtaW5AbGlz
dHMuc291cmNlZm9yZ2UubmV0XQ0KCT4gPiAgTmFtZW5zIEtvcHlsZW5rbywgRG1pdHJ5DQoJPiA+
IFZlcnpvbmRlbjogU2F0dXJkYXksIE5vdmVtYmVyIDAxLCAyMDAzIDI6MzAgUE0NCgk+ID4gQWFu
OiAnc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQnDQoJPiA+
IE9uZGVyd2VycDogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIEpJUkENCgk+ID4NCgk+ID4N
Cgk+ID4gU28sIHdoYXQgaGF2ZSB3ZSBkZWNpZGVkIG9uIEpJUkE/IEFuZCBob3cgd2UncmUgZ29p
bmcgdG8gcHJvY2VlZD8NCgk+ID4NCgk+ID4gUmVnYXJkcywNCgk+ID4gRG1pdHJpeS4NCgk+ID4N
Cgk+ID4NCgk+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KCT4gPiBUaGlzIFNGLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IFNGLm5l
dCBHaXZlYmFjayBQcm9ncmFtLg0KCT4gPiBEb2VzIFNvdXJjZUZvcmdlLm5ldCBoZWxwIHlvdSBi
ZSBtb3JlIHByb2R1Y3RpdmU/ICBEb2VzIGl0DQoJPiA+IGhlbHAgeW91IGNyZWF0ZSBiZXR0ZXIg
Y29kZT8gICBTSEFSRSBUSEUgTE9WRSwgYW5kIGhlbHAgdXMgaGVscA0KCT4gPiBZT1UhICBDbGlj
ayBIZXJlOiBodHRwOi8vc291cmNlZm9yZ2UubmV0L2RvbmF0ZS8NCgk+ID4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+ID4gU3ByaW5nZnJhbWV3b3Jr
LWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCgk+ID4gU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBs
aXN0cy5zb3VyY2Vmb3JnZS5uZXQNCgk+ID4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQv
bGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcg0KCT4gPg0KCT4NCgk+DQoJ
Pg0KCT4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQ0KCT4gVGhpcyBTRi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBTRi5uZXQgR2l2ZWJh
Y2sgUHJvZ3JhbS4NCgk+IERvZXMgU291cmNlRm9yZ2UubmV0IGhlbHAgeW91IGJlIG1vcmUgcHJv
ZHVjdGl2ZT8gIERvZXMgaXQNCgk+IGhlbHAgeW91IGNyZWF0ZSBiZXR0ZXIgY29kZT8gICBTSEFS
RSBUSEUgTE9WRSwgYW5kIGhlbHAgdXMgaGVscA0KCT4gWU9VISAgQ2xpY2sgSGVyZTogaHR0cDov
L3NvdXJjZWZvcmdlLm5ldC9kb25hdGUvDQoJPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KCT4gU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5n
IGxpc3QNCgk+IFNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0
DQoJPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdm
cmFtZXdvcmstZGV2ZWxvcGVyDQoJPg0KCQ0KCQ0KCQ0KCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCglUaGlzIFNGLm5ldCBlbWFpbCBpcyBz
cG9uc29yZWQgYnk6IFNGLm5ldCBHaXZlYmFjayBQcm9ncmFtLg0KCURvZXMgU291cmNlRm9yZ2Uu
bmV0IGhlbHAgeW91IGJlIG1vcmUgcHJvZHVjdGl2ZT8gIERvZXMgaXQNCgloZWxwIHlvdSBjcmVh
dGUgYmV0dGVyIGNvZGU/ICAgU0hBUkUgVEhFIExPVkUsIGFuZCBoZWxwIHVzIGhlbHANCglZT1Uh
ICBDbGljayBIZXJlOiBodHRwOi8vc291cmNlZm9yZ2UubmV0L2RvbmF0ZS8NCglfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCVNwcmluZ2ZyYW1ld29yay1k
ZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5z
b3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0
aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoJDQoNCg==

Re: [Springframework-developer] Bean factory getting access to its bean id

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

Q2FtZXJvbiwNCiANCkdvb2QgcG9pbnRzLiBJJ3ZlIHJlcGVhdGVkbHkgY29uc2lkZXJlZCByZWxh
eGluZyB0aGF0IFhNTCBpZCByZXF1aXJlbWVudCBteXNlbGYsIEJUVywgdG8gZWFzZSBCZWFuTmFt
ZVVybEhhbmRsZXJNYXBwaW5nLW1hcHBlZCBjb250cm9sbGVycyBkZWZpbml0aW9ucyB3aXRoIFNw
cmluZydzIHdlYiBNVkMuDQogDQpTbyBJJ3ZlIGp1c3QgaW1wbGVtZW50ZWQgdGhlIGZvbGxvd2lu
ZyBjaGFuZ2VzOg0KIA0KLSBUaGVyZSdzIGEgQmVhbk5hbWVBd2FyZSBpbnRlcmZhY2Ugbm93LCB3
aXRoIGEgc2V0QmVhbk5hbWUgbWV0aG9kIHRoYXQgZ2V0cyBjYWxsZWQgb24gaW5pdGlhbGl6YXRp
b24uIEJUVywgdGhlIEJlYW5GYWN0b3J5IGludGVyZmFjZSBjYWxscyB0aGUgY2Fub25pY2FsIG5h
bWUgIm5hbWUiIGFuZCBhbGlhcyBuYW1lcyAiYWxpYXNlcyIsIHdoaWxlIHRoZSBYTUwgYmVhbiBk
ZWZpbml0aW9uIGZvcm1hdCBhZG9wdHMgdGhlIFhNTCBzdHlsZSBvZiBhbiBpZCBhdHRyaWJ1dGUs
IGFsbG93aW5nIGZvciBtdWx0aXBsZSBhbGlhc2VzIHZpYSBhIGRlbGltaXRlZCAibmFtZSIgYXR0
cmlidXRlLg0KIA0KLSBUaGUgImlkIiBhdHRyaWJ1dGUgaXMgbm8gbG9uZ2VyIHJlcXVpcmVkIGlu
IHRoZSBYTUwgYmVhbiBkZWZpbml0aW9uIGZvcm1hdC4gSWYgbm8gaWQgaXMgc3BlY2lmaWVkLCB0
aGUgZmlyc3QgbmFtZSBpbiB0aGUgIm5hbWUiIGF0dHJpYnV0ZSB3aWxsIGJlIHVzZWQgYXMgY2Fu
b25pY2FsIG5hbWUgKGFsbCBvdGhlcnMgYXMgYWxpYXNlcykuIElmIG5vIGlkIGFuZCBubyBuYW1l
IHNwZWNpZmllZCwgYW4gZXhjZXB0aW9uIHdpbGwgZ2V0IHRocm93bi4gTm90ZSB0aGF0IHlvdSBu
ZWVkIHRvIHVzZSB0aGUgZ2VuZXJpYyA8cmVmIGJlYW49Ii4uLi8+IHN5bnRheCB0byByZWZlcmVu
Y2UgYW55IGJlYW4gbmFtZSwgYXMgdGhlIG1vcmUgcmVzdHJpY3RpdmUgPHJlZiBsb2NhbD0iLi4u
Ii8+IHdpbGwgYmUgdmFsaWRhdGVkIGFnYWluc3QgbG9jYWwgWE1MIGlkcy4gSW4gZ2VuZXJhbCwg
aWYgeW91IGRvbid0IG5lZWQgdG8gcmVseSBvbiBYTUwgaWQgdmFsaWRhdGlvbiwgYWx3YXlzIHVz
ZSA8cmVmIGJlYW49Ii4uLiIvPi4NCiANCi0gU3ByaW5nIGFscmVhZHkgaGFkIGEgUHJvcGVydGll
c0ZhY3RvcnlCZWFuIGNsYXNzIGZvciBtYWtpbmcgYSBwcm9wZXJ0aWVzIGZpbGUgaW4gdGhlIGNs
YXNzIHBhdGggYXZhaWxhYmxlIGFzIFByb3BlcnRpZXMgYmVhbiBpbiB0aGUgYmVhbiBmYWN0b3J5
LiBJJ3ZlIHJld29ya2VkIHRoaXMgdG8gYWxzbyBzdXBwb3J0IGxvY2FsIHByb3BlcnRpZXMgdmlh
IGEgInByb3BlcnRpZXMiIGJlYW4gcHJvcGVydHkgKHRvIGJlIGZpbGxlZCB2aWEgIjxwcm9wcz4i
IGluIHRoZSBYTUwgY2FzZSkuIEl0IGNhbiBhbHNvIG1lcmdlIHByb3BlcnRpZXMgZnJvbSBhIGZp
bGUgd2l0aCBsb2NhbGx5IGRlZmluZWQgb25lcy4gWW91IHNob3VsZCBiZSBhYmxlIHRvIHVzZSB0
aGF0IGluc3RlYWQgb2YgeW91ciBvd24gUHJvcGVydGllc0ZhY3RvcnlCZWFuIGltcGxlbWVudGF0
aW9uLiBUaGVyZSdzIGFsc28gYSBSZXNvdXJjZVByb3BlcnRpZXNGYWN0b3J5QmVhbiB0aGF0IGxv
YWRzIGEgcHJvcGVydGllcyBmaWxlIGFzIGFwcGxpY2F0aW9uIGNvbnRleHQgcmVzb3VyY2UgKHZp
YSBBcHBsaWNhdGlvbkNvbnRleHQuZ2V0UmVzb3VyY2VCeVBhdGgpLg0KIA0KSWYgbm9vbmUgb2Jq
ZWN0cywgSSB3aWxsIGNvbW1pdCB0aGVzZSBjaGFuZ2VzIHRvIENWUyB0b21vcnJvdy4gSSBndWVz
cyB0aGUgImlkIiByZWxheGF0aW9uIGlzIGRlYmF0YWJsZSwgYnV0IEknbSBzdHJvbmdseSBmb3Ig
aXQgYXMgbXkgY29sbGVhZ3VlcyBhdCB3ZXJrM0FUIHRlbmQgdG8gdXNlIEJlYW5OYW1lVXJsSGFu
ZGxlck1hcHBpbmcgYSBsb3QgYW5kIGhhdmUgcmVwZWF0ZWRseSBjb21wbGFpbmVkIGFib3V0IHRo
ZSBuZWVkIGZvciBhbiBhZGRpdGlvbmFsIGlkIGF0dHJpYnV0ZS4gQ2FtZXJvbiBmYWNlcyBhIHNp
bWlsYXIgdXNlIGNhc2UgZm9yIFdlYldvcmsgYWN0aW9uczsgd2Ugc2hvdWxkIGVhc2Ugc3VjaCBz
dHVmZiwgZXZlbiBpZiBYTUwgaWRzIGFyZSBzdGlsbCByZWNvbW1lbmRlZCBmb3Igbm9ybWFsIGJl
YW5zLg0KIA0KSnVlcmdlbg0KIA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0t
LSANCglWb246IENhbWVyb24gQnJhaWQgW21haWx0bzpjYW1lcm9uQGRhdGFjb2RleC5uZXRdIA0K
CUdlc2VuZGV0OiBTYSAwMS4xMS4yMDAzIDEzOjIwIA0KCUFuOiBzcHJpbmdmcmFtZXdvcmstZGV2
ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCglDYzogDQoJQmV0cmVmZjogW1tXMy1TUEFN
XV0gLSBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gQmVhbiBmYWN0b3J5IGdldHRpbmcgYWNj
ZXNzIHRvIGl0cyBiZWFuIGlkIC0gRW1haWwgZm91bmQgaW4gc3ViamVjdA0KCQ0KCQ0KDQoJSXMg
dGhlcmUgYW55IHdheSB0aGF0IEkgY2FuIGFsbG93IGEgYmVhbiBmYWN0b3J5IHRvIGZpbmQgb3V0
IGl0cyBpZA0KCWF0dHJpYnV0ZSBmcm9tIHRoZSBhcHBsaWNhdGlvbkNvbnRleHQueG1sDQoJDQoJ
aS5lLiBJIGFtIHRyeWluZyB0byBnZXQgYSBncmlwIG9uIGhvdyBzcHJpbmcgd29ya3MsIGFuZCB0
aGVyZWZvcmUgSSBhbQ0KCXRyeWluZyB0byB3cml0ZSBhIGxpdHRsZSBpbnRlZ3JhdGlvbiBsYXll
ciB0byBtYWtlIHNwcmluZyBhbiBhY3Rpb24NCglmYWN0b3J5IGZvciB4d29yaywgdG8gYWxsb3cg
bWUgdG8gdXNlIHNwcmluZyBjb21wb25lbnRzIGFuZA0KCWludGVyY2VwdG9ycy4gIEkgd2FudCB0
byB0cnkgYW5kIGF2b2lkIHJlcGV0aXRpb24gb2YgY29uZmlndXJhdGlvbg0KCXdoZXJldmVyIHBv
c3NpYmxlLg0KCQ0KCUkgaGF2ZSBpdCBhdCB0aGUgc3RhZ2Ugd2hlcmUgSSBoYXZlIGEgYmVhbiBk
ZWNsYXJhdGlvbiBsaWtlIHRoaXMgOg0KCQ0KCSAgICA8YmVhbiBpZD0iZGVmYXVsdEFjdGlvblRy
YW5zYWN0aW9uQXR0cmlidXRlcyINCgljbGFzcz0iY29tLmRhdGFjb2RleC5zcHJpbmcuYmVhbnMu
UHJvcGVydGllc0ZhY3RvcnlCZWFuIj4NCgkgICAgICAgIDxwcm9wZXJ0eSBuYW1lPSJwcm9wZXJ0
aWVzIj4NCgkgICAgICAgICAgICA8cHJvcHM+DQoJICAgICAgICAgICAgICAgIDxwcm9wIGtleT0i
ZXhlY3V0ZSI+UFJPUEFHQVRJT05fUkVRVUlSRUQ8L3Byb3A+DQoJICAgICAgICAgICAgPC9wcm9w
cz4NCgkgICAgICAgIDwvcHJvcGVydHk+DQoJICAgIDwvYmVhbj4NCgkNCgkgICAgPGJlYW4gaWQ9
ImFkbWluLlNwcmluZ0FkbWluQWN0aW9uIiBjbGFzcz0iV2Vid29ya0FjdGlvbkZhY3RvcnlCZWFu
Ij4NCgkgICAgICAgIDxwcm9wZXJ0eQ0KCW5hbWU9ImFjdGlvbiI+PHZhbHVlPi9hZG1pbi9TcHJp
bmdBZG1pbkFjdGlvbjwvdmFsdWU+PC9wcm9wZXJ0eT4NCgkgICAgICAgIDxwcm9wZXJ0eSBuYW1l
PSJ0cmFuc2FjdGlvbk1hbmFnZXIiPjxyZWYNCglsb2NhbD0idHJhbnNhY3Rpb25NYW5hZ2VyIi8+
PC9wcm9wZXJ0eT4NCgkgICAgICAgIDxwcm9wZXJ0eSBuYW1lPSJ0cmFuc2FjdGlvbkF0dHJpYnV0
ZXMiPjxyZWYNCglsb2NhbD0iZGVmYXVsdEFjdGlvblRyYW5zYWN0aW9uQXR0cmlidXRlcyIvPjwv
cHJvcGVydHk+DQoJICAgIDwvYmVhbj4NCgkNCglJIHdvdWxkIGxpa2UgdG8gYmUgYWJsZSB0byBh
Y2Nlc3MgdGhlIGlkPSJhZG1pbi5TcHJpbmdBZG1pbkFjdGlvbiIgdmFsdWUNCgkob3IgdGhlIGJl
YW4gbmFtZSBhdHRyaWJ1dGUpIGZyb20gd2l0aGluIHRoZSBXZWJ3b3JrQWN0aW9uRmFjdG9yeUJl
YW4NCgl0aGVyZWZvcmUgcmVtb3ZpbmcgdGhlIG5lZWQgdG8gaGF2ZSB0aGUgZXh0cmEgJ2FjdGlv
bicgcHJvcGVydHkNCgk8cHJvcGVydHkgbmFtZT0iYWN0aW9uIj48dmFsdWU+L2FkbWluL1Nwcmlu
Z0FkbWluQWN0aW9uPC92YWx1ZT48L3Byb3BlcnR5Pi4NCgkNCglJZGVhbHkgSSB3b3VsZCBsaWtl
IHRvIHVzZSB0aGUgL2FkbWluL1NwcmluZ0FkbWluQWN0aW9uIGFzIHRoZSBiZWFuIGlkDQoJdG8g
bWFrZSBtYXBwaW5nIGZyb20gV2ViV29yayBzZWFtbGVzcywgYW5kIHdpdGhvdXQgbmVlZGluZyB0
aGUNCgljb252ZXJzaW9uIHRvICcuJyBzdHlsZS4NCglUaGVyZWZvcmUgLSBpcyB0aGVyZSBhbnkg
d2F5IHRoYXQgdGhlIGJlYW4gaWQgY2FuIGJlIGNoYW5nZWQgdG8gYWxsb3cNCglhbnkgdmFsaWQg
eG1sIHN0cmluZyA/ICBDdXJyZW50bHkgSSBhbSByZWNlaXZpbmcgYW4gZXhjZXB0aW9uLCBmcm9t
IHRoZQ0KCXhtbCB2YWxpZGF0b3IuICBDYW4gdGhlIGlkIGF0dHRyaWJ1ZXQgYmUgY2hhbmdlZCB0
byBiZSBhDQoJDQoJWzIyOjEyOjI5XUlORk8gW1htbEJlYW5GYWN0b3J5XSBMb2FkaW5nIFhtbEJl
YW5GYWN0b3J5IGZyb20gSW5wdXRTdHJlYW0NCglbW1JlYWRTdHJlYW0gY29tLmNhdWNoby52ZnMu
RmlsZVJlYWRTdHJlYW1AMTkwYTBkNl1dDQoJWzIyOjEyOjI5XUVSUk9SW0NvbnRleHRMb2FkZXJd
IEZhaWxlZCB0byBpbml0aWFsaXplIGJlYW5zIGluIGFwcGxpY2F0aW9uDQoJY29udGV4dDogTGlu
ZSA0NCBpbiBYTUwgZG9jdW1lbnQgaXMgaW52YWxpZDsgbmVzdGVkIGV4Y2VwdGlvbiBpczoNCgkg
ICAgb3JnLnhtbC5zYXguU0FYUGFyc2VFeGNlcHRpb246IEF0dHJpYnV0ZSB2YWx1ZQ0KCSIvYWRt
aW4vU3ByaW5nQWRtaW5BY3Rpb24iIG9mIHR5cGUgSUQgbXVzdCBiZSBhIG5hbWUuDQoJb3JnLnht
bC5zYXguU0FYUGFyc2VFeGNlcHRpb246IEF0dHJpYnV0ZSB2YWx1ZQ0KCSIvYWRtaW4vU3ByaW5n
QWRtaW5BY3Rpb24iIG9mIHR5cGUgSUQgbXVzdCBiZSBhIG5hbWUuDQoJICAgIGF0IG9yZy5hcGFj
aGUueGVyY2VzLnBhcnNlcnMuRE9NUGFyc2VyLnBhcnNlKFVua25vd24gU291cmNlKQ0KCSAgICBh
dCBvcmcuYXBhY2hlLnhlcmNlcy5qYXhwLkRvY3VtZW50QnVpbGRlckltcGwucGFyc2UoVW5rbm93
biBTb3VyY2UpDQoJICAgIGF0IGphdmF4LnhtbC5wYXJzZXJzLkRvY3VtZW50QnVpbGRlci5wYXJz
ZShEb2N1bWVudEJ1aWxkZXIuamF2YTo3NikNCgkNCglUaGUgZHRkIHN0YXRlcyB0aGF0IGl0IG15
c3QgYmUgYSB2YWxpZCBYTUwgSUQsIGFuZCB0byB1c2UgdGhlIG9wdGlvbmFsDQoJbmFtZSBhdHRy
aWJ1dGUgaWYgeW91IHdhbnQgYW4gaWxsZWdhbCBuYW1lLiAgVGhvdWdoIHRoaXMgd2lsbCByZXF1
aXJlDQoJdHdvIGlkZW50aWZ5ZXJzIGZvciB0aGUgYmVhbiwgd2hpY2ggSSB0aGluayBpcyBwb2lu
dGxlc3MuICBEb2VzIHRoZSBJRA0KCWhhdmUgdG8gYmUgbWFuZGF0b3J5LiAgQ2FuJ3QgYSB2YWxp
ZGF0aW9uIGJlIGltcGxlbWVudGVkIGluIGphdmEgdG8NCgljaGVjayB0aGF0IGF0bGVhc3QgdGhl
IG5hbWUgb3IgdGhlIGlkIGlzIHN1cHBsaWVkID8gIFRoZW4gdGhlIHNhbWUgZm9yDQoJdGhlIDwh
QVRUTElTVCByZWYgbG9jYWwgSURSRUYgI0lNUExJRUQ+ICB0aGlzIGNvdWxkIGJlIGEgQ0RBVEEg
d2l0aCBqYXZhDQoJYmFzZWQgdmFsaWRhdGlvbi4NCgkNCglDaGVlcnMsDQoJDQoJQ2FtZXJvbg0K
CQ0KCS0tDQoJQW55IGRhbW4gZm9vbCBjYW4gd3JpdGUgY29kZSB0aGF0IGEgY29tcHV0ZXIgY2Fu
IHVuZGVyc3RhbmQuLi4NCglUaGUgdHJpY2sgaXMgdG8gd3JpdGUgY29kZSB0aGF0IGh1bWFucyBj
YW4gdW5kZXJzdGFuZC4NCglbTWFydGluIEZvd2xlciBodHRwOi8vd3d3Lm1hcnRpbmZvd2xlci5j
b20vZGlzdHJpYnV0ZWRDb21wdXRpbmcvcmVmYWN0b3JpbmcucGRmXQ0KCQ0KCQ0KCQ0KCQ0KCQ0K
CS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
CglUaGlzIFNGLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IFNGLm5ldCBHaXZlYmFjayBQcm9n
cmFtLg0KCURvZXMgU291cmNlRm9yZ2UubmV0IGhlbHAgeW91IGJlIG1vcmUgcHJvZHVjdGl2ZT8g
IERvZXMgaXQNCgloZWxwIHlvdSBjcmVhdGUgYmV0dGVyIGNvZGU/ICAgU0hBUkUgVEhFIExPVkUs
IGFuZCBoZWxwIHVzIGhlbHANCglZT1UhICBDbGljayBIZXJlOiBodHRwOi8vc291cmNlZm9yZ2Uu
bmV0L2RvbmF0ZS8NCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJh
bWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNv
dXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoJ
DQoNCg==