springframework-developer — Spring Framework developers list

Re: [Springframework-developer] [PATCH] doc/reference/src/aop.xml

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

On Thursday 05 February 2004 15:00, Francois Beausoleil wrote:

> Another patch, against CVS HEAD, as of 8:30 AM EST.
>
> [[[
> * doc/reference/src/aop.xml:
>   Multiple textual corrections-duplicated words, wrong
>   or dubious usage of words, spelling mistakes, etc.
>
>   Replaced decimal entity references 34 and 39 with
>   their corresponding character.  This makes it easier
>   to read and edit the text.
>
>   Created CDATA sections for all examples, as this eases
>   the editing process.
> ]]]

=46ran=E7ois,

I haven't seen anyone else pick this up, but I took a look at it.  I think=
=20
the entity references in CVS are caused by the XXE DocBook editor that Rod=
=20
used to write the aop.xml file (I tried it myself and it did the same on my=
=20
files).

Don't mind applying the patch, but it will get overridden the next time=20
anyone edits the file with XXE again and all the entity refs will re-appear=
=20
which looks confusing if ever we need to track the CVS versioning.

Regards
=2D-=20

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

[Springframework-developer] Re: Simpler Web MVC Configuration Proposal

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

I'm not sure what I was smoking, but I now realize that I can't expect the
Spring IOC framework to treat my snippet of XML above as it would a normal
BeanFactory configuration. Therefore I have to refactor the configuration to
take on DTD-compliance, or I have to parse the configuration XML as is and
give up the IOC configuration on the controllers. Not a really good
trade-off.

If I break the configuration file into a Spring DTD-compliant file, we are
pretty much back where we started with a verbose configuration file. I'm not
well-versed in Spring enough to know if there is a happy medium whereby the
small configuration can be parsed and beans created that can be subsequently
wired?

[Springframework-developer] Index properties in forms

[Anna C. <ac...@er...>]

Has the problem below been resolved? I really need to try to map indexed
properties...


Unfortunately there isn't proper support for indexed or mapped properties
yet. The getIndexedPropertyValue method in BeanWrapper is misleading;
effectively, that method shouldn't even be there.

Regarding Struts, I know that Jakarta Commons BeanUtils supports indexed and
mapped properties, so I suppose that Struts' form binding does too.

I've just raised the topic on the developer list. We definitely need to look
into this. For the time being, I'm afraid that we support sophisticated
property type conversion and type mismatch handling on form binding but no
indexed or mapped properties.

Juergen


Thanks in advance!!!

Anna

[Springframework-developer] Simpler Web MVC Configuration Proposal

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

I have previously developed web applications using WebWork (1 & 2), and I
have been drawn to the Spring Framework because of its complete IOC support
and more so, its excellent data abstraction layer. Particularly of interest
to me on my current project is its Hibernate support and Transaction
capabilities.

At the moment however, I am focused on some of the web tier architecture. It
may not be for everyone, but I find myself longing for WebWork's simple
configuration of the web tier. I realize that I could integrate Spring and
WebWork and be done with it, but I don't use WebWork's taglib, nor do I want
to introduce another dependency if I don't have to. Right now, I am trying
to get Spring's web MVC framework sorted out. I apologize in advance if I
misstate any facts or statements regarding the Spring Framework's
capabilities or implementation. I am a Spring-chicken at the moment. :-)

I think I understand the various mapping files that must be configured, and
the two, three, or twelve optional variants of each. As I was going through
each of the classes that provide a view resolver (InternalViewResolver,
ResourceBundleViewResolver and XmlViewResolver), I began to wonder if I was
the only person who would like a simplified configuration. I think the
primary differentiation when comparing Spring or WebWork on the Web-tier
alone, is WebWork's simpler and more cohesive configuration file. I don't
think either framework's WEB MVC configuration provides any more general
functionality than the other, but I would like an optional resolver class
that allows a single configuration file to specify the Controllers, URL
Mapping, View Resolvers and the parameters that each may take. I don't think
this would be difficult either because of Spring's pluggability.

In Spring, in order to use a single controller I have to configure the:

viewResolver / instance of ResourceBundleViewResolver, XmlViewResolver, 
               or InternalViewResolver.

    Used by the dispatcher servlet to resolve the ModelAndView's view 
    name (and locale) to a View class.

    This object is retrieved "by name" by the dispatcher servlet, hence 
    there is only one per servlet context.

handlerMapping / instance of BeanNameUrlHandlerMapping or 
                 SimpleUrlHandlerMapping.

    Used by the dispatcher to 

    There can be many url handlers in a single servlet context since the 
    dispatcher servlet searches for bean's in its context that implement 
    the HandlerMapping interface. They can also be sorted in order to 
    give one handler priority over another when there is a URL that 
    matches multiple HandlerMappings.
    
controller / instance of the Controller interface. There are a bunch of 
             these, and this probably represents one of the more 
             confusing aspects of Spring.
    
    Each controller provides different functionality from the next, but
    it seems like the design suffers a bit here. For example, 
    AbstractController is extended by MultiActionController,
    BaseCommandController and ParameterizableViewController. Since a
    controller must pick a single subclass to extend, a developer can
    only take advantage of the benefits of one of these controllers. I
    preferred WebWork's use of interfaces (and IOC) to drive the capabi-
    lities of the Controller. This a moot point however, since I am only 
    focused on configuration at the moment.

Each of these three configuration areas (four if you count
ExceptionResolvers, five if you count HandlerAdapters, etc.) are powerful in
their flexibility, but somewhat cumbersome for someone coming from WebWork
(or Maverick). For many of us a simpler configuration would be a welcome
augmentation to Spring, and because of Spring's configuration flexibility, I
don't imagine it would take away from any features.

As an example for configuration, consider the following sample from the
petclinic example application that ships with Spring.

-----------------------------------------------------------------------

petclinic-servlet.xml
=====================
<bean id="viewResolver"
class="org.springframework.web.servlet.view.ResourceBundleViewResolver">
	<property name="basename"><value>views</value></property>
</bean>

<bean id="urlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
	<property name="mappings">
		<props>
			<prop key="/welcome.htm">clinicController</prop>
		</props>
	</property>
</bean>

<bean id="clinicController"
class="org.springframework.samples.petclinic.web.ClinicController">
	<property name="methodNameResolver">
		<ref local="clinicControllerResolver"/>
	</property>
	<property name="clinic">
		<ref bean="clinic"/>
	</property>
</bean>

<bean id="clinicControllerResolver"
	
class="org.springframework.web.servlet.mvc.multiaction.PropertiesMethodNameR
esolver">
	<property name="mappings">
		<props>
			<prop key="/welcome.htm">welcomeHandler</prop>
		</props>
	</property>
</bean>

views.properties
================

welcomeView.class=org.springframework.web.servlet.view.JstlView
welcomeView.url=/WEB-INF/jsp/welcome.jsp

-----------------------------------------------------------------------

This is a lot of configuration information when compared to a similar
WebWork configuration. It also is spread across two files, although I
suppose that there is a Spring technique to declare viewResolver data in the
petclinic-servlet.xml file, perhaps by using an XmlViewResolver and
embedding the XML data as an IOC property? Another unclear step is the
knowledge the developer must possess that his
ClinicController.welcomeHandler() method returns the view mapping named
'welcomeView'. It is this name that is looked up in the views.properties
file. This is somewhat unintuitive and other examples have tried to combat
this ambiguity by including the view mappings directly (sort of) in the
Controller configuration.

<bean id="findOwnersForm" 
	class="org.springframework.samples.petclinic.web.FindOwnersForm">
	<property name="formView"><value>findOwnersForm</value></property>
	<property
name="selectView"><value>selectOwnerView</value></property>
	<property name="successView"><value>ownerRedirect</value></property>
