springframework-developer — Spring Framework developers list

AW: [Springframework-developer] Spring sub-projects

[Achleitner T. <ac...@ec...>]

Hi J=FCrgen, Keith!

Since i'm just designing / developing a framework for highly
configurable rich clients via springs bean factories I am quite keen on
"Spring Rich Client Platform". Is it just another eclipse plugin or can
we expect more?=20

thomas

> -----Urspr=FCngliche Nachricht-----
> Von: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
> Gesendet: Montag, 16. Februar 2004 09:59
> An: spr...@li...
> Betreff: [Springframework-developer] Spring sub-projects
>=20
>=20
> Everybody,
> =20
> As recently discussed in private mails, I suggest to keep=20
> sub-projects that are close to the Spring core as separate=20
> modules in Spring's main CVS. The first two candidates are:
> =20
> - Keith Donald's Spring Rich Client Platform
> - Torsten Juergeleit's Spring Eclipse Plugin
> =20
> Both Keith and Torsten are in favor of hosting them in our=20
> main CVS. So if noone objects, I will create new CVS modules=20
> "spring-rcp" and "spring-eclipse", and accordingly give Keith=20
> and Torsten commit rights for the main CVS. As the module=20
> names cannot be changed easily, feel free to suggest different names!
> =20
> The rationale is to keep all projects that use=20
> "org.springframework" as package name in Spring's main CVS.=20
> Separate modules make sense to let the sub-projects evolve=20
> independently; this way, they do not have to be released in=20
> direct accordance with the Spring core. Of course, generic=20
> classes that emerge can still go into the core.
> =20
> Consequently, both sub-projects should also get respective=20
> sections on our main website. We should definitely clarify=20
> all this before 1.0 final (March 1st), as I expect quite a=20
> lot of media coverage at that time - we shouldn't miss that chance!
> =20
> Juergen
> =20
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

Re: [Springframework-developer] Spring sub-projects

[Dmitriy K. <dko...@ru...>]

+1=2E Btw=2C what is =22Spring Rich Client Platform=22=3F

Dmitriy=2E

----- Original Message -----
From=3A j=C3=BCrgen h=C3=B6ller =5Bwerk3AT=5D =3Cjuergen=2Ehoeller=40werk=
3at=2Ecom=3E
Date=3A Monday=2C February 16=2C 2004 3=3A58 am
Subject=3A =5BSpringframework-developer=5D Spring sub-projects

=3E Everybody=2C
=3E =

=3E As recently discussed in private mails=2C I suggest to keep sub-
=3E projects that are close to the Spring core as separate modules in =

=3E Spring=27s main CVS=2E The first two candidates are=3A
=3E =

=3E - Keith Donald=27s Spring Rich Client Platform
=3E - Torsten Juergeleit=27s Spring Eclipse Plugin
=3E =

=3E Both Keith and Torsten are in favor of hosting them in our main =

=3E CVS=2E So if noone objects=2C I will create new CVS modules =22spring=
-
=3E rcp=22 and =22spring-eclipse=22=2C and accordingly give Keith and Tor=
sten =

=3E commit rights for the main CVS=2E As the module names cannot be =

=3E changed easily=2C feel free to suggest different names!
=3E =

=3E The rationale is to keep all projects that use =

=3E =22org=2Espringframework=22 as package name in Spring=27s main CVS=2E=
 =

=3E Separate modules make sense to let the sub-projects evolve =

=3E independently=3B this way=2C they do not have to be released in direc=
t =

=3E accordance with the Spring core=2E Of course=2C generic classes that =

=3E emerge can still go into the core=2E
=3E =

=3E Consequently=2C both sub-projects should also get respective =

=3E sections on our main website=2E We should definitely clarify all =

=3E this before 1=2E0 final (March 1st)=2C as I expect quite a lot of =

=3E media coverage at that time - we shouldn=27t miss that chance!
=3E =

=3E Juergen
=3E =

=3E =

=3E =

=3E -------------------------------------------------------
=3E SF=2ENet is sponsored by=3A Speed Start Your Linux Apps Now=2E
=3E Build and deploy apps =26 Web services for Linux with
=3E a free DVD software kit from IBM=2E Click Now!
=3E http=3A//ads=2Eosdn=2Ecom/=3Fad=5Fid=1356=26alloc=5Fid438=26op=3Dclic=
k
=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=3E Springframework-developer mailing list
=3E Springframework-developer=40lists=2Esourceforge=2Enet
=3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/springframework-de=
veloper
=3E 

[Springframework-developer] package distribution with bz2 as well as zip?

[Janek B. <ya...@st...>]

The bz2 compression format gives good results when compared with zip:

bytes:
13814006 spring-framework-1.0-rc1-with-dependencies.bz2
18259545 spring-framework-1.0-rc1-with-dependencies.zip

Having a download from sourceforge in bz2 format as well as zip would
benefit some users. I always pick bz2 over zip or gz if it is available
for a project.

Ant provides the bzip2 task so it should be straightforward.

-Janek Bogucki

[Springframework-developer] =?iso-8859-1?Q?Re:[Springframework-developer]_Spring_sub-projects?=

[=?iso-8859-1?Q?<jp....@ti...>]

+1=0D=0AJean-Pierre=0D=0A=0D=0A---------- Initial Header -----------=0D=0A=
=0D=0AFrom      : spr...@li...=0D=
=0ATo          : <spr...@li...>=0D=0AC=
c          : =0D=0ADate      : Mon, 16 Feb 2004 09:58:58 +0100=0D=0ASubje=
ct : [Springframework-developer] Spring sub-projects=0D=0A=0D=0AEverybody=
,=0D=0A =0D=0AAs recently discussed in private mails, I suggest to keep s=
ub-projects that are close to the Spring core as separate modules in Spri=
ng's main CVS. The first two candidates are:=0D=0A =0D=0A- Keith Donald's=
 Spring Rich Client Platform=0D=0A- Torsten Juergeleit's Spring Eclipse P=
