springframework-developer — Spring Framework developers list

Re: [Springframework-developer] RE: internationalizing bean properties

[Chris W. <cwi...@op...>]

Keith Donald said:
> ...
> ... the bean post processor could notice the @@Translatable attribute and
> then know to load the string value from a message source, then set it.  I
> could also use introduction to attach internationalized "descriptor"
> classes
> (having stuff like name, caption, description) which are "common"
> properties
> needed when representing an object in a GUI (for the label, tooltip, and
> detailed description, for example.)

I'll delurk for a second: Wow. This would be fantastic.

I love this framework.

Chris


-- 
Chris Winters (cwi...@op...)
Senior Software Architect

[Springframework-developer] RE: internationalizing bean properties

[Keith D. <kd...@cs...>]

I got to thinking about this some more and I think there is a better way =
to
support internationalization of bean property values---attributes =
metadata.
=20
For example, if I do this:
=20
/**
 * @@Translatable
 */
public void setMyTranslatableProperty(String property);
=20
... the bean post processor could notice the @@Translatable attribute =
and
then know to load the string value from a message source, then set it.  =
I
could also use introduction to attach internationalized "descriptor" =
classes
(having stuff like name, caption, description) which are "common" =
properties
needed when representing an object in a GUI (for the label, tooltip, and
detailed description, for example.)
=20
IoC+AOP+Metadata is quite enabling! All kinds of stuff seems possible =
that
just wasn't before.  Keith
=20
 -----Original Message-----
From: Keith Donald [mailto:kd...@cs...]=20
Sent: Wednesday, March 31, 2004 5:42 PM
To: 'spr...@li...'
Subject: internationalizing bean properties



For spring-rcp I have several bean declarations for configuring things =
like
actions, menus, and such--- basically beans whose properties need
internationalization.
=20
Wanted to make sure I am going about the best way of doing this:
=20
1. Initially, before adding internationalization support, I had these =
bean's
localizable properties simply specified manually in the bean =
configuration
xml.  Not good.
=20
Since I must provide internationalization of the GUI I've considered two
options:
    - use a property placeholder configurer to inject localized property
values from some properties file
    - use a bean post processor to retrieve localized properties/icons =
from
message source and image source (before bean initialization)
=20
I've just implemented the latter, as it simplifies the XML code (I no =
longer
have to specify values or variable names for the resolvable properties =
in
xml) - the bean post processor attempts to resolve configuration values =
by
checking to see if a bean implements a certain "DescriptionConfigurable" =
or
"LabelConfigurable" or "ImageIconConfigurable" interface, for example.  =
The
beanName is used as a prefix to the resolved message/image code.  So for
example, for the "aboutAction" bean you'd see:
=20
messages_en.properties
=20
# LabelConfigurable interface: setLabel(LabelInfo)
# (The '&' is the displayed mnemonic + index and the @ references the
accelerator key - adapted from Eclipse's format.)
aboutAction.label=3D&About @ CTRL-A
=20
# DescriptionConfigurable: setCaption(String) / setDescription(String)
aboutAction.caption=3DDisplays an about dialog
aboutAction.description=3DThe about action long description...
=20
images_en.properties
=20
# ImageIconConfigurable: setIcon(ImageIcon)
aboutAction.icon=3Dcore/about.gif
=20
# ImageIconButtonConfigurable: rollover/pressed/disabled
aboutAction.rolloverIcon=3D..
aboutAction.pressedIcon=3D...
aboutAction.disabledIcon...
=20
Seems like a pretty good approach, and simplifies the beans themselves a =
lot
since they don't have to deal with message or image lookup.  Just wanted =
to
post for comments and if there is anything I should be aware of... Keith

RE: [Springframework-developer] Road map

[Keith D. <kd...@cs...>]

I think experimenting with integration with scripting languages like
Groovy/Beanshell/Jython for configuration sounds like a great idea.  I =
like
how lists, maps, and properties are "first class citizens."

Groovy was just accepted as a JSR which I find interesting! Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
tho...@tr...
Sent: Thursday, April 01, 2004 12:09 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Road map



>From a JDBC perspective I'd like to add support for JDBC 3.0 auto=20
>generated
keys, maybe via an SqlInsert object.  This should be possible for 1.1.

I'd also like to see support for declaring ApplicationContexts using a
scripting language like Jython.  This would probably be best for 1.2.

James Duncan Davidson has an interesting take on Ant and XML files:
http://x180.net/Articles/Java/AntAndXML.html

Thomas


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

> I'll be writing a number of tools to support some people here in code
> manipulation and debuggin, but I'm not sure exactly how much actual UI =

> there'll be. A fair number of them may be command-line or with simple=20
> UIs, so at this point it's not a given that I'll need any sort of=20
> complicated library. I'll probably be starting in about 3-4 weeks.
>=20
> As for Eclipse, I've used it for ages, but on the programming side I'm
> actually a complete neophyte, although I'm itching to get into the RCP
stuff
>=20
> Keith Donald wrote:
>=20
> >Colin,
> >
> >When do you think you'll be moving to the client-side?  It'd be great =

> >to work together.  I have a similiar requirement: I need RCP in my=20
> >current project, so I will be nicely aligned for developing the=20
> >module over the coming months.  It would be great if you could be an=20
> >early adopter and developer at the same time...
> >
> >If you decide to go Eclipse RCP that would be good, too.  The main=20
> >upside I think we can offer is better Swing support (Swing is more=20
> >mature than SWT, and obviously a standard) and a nice integration=20
> >with the rest of Spring. But having an Eclipse expert would be=20
> >invaluable for improving our platform capabilities.  I'd also be=20
> >interested in seeing if there are ways we can integrate with the=20
> >Eclipse effort as it matures, too.
> >
> >Keith
> >
> >----- Original Message -----
> >From: "Colin Sampaleanu" <col...@ex...>
> >To: <spr...@li...>
> >Sent: Wednesday, March 31, 2004 5:20 PM
> >Subject: Re: [Springframework-developer] Road map
> >
> >
> > =20
> >
> >>Actually it's looking like I may be doing some client-side work (as=20
> >>opposed to the mostly back-end/web stuff I am doing now), so I may=20
> >>get involved. Haven't decided if I want to do the stuff in Swing or=20
> >>Eclipse RCP though...
> >>
> >>
> >>Keith Donald wrote:
> >>
> >>   =20
> >>
> >>>Just like to add to the pot here regarding spring-rcp (especially=20
> >>>since
> >>>     =20
> >>>
> >work
> > =20
> >
> >>>is picking back up now):
> >>>
> >>>- I'd like to target the first 1.0 RCP release candidate along side
> >>>     =20
> >>>
> >Spring
> > =20
> >
> >>>1.1 final this summer.
> >>>
> >>>We plan to include in the distribution a sample application=20
> >>>demonstrating the features of the platform (likely a port of the=20
> >>>PetClinic or Thomas's Beer app, adding RCP value like 'quick'=20
> >>>sorting/filtering and as-you-type field validation.)  I am hopeful=20
> >>>by the first release we'll have several articles lined up, too (I=20
> >>>know several people interested in rich client
> >>>     =20
> >>>
> >dev
> > =20
> >
> >>>have expressed interest in helping out there!)
> >>>
> >>>Thanks,
> >>>Keith
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: spr...@li...
> >>>[mailto:spr...@li...] On=20
> >>>Behalf
> >>>     =20
> >>>
> >Of
> > =20
> >
> >>>j=FCrgen h=F6ller [werk3AT]
> >>>Sent: Wednesday, March 31, 2004 9:44 AM
> >>>To: spr...@li...
> >>>Subject: Re: [Springframework-developer] Road map
> >>>
> >>>
> >>>Good point regarding scheduling 1.1.1. I've intended to fill in a=20
> >>>placeholder to make the gap to 1.2 RC1 seem less large ;-) I=20
> >>>completely agree that we shouldn't schedule such point releases in=20
> >>>an official
> >>>     =20
> >>>
> >release
> > =20
> >
> >>>plan.
> >>>
> >>>If we manage to get JSF and/or Portlet support done in time for=20
> >>>1.1, then I'm all for including it earlier. I'd like to release 1.1 =