</bean>

This example demonstrates something us WebWork developers have used very
effectively for some time. The view is always returned as a simple string in
WebWork and this maps to the actual view via configuration information. The
same thing is occurring in the Spring example, but in a slightly backhanded
way. The SimpleFormController defines formView and successView as String
properties. If the controller completes successfully, it returns
getSuccessView() as its view and this in turn returns 'ownerRefirect' as the
mapped view. The developer also introduced a new view result called
'selectView'. In order to support this new result view, the developer has to
implement the selectView property in their subclass. Very cumbersome when
compared to WebWork's "always map" approach to view results.

Thanks for sticking with this unintentionally long post. I guess I set all
of this up to suggest an alternative approach to configuring Spring's web
MVC that is more compact and easier for new developers. It is based heavily
on WebWork's configuration, so it should prove even easier for WebWork
developers to migrate. I do realize that this configuration will ruffle the
feathers of some architects that laud Spring's separation of components, but
I appreciate the fact that a configuration change does not necessarily
negate an architecture. In fact it is a testament to Spring's solid
architecture that such a configuration may be made possible without changing
any of Spring's infrastructure.

proposed configuration - controller.xml
==============================================

<controller alias="/welcome.htm" 
	class="org.springframework.samples.petclinic.web.ClinicController" 
	method="welcomeHandler">
	<property name="clinic"><ref bean="clinic"/></property>
	<results>
		<result name="selectView" 
	
class="org.springframework.web.servlet.view.JstlView" 
			url="/WEB-INF/jsp/welcome.jsp" />
		<result name="successView" 
	
class="org.springframework.web.servlet.view.RedirectView" 
			url="owner.htm" />
	</results>
</controller>

These seven lines in a single file represent all of the configuration
information found in the prior 23 lines spread across a couple files. There
are probably other Spring capabilities that I am not representing here in
this small example, but this is at least 95 percent of the types of web
controllers that I use. I also am not showing the new configuration bean
that would have to be configured in the xxx-servlet.xml file.

I believe this configuration data should exist in the xxx-servlet.xml file
or loadable from a separate file. No matter where it exists, it should be
loadable as an applicationContext object with full Spring IOC capability,
including parameter substitution.

If I was going to approach writing this new configuration support bean I
would create a configuration bean that can read in the controller.xml file
in a Spring IOC manner. I guess I would base this work on XmlViewResolver,
although I am unsure if this includes all of the IOC benefits automatically?

<bean id="viewResolver" 
	class="org.springframework.web.servlet.mvc.ControllerConfig">
	<property name="location">
		<value>/WEB-INF/controller.xml</value>
	</property>
</bean>

I would have to give the bean an id of "viewResolver" because that is the
only property that the dispatcher loads by name. The dispatcher discovers
the other configuration parameters by searching for interface
implementations amongst all the configured beans.

So org.springframework.web.servlet.mvc.ControllerConfig would read the
controller.xml file and implement the following interfaces:
	- org.springframework.web.servlet.ViewResolver
	- org.springframework.web.servlet.HandlerExceptionResolver
	- org.springframework.web.servlet.HandlerMapping
	
I'm not sure what the best approach for loading the XML configuration file
is to get Spring's IOC support, including external bean references from the
applicationContext and servletContexts. Also it should be reloadable during
development through the use of a flag. Any ideas on where to start with
that?
	
Once the configuration is loaded, it seems like the interface
implementations would be straightforward.	

Thanks for reading this far. Hopefully it wasn't a waste of your time!	
- jim cook

Re: [Springframework-developer] JdbcHelper

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

I have committed the new method to CVS.  I will add my local tests to the proper
test class later today or tomorrow (this is a standalone feature so little risk
of breaking any other functionality).  This might actually turn out to be more
of a test of MockObjects than real code, but it will at least outline expected
functionality.

I ended up implementing (3) as an ArrayList of HashMaps using the column name as
key.  We could replace this with a disconnected rowset in the future.

I'll think about the convenience method - is "int" sufficient?

Here is an example:

DriverManagerDataSource ds = new DriverManagerDataSource();
ds.setDriverClassName("oracle.jdbc.driver.OracleDriver");
ds.setUrl("jdbc:oracle:thin:@localhost:1521:ORCL");
ds.setUsername("scott");
ds.setPassword("tiger");
JdbcTemplate jt = new JdbcTemplate(ds);
Object o = jt.runSqlStatement("select * from emp");
System.out.println(o.getClass().getName());
System.out.println(o);

java.util.ArrayList
[{SAL=800, HIREDATE=1980-12-17 00:00:00.0, COMM=null, EMPNO=7369, JOB=CLERK,
DEPTNO=20, MGR=7902, ENAME=SMITH}, {SAL=1600, HIREDATE=1981-02-20 00:00:00.0,
COMM=300, EMPNO=7499, JOB=SALESMAN, DEPTNO=30, MGR=7698, ENAME=ALLEN},
{SAL=1250, HIREDATE=1981-02-22 00:00:00.0, COMM=500, EMPNO=7521, JOB=SALESMAN,
DEPTNO=30, MGR=7698, ENAME=WARD}, {SAL=2975, HIREDATE=1981-04-02 00:00:00.0,
COMM=null, EMPNO=7566, JOB=MANAGER, DEPTNO=20, MGR=7839, ENAME=JONES},
{SAL=1250, HIREDATE=1981-09-28 00:00:00.0, COMM=1400, EMPNO=7654, JOB=SALESMAN,
DEPTNO=30, MGR=7698, ENAME=MARTIN}, {SAL=2850, HIREDATE=1981-05-01 00:00:00.0,
COMM=null, EMPNO=7698, JOB=MANAGER, DEPTNO=30, MGR=7839, ENAME=BLAKE},
{SAL=2450, HIREDATE=1981-06-09 00:00:00.0, COMM=null, EMPNO=7782, JOB=MANAGER,
DEPTNO=10, MGR=7839, ENAME=CLARK}, {SAL=3000, HIREDATE=1987-04-19 00:00:00.0,
COMM=null, EMPNO=7788, JOB=ANALYST, DEPTNO=20, MGR=7566, ENAME=SCOTT},
{SAL=5000, HIREDATE=1981-11-17 00:00:00.0, COMM=null, EMPNO=7839, JOB=PRESIDENT,
DEPTNO=10, MGR=null, ENAME=KING}, {SAL=1500, HIREDATE=1981-09-08 00:00:00.0,
COMM=0, EMPNO=7844, JOB=SALESMAN, DEPTNO=30, MGR=7698, ENAME=TURNER}, {SAL=1100,
HIREDATE=1987-05-23 00:00:00.0, COMM=null, EMPNO=7876, JOB=CLERK, DEPTNO=20,
MGR=7788, ENAME=ADAMS}, {SAL=950, HIREDATE=1981-12-03 00:00:00.0, COMM=null,
EMPNO=7900, JOB=CLERK, DEPTNO=30, MGR=7698, ENAME=JAMES}, {SAL=3000,
HIREDATE=1981-12-03 00:00:00.0, COMM=null, EMPNO=7902, JOB=ANALYST, DEPTNO=20,
MGR=7566, ENAME=FORD}, {SAL=1300, HIREDATE=1982-01-23 00:00:00.0, COMM=null,
EMPNO=7934, JOB=CLERK, DEPTNO=10, MGR=7782, ENAME=MILLER}]

Thomas


Quoting Rod Johnson <rod...@in...>:

> Thomas,
> 
> Sounds great. With this there I'd be glad to get rid of JdbcHelper.
> 
> Not sure about (3). I think this needs further thought. For 1.1 we could add
> a true disconnected result set: not RowSet as it throws SQLException, which
> we want to get away from.
> 
> Also a convenience method returning int would be handy, for counts and the
> like. Please can I have this, despite Juergen's dislike of convenience
> methods :-)
> 
> Regards,
> Rod
> 
> ----- Original Message -----
> From: <tri...@tr...>
> To: <spr...@li...>
> Sent: Monday, February 16, 2004 5:26 PM
> Subject: RE: [Springframework-developer] JdbcHelper
> 
> 
> > I can see the need to go beyond a single row/value type query.
> >
> > How about a new method for the JdbcTemplate:
> >
> > Object runSqlStatement(String)
> >
> > Based on the type of SQL passed in it would return:
> >
> > 1) An Integer containing the number of rows affected if it is an update
> statement
> >
> > runSqlStatement("update emp set salary = salary * 1.5") would return an
> Integer
> > with the update count
> >
> > 2) A single Object (Integer/Long/String) based on the value returned from
> a
> > single value/single row query
> >
> > runSqlStatement("select last_name frmo emp where id = 2") would return a
> String
> > containing the last name
> >
> > 3) An ArrayList of ArrayLists containing a list of rows with a list of
> column
> > values returned by the query
> >
> > runSqlStatement("selecy id, last_name from emp") would return an ArrayList
> > containing an ArrayList for each row.  The second list would contain an
> Integer
> > with the id and a String with the last_name.
> >
> >
> > Number 3 might be a stretch, but we would still have to check for this,
> since we
> > have no control over the SQL coming in.
> >
> > Thomas
> >
> >
> > Quoting rod...@in...:
> >
> > > I've actually just (yesterday) introduced into into a whole
> > > bunch of test cases at a client. Maybe we could put an
> > > improved runSQLFunction() method on JdbcTemplate? This is a
> > > very convenient one-liner, and basically the only reason I
> > > use JdbcTemplate.
> > >
> > > Regards,
> > > Rod
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > > Build and deploy apps & Web services for Linux with
> > > a free DVD software kit from IBM. Click Now!
> > > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] JdbcHelper

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

Thomas,

Sounds great. With this there I'd be glad to get rid of JdbcHelper.

Not sure about (3). I think this needs further thought. For 1.1 we could add
a true disconnected result set: not RowSet as it throws SQLException, which
we want to get away from.

Also a convenience method returning int would be handy, for counts and the
like. Please can I have this, despite Juergen's dislike of convenience
methods :-)

Regards,
Rod

----- Original Message -----
From: <tri...@tr...>
To: <spr...@li...>
Sent: Monday, February 16, 2004 5:26 PM
Subject: RE: [Springframework-developer] JdbcHelper


> I can see the need to go beyond a single row/value type query.
>
> How about a new method for the JdbcTemplate:
>
> Object runSqlStatement(String)
>
> Based on the type of SQL passed in it would return:
>
> 1) An Integer containing the number of rows affected if it is an update
statement
>
> runSqlStatement("update emp set salary = salary * 1.5") would return an
Integer
> with the update count
>
> 2) A single Object (Integer/Long/String) based on the value returned from
a
> single value/single row query
>
> runSqlStatement("select last_name frmo emp where id = 2") would return a
String
> containing the last name
>
> 3) An ArrayList of ArrayLists containing a list of rows with a list of
column
> values returned by the query
>
> runSqlStatement("selecy id, last_name from emp") would return an ArrayList
> containing an ArrayList for each row.  The second list would contain an
Integer
> with the id and a String with the last_name.
>
>
> Number 3 might be a stretch, but we would still have to check for this,
since we
> have no control over the SQL coming in.
>
> Thomas
>
>
> Quoting rod...@in...:
>
> > I've actually just (yesterday) introduced into into a whole
> > bunch of test cases at a client. Maybe we could put an
> > improved runSQLFunction() method on JdbcTemplate? This is a
> > very convenient one-liner, and basically the only reason I
> > use JdbcTemplate.
> >
> > Regards,
> > Rod
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JdbcHelper

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

Thomas,
=20
That sounds excellent: simple and intuitive. +1 for implementing it that =
way!
=20
Do you have a chance to implement this within the 1.0 timeframe, i.e. =
ASAP? I'd really like to drop JdbcHelper for 1.0 final.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von tri...@tr...
Gesendet: Mo 16.02.2004 18:26
An: spr...@li...
Betreff: RE: [Springframework-developer] JdbcHelper



I can see the need to go beyond a single row/value type query.

How about a new method for the JdbcTemplate:

Object runSqlStatement(String)

Based on the type of SQL passed in it would return:

1) An Integer containing the number of rows affected if it is an update =
statement

runSqlStatement("update emp set salary =3D salary * 1.5") would return =
an Integer
with the update count

2) A single Object (Integer/Long/String) based on the value returned =
from a
single value/single row query

runSqlStatement("select last_name frmo emp where id =3D 2") would return =
a String
containing the last name

3) An ArrayList of ArrayLists containing a list of rows with a list of =
column
values returned by the query

runSqlStatement("selecy id, last_name from emp") would return an =
ArrayList
containing an ArrayList for each row.  The second list would contain an =
Integer
with the id and a String with the last_name.


Number 3 might be a stretch, but we would still have to check for this, =
since we
have no control over the SQL coming in.

Thomas


Quoting rod...@in...:

> I've actually just (yesterday) introduced into into a whole
> bunch of test cases at a client. Maybe we could put an
> improved runSQLFunction() method on JdbcTemplate? This is a
> very convenient one-liner, and basically the only reason I
> use JdbcTemplate.
>
> Regards,
> Rod
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





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

RE: [Springframework-developer] JdbcHelper

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

I can see the need to go beyond a single row/value type query.

How about a new method for the JdbcTemplate:

Object runSqlStatement(String)

Based on the type of SQL passed in it would return:

1) An Integer containing the number of rows affected if it is an update statement

runSqlStatement("update emp set salary = salary * 1.5") would return an Integer
with the update count 

2) A single Object (Integer/Long/String) based on the value returned from a
single value/single row query

runSqlStatement("select last_name frmo emp where id = 2") would return a String
containing the last name

3) An ArrayList of ArrayLists containing a list of rows with a list of column
values returned by the query

runSqlStatement("selecy id, last_name from emp") would return an ArrayList
containing an ArrayList for each row.  The second list would contain an Integer
with the id and a String with the last_name.


Number 3 might be a stretch, but we would still have to check for this, since we
have no control over the SQL coming in.

Thomas


Quoting rod...@in...:

> I've actually just (yesterday) introduced into into a whole 
> bunch of test cases at a client. Maybe we could put an 
> improved runSQLFunction() method on JdbcTemplate? This is a 
> very convenient one-liner, and basically the only reason I 
> use JdbcTemplate.
> 
> Regards,
> Rod
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: RE: [Springframework-developer] JdbcHelper

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

You meant JdbcHelper... ;-)

----- Original Message -----
From: rod...@in...
Date: Monday, February 16, 2004 11:41 am
Subject: RE: [Springframework-developer] JdbcHelper

> I've actually just (yesterday) introduced into into a whole 
> bunch of test cases at a client. Maybe we could put an 
> improved runSQLFunction() method on JdbcTemplate? This is a 
> very convenient one-liner, and basically the only reason I 
> use JdbcTemplate.
> 
> Regards,
> Rod
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

RE: [Springframework-developer] JdbcHelper

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

I've actually just (yesterday) introduced into into a whole 
bunch of test cases at a client. Maybe we could put an 
improved runSQLFunction() method on JdbcTemplate? This is a 
very convenient one-liner, and basically the only reason I 
use JdbcTemplate.

Regards,
Rod

Re: [Springframework-developer] Someone have time to complete this?

