springframework-developer — Spring Framework developers list

Re: [Springframework-developer] View technologies

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

I'll put iText back.

JP, do you want to contribute POI view? As you've been interested/involved
in this project since before we went to SourceForge, I'm happy to give you
commit access if you are likely to make ongoing contributions.

I would really like to have some form of XML/XSLT support, so I might
refactor the old one to remove the present conversion library and leave it
an abstract class. The developer would need to subclass it to generate the
actual XML from the model, using Castor or whatever. Does this sound
reasonable?

Let's leave XMLC for now. Maybe put in documentation that we can offer
support, to let people ask for it if they want it.

I've also written a simple JdbcBeanFactory that I'll add before 0.8.

====================
So what do we think is outstanding between now and 0.8? Remember this isn't
1.0...

As far as my work goes, I want to
- put iText view back
- remove Attrib4j dependency for now, as Attrib4j support isn't usable yet
and the properties tx interceptor format is the way to go for now
- add JdbcBeanFactory
- I was going to remove DynamicProxy and the ejb.access package, but I'm not
sure I have time to do this in the next few days. Might look at it today if
I get time.

We will need some examples, and preferably a web site.

Regards,
Rod


----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: "Spring Developers (E-mail)"
<spr...@li...>
Sent: Thursday, May 08, 2003 8:14 AM
Subject: RE: [Springframework-developer] View technologies


JP and Rod,

I'd also like to see the iText view back in Spring, and POI support sounds
interesting too. I'm not too fond of XMLC personally, but I wouldn't mind
including it in Spring too.

Regarding third-party dependencies: As this issue only affects developers if
we separate the libraries during deployment, I don't consider it a problem
at all. Such libraries don't change on a daily basis, so they only create
overhead on initial checkout/update but not on consecutive updates. We
shouldn't worry about them too much.

At least they are not redundant, like including numerous WARs and EARs in a
distribution - containing the same libraries again and again. I mean the
Struts/WebWork style, unnecessarily producing distributions larger than 20
MB. If we use a simpler approach for Spring distributions, even including
all docs and tutorials, we will still not exceed the 10 MB threshold,
probably clock in way below.

Apropos up-to-date libraries: We should probably care for newest JARs in our
lib directory before 0.8, i.e. Log4J 1.2.8, Velocity 1.3.1 final, Clover
1.1.1. I volunteer to check these at the beginning of next week.

Regards,
Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Thursday, May 08, 2003 8:42 AM
To: JP PAWLAK(Tiscali); Spring Developers (E-mail)
Subject: Re: [Springframework-developer] View technologies


JP,

Good point.

- XML/XSLT: this one was not really a requested feature. The cyclic java
architecture, even in core objects, was really a problem (example: a
Locale has a defaultLocale property which is itself a Locale.). This
problem was noticed by Rod, but worked not as good as expected, the
source of the patched jar being not available and the original library
didn't be aware of this problem. My feel is that in real world a product
like Castor will certainly be better, even if it's more complex at the
beginning.

I agree. I think Castor is a better approach. However, I think having
support for transforms in Spring would be good: might have to put the onus
on the user to provide the doument.

- XMLC: I had no reason for testing it and don't like too much the
approach.

XMLC is amazingly fast and, while a bit weird, it has some things going for
it. Unfortunately the XmlcView brings in about 2 Mb of XMLC dependencies, so
it would be a real problem with third party libs. Although I guess that
affects only developers.


-PDF-iText: I had to render queries results in PDF format for friendly
printing and emailing the results as one clean document. I had no time
to search on others ways like FOP having in a sense a more attractive
approach. But iText was simple to learn and the result is good. The only
drawback is the servlet-style writing hand-coded presentation.

RJ - This depends on only one Jar. Maybe we should put it back in Spring.

-Excel-POI: It was not in Rod's book, but always the same data had to be
reworked by users, so an Excel document was a good choice. Having the
velocity and iText views source, it was simple to write an ExcelView
class using Jakarta's POI.  This class loads an Excel template (it can
also generate a blank document), completes it before serving. Also a
nice result. The same drawback as for iText can be addressed.

RJ - Could be useful to have this in Spring.

I think we should put XML on the todo list, put PDF (iText) back in, and add
JP's Excel view.

If there's agreement on this I'll add the PDF view shortly.

Regards,
Rod






-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] View technologies

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

JP and Rod,

I'd also like to see the iText view back in Spring, and POI support =
sounds interesting too. I'm not too fond of XMLC personally, but I =
wouldn't mind including it in Spring too.

Regarding third-party dependencies: As this issue only affects =
developers if we separate the libraries during deployment, I don't =
consider it a problem at all. Such libraries don't change on a daily =
basis, so they only create overhead on initial checkout/update but not =
on consecutive updates. We shouldn't worry about them too much.

At least they are not redundant, like including numerous WARs and EARs =
in a distribution - containing the same libraries again and again. I =
mean the Struts/WebWork style, unnecessarily producing distributions =
larger than 20 MB. If we use a simpler approach for Spring =
distributions, even including all docs and tutorials, we will still not =
exceed the 10 MB threshold, probably clock in way below.

Apropos up-to-date libraries: We should probably care for newest JARs in =
our lib directory before 0.8, i.e. Log4J 1.2.8, Velocity 1.3.1 final, =
Clover 1.1.1. I volunteer to check these at the beginning of next week.

Regards,
Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Thursday, May 08, 2003 8:42 AM
To: JP PAWLAK(Tiscali); Spring Developers (E-mail)
Subject: Re: [Springframework-developer] View technologies


JP,

Good point.

- XML/XSLT: this one was not really a requested feature. The cyclic java
architecture, even in core objects, was really a problem (example: a
Locale has a defaultLocale property which is itself a Locale.). This
problem was noticed by Rod, but worked not as good as expected, the
source of the patched jar being not available and the original library
didn't be aware of this problem. My feel is that in real world a product
like Castor will certainly be better, even if it's more complex at the
beginning.