lugin=0D=0A =0D=0ABoth Keith and Torsten are in favor of hosting them in =
our main CVS. So if noone objects, I will create new CVS modules "spring-=
rcp" and "spring-eclipse", and accordingly give Keith and Torsten commit =
rights for the main CVS. As the module names cannot be changed easily, fe=
el free to suggest different names!=0D=0A =0D=0AThe rationale is to keep =
all projects that use "org.springframework" as package name in Spring's m=
ain CVS. Separate modules make sense to let the sub-projects evolve indep=
endently; this way, they do not have to be released in direct accordance =
with the Spring core. Of course, generic classes that emerge can still go=
 into the core.=0D=0A =0D=0AConsequently, both sub-projects should also g=
et respective sections on our main website. We should definitely clarify =
all this before 1.0 final (March 1st), as I expect quite a lot of media c=
overage at that time - we shouldn't miss that chance!=0D=0A =0D=0AJuergen=
=0D=0A=0A=0A********** PROTEGEZ VOS E-MAILS !********** =0AAvec Tiscali S=
uperMail, vos e-mails en toute s=E9curit=E9 ! =0AAnti Spam personnalisabl=
e =0AAnti Virus actualis=E9 en permanence =0Aet de nombreux bonus... =0AP=
our en savoir plus, rendez-vous sur http://www.tiscali.fr/supermail/=0A

[Springframework-developer] Spring sub-projects

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

Everybody,
=20
As recently discussed in private mails, I suggest to keep sub-projects =
that are close to the Spring core as separate modules in Spring's main =
CVS. The first two candidates are:
=20
- Keith Donald's Spring Rich Client Platform
- Torsten Juergeleit's Spring Eclipse Plugin
=20
Both Keith and Torsten are in favor of hosting them in our main CVS. So =
if noone objects, I will create new CVS modules "spring-rcp" and =
"spring-eclipse", and accordingly give Keith and Torsten commit rights =
for the main CVS. As the module names cannot be changed easily, feel =
free to suggest different names!
=20
The rationale is to keep all projects that use "org.springframework" as =
package name in Spring's main CVS. Separate modules make sense to let =
the sub-projects evolve independently; this way, they do not have to be =
released in direct accordance with the Spring core. Of course, generic =
classes that emerge can still go into the core.
=20
Consequently, both sub-projects should also get respective sections on =
our main website. We should definitely clarify all this before 1.0 final =
(March 1st), as I expect quite a lot of media coverage at that time - we =
shouldn't miss that chance!
=20
Juergen
=20

Re: [Springframework-developer] DTD versioning

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

Colin, Rod,
=20
I've just adapted BeansDtdResolver to fall back to the default DTD file =
"spring-beans_1_0.dtd" if  "spring-beans.dtd" was specified, issuing a =
corresponding message at INFO level (not committed yet). I guess INFO is =
appropriate, as "spring-beans" can simply be considered a shortcut for =
"spring-beans_1_0" for the time being.
=20
If we agree on the exact naming that Colin proposed, I'll commit this =
and adapt all our bean definition declarations in the samples etc. The =
only alternative that I see is "spring-beans-1.0.dtd" as used by =
Hibernate's DTDs, while "_1_0" is the style used by Sun's DTDs.
=20
IMO, "spring-beans.dtd" should also stay available from the website, =
simply adding the versioned DTD file there.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: So 15.02.2004 17:18
An: spr...@li...
Betreff: Re: [Springframework-developer] DTD versioning



Colin

I agree about versioning, so long as we can avoid breaking people's
definitions. We could have only the new URL on the web site and modify =
the
entity resolver so that it produces a log warning on finding the old one
(but still resolved it). This should provide a deprecation-style upgrade
path.

Regards,
Rod

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Sunday, February 15, 2004 3:26 PM
Subject: [Springframework-developer] DTD versioning


> I updated the DTD on the website, and this reminds me that we should
> version the document. I propose naming it something like
>
> spring-beans_1_0.dtd
>
> with the doctype definition being:
>
> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 1.0//EN"
>         "http://www.springframework.org/dtd/spring-beans_1_0.dtd">
>
> If everyone is in agreement, the only question is if we should keep =
the
> old one around (ie keep both versions) for the 1.0 release. I would
> favour having only the new version, to avoid future confusion, =
although
> this would force everybody to update their definition documents.
>
> Regards,
> Colin
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others

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

Colin,
=20
While I generally agree that it's more appropriate to have "inContainer" =
default to false, I'm a bit worried that such a change would break all =
bean definition files that currently rely on accessing container =
DataSources with that implicit prefix.
=20
A further option would be to change "inContainer"'s semantics to: check =
for "java:comp/env/myJndiName" first, then try "myJndiName" directly if =
the former was not found. That would catch both cases, being fully =
backward-compatible, with just minimal overhead at startup. =
"inContainer"  turned off would solely try the latter case.
=20
Juergen
=20

________________________________

Von: Colin Sampaleanu [mailto:col...@ex...]
Gesendet: So 15.02.2004 23:44
An: j=FCrgen h=F6ller [werk3AT]
Cc: spr...@li...
Betreff: Re: [Springframework-developer] AbstractJndiLocator should not =
assume java:comp/env prefix while not allowing others



I think we should revisit the decision to make inContainer=3Dtrue the
default for the AbstractJndiLocator.

While most people will of course be running in a container, having a
default value of inContainer=3Dtrue will not help them, and will make
their config work harder. inContainer=3Dtrue helps only if by default =
your
code is something like an EJB or WebApp, and you want to save typing
'java:comp/env/' at the beginning of your resource names, _and_ you have
gone to the pain of doing a resource mapping to bring resources into the
local java:comp/env/ namespace, something that most people don't bother
doing.

If I deploy an EJB in JBoss for example, it gets deployed into the
global (not even 'java:') namspace. Unless I do the resource-ref mapping
for the client code that needs to access it, it needs to be accessed via
the global namespace. Since there is no prefix at all, that's completely
impossible to do unless inContainer=3Dfalse, otherwise the code will add
the java:comp/env/. That means that for every EJB proxy I need to add
inContainer=3Dfalse as a property.