[Jonathan H. <jh...@ad...>]

----- Original Message -----=20
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Monday, February 16, 2004 8:59 AM
Subject: RE: [Springframework-developer] Someone have time to complete th=
is?


> Actually, the Pico docs/website/FAQ do not talk about bean capabilities=
 at
all.

Not true.  See "Features" on main page. http://www.picocontainer.org

:: Dependent components can also (optionally) be passed as JavaBean
properties

>There is a BeanComponentAdapter implementation included in Pico 1.0 beta=
4,
but it is undocumented.

Biggest problem with Pico IMHO.  Documentation is beyond poor.  All of th=
e
help pages are outdated.  Non of the examples compile, etc.  It's hard to
take the project seriously when it is so poorly managed.

> So all things considered, far behind Spring's capabilities.

No doubt.

RE: [Springframework-developer] Spring sub-projects

[Trevor C. <tc...@in...>]

+1 (and looking forward to Eclipse!)

T

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: February 16, 2004 3:59 AM
To: spr...@li...
Subject: [Springframework-developer] Spring sub-projects


Everybody,

As recently discussed in private mails, I suggest to keep sub-projects th=
at
are close to the Spring core as separate modules in Spring's main CVS. Th=
e
first two candidates are:

- Keith Donald's Spring Rich Client Platform
- Torsten Juergeleit's Spring Eclipse Plugin

Both Keith and Torsten are in favor of hosting them in our main CVS. So i=
f
noone objects, I will create new CVS modules "spring-rcp" and
"spring-eclipse", and accordingly give Keith and Torsten commit rights fo=
r
the main CVS. As the module names cannot be changed easily, feel free to
suggest different names!

The rationale is to keep all projects that use "org.springframework" as
package name in Spring's main CVS. Separate modules make sense to let the
sub-projects evolve independently; this way, they do not have to be relea=
sed
in direct accordance with the Spring core. Of course, generic classes tha=
t
emerge can still go into the core.

Consequently, both sub-projects should also get respective sections on ou=
r
main website. We should definitely clarify all this before 1.0 final (Mar=
ch
1st), as I expect quite a lot of media coverage at that time - we shouldn=
't
miss that chance!

Juergen



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

RE: [Springframework-developer] Someone have time to complete this?

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

Actually, the Pico docs/website/FAQ do not talk about bean capabilities =
at all. There is a BeanComponentAdapter implementation included in Pico =
1.0 beta4, but it is undocumented. From what I can judge, it just allows =
for autowiring by type: no passing of specific component instances to =
named bean properties. So all things considered, far behind Spring's =
capabilities.

BTW, I've added that Spring *does* support multiple constructors.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of rod...@in...
Sent: Monday, February 16, 2004 4:27 PM
To: spr...@li...
Subject: [Springframework-developer] Someone have time to complete this?


It would be great if someone completed this for Spring:

http://www.c2.com/cgi/wiki?IocContainerComparison

8 (no) is actually wrong for Pico. I think they support beans=20
now.

10 - we support hot swapping (via AOP). I thought Pico did too

5 - requires external XML: Spring answer "no, but recommended"

3 - Has GUI (Eclipse plugin on the way!)

Also might be worth adding

11 - Integrates with AOP for declarative services
Spring - yes
Pico - possibly, with Nanning (or is this NanoContainer?)


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

RE: [Springframework-developer] JdbcHelper

[Trevor C. <tc...@in...>]

+1 for deleting it

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: February 16, 2004 10:46 AM
To: spr...@li...
Subject: [Springframework-developer] JdbcHelper


Does anyone object to getting rid of JdbcHelper? I actually wanted to
suggest this before RC1, but I'm inclined to still move it to the sandbox=
 at
this point of time, as it's undocumented and not used within the framewor=
k.

I simply don't see the point in JdbcHelper: All you can do there can easi=
ly
be built with JdbcTemplate or JDBC operation objects - and should be buil=
t
that way. We shouldn't offer an unnecessarily large number of ways to do
things, particularly not via static utility methods.

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

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


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

Re: [Springframework-developer] JdbcHelper

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

+1 for removing it=2E I beilive I=27ve discussed the removal with Rod a l=
ong time ago=2E=2E=2E

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

=3E Does anyone object to getting rid of JdbcHelper=3F I actually wanted =

=3E to suggest this before RC1=2C but I=27m inclined to still move it to =

=3E the sandbox at this point of time=2C as it=27s undocumented and not =

=3E used within the framework=2E
=3E =

=3E I simply don=27t see the point in JdbcHelper=3A All you can do there =

=3E can easily be built with JdbcTemplate or JDBC operation objects - =

=3E and should be built that way=2E We shouldn=27t offer an unnecessarily=
 =

=3E large number of ways to do things=2C particularly not via static =

=3E utility methods=2E
=3E =

=3E Juergen
=3E =

=3E =

=3E DI J=C3=BCrgen H=C3=B6ller
=3E Senior System Architect
=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=3E =

=3E werk3ATS - division systementwicklung
=3E werk3AT informations- und mediensysteme
=3E =

=3E europaplatz 4
=3E A - 4020 linz
=3E =

=3E t=2E  +43 (0) 732 71 65 29 502
=3E f=2E  +43 (0) 732 71 65 29 3
=3E juergen=2Ehoeller=40werk3at=2Ecom
=3E http=3A//www=2Ewerk3at=2Ecom
=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=3E werk3ATS - WIR ENTWICKELN ERFOLG
=3E =

=3E =

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

[Springframework-developer] JdbcHelper

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

Does anyone object to getting rid of JdbcHelper? I actually wanted to =
suggest this before RC1, but I'm inclined to still move it to the =
sandbox at this point of time, as it's undocumented and not used within =
the framework.

I simply don't see the point in JdbcHelper: All you can do there can =
easily be built with JdbcTemplate or JDBC operation objects - and should =
be built that way. We shouldn't offer an unnecessarily large number of =
ways to do things, particularly not via static utility methods.

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

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

Re: [Springframework-developer] Someone have time to complete this?

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

Rod,

I just did, except #6. Take a look.

Regards,
Dmitriy.

----- Original Message -----
From: rod...@in...
Date: Monday, February 16, 2004 10:26 am
Subject: [Springframework-developer] Someone have time to complete this?

> It would be great if someone completed this for Spring:
> 
> http://www.c2.com/cgi/wiki?IocContainerComparison
> 
> 8 (no) is actually wrong for Pico. I think they support beans 
> now.
> 
> 10 - we support hot swapping (via AOP). I thought Pico did too
> 
> 5 - requires external XML: Spring answer "no, but recommended"
> 
> 3 - Has GUI (Eclipse plugin on the way!)
> 
> Also might be worth adding
> 
> 11 - Integrates with AOP for declarative services
> Spring - yes
> Pico - possibly, with Nanning (or is this NanoContainer?)
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Someone have time to complete this?

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

How about number 6? Yes, via AOP introduction?

----- Original Message -----
From: rod...@in...
Date: Monday, February 16, 2004 10:26 am
Subject: [Springframework-developer] Someone have time to complete this?

> It would be great if someone completed this for Spring:
> 
> http://www.c2.com/cgi/wiki?IocContainerComparison
> 
> 8 (no) is actually wrong for Pico. I think they support beans 
> now.
> 
> 10 - we support hot swapping (via AOP). I thought Pico did too
> 
> 5 - requires external XML: Spring answer "no, but recommended"
> 
> 3 - Has GUI (Eclipse plugin on the way!)
> 
> Also might be worth adding
> 
> 11 - Integrates with AOP for declarative services
> Spring - yes
> Pico - possibly, with Nanning (or is this NanoContainer?)
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] Someone have time to complete this?

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

It would be great if someone completed this for Spring:

http://www.c2.com/cgi/wiki?IocContainerComparison

8 (no) is actually wrong for Pico. I think they support beans 
now.

10 - we support hot swapping (via AOP). I thought Pico did too

5 - requires external XML: Spring answer "no, but recommended"

3 - Has GUI (Eclipse plugin on the way!)

Also might be worth adding

11 - Integrates with AOP for declarative services
Spring - yes
Pico - possibly, with Nanning (or is this NanoContainer?)

[Springframework-developer] spring-rcp project

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

There are several things initially I'd like to see the spring-rcp =
project will provide:

- A way to build configurable, GUI-standards following Swing =
applications faster by leveraging the Spring container and a rich =
library of UI factories and support classes.

More specfically right now I have:
- A core action framework that allows for centralized configuration of =
Swing actions and appropriate handler registration based on the current =
active view.  Action configuration -- as well as action contribution =
policies (to menus/toolbars), can be defined externally to the code as =
Spring bean declarations.
- Multiple window support/management, page configuration, and view =
management.  The ideas here are very much based on Eclipse's =
perspective/view concepts.  Currently views can be defined in the Spring =
container, associated with one or more pages, and a default page can be =
configured to load at startup.
- Common support classes for various rich client requirements including: =
dialogs, wizards, input validation, button bars, internationalization, =
image/icon caching, progress monitoring, UI threading (aka classes =
promoting responsive UIs), tree table/property sheet, table =
sorting/high-volume table updates, GUI standards helpers, help/about, =
etc.
- Some basic support for persisting UI state and UI preferences (needs =
to be developed further.)

I hope this provides some good background info on the project.  I see it =
adding the most value to people needing to develop Swing applications =
and do so in a way that promotes consistent, well-designed, configurable =
Swing applications.  IMO Swing is more mature than Eclipse/SWT -- and =
does some things better (for example, JTables can scale much better than =
SWT tables.)  I also think the old days of Swing apps 'not looking =
native' and not being performant or web-accessible are gone with JDK =
1.4.2 and 1.5 and webstart.  The main issue I see with Swing is there =
are a limited number of higher-level abstractions/frameworks out there =
that assist in making the toolkit simpler & easier to use, and a limited =
number of design best practices.  The the goal of spring-rcp is to =
provide that.

Project dependencies to date:
- commons-lang
- jgoodies-forms
- TableLayout
- Spring (obviously) :-)

Keith
  

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

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

I agree that such a double check is not too desirable - a bit too much =
magic behind the scenes.

On second thought, I'm not sure if "inContainer" defaulting to true is =
so inappropriate after all. Standard J2EE requires <resource-ref> =
declarations in web.xml, expecting "jdbc/myds"-style names relative to =
"java:comp/env"; the default AbstractJndiLocator accepts the same name =
syntax. I can imagine that quite a few users consider this intuitive - =
and I tend to agree...

Remember that if you use "xxx:"-style JNDI prefixes, you won't get the =
"inContainer" behavior in any case. So I'm not sure how many scenarios =
actually require setting "inContainer" to false currently. Even JBoss =
JNDI locations for JDBC DataSources (in "-ds.xml" files) are =
automatically relative to the "java:" prefix. So is it just about =
default EJB locations in JBoss?

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Monday, February 16, 2004 1:44 PM
To: spr...@li...
Subject: Re: [Springframework-developer] AbstractJndiLocator should not
assume java:comp/env prefix while not allowing others


What I don't like about checking both locations is that you then end up=20
doing two checks every single time really, for one of the most common=20
cases. I'm also not sure it's that correct to check in two places when=20
you tell it one... It would certainly work though.

I'm curious just how much existing usage would break. I don't think it's =

much of an issue for EJB access. Most people don't map their EJBs to the =

local namespace. For datasource access, JBoss puts those into=20
'java:xxxxx', not just 'xxxxx', no choice in the matter, so JBoss users=20
would not be affected at all. It's been a while since I've used WebLogic =

so I don't remember where WebLogic datasources end up.

It's unfortunate that it's this late in the game, since it's pretty=20
clear to me that the best default state for this optimization (default=20
adding of java:comp/env) is best off, if we didn't have the=20
compatibility concern... We could perhaps try to get an idea of how many =

users actually have configs where they are relying on this. The answer=20
we get back would probably be scalable towards the whole user base....

Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>Colin,
>=20
>While I generally agree that it's more appropriate to have =
"inContainer" default to false, I'm a bit worried that such a change =
would break all bean definition files that currently rely on accessing =
container DataSources with that implicit prefix.
>=20
>A further option would be to change "inContainer"'s semantics to: check =
for "java:comp/env/myJndiName" first, then try "myJndiName" directly if =
the former was not found. That would catch both cases, being fully =
backward-compatible, with just minimal overhead at startup. =
"inContainer"  turned off would solely try the latter case.
>=20
>Juergen
>=20
>
>________________________________
>
>Von: Colin Sampaleanu [mailto:col...@ex...]
>Gesendet: So 15.02.2004 23:44
>An: j=FCrgen h=F6ller [werk3AT]
>Cc: spr...@li...
>Betreff: Re: [Springframework-developer] AbstractJndiLocator should not =
assume java:comp/env prefix while not allowing others
>
>
>
>I think we should revisit the decision to make inContainer=3Dtrue the
>default for the AbstractJndiLocator.
>
>While most people will of course be running in a container, having a
>default value of inContainer=3Dtrue will not help them, and will make
>their config work harder. inContainer=3Dtrue helps only if by default =
your
>code is something like an EJB or WebApp, and you want to save typing
>'java:comp/env/' at the beginning of your resource names, _and_ you =
have
>gone to the pain of doing a resource mapping to bring resources into =
the
>local java:comp/env/ namespace, something that most people don't bother
>doing.
>
>If I deploy an EJB in JBoss for example, it gets deployed into the
>global (not even 'java:') namspace. Unless I do the resource-ref =
mapping
>for the client code that needs to access it, it needs to be accessed =
via
>the global namespace. Since there is no prefix at all, that's =
completely
>impossible to do unless inContainer=3Dfalse, otherwise the code will =
add
>the java:comp/env/. That means that for every EJB proxy I need to add
>inContainer=3Dfalse as a property.
>
>If false was the default, then people accessing resources for which
>there was a local resource mapping (again, people don't usually do =
this)
>would still have the choice of either using the full
>  java:/comp/env/
>prefix, and leaving inContainer unset, or just setting
>  inContainer=3Dtrue.
>
>I think this change makes sense because locally mapped resources (to
>java:/comp/env) are less common than non-mapped resources. What do you
>think?
>
>Regards,
>Colin
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
> =20
>
>>Just fixed: inContainer=3Dtrue does not prepend the container prefix =
if a scheme is given (i.e. a ":" contained).
>>
>>
>>-----Original Message-----
>>From: Colin Sampaleanu [mailto:col...@ex...]
>>Sent: Friday, August 22, 2003 1:33 PM
>>To: j=FCrgen h=F6ller [werk3AT]
>>Cc: spr...@li...
>>Subject: Re: [Springframework-developer] AbstractJndiLocator should =
not
>>assume java:comp/env prefix while not allowing others
>>
>>
>>I somehow missed the inContainer property, even though I looked at the
>>source!   I think it does make sense though to add the check for the
>>scheme as per your and mine suggestion; even in a container you still
>>need to be able to override this...
>>
>>Regards,
>>Colin
>>
>>j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>
>>
>>   =20
>>
>>>Hi Colin,
>>>
>>>AbstractJndiLocator only does so when the "inContainer" property is =
set to true (the default). Setting this property to false should result =
in looking up the JNDI name as is. It could make sense to add a check =
for scheme though, e.g. only apply "java:comp/env/" if "inContainer" is =
true *and* the JNDI name does not contain a ":". What do you think?
>>>
>>>Juergen
>>>
>>>
>>>     -----Urspr=FCngliche Nachricht-----
>>>     Von: Colin Sampaleanu [mailto:col...@ex...]
>>>     Gesendet: Fr 22.08.2003 05:43
>>>     An: spr...@li...
>>>     Cc:
>>>     Betreff: [Springframework-developer] AbstractJndiLocator should =
not assume java:comp/env prefix while not allowing others
>>>   =20
>>>   =20
>>>
>>>     AbstractJndiLocator right now looks at the jndi name it is =
given, and if
>>>     it doesn't start with
>>>        java:comp/env
>>>     prepends this value automatically. This behaviour is not =
correct.
>>>     Somebody using the bean should be able to look up resources =
anywhere,
>>>     and currently you can't. For example, in jboss, the main =
datasource by
>>>     default is bound to
>>>       java:DefaultDS
>>>   =20
>>>     As well, you may want to look up something on JNDI using another =
scheme
>>>     entirely...
>>>   =20
>>>     What the code should probably do is see if the is a scheme
>>>        xxxxx:
>>>     at the beginning of the jndi name. If there isn't, then it is =
probably
>>>     reasonable to assume 'java:comp/env. or 'java:' If there is a =
scheme, it
>>>     should leave the name alone.
>>>   =20
>>>     I would have supplied a patch, but the fix is trivial, and I =
don't know
>>>     how exactly you want to handle this, but it's pretty critical to =
me.
>>>   =20
>>>     Right now with JBoss it's pretty nasty. I can not use JBoss's =
naming
>>>     alias service to alias
>>>       java:comp/env/DefaultDS
>>>     to
>>>       java:DefaultDS
>>>     because it apparently doesn't let you alias stuff under =
comp/env.  I can
>>>     probably modify my resource entries in the war file I use to do =
a
>>>     resource ref to the right location, but I would really rather =
not do
>>>     that, since the war is fine the way it is.
>>>   =20
>>>     Regards,
>>>     Colin
>>>   =20
>>>




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

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

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