I agree. I think Castor is a better approach. However, I think having
support for transforms in Spring would be good: might have to put the =
onus
on the user to provide the doument.

- XMLC: I had no reason for testing it and don't like too much the
approach.

XMLC is amazingly fast and, while a bit weird, it has some things going =
for
it. Unfortunately the XmlcView brings in about 2 Mb of XMLC =
dependencies, so
it would be a real problem with third party libs. Although I guess that
affects only developers.


-PDF-iText: I had to render queries results in PDF format for friendly
printing and emailing the results as one clean document. I had no time
to search on others ways like FOP having in a sense a more attractive
approach. But iText was simple to learn and the result is good. The only
drawback is the servlet-style writing hand-coded presentation.

RJ - This depends on only one Jar. Maybe we should put it back in =
Spring.

-Excel-POI: It was not in Rod's book, but always the same data had to be
reworked by users, so an Excel document was a good choice. Having the
velocity and iText views source, it was simple to write an ExcelView
class using Jakarta's POI.  This class loads an Excel template (it can
also generate a blank document), completes it before serving. Also a
nice result. The same drawback as for iText can be addressed.

RJ - Could be useful to have this in Spring.

I think we should put XML on the todo list, put PDF (iText) back in, and =
add
JP's Excel view.

If there's agreement on this I'll add the PDF view shortly.

Regards,
Rod






-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] View technologies

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

JP,

Good point.

- XML/XSLT: this one was not really a requested feature. The cyclic java
architecture, even in core objects, was really a problem (example: a
Locale has a defaultLocale property which is itself a Locale.). This
problem was noticed by Rod, but worked not as good as expected, the
source of the patched jar being not available and the original library
didn't be aware of this problem. My feel is that in real world a product
like Castor will certainly be better, even if it's more complex at the
beginning.

I agree. I think Castor is a better approach. However, I think having
support for transforms in Spring would be good: might have to put the onus
on the user to provide the doument.

- XMLC: I had no reason for testing it and don't like too much the
approach.

XMLC is amazingly fast and, while a bit weird, it has some things going for
it. Unfortunately the XmlcView brings in about 2 Mb of XMLC dependencies, so
it would be a real problem with third party libs. Although I guess that
affects only developers.


-PDF-iText: I had to render queries results in PDF format for friendly
printing and emailing the results as one clean document. I had no time
to search on others ways like FOP having in a sense a more attractive
approach. But iText was simple to learn and the result is good. The only
drawback is the servlet-style writing hand-coded presentation.

RJ - This depends on only one Jar. Maybe we should put it back in Spring.

-Excel-POI: It was not in Rod's book, but always the same data had to be
reworked by users, so an Excel document was a good choice. Having the
velocity and iText views source, it was simple to write an ExcelView
class using Jakarta's POI.  This class loads an Excel template (it can
also generate a blank document), completes it before serving. Also a
nice result. The same drawback as for iText can be addressed.

RJ - Could be useful to have this in Spring.

I think we should put XML on the todo list, put PDF (iText) back in, and add
JP's Excel view.

If there's agreement on this I'll add the PDF view shortly.

Regards,
Rod

[Springframework-developer] View technologies

[JP PAWLAK\(Tiscali\) <jp....@ti...>]

Hello,

I have noticed that only JSP and velocity are for now available on the
Spring framework, as in Rod=92s book a larger tour was made.

I have used for special uses a few of these with the original i21
framework.

- XML/XSLT: this one was not really a requested feature. The cyclic java
architecture, even in core objects, was really a problem (example: a
Locale has a defaultLocale property which is itself a Locale=85). This
problem was noticed by Rod, but worked not as good as expected, the
source of the patched jar being not available and the original library
didn't be aware of this problem. My feel is that in real world a product
like Castor will certainly be better, even if it=92s more complex at the
beginning.

- XMLC: I had no reason for testing it and don=92t like too much the
approach.

-PDF-iText: I had to render queries results in PDF format for friendly
printing and emailing the results as one clean document. I had no time
to search on others ways like FOP having in a sense a more attractive
approach. But iText was simple to learn and the result is good. The only
drawback is the servlet-style writing hand-coded presentation. =20

-Excel-POI: It was not in Rod=92s book, but always the same data had to =
be
reworked by users, so an Excel document was a good choice. Having the
velocity and iText views source, it was simple to write an ExcelView
class using Jakarta=92s POI.  This class loads an Excel template (it can
also generate a blank document), completes it before serving. Also a
nice result. The same drawback as for iText can be addressed.

I am aware that using iText or POI links to their code the specialized
View class and launches once more the discussion about the external
libraries, but, at least marginally, it=92s useful.=20
My question in this context is: is the re-introducing of alternative
views planned or will we consider this has to rest a user development?=20

Regards,
=A0
Jean-Pierre Pawlak
jp....@ti...

[Springframework-developer] TxInterceptor

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

F.Y.I.

I've tested the AOP declarative Tx in small portion of our application (POC)
and it works BEAUTIFULLY !!!

Rod,

Where could I find javadocs/more information on aopalliance API/interceptors
and what are the possibilities with this AOP interceptors based approach?
Again, it looks really promising :-)

Dmitriy.

Re: [Springframework-developer] spring-web broken on unix

[Ken K. <kk...@kk...>]

Rod,

While working on the demo/tutorial, I noticed that the name of the 
context-param you mentioned has changed in XmlApplicationContext.java 
from "configUrl" to "configLocation".

The value shown below is now the default value and does not need to be 
specified in web.xml.

<context-param>
  <param-name>configLocation</param-name>
    <param-value>/WEB-INF/applicationContext.xml</param-value>
 </context-param>


Ken


Rod Johnson wrote:

>I'm still getting the same failure with the latest build from CVS.
>
>My web.xml is the same as it's always been:
>
><context-param>
>  <param-name>configUrl</param-name>
>    <param-value>/WEB-INF/applicationContext.xml</param-value>
> </context-param>
>
>
>The stack trace is as follows. It is the test servlet namespace that's
>failing. Omitting the leading / above, or omitting the context-param
>altogether fails the same way.
>
>I'm using Orion 2.01 on Windows XP Professional. (Maybe it's the app server
>that's the issue.)
>
>I think the first attempt should try to get the resource from the
>ServletContext when running in a web container. Also, it should definitely
>be backward compatible.
>
>I think getting resources from the classpath is more portable (and useful)
>than getting them from the file system. I think this should be included as a
>fallback as well.
>
>
>ApplicationServerThread
>com.interface21.context.ApplicationContextException: IOException parsing XML
>doc
>ument for application context with display name [WebApplicationContext for
>names
>pace 'test-servlet']; nested exception is:
>        java.io.FileNotFoundException: Location 'WEB-INF/test-servlet.xml'
>isn't
> a URL and cannot be interpreted as (file) path
>java.io.FileNotFoundException: Location 'WEB-INF/test-servlet.xml' isn't a
>URL a
>nd cannot be interpreted as (file) path
>        at
>com.interface21.context.support.AbstractApplicationContext.getResourc
>eAsStream(AbstractApplicationContext.java:314)
>        at
>com.interface21.web.context.support.XmlWebApplicationContext.getInput
>StreamForBeanFactory(XmlWebApplicationContext.java:172)
>        at
>com.interface21.context.support.AbstractXmlApplicationContext.refresh
>BeanFactory(AbstractXmlApplicationContext.java:56)
>        at
>com.interface21.context.support.AbstractApplicationContext.refresh(Ab
>stractApplicationContext.java:167)
>        at
>com.interface21.web.context.support.XmlWebApplicationContext.setServl
>etContext(XmlWebApplicationContext.java:121)
>        at
>com.interface21.web.servlet.FrameworkServlet.createWebApplicationCont
>ext(FrameworkServlet.java:267)
>        at
>com.interface21.web.servlet.FrameworkServlet.initServletBean(Framewor
>kServlet.java:235)
>        at
>com.interface21.web.servlet.HttpServletBean.init(HttpServletBean.java
>:102)
>        at javax.servlet.GenericServlet.init(GenericServlet.java:44)
>        at com.evermind._ay._lae(.:1672)
>
>
>
>
>-------------------------------------------------------
>Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
>The only event dedicated to issues related to Linux enterprise solutions
>www.enterpriselinuxforum.com
>
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

[Springframework-developer] Hibernate support and DataSource transactions

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

Hi everybody,

I've just checked the Hibernate stuff in, including the Hibernate =
libraries that are necessary for executing the test suite (not enough =
for full usage by applications). It's in com.interface21.orm.hibernate. =
Most of it should be pretty self-evident and extensively documented, for =
people who already know Hibernate's basics.

A special issue is handling a Hibernate SessionFactory: I've provided 2 =
classes named LocalSessionFactory and JndiSessionFactory. Being =
FactoryBeans, they behave like a Hibernate SessionFactory when used as =
bean reference. This allows for setting up a SessionFactory in an =
application context, and handing it to =
HibernateTemplate/HibernateTransactionManager's "sessionFactory" =
property as bean reference (or to any custom services having a =
SessionFactory-type property). This way, changing from a locally built =
SessionFactory to a JNDI one (when using the J2EE Connector) is just a =
matter of configuration. For convenience, =
HibernateTemplate/HibernateTransactionManager also provide a property =
"sessionFactoryName", for direct JDNI lookup.

I've also reworked our DataSourceUtils and our DataSource =
implementations (DriverManagerDataSource and =
SingleConnectionDataSource), reusing code as far as possible, and =
allowing for bean-style configuration. All the DataSource-related stuff =
is now in com.interface21.jdbc.datasource, taking some classes from =
jdbc.core and jdbc.mock (jdbc.mock doesn't exist anymore). On the =
occasion, I've introduced a JndiDataSource class that applies the =
FactoryBean setup approach to DataSource (as elaborated above regarding =
Hibernate). This allows for setting up a DataSource bean in an =
application context, either =
DriverManagerDataSource/SingleConnectionDataSource or the JndiDataSource =
factory, all of them representing a DataSource when given as bean =
reference, e.g. to JdbcTemplate, DataSourceTransactionManager, or =
HibernateTemplate. Changing from a JNDI DataSource to a local DataSource =
is just a matter of configuration, which is nice for test or standalone =
environments. Of course, we still support mock JNDI with our =
com.interface21.jndi.mock too.

Apropos: There's a DataSourceTransactionManager now, an implementation =
of PlatformTransactionManager capable of handling transactions for a =
single DataSource. It allows applications that just access a single =
database to use high-level transaction demarcation, either via =
TransactionTemplate or the AOP transaction interceptor - without =
requiring JTA support in the container! HibernateTransactionManager =
applies the same approach to a single Hibernate SessionFactory, for =
applications that access their single database just via Hibernate, =
allowing for Hibernate's transactional caching. If the latter isn't =
required, DataSourceTransactionManager can be used with Hibernate too, =
with the requirement that the Hibernate Sessions must be fed with a =
custom DataSourceUtils-looked-up JDBC connection. HibernateTemplate =
conveniently supports this with its dataSource/dataSourceName property. =
With this approach, direct JDBC access is supported too, while other =
code can leverage Hibernate on the same DataSource - within one =
transaction!

We're already using that stuff in a new product we're developing at =
werk3AT, and are pleased with it so far. Have a look at it, I'm looking =
forward to your feedback!

Regards,
Juergen

P.S.:
In contrast to standard JTA and thus our JtaTransactionManager, both =
DataSourceTransactionManager and HibernateTransactionManager do support =
isolation levels!

P.P.S.:
An obvious follow-up is similar support for JDO: a JdoTemplate, a =
JdoTransactionManager for JDO-only access to a single database, a =
LocalPersistenceManagerFactory and a JndiPersistenceManagerFactory. I =
_might_ look at this myself some time, but I've invested quite a lot of =
time on the stuff above, so it would definitely take a while. Any =
volunteers? :-)


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