If false was the default, then people accessing resources for which
there was a local resource mapping (again, people don't usually do this)
would still have the choice of either using the full
  java:/comp/env/
prefix, and leaving inContainer unset, or just setting
  inContainer=3Dtrue.

I think this change makes sense because locally mapped resources (to
java:/comp/env) are less common than non-mapped resources. What do you
think?

Regards,
Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>Just fixed: inContainer=3Dtrue does not prepend the container prefix if =
a scheme is given (i.e. a ":" contained).
>
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...]
>Sent: Friday, August 22, 2003 1:33 PM
>To: j=FCrgen h=F6ller [werk3AT]
>Cc: spr...@li...
>Subject: Re: [Springframework-developer] AbstractJndiLocator should not
>assume java:comp/env prefix while not allowing others
>
>
>I somehow missed the inContainer property, even though I looked at the
>source!   I think it does make sense though to add the check for the
>scheme as per your and mine suggestion; even in a container you still
>need to be able to override this...
>
>Regards,
>Colin
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
>=20
>
>>Hi Colin,
>>
>>AbstractJndiLocator only does so when the "inContainer" property is =
set to true (the default). Setting this property to false should result =
in looking up the JNDI name as is. It could make sense to add a check =
for scheme though, e.g. only apply "java:comp/env/" if "inContainer" is =
true *and* the JNDI name does not contain a ":". What do you think?
>>
>>Juergen
>>
>>
>>      -----Urspr=FCngliche Nachricht-----
>>      Von: Colin Sampaleanu [mailto:col...@ex...]
>>      Gesendet: Fr 22.08.2003 05:43
>>      An: spr...@li...
>>      Cc:
>>      Betreff: [Springframework-developer] AbstractJndiLocator should =
not assume java:comp/env prefix while not allowing others
>>    =20
>>    =20
>>
>>      AbstractJndiLocator right now looks at the jndi name it is =
given, and if
>>      it doesn't start with
>>         java:comp/env
>>      prepends this value automatically. This behaviour is not =
correct.
>>      Somebody using the bean should be able to look up resources =
anywhere,
>>      and currently you can't. For example, in jboss, the main =
datasource by
>>      default is bound to
>>        java:DefaultDS
>>    =20
>>      As well, you may want to look up something on JNDI using another =
scheme
>>      entirely...
>>    =20
>>      What the code should probably do is see if the is a scheme
>>         xxxxx:
>>      at the beginning of the jndi name. If there isn't, then it is =
probably
>>      reasonable to assume 'java:comp/env. or 'java:' If there is a =
scheme, it
>>      should leave the name alone.
>>    =20
>>      I would have supplied a patch, but the fix is trivial, and I =
don't know
>>      how exactly you want to handle this, but it's pretty critical to =
me.
>>    =20
>>      Right now with JBoss it's pretty nasty. I can not use JBoss's =
naming
>>      alias service to alias
>>        java:comp/env/DefaultDS
>>      to
>>        java:DefaultDS
>>      because it apparently doesn't let you alias stuff under =
comp/env.  I can
>>      probably modify my resource entries in the war file I use to do =
a
>>      resource ref to the right location, but I would really rather =
not do
>>      that, since the war is fine the way it is.
>>    =20
>>      Regards,
>>      Colin
>>    =20
>>

Re: [Springframework-developer] JTATransactionManager isExistingTransaction() logic

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

Good point - I can't remember why I wrote it that way; probably some =
misguided attempt at optimization. Anyway, I changed it to just check =
for STATUS_NO_TRANSACTION.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Sa 14.02.2004 22:39
An: spr...@li...
Betreff: [Springframework-developer] JTATransactionManager =
isExistingTransaction() logic



Juerge,