> >>>final by the
> >>>     =20
> >>>
> >end
> > =20
> >
> >>>of August, though; I don't want to delay it for further features.
> >>>
> >>>Juergen
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: spr...@li...
> >>>[mailto:spr...@li...]On=20
> >>>Behalf
> >>>     =20
> >>>
> >Of
> > =20
> >
> >>>Rod Johnson
> >>>Sent: Wednesday, March 31, 2004 2:41 PM
> >>>To: spr...@li...
> >>>Subject: Re: [Springframework-developer] Road map
> >>>
> >>>
> >>>Some comments:
> >>>
> >>>Spring 1.0.x: doc polishing, bugfixing, minor enhancements
> >>>- 1.0.1: early April
> >>>- 1.0.2: late May
> >>>
> >>>Spring 1.1.x: JMS support, JMX support, declarative validation
> >>>[RJ: pointcut expression language (AOP), JSR-175 preview? ]
> >>>- 1.1 RC1: early July
> >>>- 1.1 final: late August
> >>>- 1.1.1: late September
> >>>[RJ: why are we _scheduling_ a 1.1.1?]
> >>>
> >>>Spring 1.2.x: OGNL support, JCA support, enhanced RMI support
> >>>- 1.2 RC1: early November
> >>>- 1.2 final: late December
> >>>
> >>>Further issues are JSF and Portlet support. There is actually quite =

> >>>a bit
> >>>     =20
> >>>
> >of
> > =20
> >
> >>>interest in these from various users/integrators; they are also=20
> >>>important for us from a marketing perspective. I'm not keen on=20
> >>>providing official support before 1.2, though.
> >>>
> >>>[RJ: depends on what's involved. I'd be keen to have JSF support=20
> >>>sooner rather than later if it's straightforward. I'm going to be=20
> >>>looking at
> >>>     =20
> >>>
> >that
> > =20
> >
> >>>soon. Portlets I think are more of a niche interest. ]
> >>>
> >>>Regards,
> >>>Juergen
> >>>     =20
> >>>
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of=20
> GenToo technologies. Learn everything from fundamentals to system=20
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20





-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Road map

[<tho...@tr...>]

From a JDBC perspective I'd like to add support for JDBC 3.0 auto generated
keys, maybe via an SqlInsert object.  This should be possible for 1.1.

I'd also like to see support for declaring ApplicationContexts using a scripting
language like Jython.  This would probably be best for 1.2.

James Duncan Davidson has an interesting take on Ant and XML files:
http://x180.net/Articles/Java/AntAndXML.html

Thomas


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

> I'll be writing a number of tools to support some people here in code 
> manipulation and debuggin, but I'm not sure exactly how much actual UI 
> there'll be. A fair number of them may be command-line or with simple 
> UIs, so at this point it's not a given that I'll need any sort of 
> complicated library. I'll probably be starting in about 3-4 weeks.
> 
> As for Eclipse, I've used it for ages, but on the programming side I'm 
> actually a complete neophyte, although I'm itching to get into the RCP stuff
> 
> Keith Donald wrote:
> 
> >Colin,
> >
> >When do you think you'll be moving to the client-side?  It'd be great to
> >work together.  I have a similiar requirement: I need RCP in my current
> >project, so I will be nicely aligned for developing the module over the
> >coming months.  It would be great if you could be an early adopter and
> >developer at the same time...
> >
> >If you decide to go Eclipse RCP that would be good, too.  The main upside I
> >think we can offer is better Swing support (Swing is more mature than SWT,
> >and obviously a standard) and a nice integration with the rest of Spring.
> >But having an Eclipse expert would be invaluable for improving our platform
> >capabilities.  I'd also be interested in seeing if there are ways we can
> >integrate with the Eclipse effort as it matures, too.
> >
> >Keith
> >
> >----- Original Message ----- 
> >From: "Colin Sampaleanu" <col...@ex...>
> >To: <spr...@li...>
> >Sent: Wednesday, March 31, 2004 5:20 PM
> >Subject: Re: [Springframework-developer] Road map
> >
> >
> >  
> >
> >>Actually it's looking like I may be doing some client-side work (as
> >>opposed to the mostly back-end/web stuff I am doing now), so I may get
> >>involved. Haven't decided if I want to do the stuff in Swing or Eclipse
> >>RCP though...
> >>
> >>
> >>Keith Donald wrote:
> >>
> >>    
> >>
> >>>Just like to add to the pot here regarding spring-rcp (especially since
> >>>      
> >>>
> >work
> >  
> >
> >>>is picking back up now):
> >>>
> >>>- I'd like to target the first 1.0 RCP release candidate along side
> >>>      
> >>>
> >Spring
> >  
> >
> >>>1.1 final this summer.
> >>>
> >>>We plan to include in the distribution a sample application demonstrating
> >>>the features of the platform (likely a port of the PetClinic or Thomas's
> >>>Beer app, adding RCP value like 'quick' sorting/filtering and as-you-type
> >>>field validation.)  I am hopeful by the first release we'll have several
> >>>articles lined up, too (I know several people interested in rich client
> >>>      
> >>>
> >dev
> >  
> >
> >>>have expressed interest in helping out there!)
> >>>
> >>>Thanks,
> >>>Keith
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: spr...@li...
> >>>[mailto:spr...@li...] On Behalf
> >>>      
> >>>
> >Of
> >  
> >
> >>>jürgen höller [werk3AT]
> >>>Sent: Wednesday, March 31, 2004 9:44 AM
> >>>To: spr...@li...
> >>>Subject: Re: [Springframework-developer] Road map
> >>>
> >>>
> >>>Good point regarding scheduling 1.1.1. I've intended to fill in a
> >>>placeholder to make the gap to 1.2 RC1 seem less large ;-) I completely
> >>>agree that we shouldn't schedule such point releases in an official
> >>>      
> >>>
> >release
> >  
> >
> >>>plan.
> >>>
> >>>If we manage to get JSF and/or Portlet support done in time for 1.1, then
> >>>I'm all for including it earlier. I'd like to release 1.1 final by the
> >>>      
> >>>
> >end
> >  
> >
> >>>of August, though; I don't want to delay it for further features.
> >>>
> >>>Juergen
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: spr...@li...
> >>>[mailto:spr...@li...]On Behalf
> >>>      
> >>>
> >Of
> >  
> >
> >>>Rod Johnson
> >>>Sent: Wednesday, March 31, 2004 2:41 PM
> >>>To: spr...@li...
> >>>Subject: Re: [Springframework-developer] Road map
> >>>
> >>>
> >>>Some comments:
> >>>
> >>>Spring 1.0.x: doc polishing, bugfixing, minor enhancements
> >>>- 1.0.1: early April
> >>>- 1.0.2: late May
> >>>
> >>>Spring 1.1.x: JMS support, JMX support, declarative validation
> >>>[RJ: pointcut expression language (AOP), JSR-175 preview? ]
> >>>- 1.1 RC1: early July
> >>>- 1.1 final: late August
> >>>- 1.1.1: late September
> >>>[RJ: why are we _scheduling_ a 1.1.1?]
> >>>
> >>>Spring 1.2.x: OGNL support, JCA support, enhanced RMI support
> >>>- 1.2 RC1: early November
> >>>- 1.2 final: late December
> >>>
> >>>Further issues are JSF and Portlet support. There is actually quite a bit
> >>>      
> >>>
> >of
> >  
> >
> >>>interest in these from various users/integrators; they are also important
> >>>for us from a marketing perspective. I'm not keen on providing official
> >>>support before 1.2, though.
> >>>
> >>>[RJ: depends on what's involved. I'd be keen to have JSF support sooner
> >>>rather than later if it's straightforward. I'm going to be looking at
> >>>      
> >>>
> >that
> >  
> >
> >>>soon. Portlets I think are more of a niche interest. ]
> >>>
> >>>Regards,
> >>>Juergen
> >>>      
> >>>
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