[Springframework-developer] dtd's

[Isabelle M. <isa...@me...>]

Hi Rod,

Could you please put the DTD's (for web app config etc...) in the CVS tree?

Thanks,

Isabelle

-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

Re: [Springframework-developer] spring-web broken on unix

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

I'm still getting the same failure with the latest build from CVS.

My web.xml is the same as it's always been:

<context-param>
  <param-name>configUrl</param-name>
    <param-value>/WEB-INF/applicationContext.xml</param-value>
 </context-param>


The stack trace is as follows. It is the test servlet namespace that's
failing. Omitting the leading / above, or omitting the context-param
altogether fails the same way.

I'm using Orion 2.01 on Windows XP Professional. (Maybe it's the app server
that's the issue.)

I think the first attempt should try to get the resource from the
ServletContext when running in a web container. Also, it should definitely
be backward compatible.

I think getting resources from the classpath is more portable (and useful)
than getting them from the file system. I think this should be included as a
fallback as well.


ApplicationServerThread
com.interface21.context.ApplicationContextException: IOException parsing XML
doc
ument for application context with display name [WebApplicationContext for
names
pace 'test-servlet']; nested exception is:
        java.io.FileNotFoundException: Location 'WEB-INF/test-servlet.xml'
isn't
 a URL and cannot be interpreted as (file) path
java.io.FileNotFoundException: Location 'WEB-INF/test-servlet.xml' isn't a
URL a
nd cannot be interpreted as (file) path
        at
com.interface21.context.support.AbstractApplicationContext.getResourc
eAsStream(AbstractApplicationContext.java:314)
        at
com.interface21.web.context.support.XmlWebApplicationContext.getInput
StreamForBeanFactory(XmlWebApplicationContext.java:172)
        at
com.interface21.context.support.AbstractXmlApplicationContext.refresh
BeanFactory(AbstractXmlApplicationContext.java:56)
        at
com.interface21.context.support.AbstractApplicationContext.refresh(Ab
stractApplicationContext.java:167)
        at
com.interface21.web.context.support.XmlWebApplicationContext.setServl
etContext(XmlWebApplicationContext.java:121)
        at
com.interface21.web.servlet.FrameworkServlet.createWebApplicationCont
ext(FrameworkServlet.java:267)
        at
com.interface21.web.servlet.FrameworkServlet.initServletBean(Framewor
kServlet.java:235)
        at
com.interface21.web.servlet.HttpServletBean.init(HttpServletBean.java
:102)
        at javax.servlet.GenericServlet.init(GenericServlet.java:44)
        at com.evermind._ay._lae(.:1672)

[Springframework-developer] setup for tutorial files and docs

[Isabelle M. <isa...@me...>]

Hi everyone,

Can we please discuss (and act on result) how we want to provide the tutorial files. I think we have 2 alternatives :

(1) The downloads section of the sourceforge site. If that's the way we go, how do I put something there. Also the Docs section of the sourceforge site.
(2) In the cvs tree. I don't like the idea of putting PDF's there, that's not really waht CVS is for. But might be OK for the tutorial code.

Isabelle

-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

Re: [Springframework-developer] ejb.access package

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

Yes, I noticed this. I'll change it.

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Wednesday, May 07, 2003 8:44 AM
Subject: RE: [Springframework-developer] ejb.access package


I've used DynamicProxy for suppressing close calls on connections from
SingleConnectionDataSource, via
DataSourceUtils.getCloseSuppressingConnectionProxy. If you'd like to use a
different proxy, just adapt DataSourceUtils, and I'm fine :-)

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Wednesday, May 07, 2003 9:39 AM
To: spr...@li...
Subject: [Springframework-developer] ejb.access package


Guys,

I would like to remove the ejb.access EJB proxy stuff before 1.0. Just
wondering who is using it.

If you can send me a section of your bean file definition, I'll try to
produce the alternative version.

Also the DynamicProxy class will eventually go. Is anyone using this?

The recommended way forward is an AOP-based proxy. I will put together an
example. It should be no harder to use.

Regards,
Rod





-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] ejb.access package

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

I've used DynamicProxy for suppressing close calls on connections from =
SingleConnectionDataSource, via =
DataSourceUtils.getCloseSuppressingConnectionProxy. If you'd like to use =
a different proxy, just adapt DataSourceUtils, and I'm fine :-)

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Wednesday, May 07, 2003 9:39 AM
To: spr...@li...
Subject: [Springframework-developer] ejb.access package


Guys,

I would like to remove the ejb.access EJB proxy stuff before 1.0. Just
wondering who is using it.

If you can send me a section of your bean file definition, I'll try to
produce the alternative version.

Also the DynamicProxy class will eventually go. Is anyone using this?

The recommended way forward is an AOP-based proxy. I will put together =
an
example. It should be no harder to use.

Regards,
Rod





-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] ejb.access package

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

Guys,

I would like to remove the ejb.access EJB proxy stuff before 1.0. Just
wondering who is using it.

If you can send me a section of your bean file definition, I'll try to
produce the alternative version.

Also the DynamicProxy class will eventually go. Is anyone using this?

The recommended way forward is an AOP-based proxy. I will put together an
example. It should be no harder to use.

Regards,
Rod

Re: [Springframework-developer] Returning ResultSet from jdbc.objectStoredProcedure and 0.8 release

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

This would be very useful, if done portably.

Multiple resultsets.... I could envisage using it, but wouldn't want it to
complicate the API too much. I think it's important that users can get to
basic functionality easily.

Making SP use the JdbcTemplate sounds like a good idea. (I was thinking of
it myself last week, actually.)

I am keen to get to 0.8 ASAP. As far as my stuff goes, (AOP etc.) I'm happy
to go to 0.8 now.

I guess Juergen should also think about his packages.

I think you should start work on the StoredProcedure changes, and if they
get checked in in time, they make 0.8.

We also need to think about what release tag names we plan to use.

Regards,
Rod