In JTATransactionManager, you've got:

    protected boolean isExistingTransaction(Object transaction) {
        try {
            int status =3D ((UserTransaction) transaction).getStatus();
            return (status !=3D Status.STATUS_NO_TRANSACTION && status =
!=3D
Status.STATUS_MARKED_ROLLBACK);
        }
        catch (SystemException ex) {
            throw new TransactionSystemException("JTA failure on
getStatus", ex);
        }
    }

I'm wondering why you lumped together STATUS_NO_TRANSACTION and
STATUS_MARKED_ROLLBACK.

In some code I'm running, inside an EJB demarcated transaction, a
third-party EJB did a setRollbakOnly() on it's context. Then in a
subsequent step, still inside that rollback-marked exception, my spring
based code tried to execute something through a transactionally wrapped
POJO. What happened is that Spring then thought (because of the above
code) that there was no transaction, and tried to initiate one. At that
point I got an exception from the JBoss Transaction Manager that it
didin't support nested transactions. Now in this case, either way
everything fails. But I think it would be more correct to treat the
marked for rollback case as 'there is an existing transaction'. If the
JTA Transaction manager in the container actually supported nested
transactions, the above code would allow the spring code to execute in a
new tranasaction, when it in fact should just join the (marked for
rollback) existing transaction.

Regards,
Colin





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Target date for Spring 1.0 final

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

Excellent - thanks, Chris!
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Chris Nokleberg
Gesendet: So 15.02.2004 23:49
An: spr...@li...
Betreff: [Springframework-developer] Re: Target date for Spring 1.0 =
final



j=FCrgen h=F6ller [werk3AT] wrote:
> Some things remain to be clarified for 1.0, namely the AOP Alliance
> version that we ship, and updating to the most current Commons =
Attributes
> snapshot. All other dependencies are up-to-date as far as I see; =
updating
> to Ant 1.6.1 is hardly worth mentioning. On the occasion, it would be =
good
> if CGLIB 2.0 went final in time.

FYI CGLIB 2.0 Final was released a couple of days ago.

Chris




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Revised BeanFactoryLocator and EJB support classes

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

Colin,
=20
Oops, I seem to have gotten that wrong then for the =
SingletonBeanFactoryLocator: Please change it back to a more reasonable =
implementation before 1.0 final.=20
=20
However, the JndiBeanFactoryLocator doesn't have a reference count; it =
creates the factory on each locator call. Isn't it be appropriate here =
to call BeanFactory.destroySingletons respectively =
ApplicationContext.close on release?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Sa 14.02.2004 20:06
An: spr...@li...
Betreff: Re: [Springframework-developer] Revised BeanFactoryLocator and =
EJB support classes



I've got no problem with these changes in terms of making the names
consistent. The new handling of the BeanFactoryReference is wrong
though. There was a reason why it was an inner class before, as per the
comment:

            return new BeanFactoryReference() {
                public BeanFactory getFactory() {
                    return retval;
                }
                public void release() throws FatalBeanException {
                    // Currently does nothing.
                    // An ideal implementation would use reference
counting data to release owning
                    // container when no more BeanFactories within it
are used, however depending on
                    // the usage scenario, this could also cause =
thrashing.
                }
            };

Now it was somewhat of a copout not to do anything on the release; my
original intent when I checked this stuff in was that we would have some
discussion on the best handling for the release call, and then it would
get implemented, probably to just use the reference count in its outer
class to decide whether to release or not, but we've all been pretty
busy and that didn't happen.

So you can not just call
   ((ConfigurableBeanFactory) this.beanFactory).destroySingletons()
and
   ((ConfigurableApplicationContext) this.applicationContext).close();
as your new implementation does in the new separate implementations of
BeanFactoryReference. It should probably stay an inner class, and only
call the destroy or close, respectively, if the reference count on the
keyed singleton beanfactory or context goes down to zero.
:
This will work absolutely fine for people using it like I am, where it
is used to obtain the parent for the web application context(s), and
then only released when the web application context gets unloaded.

The other situation, where people do not have one get and release
wrapping all other gets and releases, is more problematic, since if they
do sequential gets and releases they will get a sort of thrashing as
stuff gets continuously loaded and unloaded. What these people will have
to do is themselves force an initial load without a release, at their
app startup.

As for the default ejbRemove not calling unloadBeanFactory (like the
comment for unloadBeanFActory says is supposed to happen), that appears
to be an oversight and something that was in there since Nov. or Dec.
Thanks for catching that. The old old code never did any unloading at
all. Then in Nov./Dec. I added the unloadBeanFactory method, but
apparently forgot to call it.

Regards,
Colin


j=FCrgen h=F6ller [werk3AT] wrote:

>Agreed, the RC1 API should be considered as final as possible. However, =
the BeanFactoryLocator was a brand-new RC1 feature, added pretty much =
last minute there, so I guess it's arguable to refine this for 1.0 final =
- particularly if it just affects advanced users that diverge from the =
default EJB support configuration.
>
>From my point of view, I'm as happy as can be with the current state of =
the framework. What I would like to see included in 1.0 final =
nevertheless is (backward-compatible) support for more exception =
categories in the SQLException translator, as suggested by Thomas, and =
possibly a convenient option to set a transaction rollback-only no =
matter if driven by declarative or programmatic demarcation, as =
suggested by Colin and Alef.
>
>BTW, I'll send a mail regarding the Spring roadmap shortly.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von Rod Johnson
>Gesendet: Sa 14.02.2004 18:42
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Revised BeanFactoryLocator and =
EJB support classes
>
>
>
>I agree with these changes, but I think we should try to avoid API =
changes
>in general from now to 1.0 final. With RC1 we are committing to a final =
API.
>Also, I'd rather we don't have enough changes that we need an RC2.
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Saturday, February 14, 2004 5:22 PM
>Subject: [Springframework-developer] Revised BeanFactoryLocator and EJB
>support classes
>
>
>Colin, Rod, everyone,
>
>I revised the BeanFactoryLocator and EJB support classes yesterday, =
mainly
>to align the naming of the implementation classes with Spring's general
>naming patterns. For example, the ApplicationContext-specific classes =
are
>now called "ContextJndiBeanFactoryLocator" and
>"ContextSingletonBeanFactoryLocator". I've also factored out the
>BeanFactoryReference implementations for newly created BeanFactories =
into
>separate classes, making them invoke
>"ConfigurableBeanFactory.destroySingletons" respectively
>"ConfigurableApplicationContext.close" on release.
>
>I've adapted the EJB support classes accordingly and, on the occasion, =
moved
>the logger instance variable from AbstractEnterpriseBean to
>AbstractStatelessSessionBean and AbstractMessageDriverBean. Someone
>complained on the mailing list a while ago that removing and setting =
the
>logger instance for SFSBs is a nuisance, and I agree - the subclass =
should
>hold its own *static* logger instance there. Of course, this doesn't =
apply
>to SLSBs and MDBs, thus the change.
>
>I've also noted that AbstractEnterpriseBean's "ejbRemove" =
implementation did
>*not* invoke BeanFactoryLocator.release; is there any rationale for =
this?
>For the time being, I've made it invoke release, as I consider it =
important
>to destroy resource singletons like a local SessionFactory or
>PersistenceManager on BeanFactory respectively ApplicationContext =
shutdown.
>
>I hope you don't mind the name changes. My goal is to keep class and =
method
>naming as consistent as possible within the Spring codebase; something =
many
>other open source projects to not respect at all.
>
>Juergen
>=20
>




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Target date for Spring 1.0 final

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

Chris Nokleberg wrote:

>jürgen höller [werk3AT] wrote:
>  
>
>>Some things remain to be clarified for 1.0, namely the AOP Alliance
>>version that we ship, and updating to the most current Commons Attributes
>>snapshot. All other dependencies are up-to-date as far as I see; updating
>>to Ant 1.6.1 is hardly worth mentioning. On the occasion, it would be good
>>if CGLIB 2.0 went final in time.
>>    
>>
>
>FYI CGLIB 2.0 Final was released a couple of days ago.
>
>Chris
>  
>
Thanks. Upgraded in our cvs.

[Springframework-developer] Re: Target date for Spring 1.0 final

[Chris N. <ch...@si...>]

jürgen höller [werk3AT] wrote:
> Some things remain to be clarified for 1.0, namely the AOP Alliance
> version that we ship, and updating to the most current Commons Attributes
> snapshot. All other dependencies are up-to-date as far as I see; updating
> to Ant 1.6.1 is hardly worth mentioning. On the occasion, it would be good
> if CGLIB 2.0 went final in time.

FYI CGLIB 2.0 Final was released a couple of days ago.

Chris

Re: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others

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

I think we should revisit the decision to make inContainer=true the 
default for the AbstractJndiLocator.

While most people will of course be running in a container, having a 
default value of inContainer=true will not help them, and will make 
their config work harder. inContainer=true helps only if by default your 
code is something like an EJB or WebApp, and you want to save typing 
'java:comp/env/' at the beginning of your resource names, _and_ you have 
gone to the pain of doing a resource mapping to bring resources into the 
local java:comp/env/ namespace, something that most people don't bother 
doing.

If I deploy an EJB in JBoss for example, it gets deployed into the 
global (not even 'java:') namspace. Unless I do the resource-ref mapping 
for the client code that needs to access it, it needs to be accessed via 
the global namespace. Since there is no prefix at all, that's completely 
impossible to do unless inContainer=false, otherwise the code will add 
the java:comp/env/. That means that for every EJB proxy I need to add 
inContainer=false as a property.

If false was the default, then people accessing resources for which 
there was a local resource mapping (again, people don't usually do this) 
would still have the choice of either using the full
  java:/comp/env/
prefix, and leaving inContainer unset, or just setting
  inContainer=true.

I think this change makes sense because locally mapped resources (to 
java:/comp/env) are less common than non-mapped resources. What do you 
think?

Regards,
Colin

jürgen höller [werk3AT] wrote:

>Just fixed: inContainer=true does not prepend the container prefix if a scheme is given (i.e. a ":" contained).
>
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...]
>Sent: Friday, August 22, 2003 1:33 PM
>To: jürgen höller [werk3AT]
>Cc: spr...@li...
>Subject: Re: [Springframework-developer] AbstractJndiLocator should not
>assume java:comp/env prefix while not allowing others
>
>
>I somehow missed the inContainer property, even though I looked at the 
>source!   I think it does make sense though to add the check for the 
>scheme as per your and mine suggestion; even in a container you still 
>need to be able to override this...
>
>Regards,
>Colin
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Hi Colin,
>>
>>AbstractJndiLocator only does so when the "inContainer" property is set to true (the default). Setting this property to false should result in looking up the JNDI name as is. It could make sense to add a check for scheme though, e.g. only apply "java:comp/env/" if "inContainer" is true *and* the JNDI name does not contain a ":". What do you think?
>>
>>Juergen
>>
>>
>>	-----Ursprüngliche Nachricht----- 
>>	Von: Colin Sampaleanu [mailto:col...@ex...] 
>>	Gesendet: Fr 22.08.2003 05:43 
>>	An: spr...@li... 
>>	Cc: 
>>	Betreff: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others
>>	
>>	
>>
>>	AbstractJndiLocator right now looks at the jndi name it is given, and if
>>	it doesn't start with
>>	   java:comp/env
>>	prepends this value automatically. This behaviour is not correct.
>>	Somebody using the bean should be able to look up resources anywhere,
>>	and currently you can't. For example, in jboss, the main datasource by
>>	default is bound to
>>	  java:DefaultDS
>>	
>>	As well, you may want to look up something on JNDI using another scheme
>>	entirely...
>>	
>>	What the code should probably do is see if the is a scheme
>>	   xxxxx:
>>	at the beginning of the jndi name. If there isn't, then it is probably
>>	reasonable to assume 'java:comp/env. or 'java:' If there is a scheme, it
>>	should leave the name alone.
>>	
>>	I would have supplied a patch, but the fix is trivial, and I don't know
>>	how exactly you want to handle this, but it's pretty critical to me.
>>	
>>	Right now with JBoss it's pretty nasty. I can not use JBoss's naming
>>	alias service to alias
>>	  java:comp/env/DefaultDS
>>	to
>>	  java:DefaultDS
>>	because it apparently doesn't let you alias stuff under comp/env.  I can
>>	probably modify my resource entries in the war file I use to do a
>>	resource ref to the right location, but I would really rather not do
>>	that, since the war is fine the way it is.
>>	
>>	Regards,
>>	Colin
>>	
>>

Re: [Springframework-developer] DTD versioning

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

Colin

I agree about versioning, so long as we can avoid breaking people's
definitions. We could have only the new URL on the web site and modify the
entity resolver so that it produces a log warning on finding the old one
(but still resolved it). This should provide a deprecation-style upgrade
path.

Regards,
Rod

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Sunday, February 15, 2004 3:26 PM
Subject: [Springframework-developer] DTD versioning


> I updated the DTD on the website, and this reminds me that we should
> version the document. I propose naming it something like
>
> spring-beans_1_0.dtd
>
> with the doctype definition being:
>
> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 1.0//EN"
>         "http://www.springframework.org/dtd/spring-beans_1_0.dtd">
>
> If everyone is in agreement, the only question is if we should keep the
> old one around (ie keep both versions) for the 1.0 release. I would
> favour having only the new version, to avoid future confusion, although
> this would force everybody to update their definition documents.
>
> Regards,
> Colin
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] DTD versioning

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