What I don't like about checking both locations is that you then end up 
doing two checks every single time really, for one of the most common 
cases. I'm also not sure it's that correct to check in two places when 
you tell it one... It would certainly work though.

I'm curious just how much existing usage would break. I don't think it's 
much of an issue for EJB access. Most people don't map their EJBs to the 
local namespace. For datasource access, JBoss puts those into 
'java:xxxxx', not just 'xxxxx', no choice in the matter, so JBoss users 
would not be affected at all. It's been a while since I've used WebLogic 
so I don't remember where WebLogic datasources end up.

It's unfortunate that it's this late in the game, since it's pretty 
clear to me that the best default state for this optimization (default 
adding of java:comp/env) is best off, if we didn't have the 
compatibility concern... We could perhaps try to get an idea of how many 
users actually have configs where they are relying on this. The answer 
we get back would probably be scalable towards the whole user base....

Colin

jürgen höller [werk3AT] wrote:

>Colin,
> 
>While I generally agree that it's more appropriate to have "inContainer" default to false, I'm a bit worried that such a change would break all bean definition files that currently rely on accessing container DataSources with that implicit prefix.
> 
>A further option would be to change "inContainer"'s semantics to: check for "java:comp/env/myJndiName" first, then try "myJndiName" directly if the former was not found. That would catch both cases, being fully backward-compatible, with just minimal overhead at startup. "inContainer"  turned off would solely try the latter case.
> 
>Juergen
> 
>
>________________________________
>
>Von: Colin Sampaleanu [mailto:col...@ex...]
>Gesendet: So 15.02.2004 23:44
>An: jürgen höller [werk3AT]
>Cc: spr...@li...
>Betreff: Re: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others
>
>
>
>I think we should revisit the decision to make inContainer=true the
>default for the AbstractJndiLocator.
>
>While most people will of course be running in a container, having a
>default value of inContainer=true will not help them, and will make
>their config work harder. inContainer=true helps only if by default your
>code is something like an EJB or WebApp, and you want to save typing
>'java:comp/env/' at the beginning of your resource names, _and_ you have
>gone to the pain of doing a resource mapping to bring resources into the
>local java:comp/env/ namespace, something that most people don't bother
>doing.
>
>If I deploy an EJB in JBoss for example, it gets deployed into the
>global (not even 'java:') namspace. Unless I do the resource-ref mapping
>for the client code that needs to access it, it needs to be accessed via
>the global namespace. Since there is no prefix at all, that's completely
>impossible to do unless inContainer=false, otherwise the code will add
>the java:comp/env/. That means that for every EJB proxy I need to add
>inContainer=false as a property.
>
>If false was the default, then people accessing resources for which
>there was a local resource mapping (again, people don't usually do this)
>would still have the choice of either using the full
>  java:/comp/env/
>prefix, and leaving inContainer unset, or just setting
>  inContainer=true.
>
>I think this change makes sense because locally mapped resources (to
>java:/comp/env) are less common than non-mapped resources. What do you
>think?
>
>Regards,
>Colin
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Just fixed: inContainer=true does not prepend the container prefix if a scheme is given (i.e. a ":" contained).
>>
>>
>>-----Original Message-----
>>From: Colin Sampaleanu [mailto:col...@ex...]
>>Sent: Friday, August 22, 2003 1:33 PM
>>To: jürgen höller [werk3AT]
>>Cc: spr...@li...
>>Subject: Re: [Springframework-developer] AbstractJndiLocator should not
>>assume java:comp/env prefix while not allowing others
>>
>>
>>I somehow missed the inContainer property, even though I looked at the
>>source!   I think it does make sense though to add the check for the
>>scheme as per your and mine suggestion; even in a container you still
>>need to be able to override this...
>>
>>Regards,
>>Colin
>>
>>jürgen höller [werk3AT] wrote:
>>
>>
>>
>>    
>>
>>>Hi Colin,
>>>
>>>AbstractJndiLocator only does so when the "inContainer" property is set to true (the default). Setting this property to false should result in looking up the JNDI name as is. It could make sense to add a check for scheme though, e.g. only apply "java:comp/env/" if "inContainer" is true *and* the JNDI name does not contain a ":". What do you think?
>>>
>>>Juergen
>>>
>>>
>>>     -----Ursprüngliche Nachricht-----
>>>     Von: Colin Sampaleanu [mailto:col...@ex...]
>>>     Gesendet: Fr 22.08.2003 05:43
>>>     An: spr...@li...
>>>     Cc:
>>>     Betreff: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others
>>>    
>>>    
>>>
>>>     AbstractJndiLocator right now looks at the jndi name it is given, and if
>>>     it doesn't start with
>>>        java:comp/env
>>>     prepends this value automatically. This behaviour is not correct.
>>>     Somebody using the bean should be able to look up resources anywhere,
>>>     and currently you can't. For example, in jboss, the main datasource by
>>>     default is bound to
>>>       java:DefaultDS
>>>    
>>>     As well, you may want to look up something on JNDI using another scheme
>>>     entirely...
>>>    
>>>     What the code should probably do is see if the is a scheme
>>>        xxxxx:
>>>     at the beginning of the jndi name. If there isn't, then it is probably
>>>     reasonable to assume 'java:comp/env. or 'java:' If there is a scheme, it
>>>     should leave the name alone.
>>>    
>>>     I would have supplied a patch, but the fix is trivial, and I don't know
>>>     how exactly you want to handle this, but it's pretty critical to me.
>>>    
>>>     Right now with JBoss it's pretty nasty. I can not use JBoss's naming
>>>     alias service to alias
>>>       java:comp/env/DefaultDS
>>>     to
>>>       java:DefaultDS
>>>     because it apparently doesn't let you alias stuff under comp/env.  I can
>>>     probably modify my resource entries in the war file I use to do a
>>>     resource ref to the right location, but I would really rather not do
>>>     that, since the war is fine the way it is.
>>>    
>>>     Regards,
>>>     Colin
>>>    
>>>

Re: [Springframework-developer] Spring sub-projects

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

+1

jürgen höller [werk3AT] wrote:

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

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

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

Yes, the Jndi variant's behaviour is ok.  I'll modify the keyed 
singleton variants later this week to use the reference count.

jürgen höller [werk3AT] wrote:

>Colin,
> 
>Oops, I seem to have gotten that wrong then for the SingletonBeanFactoryLocator: Please change it back to a more reasonable implementation before 1.0 final. 
> 
>However, the JndiBeanFactoryLocator doesn't have a reference count; it creates the factory on each locator call. Isn't it be appropriate here to call BeanFactory.destroySingletons respectively ApplicationContext.close on release?
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Sa 14.02.2004 20:06
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Revised BeanFactoryLocator and EJB support classes
>
>
>
>I've got no problem with these changes in terms of making the names
>consistent. The new handling of the BeanFactoryReference is wrong
>though. There was a reason why it was an inner class before, as per the
>comment:
>
>            return new BeanFactoryReference() {
>                public BeanFactory getFactory() {
>                    return retval;
>                }
>                public void release() throws FatalBeanException {
>                    // Currently does nothing.
>                    // An ideal implementation would use reference
>counting data to release owning
>                    // container when no more BeanFactories within it
>are used, however depending on
>                    // the usage scenario, this could also cause thrashing.
>                }
>            };
>
>Now it was somewhat of a copout not to do anything on the release; my
>original intent when I checked this stuff in was that we would have some
>discussion on the best handling for the release call, and then it would
>get implemented, probably to just use the reference count in its outer
>class to decide whether to release or not, but we've all been pretty
>busy and that didn't happen.
>
>So you can not just call
>   ((ConfigurableBeanFactory) this.beanFactory).destroySingletons()
>and
>   ((ConfigurableApplicationContext) this.applicationContext).close();
>as your new implementation does in the new separate implementations of
>BeanFactoryReference. It should probably stay an inner class, and only
>call the destroy or close, respectively, if the reference count on the
>keyed singleton beanfactory or context goes down to zero.
>:
>This will work absolutely fine for people using it like I am, where it
>is used to obtain the parent for the web application context(s), and
>then only released when the web application context gets unloaded.
>
>The other situation, where people do not have one get and release
>wrapping all other gets and releases, is more problematic, since if they
>do sequential gets and releases they will get a sort of thrashing as
>stuff gets continuously loaded and unloaded. What these people will have
>to do is themselves force an initial load without a release, at their
>app startup.
>
>As for the default ejbRemove not calling unloadBeanFactory (like the
>comment for unloadBeanFActory says is supposed to happen), that appears
>to be an oversight and something that was in there since Nov. or Dec.
>Thanks for catching that. The old old code never did any unloading at
>all. Then in Nov./Dec. I added the unloadBeanFactory method, but
>apparently forgot to call it.
>
>Regards,
>Colin
>
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Agreed, the RC1 API should be considered as final as possible. However, the BeanFactoryLocator was a brand-new RC1 feature, added pretty much last minute there, so I guess it's arguable to refine this for 1.0 final - particularly if it just affects advanced users that diverge from the default EJB support configuration.
>>
>>    
>>
>>From my point of view, I'm as happy as can be with the current state of the framework. What I would like to see included in 1.0 final nevertheless is (backward-compatible) support for more exception categories in the SQLException translator, as suggested by Thomas, and possibly a convenient option to set a transaction rollback-only no matter if driven by declarative or programmatic demarcation, as suggested by Colin and Alef.
>  
>
>>BTW, I'll send a mail regarding the Spring roadmap shortly.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von Rod Johnson
>>Gesendet: Sa 14.02.2004 18:42
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] Revised BeanFactoryLocator and EJB support classes
>>
>>
>>
>>I agree with these changes, but I think we should try to avoid API changes
>>in general from now to 1.0 final. With RC1 we are committing to a final API.
>>Also, I'd rather we don't have enough changes that we need an RC2.
>>
>>Regards,
>>Rod
>>
>>----- Original Message -----
>>From: "jürgen höller [werk3AT]" <jue...@we...>
>>To: <spr...@li...>
>>Sent: Saturday, February 14, 2004 5:22 PM
>>Subject: [Springframework-developer] Revised BeanFactoryLocator and EJB
>>support classes
>>
>>
>>Colin, Rod, everyone,
>>
>>I revised the BeanFactoryLocator and EJB support classes yesterday, mainly
>>to align the naming of the implementation classes with Spring's general
>>naming patterns. For example, the ApplicationContext-specific classes are
>>now called "ContextJndiBeanFactoryLocator" and
>>"ContextSingletonBeanFactoryLocator". I've also factored out the
>>BeanFactoryReference implementations for newly created BeanFactories into
>>separate classes, making them invoke
>>"ConfigurableBeanFactory.destroySingletons" respectively
>>"ConfigurableApplicationContext.close" on release.
>>
>>I've adapted the EJB support classes accordingly and, on the occasion, moved
>>the logger instance variable from AbstractEnterpriseBean to
>>AbstractStatelessSessionBean and AbstractMessageDriverBean. Someone
>>complained on the mailing list a while ago that removing and setting the
>>logger instance for SFSBs is a nuisance, and I agree - the subclass should
>>hold its own *static* logger instance there. Of course, this doesn't apply
>>to SLSBs and MDBs, thus the change.
>>
>>I've also noted that AbstractEnterpriseBean's "ejbRemove" implementation did
>>*not* invoke BeanFactoryLocator.release; is there any rationale for this?
>>For the time being, I've made it invoke release, as I consider it important
>>to destroy resource singletons like a local SessionFactory or
>>PersistenceManager on BeanFactory respectively ApplicationContext shutdown.
>>
>>I hope you don't mind the name changes. My goal is to keep class and method
>>naming as consistent as possible within the Spring codebase; something many
>>other open source projects to not respect at all.
>>
>>Juergen
>>    
>>