RE: [Springframework-developer] Examples of PlatformTransactionManager?

[Alef A. <al...@jt...>]

I'll do it this afternoon.

Alef

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of rod...@in...
> Sent: Thursday, April 01, 2004 10:32 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Examples of
> PlatformTransactionManager?
> 
> Can someone please put this example in the reference manual
> transaction chapter? I won't have CVS access for a few days...
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Examples of PlatformTransactionManager?

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

Can someone please put this example in the reference manual 
transaction chapter? I won't have CVS access for a few days...

Re: [Springframework-developer] Examples of PlatformTransactionManager?

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

It's pretty simple: First, pass your PlatformTransactionManager bean via =
a bean reference to an application object (for example a controller), =
into a bean property of type PlatformTransactionManager. Then write code =
like the following, assuming a transactionManager reference:

  DefaultTransactionDefinition def =3D new =
DefaultTransactionDefinition()
  =
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
  TransactionStatus status =3D =
transactionManager.getTransactionDefinition(def);
  try {
    ...
  }
  catch (MyException ex) {
    transactionManager.rollback(status);
    throw ex;
  }
  transactionManager.commit(status);

Note that you do not need to invoke rollback if commit failed (like with =
JTA), therefore the commit occurs after the try-catch block. You can =
throw any checked exception from within the try-catch block; that's the =
advantage over using TransactionTemplate which in other respects behaves =
exactly the same.

Suspend and resume do not have to be invoked directly but can be =
achieved by setting an appropriate propagation behavior, just like with =
declarative demarcation. If you change PROPAGATION_REQUIRED to =
PROPAGATION_REQUIRES_NEW in the example above, your block will execute =
in a new transaction, with the current one (if any) getting suspended at =
the beginning and resumed at the end.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of James Cook
Sent: Thursday, April 01, 2004 1:28 AM
To: spr...@li...
Subject: [Springframework-developer] Examples of
PlatformTransactionManager?


Are there any examples of how to use the PlatformTransactionManager
available anywhere? We are using Hibernate and JDBC and feel that there =
may
be instances where we will want to use this API instead of the
TransactionTemplate or declarative approach.

For starters, how does our controller class get access to a
PlatformTransaction Manager?

Is calling getTransaction(TransactionDefinition) the technique for =
beginning
a transaction?

Commit and rollback seemed straightforward, but what about suspend and
resume?

Thanks for any pointers





-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Road map

[Keith D. <kd...@cs...>]

Like Eclipse RCP you'll find with the spring-rcp stuff it's easy to get a
simple GUI up and running which you then decorate with action bars, views=
,
and pages that support various user-tasks.  I just did some of that today
actually, as we just kicked off our client-side GUI development here.

Without going too much into the details, essentially here's what I had to
do:

- I configure a "Console" singleton bean in a Spring application context =
--=20
which is similiar to Eclipse's Workbench class.  The console provides the
application name/version/build ID, startup splash screen, window icon, ja=
va
help set path, and about box for the app.  It also loads a configurable
"defaultPage" for the application on startup in a single ConsoleWindow, a=
nd
is capable of opening/managing multiple ConsoleWindows.

Each ConsoleWindow has a menubar, toolbar, center page display, and statu=
s
line/progress bar.  Individual GUI actions, which can be "contributed" to
any of the "bars" like a menubar or toolbar -- are also configured by Spr=
ing
(their label, icon, mnemonic, etc.)  So for example, I needed a "New Sche=
ma"
action today placed in the "File" menu and also in the toolbar.  To do th=
is
I specified that in Spring configuration, and the system handled the rest=
.

The platform uses the Spring message source and awt image source for
internationalizing GUI messages and icons.  I was using the wizard framew=
ork
extensively today, which provides classes enabling step-by-step wizards w=
ith
one or more wizard pages.

Just to give you an idea from some fresh stuff I worked on today.  There =
is
a lot we should be able to do by summer time.  Keith

----- Original Message -----=20
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Wednesday, March 31, 2004 9:14 PM
Subject: Re: [Springframework-developer] Road map