I updated the DTD on the website, and this reminds me that we should 
version the document. I propose naming it something like

spring-beans_1_0.dtd

with the doctype definition being:

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 1.0//EN"
        "http://www.springframework.org/dtd/spring-beans_1_0.dtd">

If everyone is in agreement, the only question is if we should keep the 
old one around (ie keep both versions) for the 1.0 release. I would 
favour having only the new version, to avoid future confusion, although 
this would force everybody to update their definition documents.

Regards,
Colin

Re: [Springframework-developer] Hibernate and JDBC connection vs. Spring's need for a DataSource.

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

There are 2 ways you can do this I can think of:

1. Configure Hibernate using the Spring LocalSessionFactory. This means that
you end up configuring Hibernate using a DataSource. You can get connections
from that DataSource in your JDBC code also, rather than from Hibernate
(although they still come from the same pool).  This makes Hibernate
configuration easier. This is definitely how I'd do it, and works well.

2. Get a connection from Hibernate and create a Spring
SingleConnectionDataSource from it to pass to Spring JDBC. This will work,
but is really a hack.

Spring JDBC is designed to take away the pain of obtaining and closing a
connection, among other things. Hence it would deliver less value if it
worked with Connections, rather than DataSources. Also, with a DataSource it
makes more sense to incur the cost of getting metadata to enabling exception
mapping. You wouldn't want to do this for every connection.