----- Original Message -----
From: "Thomas Risberg" <tri...@tr...>
To: <spr...@li...>
Sent: Tuesday, May 06, 2003 9:44 PM
Subject: [Springframework-developer] Returning ResultSet from
jdbc.objectStoredProcedure


> I'm looking into the request of adding support for returning a ResultSet
> from jdbc.object.StoredProcedure.
>
> I would like to handle the returned resultset the same way it is handled
> in SqlQuery using a RowCallbackHandler.  There is the possibility of a
> stored procedure returning multiple resultsets - is this something we
> would like to support?  If so, then we would have to pass in multiple
> RowCallBackHandlers - one for each resultset.
>
> Currently the StoredProcedure class does not utilize the JdbcTemplate
> class - it handles the connection, execution and results extraction on
> its own.  There is some functionality in JdbcTemplate that I would like
> to reuse, like RowCallBackHandlerResultSetExtracter.  I think the best
> way to proceed is to refactor the StoredProcedure to use JdbcTemplate
> for all JDBC calls, but I don't yet know how much work is involved here.
>
> I welcome any thoughts or suggestions.
>
> Is this something that should wait until after the 0.8 release?  Do we
> have a target date in mind for this release yet?
>
> Thomas
>
> > Looks like it's down or nearly down. I've just been getting the same
> > problem.
> >
> > Rod
> >
> > ----- Original Message -----
> > From: "JP PAWLAK(Tiscali)" <jp....@ti...>
> > To: "Spring Developers (E-mail)"
> > <spr...@li...>
> > Sent: Tuesday, May 06, 2003 8:11 PM
> > Subject: [Springframework-developer] CVS Server
> >
> >
> > > Hello,
> > >
> > > Has the cvs server a problem?
> > >
> > > I have only access to anonymous. But I'm not able to have a connection
> > > on the server today.  During a first lap of time the server was not
> > > found at all.  And now, it systematically reset the connection.
> > >
> > > What's currently with it?
> > >
> > >   _____
> > >
> > >
> > >
> > > Jean-Pierre Pawlak
> > >
> > >  <mailto:jp....@ti...> jp....@ti...
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> > The only event dedicated to issues related to Linux enterprise solutions
> > www.enterpriselinuxforum.com
> >
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
>
> --
> Thomas Risberg
> tri...@tr...
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] RE: Compile errors

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

Just fixed both, I gave up on it yesterday after accessing the =
SourceForge CVS failed repeatedly.

Something got mixed with IDEA's refactoring. It changed the package =
names in the classes in test/.../jdbc/mock too when renaming =
src/.../jdbc/mock to .../jdbc/datasource, but left the test/... =
directory name. As renaming the package in the test tree was =
unintentional, everything is jdbc/mock again in the test package now.

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Wednesday, May 07, 2003 8:59 AM
To: spr...@li...
Cc: j=FCrgen h=F6ller [werk3AT]
Subject: Compile errors


Juergen,

There are still compile errors in the jdbc.mock test package. (Wrong =
package
names).

Also =
src/com.interface21.transaction.mock.SingleConnectionTransactionManager
has an incorrect import.

Regards,
Rod

[Springframework-developer] Compile errors

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

Juergen,

There are still compile errors in the jdbc.mock test package. (Wrong package
names).

Also src/com.interface21.transaction.mock.SingleConnectionTransactionManager
has an incorrect import.

Regards,
Rod

[Springframework-developer] Returning ResultSet from jdbc.objectStoredProcedure

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

I'm looking into the request of adding support for returning a ResultSet
from jdbc.object.StoredProcedure.  

I would like to handle the returned resultset the same way it is handled
in SqlQuery using a RowCallbackHandler.  There is the possibility of a
stored procedure returning multiple resultsets - is this something we
would like to support?  If so, then we would have to pass in multiple
RowCallBackHandlers - one for each resultset.

Currently the StoredProcedure class does not utilize the JdbcTemplate
class - it handles the connection, execution and results extraction on
its own.  There is some functionality in JdbcTemplate that I would like
to reuse, like RowCallBackHandlerResultSetExtracter.  I think the best
way to proceed is to refactor the StoredProcedure to use JdbcTemplate
for all JDBC calls, but I don't yet know how much work is involved here.

I welcome any thoughts or suggestions.

Is this something that should wait until after the 0.8 release?  Do we
have a target date in mind for this release yet?

Thomas
 
> Looks like it's down or nearly down. I've just been getting the same
> problem.
> 
> Rod
> 
> ----- Original Message -----
> From: "JP PAWLAK(Tiscali)" <jp....@ti...>
> To: "Spring Developers (E-mail)"
> <spr...@li...>
> Sent: Tuesday, May 06, 2003 8:11 PM
> Subject: [Springframework-developer] CVS Server
> 
> 
> > Hello,
> >
> > Has the cvs server a problem?
> >
> > I have only access to anonymous. But I'm not able to have a connection
> > on the server today.  During a first lap of time the server was not
> > found at all.  And now, it systematically reset the connection.
> >
> > What's currently with it?
> >
> >   _____
> >
> >
> >
> > Jean-Pierre Pawlak
> >
> >  <mailto:jp....@ti...> jp....@ti...
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 

-- 
Thomas Risberg
tri...@tr...

Re: [Springframework-developer] CVS Server

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

Looks like it's down or nearly down. I've just been getting the same
problem.

Rod

----- Original Message -----
From: "JP PAWLAK(Tiscali)" <jp....@ti...>
To: "Spring Developers (E-mail)"
<spr...@li...>
Sent: Tuesday, May 06, 2003 8:11 PM
Subject: [Springframework-developer] CVS Server


> Hello,
>
> Has the cvs server a problem?
>
> I have only access to anonymous. But I'm not able to have a connection
> on the server today.  During a first lap of time the server was not
> found at all.  And now, it systematically reset the connection.
>
> What's currently with it?
>
>   _____
>
>
>
> Jean-Pierre Pawlak
>
>  <mailto:jp....@ti...> jp....@ti...
>
>
>
>
>
>