> I'll be writing a number of tools to support some people here in code
> manipulation and debuggin, but I'm not sure exactly how much actual UI
> there'll be. A fair number of them may be command-line or with simple
> UIs, so at this point it's not a given that I'll need any sort of
> complicated library. I'll probably be starting in about 3-4 weeks.
>
> As for Eclipse, I've used it for ages, but on the programming side I'm
> actually a complete neophyte, although I'm itching to get into the RCP
stuff
>
> Keith Donald wrote:
>
> >Colin,
> >
> >When do you think you'll be moving to the client-side?  It'd be great =
to
> >work together.  I have a similiar requirement: I need RCP in my curren=
t
> >project, so I will be nicely aligned for developing the module over th=
e
> >coming months.  It would be great if you could be an early adopter and
> >developer at the same time...
> >
> >If you decide to go Eclipse RCP that would be good, too.  The main ups=
ide
I
> >think we can offer is better Swing support (Swing is more mature than
SWT,
> >and obviously a standard) and a nice integration with the rest of Spri=
ng.
> >But having an Eclipse expert would be invaluable for improving our
platform
> >capabilities.  I'd also be interested in seeing if there are ways we c=
an
> >integrate with the Eclipse effort as it matures, too.
> >
> >Keith
> >
> >----- Original Message -----=20
> >From: "Colin Sampaleanu" <col...@ex...>
> >To: <spr...@li...>
> >Sent: Wednesday, March 31, 2004 5:20 PM
> >Subject: Re: [Springframework-developer] Road map
> >
> >
> >
> >
> >>Actually it's looking like I may be doing some client-side work (as
> >>opposed to the mostly back-end/web stuff I am doing now), so I may ge=
t
> >>involved. Haven't decided if I want to do the stuff in Swing or Eclip=
se
> >>RCP though...
> >>
> >>
> >>Keith Donald wrote:
> >>
> >>
> >>
> >>>Just like to add to the pot here regarding spring-rcp (especially si=
nce
> >>>
> >>>
> >work
> >
> >
> >>>is picking back up now):
> >>>
> >>>- I'd like to target the first 1.0 RCP release candidate along side
> >>>
> >>>
> >Spring
> >
> >
> >>>1.1 final this summer.
> >>>
> >>>We plan to include in the distribution a sample application
demonstrating
> >>>the features of the platform (likely a port of the PetClinic or
Thomas's
> >>>Beer app, adding RCP value like 'quick' sorting/filtering and
as-you-type
> >>>field validation.)  I am hopeful by the first release we'll have
several
> >>>articles lined up, too (I know several people interested in rich cli=
ent
> >>>
> >>>
> >dev
> >
> >
> >>>have expressed interest in helping out there!)
> >>>
> >>>Thanks,
> >>>Keith
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: spr...@li...
> >>>[mailto:spr...@li...] On
Behalf
> >>>
> >>>
> >Of
> >
> >
> >>>j=FCrgen h=F6ller [werk3AT]
> >>>Sent: Wednesday, March 31, 2004 9:44 AM
> >>>To: spr...@li...
> >>>Subject: Re: [Springframework-developer] Road map
> >>>
> >>>
> >>>Good point regarding scheduling 1.1.1. I've intended to fill in a
> >>>placeholder to make the gap to 1.2 RC1 seem less large ;-) I complet=
ely
> >>>agree that we shouldn't schedule such point releases in an official
> >>>
> >>>
> >release
> >
> >
> >>>plan.
> >>>
> >>>If we manage to get JSF and/or Portlet support done in time for 1.1,
then
> >>>I'm all for including it earlier. I'd like to release 1.1 final by t=
he
> >>>
> >>>
> >end
> >
> >
> >>>of August, though; I don't want to delay it for further features.
> >>>
> >>>Juergen
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: spr...@li...
> >>>[mailto:spr...@li...]On Beh=
alf
> >>>
> >>>
> >Of
> >
> >
> >>>Rod Johnson
> >>>Sent: Wednesday, March 31, 2004 2:41 PM
> >>>To: spr...@li...
> >>>Subject: Re: [Springframework-developer] Road map
> >>>
> >>>
> >>>Some comments:
> >>>
> >>>Spring 1.0.x: doc polishing, bugfixing, minor enhancements
> >>>- 1.0.1: early April
> >>>- 1.0.2: late May
> >>>
> >>>Spring 1.1.x: JMS support, JMX support, declarative validation
> >>>[RJ: pointcut expression language (AOP), JSR-175 preview? ]
> >>>- 1.1 RC1: early July
> >>>- 1.1 final: late August
> >>>- 1.1.1: late September
> >>>[RJ: why are we _scheduling_ a 1.1.1?]
> >>>
> >>>Spring 1.2.x: OGNL support, JCA support, enhanced RMI support
> >>>- 1.2 RC1: early November
> >>>- 1.2 final: late December
> >>>
> >>>Further issues are JSF and Portlet support. There is actually quite =
a
bit
> >>>
> >>>
> >of
> >
> >
> >>>interest in these from various users/integrators; they are also
important
> >>>for us from a marketing perspective. I'm not keen on providing offic=
ial
> >>>support before 1.2, though.
> >>>
> >>>[RJ: depends on what's involved. I'd be keen to have JSF support soo=
ner
> >>>rather than later if it's straightforward. I'm going to be looking a=
t
> >>>
> >>>
> >that
> >
> >
> >>>soon. Portlets I think are more of a niche interest. ]
> >>>
> >>>Regards,
> >>>Juergen
> >>>
> >>>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Road map

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

I'll be writing a number of tools to support some people here in code 
manipulation and debuggin, but I'm not sure exactly how much actual UI 
there'll be. A fair number of them may be command-line or with simple 
UIs, so at this point it's not a given that I'll need any sort of 
complicated library. I'll probably be starting in about 3-4 weeks.

As for Eclipse, I've used it for ages, but on the programming side I'm 
actually a complete neophyte, although I'm itching to get into the RCP stuff

Keith Donald wrote:

>Colin,
>
>When do you think you'll be moving to the client-side?  It'd be great to
>work together.  I have a similiar requirement: I need RCP in my current
>project, so I will be nicely aligned for developing the module over the
>coming months.  It would be great if you could be an early adopter and
>developer at the same time...
>
>If you decide to go Eclipse RCP that would be good, too.  The main upside I
>think we can offer is better Swing support (Swing is more mature than SWT,
>and obviously a standard) and a nice integration with the rest of Spring.
>But having an Eclipse expert would be invaluable for improving our platform
>capabilities.  I'd also be interested in seeing if there are ways we can
>integrate with the Eclipse effort as it matures, too.
>
>Keith
>
>----- Original Message ----- 
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Wednesday, March 31, 2004 5:20 PM
>Subject: Re: [Springframework-developer] Road map
>
>
>  
>
>>Actually it's looking like I may be doing some client-side work (as
>>opposed to the mostly back-end/web stuff I am doing now), so I may get
>>involved. Haven't decided if I want to do the stuff in Swing or Eclipse
>>RCP though...
>>
>>
>>Keith Donald wrote:
>>
>>    
>>
>>>Just like to add to the pot here regarding spring-rcp (especially since
>>>      
>>>
>work
>  
>
>>>is picking back up now):
>>>
>>>- I'd like to target the first 1.0 RCP release candidate along side
>>>      
>>>
>Spring
>  
>
>>>1.1 final this summer.
>>>
>>>We plan to include in the distribution a sample application demonstrating
>>>the features of the platform (likely a port of the PetClinic or Thomas's
>>>Beer app, adding RCP value like 'quick' sorting/filtering and as-you-type
>>>field validation.)  I am hopeful by the first release we'll have several
>>>articles lined up, too (I know several people interested in rich client
>>>      
>>>
>dev
>  
>
>>>have expressed interest in helping out there!)
>>>
>>>Thanks,
>>>Keith
>>>
>>>
>>>-----Original Message-----
>>>From: spr...@li...
>>>[mailto:spr...@li...] On Behalf
>>>      
>>>
>Of
>  
>
>>>jürgen höller [werk3AT]
>>>Sent: Wednesday, March 31, 2004 9:44 AM
>>>To: spr...@li...
>>>Subject: Re: [Springframework-developer] Road map
>>>
>>>
>>>Good point regarding scheduling 1.1.1. I've intended to fill in a
>>>placeholder to make the gap to 1.2 RC1 seem less large ;-) I completely
>>>agree that we shouldn't schedule such point releases in an official
>>>      
>>>
>release
>  
>
>>>plan.
>>>
>>>If we manage to get JSF and/or Portlet support done in time for 1.1, then
>>>I'm all for including it earlier. I'd like to release 1.1 final by the
>>>      
>>>
>end
>  
>
>>>of August, though; I don't want to delay it for further features.
>>>
>>>Juergen
>>>
>>>
>>>-----Original Message-----
>>>From: spr...@li...
>>>[mailto:spr...@li...]On Behalf
>>>      
>>>
>Of
>  
>
>>>Rod Johnson
>>>Sent: Wednesday, March 31, 2004 2:41 PM
>>>To: spr...@li...
>>>Subject: Re: [Springframework-developer] Road map
>>>
>>>
>>>Some comments:
>>>
>>>Spring 1.0.x: doc polishing, bugfixing, minor enhancements
>>>- 1.0.1: early April
>>>- 1.0.2: late May
>>>
>>>Spring 1.1.x: JMS support, JMX support, declarative validation
>>>[RJ: pointcut expression language (AOP), JSR-175 preview? ]
>>>- 1.1 RC1: early July
>>>- 1.1 final: late August
>>>- 1.1.1: late September
>>>[RJ: why are we _scheduling_ a 1.1.1?]
>>>
>>>Spring 1.2.x: OGNL support, JCA support, enhanced RMI support
>>>- 1.2 RC1: early November
>>>- 1.2 final: late December
>>>
>>>Further issues are JSF and Portlet support. There is actually quite a bit
>>>      
>>>
>of
>  
>
>>>interest in these from various users/integrators; they are also important
>>>for us from a marketing perspective. I'm not keen on providing official
>>>support before 1.2, though.
>>>
>>>[RJ: depends on what's involved. I'd be keen to have JSF support sooner
>>>rather than later if it's straightforward. I'm going to be looking at
>>>      
>>>
>that
>  
>
>>>soon. Portlets I think are more of a niche interest. ]
>>>
>>>Regards,
>>>Juergen
>>>      
>>>