P.S. We are thinking about searchable resources. However, this won't happen
in the near future.

----- Original Message -----
From: "Ezra Epstein" <eep...@pr...>
To: <spr...@li...>
Sent: Sunday, February 15, 2004 3:05 AM
Subject: [Springframework-developer] Hibernate and JDBC connection vs.
Spring's need for a DataSource.


> First off, I tried searching the existing list, but since it's
sourceforge,
> search doesn't work.  I tried: "hibernate", "datasource", etc.  No luck.
> Even tried "IHibernateTemplate" which is saw in to topic of one post and
> that returned an empty set as well.  Sigh.  Wouldn't a searchable phpBB
> forum be nice...
>
> Meanwhile, the issue at hand.  I'm using Hibernate.  I've read about
Spring.
> I'm thinking Spring sounds great.  Want to move to include it.  This being
a
> needs-driven development effort, we have a problem with Hibernate: it has
> zero support for stored procedures.  So, enter Spring.  Nice support for
> arbitrary JDBC/SQL.  Just write the result-set row handler and you are
done.
> Sounds perfect.  3 hours later I've abandoned Spring.   Why?  Well, Spring
> wants everything to include a DataSource.  But we run Hibernate in 2
modes:
> stand-alone, for testing and inside a container for web deployed apps.
> Currently we configure Hibernate directly -- easy, external
> hibernate.cfg.xml file.  But Hibernate's "abstraction" is all based on a
> java.sql.Connection object, which for sending queries, makes perfect
sense.
> So, for the life of me, I can't figure out why Spring always wants a
> DataSource and rather than change everything that currently works and move
> it all over so that Spring handles configuration and gives itself a
> DataSource, I've decided it's not worth it.  By then I could have written
> the calls and handlers in plain JDBC 3 times over.... Again, this is a
> needs-driven effort.
>
> 2 questions:
>
>   1. Is there a different entry point to all of Springs JDBC utility
methods
> that relies on a lowly connection object instead of a DataSource?
>   2. If not, why not?
>
> Thanks,
>
>    == Ee
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Target date for Spring 1.0 final

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

> However, I will try to do the EJB section. What have people finally 
> ended up using for a DocBook editor?
Good. I'm using XMLMind. The community ed is free, and it's great.

[Springframework-developer] use java.util.Collections.EMPTY_LIST et. al. not new LinkedList()

[<ak...@sp...>]

Reading the sources trying to see if I can extract Spring's JDBC function=
ality away from its dependence on DataSource I noticed that quite a few m=
ethods that take optional List parameters substitute an empty LinkedList =
(via new LinkedList()) to methods on which they depend.

Which left me wondering: are those LinkedList instances ever written to -=
- they seem to not need to be, but I couldn't answer definitively without=
 significantly greater intimacy with Spring's code. 

So, if those are meant to be read-only, I'd encourage using java.util.Col=
lections.EMPTY_LIST instead (and similarly EMPTY_MAP and EMPTY_SET as nee=
ded).  Why?  3 reasons:

    1.  Better self-documenting code.  If a default parameter value is re=
ad-only, use a read-only (immutable) instance.  You still get the List se=
mantics and don't need null checks in the called methods.
    2.  It is faster.  Object creation ion the heap is orders of magnitud=
e slower than putting an object reference on the stack.
    3.  Uses less memory.  Small though they be, new objects still consum=
e resources.  And have to be garbage collected later -- which goes back t=
o point #2.

Seems like a win all-around.

=3D=3D Ee

[Springframework-developer] Hibernate and JDBC connection vs. Spring's need for a DataSource.

[Ezra E. <eep...@pr...>]

First off, I tried searching the existing list, but since it's sourceforge,
search doesn't work.  I tried: "hibernate", "datasource", etc.  No luck.
Even tried "IHibernateTemplate" which is saw in to topic of one post and
that returned an empty set as well.  Sigh.  Wouldn't a searchable phpBB
forum be nice...

Meanwhile, the issue at hand.  I'm using Hibernate.  I've read about Spring.
I'm thinking Spring sounds great.  Want to move to include it.  This being a
needs-driven development effort, we have a problem with Hibernate: it has
zero support for stored procedures.  So, enter Spring.  Nice support for
arbitrary JDBC/SQL.  Just write the result-set row handler and you are done.
Sounds perfect.  3 hours later I've abandoned Spring.   Why?  Well, Spring
wants everything to include a DataSource.  But we run Hibernate in 2 modes:
stand-alone, for testing and inside a container for web deployed apps.
Currently we configure Hibernate directly -- easy, external
hibernate.cfg.xml file.  But Hibernate's "abstraction" is all based on a
java.sql.Connection object, which for sending queries, makes perfect sense.
So, for the life of me, I can't figure out why Spring always wants a
DataSource and rather than change everything that currently works and move
it all over so that Spring handles configuration and gives itself a
DataSource, I've decided it's not worth it.  By then I could have written
the calls and handlers in plain JDBC 3 times over.... Again, this is a
needs-driven effort.

2 questions:

  1. Is there a different entry point to all of Springs JDBC utility methods
that relies on a lowly connection object instead of a DataSource?
  2. If not, why not?

Thanks,

   == Ee

[Springframework-developer] JTATransactionManager isExistingTransaction() logic

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

Juerge,