RE: [Springframework-developer] Spring sub-projects

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

SXQncyBhYm91dCBLZWl0aCdzIHN1cHBvcnQgY2xhc3NlcyBmb3IgU3ByaW5nLWJhc2VkIFN3aW5n
IGFwcGxpY2F0aW9ucy4gVGhleSB3ZXJlIGluaXRpYWxseSB0YXJnZXRlZCBhdCBpbmNsdXNpb24g
aW4gdGhlIFNwcmluZyAxLjEgY29yZSwgYnV0IHR1cm5lZCBvdXQgbW9yZSBleHRlbnNpdmUgdGhl
biBleHBlY3RlZC4gVGh1cywgSSBjb25zaWRlciBpdCByZWFzb25hYmxlIHRvIGhvc3QgdGhlbSBh
cyBhIFNwcmluZyBzdWItcHJvamVjdCByYXRoZXIgdGhhbiBhcyBwYXJ0IG9mIHRoZSBTcHJpbmcg
Y29yZS4NCg0KSXQgaXMgKm5vdCogYW4gRWNsaXBzZSBwbHVnaW4gb3IgdGhlIGxpa2UsIGl0J3Mg
YSBzdXBwb3J0IHBsYXRmb3JtIGZvciBidWlsZGluZyByaWNoIGNsaWVudCBhcHBsaWNhdGlvbnMg
b24gU3ByaW5nLCBjdXJyZW50bHkgZm9jdXNzaW5nIG9uIFN3aW5nLiBJIGd1ZXNzIEtlaXRoIGhp
bXNlbGYgaXMgaW4gYSBiZXR0ZXIgcG9zaXRpb24gdG8gZGVzY3JpYmUgdGhlIG1pc3Npb24gaGVy
ZS4uLiBBbmQgSSBhc3N1bWUgdGhhdCBoZSdzIG1vcmUgdGhhbiBoYXBweSB0byBnZXQgb3RoZXIg
cmljaCBjbGllbnQgZGV2ZWxvcGVycyBvbiBib2FyZCA6LSkNCg0KSnVlcmdlbg0KDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyLWFk
bWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KW21haWx0bzpzcHJpbmdmcmFtZXdvcmstZGV2ZWxv
cGVyLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldF1PbiBCZWhhbGYNCk9mIERtaXRyaXkgS29w
eWxlbmtvDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE2LCAyMDA0IDEyOjQ4IFBNDQpUbzogc3By
aW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNClN1YmplY3Q6IFJl
OiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gU3ByaW5nIHN1Yi1wcm9qZWN0cw0KDQoNCisx
LiBCdHcsIHdoYXQgaXMgIlNwcmluZyBSaWNoIENsaWVudCBQbGF0Zm9ybSI/DQoNCkRtaXRyaXku
DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IGrDvHJnZW4gaMO2bGxlciBb
d2VyazNBVF0gPGp1ZXJnZW4uaG9lbGxlckB3ZXJrM2F0LmNvbT4NCkRhdGU6IE1vbmRheSwgRmVi
cnVhcnkgMTYsIDIwMDQgMzo1OCBhbQ0KU3ViamVjdDogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9w
ZXJdIFNwcmluZyBzdWItcHJvamVjdHMNCg0KPiBFdmVyeWJvZHksDQo+IA0KPiBBcyByZWNlbnRs
eSBkaXNjdXNzZWQgaW4gcHJpdmF0ZSBtYWlscywgSSBzdWdnZXN0IHRvIGtlZXAgc3ViLQ0KPiBw
cm9qZWN0cyB0aGF0IGFyZSBjbG9zZSB0byB0aGUgU3ByaW5nIGNvcmUgYXMgc2VwYXJhdGUgbW9k
dWxlcyBpbiANCj4gU3ByaW5nJ3MgbWFpbiBDVlMuIFRoZSBmaXJzdCB0d28gY2FuZGlkYXRlcyBh
cmU6DQo+IA0KPiAtIEtlaXRoIERvbmFsZCdzIFNwcmluZyBSaWNoIENsaWVudCBQbGF0Zm9ybQ0K
PiAtIFRvcnN0ZW4gSnVlcmdlbGVpdCdzIFNwcmluZyBFY2xpcHNlIFBsdWdpbg0KPiANCj4gQm90
aCBLZWl0aCBhbmQgVG9yc3RlbiBhcmUgaW4gZmF2b3Igb2YgaG9zdGluZyB0aGVtIGluIG91ciBt
YWluIA0KPiBDVlMuIFNvIGlmIG5vb25lIG9iamVjdHMsIEkgd2lsbCBjcmVhdGUgbmV3IENWUyBt
b2R1bGVzICJzcHJpbmctDQo+IHJjcCIgYW5kICJzcHJpbmctZWNsaXBzZSIsIGFuZCBhY2NvcmRp
bmdseSBnaXZlIEtlaXRoIGFuZCBUb3JzdGVuIA0KPiBjb21taXQgcmlnaHRzIGZvciB0aGUgbWFp
biBDVlMuIEFzIHRoZSBtb2R1bGUgbmFtZXMgY2Fubm90IGJlIA0KPiBjaGFuZ2VkIGVhc2lseSwg
ZmVlbCBmcmVlIHRvIHN1Z2dlc3QgZGlmZmVyZW50IG5hbWVzIQ0KPiANCj4gVGhlIHJhdGlvbmFs
ZSBpcyB0byBrZWVwIGFsbCBwcm9qZWN0cyB0aGF0IHVzZSANCj4gIm9yZy5zcHJpbmdmcmFtZXdv
cmsiIGFzIHBhY2thZ2UgbmFtZSBpbiBTcHJpbmcncyBtYWluIENWUy4gDQo+IFNlcGFyYXRlIG1v
ZHVsZXMgbWFrZSBzZW5zZSB0byBsZXQgdGhlIHN1Yi1wcm9qZWN0cyBldm9sdmUgDQo+IGluZGVw
ZW5kZW50bHk7IHRoaXMgd2F5LCB0aGV5IGRvIG5vdCBoYXZlIHRvIGJlIHJlbGVhc2VkIGluIGRp
cmVjdCANCj4gYWNjb3JkYW5jZSB3aXRoIHRoZSBTcHJpbmcgY29yZS4gT2YgY291cnNlLCBnZW5l
cmljIGNsYXNzZXMgdGhhdCANCj4gZW1lcmdlIGNhbiBzdGlsbCBnbyBpbnRvIHRoZSBjb3JlLg0K
PiANCj4gQ29uc2VxdWVudGx5LCBib3RoIHN1Yi1wcm9qZWN0cyBzaG91bGQgYWxzbyBnZXQgcmVz
cGVjdGl2ZSANCj4gc2VjdGlvbnMgb24gb3VyIG1haW4gd2Vic2l0ZS4gV2Ugc2hvdWxkIGRlZmlu
aXRlbHkgY2xhcmlmeSBhbGwgDQo+IHRoaXMgYmVmb3JlIDEuMCBmaW5hbCAoTWFyY2ggMXN0KSwg
YXMgSSBleHBlY3QgcXVpdGUgYSBsb3Qgb2YgDQo+IG1lZGlhIGNvdmVyYWdlIGF0IHRoYXQgdGlt
ZSAtIHdlIHNob3VsZG4ndCBtaXNzIHRoYXQgY2hhbmNlIQ0KPiANCj4gSnVlcmdlbg0KPiANCj4g
DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQo+IFNGLk5ldCBpcyBzcG9uc29yZWQgYnk6IFNwZWVkIFN0YXJ0IFlvdXIgTGludXgg
QXBwcyBOb3cuDQo+IEJ1aWxkIGFuZCBkZXBsb3kgYXBwcyAmIFdlYiBzZXJ2aWNlcyBmb3IgTGlu
dXggd2l0aA0KPiBhIGZyZWUgRFZEIHNvZnR3YXJlIGtpdCBmcm9tIElCTS4gQ2xpY2sgTm93IQ0K
PiBodHRwOi8vYWRzLm9zZG4uY29tLz9hZF9pZBM1NiZhbGxvY19pZDQzOCZvcD1jbGljaw0KPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTcHJpbmdm
cmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0KPiBTcHJpbmdmcmFtZXdvcmstZGV2ZWxv
cGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5l
dC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQo+IA0KDQoNCg0KLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU0Yu
TmV0IGlzIHNwb25zb3JlZCBieTogU3BlZWQgU3RhcnQgWW91ciBMaW51eCBBcHBzIE5vdy4NCkJ1
aWxkIGFuZCBkZXBsb3kgYXBwcyAmIFdlYiBzZXJ2aWNlcyBmb3IgTGludXggd2l0aA0KYSBmcmVl
IERWRCBzb2Z0d2FyZSBraXQgZnJvbSBJQk0uIENsaWNrIE5vdyENCmh0dHA6Ly9hZHMub3Nkbi5j
b20vP2FkX2lkEzU2JmFsbG9jX2lkNDM4Jm9wPWljaw0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NClNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGlu
ZyBsaXN0DQpTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0K
aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3
b3JrLWRldmVsb3Blcg0K