Re: [Springframework-developer] sql-error-codes.xml

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

Yes, this is more logical.

----- Original Message -----
From: "Thomas Risberg" <tri...@tr...>
To: <spr...@li...>
Sent: Tuesday, May 06, 2003 7:11 PM
Subject: Re: [Springframework-developer] sql-error-codes.xml


> Rod,
>
> maybe the other way around.  First look for any overrides in the root of
> the classpath (WEB-INF/classes) and if we don't find the file then we'll
> look in the jdbc/core package and we should find the default one.
>
> Thomas
>
> > I think we should make it look in both places. First in jdbc.core (no /)
> > then in the root of the classpath if not found. All jars should ship
with
> > the file in the jdbc.core package.
> >
> > Does this make sense?
> >
> > Regards,
> > Rod
> >
> > ----- Original Message -----
> > From: "Thomas Risberg" <tri...@tr...>
> > To: <spr...@li...>
> > Sent: Sunday, May 04, 2003 3:37 PM
> > Subject: Re: [Springframework-developer] sql-error-codes.xml
> >
> >
> > > Jean-Pierre,
> > >
> > > I think there is some confusion over where this file should live.
> > > Juergen suggested moving the source to the jdbc.core package  and have
> > > the build script copy it to the root of the build directory. I made
that
> > > change, but Rod also took out the leading '/' to make it look in the
> > > current directory.  I think we should put the '/' back in so the file
> > > will be found at the root of the classpath. That way you can put your
> > > version in WEB-INF/classes and it should be picked up.
> > >
> > > change line 38 of
> > > com.interface21.jdbc.core.SQLExceptionTranslaterFactory to:
> > >
> > > public static final String SQL_ERROR_CODE_PATH =
"/sql-error-codes.xml";
> > >
> > > Thomas
> > >
> > > > Hi,
> > > >
> > > > Why the console tells me about the sql-error-codes.xml cannot be
> loaded
> > > > ?
> > > > It is in the jar. When I copy it in WEB-INF/classes, the behaviour
is
> > > > the same. At least for normal processing, the database access runs
> well.
> > > >
> > > > Regards,
> > > >
> > > > Jean-Pierre Pawlak
> > > > jp....@ti...
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Springframework-developer mailing list
> > > > Spr...@li...
> > > >
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > > >
> > > >
> > >
> > > --
> > > Thomas Risberg
> > > tri...@tr...
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
>
> --
> Thomas Risberg
> tri...@tr...
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] CVS Server

[JP PAWLAK\(Tiscali\) <jp....@ti...>]

Hello,

Has the cvs server a problem?

I have only access to anonymous. But I'm not able to have a connection
on the server today.  During a first lap of time the server was not
found at all.  And now, it systematically reset the connection.

What's currently with it? 

  _____  

 

Jean-Pierre Pawlak

 <mailto:jp....@ti...> jp....@ti...

 

 

Re: [Springframework-developer] sql-error-codes.xml

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

Rod,

maybe the other way around.  First look for any overrides in the root of
the classpath (WEB-INF/classes) and if we don't find the file then we'll
look in the jdbc/core package and we should find the default one.

Thomas

> I think we should make it look in both places. First in jdbc.core (no /)
> then in the root of the classpath if not found. All jars should ship with
> the file in the jdbc.core package.
> 
> Does this make sense?
> 
> Regards,
> Rod
> 
> ----- Original Message -----
> From: "Thomas Risberg" <tri...@tr...>
> To: <spr...@li...>
> Sent: Sunday, May 04, 2003 3:37 PM
> Subject: Re: [Springframework-developer] sql-error-codes.xml
> 
> 
> > Jean-Pierre,
> >
> > I think there is some confusion over where this file should live.
> > Juergen suggested moving the source to the jdbc.core package  and have
> > the build script copy it to the root of the build directory. I made that
> > change, but Rod also took out the leading '/' to make it look in the
> > current directory.  I think we should put the '/' back in so the file
> > will be found at the root of the classpath. That way you can put your
> > version in WEB-INF/classes and it should be picked up.
> >
> > change line 38 of
> > com.interface21.jdbc.core.SQLExceptionTranslaterFactory to:
> >
> > public static final String SQL_ERROR_CODE_PATH = "/sql-error-codes.xml";
> >
> > Thomas
> >
> > > Hi,
> > >
> > > Why the console tells me about the sql-error-codes.xml cannot be
loaded
> > > ?
> > > It is in the jar. When I copy it in WEB-INF/classes, the behaviour is
> > > the same. At least for normal processing, the database access runs
well.
> > >
> > > Regards,
> > >
> > > Jean-Pierre Pawlak
> > > jp....@ti...
> > >
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> > >
> >
> > --
> > Thomas Risberg
> > tri...@tr...
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 

-- 
Thomas Risberg
tri...@tr...

Re: [Springframework-developer] spring-web broken on unix

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

I'm also getting a failure with the previous
/WEB-INF/applicationContext.xml.

What's the recommended form now? No leading slash failed also, so I haven't
been able to start my application.

The error message should also include the location, e.g. "Location '" +
location + "' isn't a URL...



2003-05-06 18:27:34,685 ERROR
com.interface21.web.servlet.ControllerServlet - <S
ervlet with name 'test' : initialization error>
(HttpServletBean.java.init:113)
ApplicationServerThread
com.interface21.context.ApplicationContextException: IOException parsing XML
doc
ument for application context with display name [WebApplicationContext for
names
pace 'test-servlet']; nested exception is:
        java.io.FileNotFoundException: Location isn't a URL and cannot be
interp
reted as (file) path
java.io.FileNotFoundException: Location isn't a URL and cannot be
interpreted as
 (file) path

Regards,
Rod

----- Original Message -----
From: "Chris Smith" <ch...@lo...>
To: "jürgen höller [werk3AT]" <jue...@we...>
Cc: <spr...@li...>
Sent: Monday, May 05, 2003 12:49 PM
Subject: Re: [Springframework-developer] spring-web broken on unix