In JTATransactionManager, you've got:

    protected boolean isExistingTransaction(Object transaction) {
        try {
            int status = ((UserTransaction) transaction).getStatus();
            return (status != Status.STATUS_NO_TRANSACTION && status != 
Status.STATUS_MARKED_ROLLBACK);
        }
        catch (SystemException ex) {
            throw new TransactionSystemException("JTA failure on 
getStatus", ex);
        }
    }

I'm wondering why you lumped together STATUS_NO_TRANSACTION and 
STATUS_MARKED_ROLLBACK.

In some code I'm running, inside an EJB demarcated transaction, a 
third-party EJB did a setRollbakOnly() on it's context. Then in a 
subsequent step, still inside that rollback-marked exception, my spring 
based code tried to execute something through a transactionally wrapped 
POJO. What happened is that Spring then thought (because of the above 
code) that there was no transaction, and tried to initiate one. At that 
point I got an exception from the JBoss Transaction Manager that it 
didin't support nested transactions. Now in this case, either way 
everything fails. But I think it would be more correct to treat the 
marked for rollback case as 'there is an existing transaction'. If the 
JTA Transaction manager in the container actually supported nested 
transactions, the above code would allow the spring code to execute in a 
new tranasaction, when it in fact should just join the (marked for 
rollback) existing transaction.

Regards,
Colin

Re: [Springframework-developer] Re: [Springframework-user] Mapping Exceptions with sql-error-codes.xm l

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

Completed and in CVS.

Thomas

jürgen höller [werk3AT] wrote:

>Thomas, if we want to include this in 1.0 final, please add these exception categories promptly. It represents a minor enhancement; therefore I don't mind it as a last minute addition as long as there are no further framework changes necessary.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von tri...@tr...
>Gesendet: Mi 11.02.2004 18:25
>An: spr...@li...
>Cc: spr...@li...
>Betreff: [Springframework-developer] Re: [Springframework-user] Mapping Exceptions with sql-error-codes.xm l
>
>
>
>
>This has come up a couple of times, but we have never really committed to adding
>additional exception categories.
>
>We are currently supporting translation to:
>        DataIntegrityViolationException
>        BadSqlGrammarException
>       
>       
>Suggested categories to add (from my recollection):
>        DataRetrievalFailureException
>        OptimisticLockingFailureException
>        DataAccessResourceFailureException
>
>Do we want to add some additional categories to the
>SQLErrorCodeSQLExceptionTranslator? 
>If we do, we could keep it backwards compatible by making these additional
>categories optional based on entries in sql-error-codes.xml.
>
>If we decide to add this, when would be a good time considering RC1 being
>released any minute?
>
>Thomas
>
>
>Quoting Meier Martin <mar...@el...>:
>
>  
>
>>Hi,
>>
>>I tried to map a stale connection error code to a
>>DataAccessResourceFailureException, but this did not work:
>>
>>  <bean id="Oracle" class="org.springframework.jdbc.support.SQLErrorCodes">
>>    <property
>>name="badSqlGrammarCodes"><value>900,903,904,917,936,942,17006</value></prop
>>erty>
>>    <property
>>name="dataIntegrityViolationCodes"><value>1,1400,1722,2291</value></property
>>    
>>
>>    <property
>>name="dataIntegrityViolationCodes"><value>1,1400,1722,2291</value></property
>>    
>>
>>    <property
>>name="dataAccessResourceFailureCodes"><value>17002</value></property>
>>  </bean>
>>
>>As I saw in the class SQLErrorCodes only the methods
>>setBadSqlGrammerCodes(...) and setDataIntegrityViolationCodes(...) are
>>supported. How is it possible to map an error code to a
>>dataAccessResourceFailureException with the sql-error-codes.xml?
>>
>>Cheers
>>-Martin
>>
>>    
>>
>
>
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id56&alloc_id438&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>  
>

Re: [Springframework-developer] Target date for Spring 1.0 final

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

I am ok with the Mar. 1 date, but on my part that means I probably can 
not help with the release in almost any capacity. I have a big deadline 
on Feb. 26th, another on Mar. 12, and an unchangeable 9 day vacation in 
the middle of those 2 dates, so for the last 2-3 weeks have been and for 
the next 3-4 weeks will be basically in burn mode to try to produce code 
for work...

However, I will try to do the EJB section. What have people finally 
ended up using for a DocBook editor?

Regards,
Colin

jürgen höller [werk3AT] wrote:

>Dear Spring developers,
> 
>After a few minor bugfixes and modifications after 1.0 RC1, we are now ready to concentrate on 1.0 final. So I suggest *March 1st* as target date for the 1.0 final release! I won't be worried if some parts of the docs aren't completely finished by then, as we can always complete them afterwards.
> 
>As discussed in other recent mails, we should concentrate on fixing bugs and completing documentation. Minor feature enhancements are OK from my point of view; however, they should be delayed till 1.1 if they are beyond trivial. We should avoid the need for an RC2 if possible; after all, there's a life after Spring 1.0 final :-)
> 
>Some things remain to be clarified for 1.0, namely the AOP Alliance version that we ship, and updating to the most current Commons Attributes snapshot. All other dependencies are up-to-date as far as I see; updating to Ant 1.6.1 is hardly worth mentioning. On the occasion, it would be good if CGLIB 2.0 went final in time.
> 
>We should also avoid double documentation in the distribution, i.e. remove the separate HTML documents in the docs directory as soon as all the info in there is also available in the reference documentation. I'm happy if someone does a cleanup in there promptly; I intend to browse through it again myself before the actual release.
> 
>So, next stop: 1.0 final - March 1st!
> 
>

Re: [Springframework-developer] Revised BeanFactoryLocator and EJB support classes

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

I've got no problem with these changes in terms of making the names 
consistent. The new handling of the BeanFactoryReference is wrong 
though. There was a reason why it was an inner class before, as per the 
comment:

            return new BeanFactoryReference() {
                public BeanFactory getFactory() {
                    return retval;
                }
                public void release() throws FatalBeanException {
                    // Currently does nothing.
                    // An ideal implementation would use reference 
counting data to release owning
                    // container when no more BeanFactories within it 
are used, however depending on
                    // the usage scenario, this could also cause thrashing.
                }
            };

Now it was somewhat of a copout not to do anything on the release; my 
original intent when I checked this stuff in was that we would have some 
discussion on the best handling for the release call, and then it would 
get implemented, probably to just use the reference count in its outer 
class to decide whether to release or not, but we've all been pretty 
busy and that didn't happen.

So you can not just call
   ((ConfigurableBeanFactory) this.beanFactory).destroySingletons()
and
   ((ConfigurableApplicationContext) this.applicationContext).close();
as your new implementation does in the new separate implementations of 
BeanFactoryReference. It should probably stay an inner class, and only 
call the destroy or close, respectively, if the reference count on the 
keyed singleton beanfactory or context goes down to zero.

This will work absolutely fine for people using it like I am, where it 
is used to obtain the parent for the web application context(s), and 
then only released when the web application context gets unloaded.

The other situation, where people do not have one get and release 
wrapping all other gets and releases, is more problematic, since if they 
do sequential gets and releases they will get a sort of thrashing as 
stuff gets continuously loaded and unloaded. What these people will have 
to do is themselves force an initial load without a release, at their 
app startup.

As for the default ejbRemove not calling unloadBeanFactory (like the 
comment for unloadBeanFActory says is supposed to happen), that appears 
to be an oversight and something that was in there since Nov. or Dec. 
Thanks for catching that. The old old code never did any unloading at 
all. Then in Nov./Dec. I added the unloadBeanFactory method, but 
apparently forgot to call it.

Regards,
Colin


jürgen höller [werk3AT] wrote:

>Agreed, the RC1 API should be considered as final as possible. However, the BeanFactoryLocator was a brand-new RC1 feature, added pretty much last minute there, so I guess it's arguable to refine this for 1.0 final - particularly if it just affects advanced users that diverge from the default EJB support configuration.
> 
>From my point of view, I'm as happy as can be with the current state of the framework. What I would like to see included in 1.0 final nevertheless is (backward-compatible) support for more exception categories in the SQLException translator, as suggested by Thomas, and possibly a convenient option to set a transaction rollback-only no matter if driven by declarative or programmatic demarcation, as suggested by Colin and Alef.
> 
>BTW, I'll send a mail regarding the Spring roadmap shortly.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Rod Johnson
>Gesendet: Sa 14.02.2004 18:42
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Revised BeanFactoryLocator and EJB support classes
>
>
>
>I agree with these changes, but I think we should try to avoid API changes
>in general from now to 1.0 final. With RC1 we are committing to a final API.
>Also, I'd rather we don't have enough changes that we need an RC2.
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "jürgen höller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Saturday, February 14, 2004 5:22 PM
>Subject: [Springframework-developer] Revised BeanFactoryLocator and EJB
>support classes
>
>
>Colin, Rod, everyone,
>
>I revised the BeanFactoryLocator and EJB support classes yesterday, mainly
>to align the naming of the implementation classes with Spring's general
>naming patterns. For example, the ApplicationContext-specific classes are
>now called "ContextJndiBeanFactoryLocator" and
>"ContextSingletonBeanFactoryLocator". I've also factored out the
>BeanFactoryReference implementations for newly created BeanFactories into
>separate classes, making them invoke
>"ConfigurableBeanFactory.destroySingletons" respectively
>"ConfigurableApplicationContext.close" on release.
>
>I've adapted the EJB support classes accordingly and, on the occasion, moved
>the logger instance variable from AbstractEnterpriseBean to
>AbstractStatelessSessionBean and AbstractMessageDriverBean. Someone
>complained on the mailing list a while ago that removing and setting the
>logger instance for SFSBs is a nuisance, and I agree - the subclass should
>hold its own *static* logger instance there. Of course, this doesn't apply
>to SLSBs and MDBs, thus the change.
>
>I've also noted that AbstractEnterpriseBean's "ejbRemove" implementation did
>*not* invoke BeanFactoryLocator.release; is there any rationale for this?
>For the time being, I've made it invoke release, as I consider it important
>to destroy resource singletons like a local SessionFactory or
>PersistenceManager on BeanFactory respectively ApplicationContext shutdown.
>
>I hope you don't mind the name changes. My goal is to keep class and method
>naming as consistent as possible within the Spring codebase; something many
>other open source projects to not respect at all.
>
>Juergen
>  
>

Re: [Springframework-developer] Target date for Spring 1.0 final

[Darren D. <da...@da...>]

j=FCrgen h=F6ller [werk3AT] wrote:

> We should also avoid double documentation in the distribution, i.e.
> remove the separate HTML documents in the docs directory as soon as all
> the info in there is also available in the reference documentation. I'm
> happy if someone does a cleanup in there promptly; I intend to browse
> through it again myself before the actual release.

I'll remove the velocity and tapestry docs as they're now in the referenc=
e=20
source.  I could do with creating a couple of images first though.  Could=
=20
whoever created the images in the introductory chapters tell me what was=20
used to do them so I can try and create similar types?

Cheers

--=20

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

[Springframework-developer] Target date for Spring 1.0 final

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

Dear Spring developers,
=20
After a few minor bugfixes and modifications after 1.0 RC1, we are now =
ready to concentrate on 1.0 final. So I suggest *March 1st* as target =
date for the 1.0 final release! I won't be worried if some parts of the =
docs aren't completely finished by then, as we can always complete them =
afterwards.
=20
As discussed in other recent mails, we should concentrate on fixing bugs =
and completing documentation. Minor feature enhancements are OK from my =
point of view; however, they should be delayed till 1.1 if they are =
beyond trivial. We should avoid the need for an RC2 if possible; after =
all, there's a life after Spring 1.0 final :-)
=20
Some things remain to be clarified for 1.0, namely the AOP Alliance =
version that we ship, and updating to the most current Commons =
Attributes snapshot. All other dependencies are up-to-date as far as I =
see; updating to Ant 1.6.1 is hardly worth mentioning. On the occasion, =
it would be good if CGLIB 2.0 went final in time.
=20
We should also avoid double documentation in the distribution, i.e. =
remove the separate HTML documents in the docs directory as soon as all =
the info in there is also available in the reference documentation. I'm =
happy if someone does a cleanup in there promptly; I intend to browse =
through it again myself before the actual release.
=20
So, next stop: 1.0 final - March 1st!
=20
Regards,
Juergen
=20