Re: [Springframework-developer] Road map

[Keith D. <kd...@cs...>]

Colin,

When do you think you'll be moving to the client-side?  It'd be great to
work together.  I have a similiar requirement: I need RCP in my current
project, so I will be nicely aligned for developing the module over the
coming months.  It would be great if you could be an early adopter and
developer at the same time...

If you decide to go Eclipse RCP that would be good, too.  The main upside=
 I
think we can offer is better Swing support (Swing is more mature than SWT=
,
and obviously a standard) and a nice integration with the rest of Spring.
But having an Eclipse expert would be invaluable for improving our platfo=
rm
capabilities.  I'd also be interested in seeing if there are ways we can
integrate with the Eclipse effort as it matures, too.

Keith

----- Original Message -----=20
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Wednesday, March 31, 2004 5:20 PM
Subject: Re: [Springframework-developer] Road map


> Actually it's looking like I may be doing some client-side work (as
> opposed to the mostly back-end/web stuff I am doing now), so I may get
> involved. Haven't decided if I want to do the stuff in Swing or Eclipse
> RCP though...
>
>
> Keith Donald wrote:
>
> >Just like to add to the pot here regarding spring-rcp (especially sinc=
e
work
> >is picking back up now):
> >
> >- I'd like to target the first 1.0 RCP release candidate along side
Spring
> >1.1 final this summer.
> >
> >We plan to include in the distribution a sample application demonstrat=
ing
> >the features of the platform (likely a port of the PetClinic or Thomas=
's
> >Beer app, adding RCP value like 'quick' sorting/filtering and as-you-t=
ype
> >field validation.)  I am hopeful by the first release we'll have sever=
al
> >articles lined up, too (I know several people interested in rich clien=
t
dev
> >have expressed interest in helping out there!)
> >
> >Thanks,
> >Keith
> >
> >
> >-----Original Message-----
> >From: spr...@li...
> >[mailto:spr...@li...] On Beha=
lf
Of
> >j=FCrgen h=F6ller [werk3AT]
> >Sent: Wednesday, March 31, 2004 9:44 AM
> >To: spr...@li...
> >Subject: Re: [Springframework-developer] Road map
> >
> >
> >Good point regarding scheduling 1.1.1. I've intended to fill in a
> >placeholder to make the gap to 1.2 RC1 seem less large ;-) I completel=
y
> >agree that we shouldn't schedule such point releases in an official
release
> >plan.
> >
> >If we manage to get JSF and/or Portlet support done in time for 1.1, t=
hen
> >I'm all for including it earlier. I'd like to release 1.1 final by the
end
> >of August, though; I don't want to delay it for further features.
> >
> >Juergen
> >
> >
> >-----Original Message-----
> >From: spr...@li...
> >[mailto:spr...@li...]On Behal=
f
Of
> >Rod Johnson
> >Sent: Wednesday, March 31, 2004 2:41 PM
> >To: spr...@li...
> >Subject: Re: [Springframework-developer] Road map
> >
> >
> >Some comments:
> >
> >Spring 1.0.x: doc polishing, bugfixing, minor enhancements
> >- 1.0.1: early April
> >- 1.0.2: late May
> >
> >Spring 1.1.x: JMS support, JMX support, declarative validation
> >[RJ: pointcut expression language (AOP), JSR-175 preview? ]
> >- 1.1 RC1: early July
> >- 1.1 final: late August
> >- 1.1.1: late September
> >[RJ: why are we _scheduling_ a 1.1.1?]
> >
> >Spring 1.2.x: OGNL support, JCA support, enhanced RMI support
> >- 1.2 RC1: early November
> >- 1.2 final: late December
> >
> >Further issues are JSF and Portlet support. There is actually quite a =
bit
of
> >interest in these from various users/integrators; they are also import=
ant
> >for us from a marketing perspective. I'm not keen on providing officia=
l
> >support before 1.2, though.
> >
> >[RJ: depends on what's involved. I'd be keen to have JSF support soone=
r
> >rather than later if it's straightforward. I'm going to be looking at
that
> >soon. Portlets I think are more of a niche interest. ]
> >
> >Regards,
> >Juergen
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Examples of PlatformTransactionManager?

[James C. <jim...@do...>]

Are there any examples of how to use the PlatformTransactionManager
available anywhere? We are using Hibernate and JDBC and feel that there may
be instances where we will want to use this API instead of the
TransactionTemplate or declarative approach.

For starters, how does our controller class get access to a
PlatformTransaction Manager?

Is calling getTransaction(TransactionDefinition) the technique for beginning
a transaction?

Commit and rollback seemed straightforward, but what about suspend and
resume?

Thanks for any pointers

[Springframework-developer] internationalizing bean properties

[Keith D. <kd...@cs...>]

For spring-rcp I have several bean declarations for configuring things =
like
actions, menus, and such--- basically beans whose properties need
internationalization.
=20
Wanted to make sure I am going about the best way of doing this:
=20
1. Initially, before adding internationalization support, I had these =
bean's
localizable properties simply specified manually in the bean =
configuration
xml.  Not good.
=20
Since I must provide internationalization of the GUI I've considered two
options:
    - use a property placeholder configurer to inject localized property
values from some properties file
    - use a bean post processor to retrieve localized properties/icons =