> Hi Juergen,
>
> Yes, that's much neater.  I forgot you could use a URL to load a file
> and agree about keeping the number of config parameters down.
>
> Regards,
> Chris
>
> jürgen höller [werk3AT] wrote:
>
> >Hi Chris,
> >
> >You're right, this can easily lead to confustion on Unix platforms. We
need a more convenient solution.
> >
> >I don't want to introduce yet another config parameter, so I've applied a
more general change. From the beginning, I've planned to support plain
absolute file paths as a convenience, not as a major feature. Given the
current problematic interpretation of file paths, I've removed
AbstractApplicationContext's absolute file path support altogether,
replacing the getResourceByRelativePath template method with
getResourceByPath.
> >
> >This means that an ApplicationContext implementation can interpret any
non-URL path any way it wants, not just relative file paths.
AbstractApplicationContext's default implementation treats it as (absolute
or relative) file path now, XmlWebApplicationContext generally as
ServletContext resource (no matter if relative or not),
ClassPathApplicationContext as classpath resource (always interpreting as
root path, not relative to the class).
> >
> >Note that absolute file paths can still be accessed easily by using a URL
like "file://C:/test/test.dat", so we don't lose that capability. I consider
this clean and convenient, sacrificing non-URL absolute file path support
isn't a hassle at all. Is that appropriate for your requirements too?
> >
> >Regards,
> >Juergen
> >
> >
> >-----Original Message-----
> >From: Chris Smith [mailto:ch...@lo...]
> >Sent: Monday, May 05, 2003 11:33 AM
> >To: jürgen höller [werk3AT]
> >Subject: Re: [Springframework-developer] spring-web broken on unix
> >
> >
> >Hi Jürgen,
> >
> >I thought about suggesting using relative paths by default, but that
> >leads to a confusing situation where absolute paths are looked up in the
> >file system and relative paths are looked up in the servlet context.
> >Not to mention the fact that an absolute path on one OS can be
> >considered a relative path on another.  And I don't like removing the
> >leading "/" from "/WEB-INF" as there will be plenty of people who
> >include it and end up tearing their hair out when Spring reports it
> >can't find a file that patently exists (like I did yesterday!).
> >
> >What I was going to suggest in my original email is that we have an
> >explicit param that states where a config location should be loaded from:
> >
> ><web-app>
> >    <context-param>
> >        <param-name>configLocation</param-name>
> >        <param-value>/WEB-INF/applicationContext.xml</param-value>
> >    </context-param>
> >    <context-param>
> >        <param-name>configLocationType</param-name>
> >        <param-value>servletcontext</param-value>
> >    </context-param>
> >...
> >
> >configLocationType could have the values "servletcontext" or
> >"filesystem".  "servletcontext" should be the default for a web app
> >context loader, so you could omit it from the above example.  This way,
> >you can control where files are loaded from explicitly, regardless of
> >whether they are relative or absolute.
> >
> >So, that's what I was going to suggest yesterday, but I wasn't sure
> >whether servlets had the same restrictions as EJBs on accessing the file
> >system.  I'm sure I read it somewhere but still can't find it in the
> >servlet spec, so I guess it's ok.  (If it wasn't allowed, the solution
> >would be straightforward - always load from the servlet context).
> >
> >I'm happy to code this up if you like, but you'd have to commit it.
> >
> >Regards,
> >Chris
> >
> >jürgen höller [werk3AT] wrote:
> >
> >
> >
> >>Hi Chris, Spring web users,
> >>
> >>Thanks for the report! Admittedly, I only testet this on Windows and
didn't think about Unix path names (should have come to my mind, though).
I've changed the default paths ("/WEB-INF/applicationContext.xml",
"/WEB-INF/<servlet-name>-servlet.xml") to clear relative paths now, omitting
the leading slash.
> >>
> >>On the occasion, I've made config lookup more flexible, allowing not
only for a servlet context init param "configLocation" for the root context,
but also "configLocationPrefix" and "configLocationSuffix" for namespaced
contexts (defaults are "WEB-INF/" and ".xml").
> >>
> >>Note that the trailing "-servlet" comes from the FrameworkServlet's
namespace handling and is thus part of the namespace. To override the
namespace for a specific servlet, just set a servlet init parameter
"namespace" to the desired value.
> >>
> >>Default initialization should still behave like before, and often you
won't need any customization. But if you like to, you can now customize
config lookup like this:
> >>
> >><web-app>
> >> <context-param>
> >> <param-name>configLocationPrefix</param-name>
> >> <param-value>WEB-INF/myControllers/</param-value>
> >> </context-param>
> >> <context-param>
> >> <param-name>configLocation</param-name>
> >> <param-value>WEB-INF/myRoot.xml</param-value>
> >> </context-param>
> >> <listener>
> >>
<listener-class>com.interface21.web.context.ContextLoaderListener</listener-
class>
> >> </listener>
> >> <servlet>
> >> <servlet-name>test</servlet-name>
> >>
<servlet-class>com.interface21.web.servlet.ControllerServlet</servlet-class>
> >> <init-param>
> >> <param-name>namespace</param-name>
> >> <param-value>myTest</param-value>
> >> </init-param>
> >> <load-on-startup>3</load-on-startup>
> >> </servlet>
> >></web-app>
> >>
> >>This should look up the root context file in "WEB-INF/myRoot.xml", and
the ControllerServlet context file in "WEB-INF/myControllers/myTest.xml".
> >>
> >>Regards,
> >>Juergen
> >>
> >>
> >>-----Original Message-----
> >>From: Chris Smith [mailto:ch...@lo...]
> >>Sent: Sunday, May 04, 2003 3:02 PM
> >>To: spr...@li...
> >>Subject: [Springframework-developer] spring-web broken on unix
> >>
> >>
> >>Hi everyone,
> >>
> >>Juergen, I've just found a problem with the changes you made to
> >>XmlWebApplicationContext recently.
> >>
> >>When loading the bean config in getInputStreamForBeanFactory(), it
> >>delegates to the base class AbstractApplicationContext's
> >>getResourceAsStream() method.  For a config location such as
> >>"/WEB-INF/test-servlet.xml", that method will try to load it using a
> >>URL, fail, catch the MalformedURLException, then see if the path is
> >>relative or absolute.  If relative, it loads it using the overridden
> >>getResourceByRelativePath().
> >>
> >>That all works fine on windows, but on unix, "/WEB-INF/test-servlet.xml"
> >>is considered an absolute path because it starts with a slash.  The
> >>context fails to load because it tries to load it as a File rather than
> >>
> >>
> >>from the servlet context.
> >
> >
> >>The problem is that we can't tell whether a config location like
> >>"/WEB-INF/test-servlet.xml" is a path to a file or a resource in the
> >>servlet context.  I couldn't find it in a brief flick through the
> >>servlet spec, but I didn't think servlets were allowed to access
> >>resources outside the servlet container.  If that's the case, then
> >>XmlWebApplicationContext ought to override getResourceAsStream() with an
> >>implementation that always loads from the servlet context.
> >>
> >>Regards,
> >>
> >>Chris
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This sf.net email is sponsored by:ThinkGeek
> >>Welcome to geek heaven.
> >>http://thinkgeek.com/sf
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>-------------------------------------------------------
> >>This sf.net email is sponsored by:ThinkGeek
> >>Welcome to geek heaven.
> >>http://thinkgeek.com/sf
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>
> >>
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:ThinkGeek
> >Welcome to geek heaven.
> >http://thinkgeek.com/sf
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

RE: [Springframework-developer] Compilation errors

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

In the course of reintroducing com.interface21.web.BindUtils and =
extracting a invokeValidator method to =
com.interface21.validation.ValidationUtils, I've removed the =
validateEmailAddress implementation. The latter was just a showcase =
anyway, thus we can defer the JavaMail discussion for now.

For anyone wanting to validate an email address: Grab JavaMail 1.3, =
instantiate an InternetAddress with your email string, and call =
validate... :-)

Juergen


-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT]=20
Sent: Tuesday, May 06, 2003 3:17 PM
To: spring-dev-list
Subject: RE: [Springframework-developer] Compilation errors


Hi Dmitriy,

Can you please elaborate on the compilation errors in the test tree? I'm =
currently in the process of checking in some stuff, so you might have =
got an inconsistent state.

Hmmm, the validateEmail implementation. You're right, =
InternetAddress.validate is a JavaMail 1.3 method, I didn't consider =
that this isn't part of J2EE 1.3. I've checked in the correct libraries =
in our lib/j2ee directory, though: JAF 1.0.2 and JavaMail 1.3 were =
released quite some time ago, they are far from dependent on the =
"official" J2EE 1.4.

I guess this a general question: Does sticking to J2EE 1.3 include the =
respective JavaMail version, or just Servler 2.3/JSP 1.2/EJB 2.0/JMS =
1.0? Personally, I consider JavaMail part of J2SE anyway, and you can =
always include a new JavaMail jar yourself - it won't clash with =
anything else.

In any case, the definitive libraries should be the ones in our j2ee/lib =
- we should all use them and only them for compilation (not the previous =
manual linking of an RI jar). If we decide to go back to JavaMail 1.2, =
we should simply check in the respective jar there.

Regards,
Juergen


-----Original Message-----
From: Kopylenko, Dmitry [mailto:dko...@ac...]
Sent: Tuesday, May 06, 2003 2:52 PM
To: 'spring-dev-list'
Subject: [Springframework-developer] Compilation errors


Juergen,

I got the latest version of src from CVS and there are number of =
compilation
errors in test src tree mainly because of the package names do not match
package structures. Also, the ValidationUtils.validateEmail() does not
compile, because it calls javax.mail.internet.InternetAddress.validate() =
but
there is no such method defined in J2EE sdk 1.3, only in 1.4

Regards,

Dmitriy.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Compilation errors

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

Hi Dmitriy,

Can you please elaborate on the compilation errors in the test tree? I'm =
currently in the process of checking in some stuff, so you might have =
got an inconsistent state.

Hmmm, the validateEmail implementation. You're right, =
InternetAddress.validate is a JavaMail 1.3 method, I didn't consider =
that this isn't part of J2EE 1.3. I've checked in the correct libraries =
in our lib/j2ee directory, though: JAF 1.0.2 and JavaMail 1.3 were =
released quite some time ago, they are far from dependent on the =
"official" J2EE 1.4.

I guess this a general question: Does sticking to J2EE 1.3 include the =
respective JavaMail version, or just Servler 2.3/JSP 1.2/EJB 2.0/JMS =
1.0? Personally, I consider JavaMail part of J2SE anyway, and you can =
always include a new JavaMail jar yourself - it won't clash with =
anything else.

In any case, the definitive libraries should be the ones in our j2ee/lib =
- we should all use them and only them for compilation (not the previous =
manual linking of an RI jar). If we decide to go back to JavaMail 1.2, =
we should simply check in the respective jar there.

Regards,
Juergen


-----Original Message-----
From: Kopylenko, Dmitry [mailto:dko...@ac...]
Sent: Tuesday, May 06, 2003 2:52 PM
To: 'spring-dev-list'
Subject: [Springframework-developer] Compilation errors


Juergen,

I got the latest version of src from CVS and there are number of =
compilation
errors in test src tree mainly because of the package names do not match
package structures. Also, the ValidationUtils.validateEmail() does not
compile, because it calls javax.mail.internet.InternetAddress.validate() =
but
there is no such method defined in J2EE sdk 1.3, only in 1.4

Regards,

Dmitriy.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Compilation errors

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

Juergen,

I got the latest version of src from CVS and there are number of compilation
errors in test src tree mainly because of the package names do not match
package structures. Also, the ValidationUtils.validateEmail() does not
compile, because it calls javax.mail.internet.InternetAddress.validate() but
there is no such method defined in J2EE sdk 1.3, only in 1.4

Regards,

Dmitriy.