from
message source and image source (before bean initialization)
=20
I've just implemented the latter, as it simplifies the XML code (I no =
longer
have to specify values or variable names for the resolvable properties =
in
xml) - the bean post processor attempts to resolve configuration values =
by
checking to see if a bean implements a certain "DescriptionConfigurable" =
or
"LabelConfigurable" or "ImageIconConfigurable" interface, for example.  =
The
beanName is used as a prefix to the resolved message/image code.  So for
example, for the "aboutAction" bean you'd see:
=20
messages_en.properties
=20
# LabelConfigurable interface: setLabel(LabelInfo)
# (The '&' is the displayed mnemonic + index and the @ references the
accelerator key - adapted from Eclipse's format.)
aboutAction.label=3D&About @ CTRL-A
=20
# DescriptionConfigurable: setCaption(String) / setDescription(String)
aboutAction.caption=3DDisplays an about dialog
aboutAction.description=3DThe about action long description...
=20
images_en.properties
=20
# ImageIconConfigurable: setIcon(ImageIcon)
aboutAction.icon=3Dcore/about.gif
=20
# ImageIconButtonConfigurable: rollover/pressed/disabled
aboutAction.rolloverIcon=3D..
aboutAction.pressedIcon=3D...
aboutAction.disabledIcon...
=20
Seems like a pretty good approach, and simplifies the beans themselves a =
lot
since they don't have to deal with message or image lookup.  Just wanted =
to
post for comments and if there is anything I should be aware of... Keith

Re: [Springframework-developer] Road map

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

Actually it's looking like I may be doing some client-side work (as=20
opposed to the mostly back-end/web stuff I am doing now), so I may get=20
involved. Haven't decided if I want to do the stuff in Swing or Eclipse=20
RCP though...


Keith Donald wrote:

>Just like to add to the pot here regarding spring-rcp (especially since =
work
>is picking back up now):
>
>- I'd like to target the first 1.0 RCP release candidate along side Spri=
ng
>1.1 final this summer.
>
>We plan to include in the distribution a sample application demonstratin=
g
>the features of the platform (likely a port of the PetClinic or Thomas's
>Beer app, adding RCP value like 'quick' sorting/filtering and as-you-typ=
e
>field validation.)  I am hopeful by the first release we'll have several
>articles lined up, too (I know several people interested in rich client =
dev
>have expressed interest in helping out there!)
>
>Thanks,
>Keith
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf=
 Of
>j=FCrgen h=F6ller [werk3AT]
>Sent: Wednesday, March 31, 2004 9:44 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Road map
>
>
>Good point regarding scheduling 1.1.1. I've intended to fill in a
>placeholder to make the gap to 1.2 RC1 seem less large ;-) I completely
>agree that we shouldn't schedule such point releases in an official rele=
ase
>plan.
>
>If we manage to get JSF and/or Portlet support done in time for 1.1, the=
n
>I'm all for including it earlier. I'd like to release 1.1 final by the e=
nd
>of August, though; I don't want to delay it for further features.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf =
Of
>Rod Johnson
>Sent: Wednesday, March 31, 2004 2:41 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Road map
>
>
>Some comments:
>
>Spring 1.0.x: doc polishing, bugfixing, minor enhancements
>- 1.0.1: early April
>- 1.0.2: late May
>
>Spring 1.1.x: JMS support, JMX support, declarative validation
>[RJ: pointcut expression language (AOP), JSR-175 preview? ]
>- 1.1 RC1: early July
>- 1.1 final: late August
>- 1.1.1: late September
>[RJ: why are we _scheduling_ a 1.1.1?]
>
>Spring 1.2.x: OGNL support, JCA support, enhanced RMI support
>- 1.2 RC1: early November
>- 1.2 final: late December
>
>Further issues are JSF and Portlet support. There is actually quite a bi=
t of
>interest in these from various users/integrators; they are also importan=
t
>for us from a marketing perspective. I'm not keen on providing official
>support before 1.2, though.
>
>[RJ: depends on what's involved. I'd be keen to have JSF support sooner
>rather than later if it's straightforward. I'm going to be looking at th=
at
>soon. Portlets I think are more of a niche interest. ]
>
>Regards,
>Juergen
> =20
>

Re: [Springframework-developer] DocBook: 'method' and c'lassname' tags work for html, but not 'property'

[<tho...@tr...>]

I made one change at one point that caused the html generation to spin in what
seemed to be an endless loop. I killed the process so I don't know if it would
have filled my disk or not.  The same docs ran fine in the pdf generator.  I
think Colin got hit by this change as well and got an out of memory error after
some time.

Thomas

Quoting Luke Taylor <ne...@fr...>:

> I had a bizarre experience with the automated doc generation recently... 
> The build broke (along with various other things on the server) and when 
> I checked it out I found that my entire /opt paritition had been filled 
> up with the single HTML documentation page - one 16 GB html file! 
> Must've got stuck in a loop somewhere. Anyone noticed anything like that 
> happening with docbook before?
> 
> Luke.
> 
> Colin Sampaleanu wrote:
> > I was just doing some more proofing on the manual, and noticed something 
> > weird. Most people seem to have used the <literal> tag everywhere for 
> > classnames, methods, and properties, but I actually tried to use 
> > <classname>, <method>, and <property>. All seems ok for the PDF, but I 
> > notice for the generated html, that <property> does not seem to have any 
> > effect.
> > 
> > Not that big a deal I guess, but people should stay away from the 
> > <property> tag for now. I will change all my usages to <method> instead...
> > 
> > 
> > 
> > 
> 
> 
> -- 
>   Luke Taylor.                      Monkey Machine Ltd.
>   PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] DocBook: 'method' and c'lassname' tags work for html, but not 'property'

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

Remind me not to generate docs on the production server :-)

Is it working now for you?

Luke Taylor wrote:

> I had a bizarre experience with the automated doc generation 
> recently... The build broke (along with various other things on the 
> server) and when I checked it out I found that my entire /opt 
> paritition had been filled up with the single HTML documentation page 
> - one 16 GB html file! Must've got stuck in a loop somewhere. Anyone 
> noticed anything like that happening with docbook before?
>
> Luke.
>
> Colin Sampaleanu wrote:
>
>> I was just doing some more proofing on the manual, and noticed 
>> something weird. Most people seem to have used the <literal> tag 
>> everywhere for classnames, methods, and properties, but I actually 
>> tried to use <classname>, <method>, and <property>. All seems ok for 
>> the PDF, but I notice for the generated html, that <property> does 
>> not seem to have any effect.
>>
>> Not that big a deal I guess, but people should stay away from the 
>> <property> tag for now. I will change all my usages to <method> 
>> instead...
>>
>>
>>
>>
>
>

RE: [Springframework-developer] Road map

[Keith D. <kd...@cs...>]

Just like to add to the pot here regarding spring-rcp (especially since =
work
is picking back up now):

- I'd like to target the first 1.0 RCP release candidate along side =
Spring
1.1 final this summer.

We plan to include in the distribution a sample application =
demonstrating
the features of the platform (likely a port of the PetClinic or Thomas's
Beer app, adding RCP value like 'quick' sorting/filtering and =
as-you-type
field validation.)  I am hopeful by the first release we'll have several
articles lined up, too (I know several people interested in rich client =
dev
have expressed interest in helping out there!)

Thanks,
Keith


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Wednesday, March 31, 2004 9:44 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Road map


Good point regarding scheduling 1.1.1. I've intended to fill in a
placeholder to make the gap to 1.2 RC1 seem less large ;-) I completely
agree that we shouldn't schedule such point releases in an official =
release
plan.

If we manage to get JSF and/or Portlet support done in time for 1.1, =
then
I'm all for including it earlier. I'd like to release 1.1 final by the =
end
of August, though; I don't want to delay it for further features.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf =
Of
Rod Johnson
Sent: Wednesday, March 31, 2004 2:41 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Road map


Some comments:

Spring 1.0.x: doc polishing, bugfixing, minor enhancements
- 1.0.1: early April
- 1.0.2: late May

Spring 1.1.x: JMS support, JMX support, declarative validation
[RJ: pointcut expression language (AOP), JSR-175 preview? ]
- 1.1 RC1: early July
- 1.1 final: late August
- 1.1.1: late September
[RJ: why are we _scheduling_ a 1.1.1?]

Spring 1.2.x: OGNL support, JCA support, enhanced RMI support
- 1.2 RC1: early November
- 1.2 final: late December

Further issues are JSF and Portlet support. There is actually quite a =
bit of
interest in these from various users/integrators; they are also =
important
for us from a marketing perspective. I'm not keen on providing official
support before 1.2, though.

[RJ: depends on what's involved. I'd be keen to have JSF support sooner
rather than later if it's straightforward. I'm going to be looking at =
that
soon. Portlets I think are more of a niche interest. ]

Regards,
Juergen



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] DocBook: 'method' and c'lassname' tags work for html, but not 'property'

[Luke T. <ne...@fr...>]

I had a bizarre experience with the automated doc generation recently... 
The build broke (along with various other things on the server) and when 
I checked it out I found that my entire /opt paritition had been filled 
up with the single HTML documentation page - one 16 GB html file! 
Must've got stuck in a loop somewhere. Anyone noticed anything like that 
happening with docbook before?

Luke.

Colin Sampaleanu wrote:
> I was just doing some more proofing on the manual, and noticed something 
> weird. Most people seem to have used the <literal> tag everywhere for 
> classnames, methods, and properties, but I actually tried to use 
> <classname>, <method>, and <property>. All seems ok for the PDF, but I 
> notice for the generated html, that <property> does not seem to have any 
> effect.
> 
> Not that big a deal I guess, but people should stay away from the 
> <property> tag for now. I will change all my usages to <method> instead...
> 
> 
> 
> 


-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

Re: [Springframework-developer] Connection error using Spring/Hibernate/JBoss

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

As far as I can tell all is ok.   Now to tell you the truth, the only=20
reason it was ever happening for me is that due to something being=20
misconfigured; a tx was not rolling back on a checked exception, so=20
commit was still being called on a Hibernate Session that had thrown an=20
exception, which caused a flush to happen at that inopportune time. My=20
current code would now never get that far. But from what I remember I=20
switched over to the fixed Spring code before I reworked my code, and=20
all was ok...



j=FCrgen h=F6ller [werk3AT] wrote:

>BTW, Colin, is the JTA/Hibernate resource management issue completely re=
solved for you now?
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Wednesday, March 31, 2004 4:25 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Re: [springframework - Help]
>RE: Connection error using Spring/Hibernate/JBoss
>
>
>The issue I had was that sometimes JBoss would complain about having to=20
>release a connection for me. Additionally, I earlier had some cases=20
>where it said it didn't know the connection I was trying to release. I=20
>did a fair amount of tracing through our whole code when this was=20
>happeing, and am almost 100% sure it's a jboss problem. This is=20
>corroborated by the fact that the problem was _much_ worse in JBoss=20
>3.2.2RC3 than in the current 3.2.3 I am using.  As of a few weeks ago I=20
>actually got rid of all EJBs except for a message driven bean which is=20
>still around, and I still seem to get the complaint releasing the=20
>connection for me, in some cases, as far as I know (have to verify this=20
>completely).
>
>So I don't think this is quite the same issue. I was going a lot of mix=20
>and matching of CMT and Spring, and never got the warning below. I will=20
>follow up on the post below...
>
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
> =20
>
>>Colin,
>>
>>I remember you had similar problems a while ago. What's your take on th=
is? Can you recheck the issue?
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: SourceForge.net [mailto:no...@so...]
>>Gesendet: Mi 31.03.2004 02:54
>>An: no...@so...
>>Betreff: [springframework - Help] RE: Connection error using Spring/Hib=
ernate/JBoss
>>
>>
>>
>>
>>Read and respond to this message at:
>>https://sourceforge.net/forum/message.php?msg_id=3D2499567
>>By: pgmjsd
>>
>>Bad news I'm afraid.
>>
>>Hibernate 2.1.2 + Spring 1.0 + JBoss CMT results in *many* warnings suc=
h as...
>>
>>
>>2004-03-30 19:37:32,359 [Thread Pool Worker-7] WARN
>>org.jboss.resource.connectionmanager.TxConnectionManager - Prepare call=
ed on
>>a local tx. Use of local transactions on a jta transaction with more th=
an one
>>branch may result in inconsistent data in some cases of failure.
>>   =20
>>

Re: [Springframework-developer] Road map

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

Good point regarding scheduling 1.1.1. I've intended to fill in a =
placeholder to make the gap to 1.2 RC1 seem less large ;-) I completely =
agree that we shouldn't schedule such point releases in an official =
release plan.

If we manage to get JSF and/or Portlet support done in time for 1.1, =
then I'm all for including it earlier. I'd like to release 1.1 final by =
the end of August, though; I don't want to delay it for further =
features.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Wednesday, March 31, 2004 2:41 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Road map


Some comments:

Spring 1.0.x: doc polishing, bugfixing, minor enhancements
- 1.0.1: early April
- 1.0.2: late May

Spring 1.1.x: JMS support, JMX support, declarative validation
[RJ: pointcut expression language (AOP), JSR-175 preview? ]
- 1.1 RC1: early July
- 1.1 final: late August
- 1.1.1: late September
[RJ: why are we _scheduling_ a 1.1.1?]

Spring 1.2.x: OGNL support, JCA support, enhanced RMI support
- 1.2 RC1: early November
- 1.2 final: late December

Further issues are JSF and Portlet support. There is actually quite a =
bit of
interest in these from various users/integrators; they are also =
important
for us from a marketing perspective. I'm not keen on providing official
support before 1.2, though.

[RJ: depends on what's involved. I'd be keen to have JSF support sooner
rather than later if it's straightforward. I'm going to be looking at =
that
soon. Portlets I think are more of a niche interest. ]

Regards,
Juergen



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Connection error using Spring/Hibernate/JBoss

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

BTW, Colin, is the JTA/Hibernate resource management issue completely =
resolved for you now?

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, March 31, 2004 4:25 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: [springframework - Help]
RE: Connection error using Spring/Hibernate/JBoss


The issue I had was that sometimes JBoss would complain about having to=20
release a connection for me. Additionally, I earlier had some cases=20
where it said it didn't know the connection I was trying to release. I=20
did a fair amount of tracing through our whole code when this was=20
happeing, and am almost 100% sure it's a jboss problem. This is=20
corroborated by the fact that the problem was _much_ worse in JBoss=20
3.2.2RC3 than in the current 3.2.3 I am using.  As of a few weeks ago I=20
actually got rid of all EJBs except for a message driven bean which is=20
still around, and I still seem to get the complaint releasing the=20
connection for me, in some cases, as far as I know (have to verify this=20
completely).

So I don't think this is quite the same issue. I was going a lot of mix=20
and matching of CMT and Spring, and never got the warning below. I will=20
follow up on the post below...


j=FCrgen h=F6ller [werk3AT] wrote:

>Colin,
>=20
>I remember you had similar problems a while ago. What's your take on =
this? Can you recheck the issue?
>=20
>Juergen
>=20
>
>________________________________
>
>Von: SourceForge.net [mailto:no...@so...]
>Gesendet: Mi 31.03.2004 02:54
>An: no...@so...
>Betreff: [springframework - Help] RE: Connection error using =
Spring/Hibernate/JBoss
>
>
>
>
>Read and respond to this message at:
>https://sourceforge.net/forum/message.php?msg_id=3D2499567
>By: pgmjsd
>
>Bad news I'm afraid.
>
>Hibernate 2.1.2 + Spring 1.0 + JBoss CMT results in *many* warnings =
such as...
>
>
>2004-03-30 19:37:32,359 [Thread Pool Worker-7] WARN
>org.jboss.resource.connectionmanager.TxConnectionManager - Prepare =
called on
>a local tx. Use of local transactions on a jta transaction with more =
than one
>branch may result in inconsistent data in some cases of failure.
> =20
>



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: [springframework - Help] RE: Connection error using Spring/Hibernate/JBoss

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

The issue I had was that sometimes JBoss would complain about having to=20
release a connection for me. Additionally, I earlier had some cases=20
where it said it didn't know the connection I was trying to release. I=20
did a fair amount of tracing through our whole code when this was=20
happeing, and am almost 100% sure it's a jboss problem. This is=20
corroborated by the fact that the problem was _much_ worse in JBoss=20
3.2.2RC3 than in the current 3.2.3 I am using.  As of a few weeks ago I=20
actually got rid of all EJBs except for a message driven bean which is=20
still around, and I still seem to get the complaint releasing the=20
connection for me, in some cases, as far as I know (have to verify this=20
completely).

So I don't think this is quite the same issue. I was going a lot of mix=20
and matching of CMT and Spring, and never got the warning below. I will=20
follow up on the post below...


j=FCrgen h=F6ller [werk3AT] wrote:

>Colin,
>=20
>I remember you had similar problems a while ago. What's your take on thi=
s? Can you recheck the issue?
>=20
>Juergen
>=20
>
>________________________________
>
>Von: SourceForge.net [mailto:no...@so...]
>Gesendet: Mi 31.03.2004 02:54
>An: no...@so...
>Betreff: [springframework - Help] RE: Connection error using Spring/Hibe=
rnate/JBoss
>
>
>
>
>Read and respond to this message at:
>https://sourceforge.net/forum/message.php?msg_id=3D2499567
>By: pgmjsd
>
>Bad news I'm afraid.
>
>Hibernate 2.1.2 + Spring 1.0 + JBoss CMT results in *many* warnings such=
 as...
>
>
>2004-03-30 19:37:32,359 [Thread Pool Worker-7] WARN
>org.jboss.resource.connectionmanager.TxConnectionManager - Prepare calle=
d on
>a local tx. Use of local transactions on a jta transaction with more tha=
n one
>branch may result in inconsistent data in some cases of failure.
> =20
>

Re: [Springframework-developer] Road map

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

This is fine with me. It seems like JMX and validation are in fairly=20
capable hands, and JMS is on it's way at least, so as OGNL scratches an=20
itch for a lot of people (including me), I think I will be working on it=20
before this timeframe, hopefully for inclusion in 1.1...


j=FCrgen h=F6ller [werk3AT] wrote:

>Dear Spring developers,
>=20
>I'd like to discuss a refined road map for the next couple of months. My=
 initial suggestions were a bit too eager, I guess, given that we still n=
eed to refine javadocs and reference docs for 1.0.x, and of course apply =
bugfixes respectively appropriate minor enhancements.
>=20
>So I suggest the following time plan now:
>=20
>Spring 1.0.x: doc polishing, bugfixing, minor enhancements
>- 1.0.1: early April
>- 1.0.2: late May
>=20
>Spring 1.1.x: JMS support, JMX support, declarative validation
>- 1.1 RC1: early July
>- 1.1 final: late August
>- 1.1.1: late September
>=20
>Spring 1.2.x: OGNL support, JCA support, enhanced RMI support
>- 1.2 RC1: early November
>- 1.2 final: late December
>=20
>Further issues are JSF and Portlet support. There is actually quite a bi=
t of interest in these from various users/integrators; they are also impo=
rtant for us from a marketing perspective. I'm not keen on providing offi=
cial support before 1.2, though.
>=20
>Regards,
>Juergen
>=20
>

Re: [Springframework-developer] Road map

[William G. T. Jr. <wg...@ru...>]

Rod Johnson wrote:

> Some comments:
> 
> Spring 1.0.x: doc polishing, bugfixing, minor enhancements
> - 1.0.1: early April
> - 1.0.2: late May
> 
> Spring 1.1.x: JMS support, JMX support, declarative validation
> [RJ: pointcut expression language (AOP), JSR-175 preview? ]
> - 1.1 RC1: early July
> - 1.1 final: late August
> - 1.1.1: late September
> [RJ: why are we _scheduling_ a 1.1.1?]
> 
> Spring 1.2.x: OGNL support, JCA support, enhanced RMI support
> - 1.2 RC1: early November
> - 1.2 final: late December
> 
> Further issues are JSF and Portlet support. There is actually quite a bit of
> interest in these from various users/integrators; they are also important
> for us from a marketing perspective. I'm not keen on providing official
> support before 1.2, though.
> 
> [RJ: depends on what's involved. I'd be keen to have JSF support sooner
> rather than later if it's straightforward. I'm going to be looking at that
> soon. Portlets I think are more of a niche interest. ]

Not sure if we constitute the niche or not, but I tell you that we are 
very interested in having Spring support for the Portlet API similar to 
the Spring WebMVC.  If things continue to go the way they are around 
here the portal will be the primary service delivery mechanism...meaning 
all of our Spring apps will live behind the Portlet API not the Servlet API.

Cheers,
Bill
-- 
William G. Thompson, Jr.
Associate Director of New Technologies
Administrative Computing Services, Rutgers University
voice: 732 445-5428 | fax: 732 445-5493 | wg...@ru...

Re: [Springframework-developer] Road map

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

Some comments:

Spring 1.0.x: doc polishing, bugfixing, minor enhancements
- 1.0.1: early April
- 1.0.2: late May

Spring 1.1.x: JMS support, JMX support, declarative validation
[RJ: pointcut expression language (AOP), JSR-175 preview? ]
- 1.1 RC1: early July
- 1.1 final: late August
- 1.1.1: late September
[RJ: why are we _scheduling_ a 1.1.1?]

Spring 1.2.x: OGNL support, JCA support, enhanced RMI support
- 1.2 RC1: early November
- 1.2 final: late December

Further issues are JSF and Portlet support. There is actually quite a bit of
interest in these from various users/integrators; they are also important
for us from a marketing perspective. I'm not keen on providing official
support before 1.2, though.

[RJ: depends on what's involved. I'd be keen to have JSF support sooner
rather than later if it's straightforward. I'm going to be looking at that
soon. Portlets I think are more of a niche interest. ]

Regards,
Juergen



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Possible Bug: org.springframework.beans.FatalBeanException: No property 'visible' in class, but there is a property called visible

[Roberto C. <rob...@in...>]

Ronald Haring wrote:

> isVisibile is different from isVisible :)
>
> notice the extra i between b and l?
>
> Cheers
> Ronald

Mea culpa!!!!
Thanx a lot!
I thought it was a lot strange!
/roberto