springframework-developer — Spring Framework developers list

Re: [Springframework-developer] springframework.org currently down

[Matthew E. P. <mat...@co...>]

Contegix support is already addressing the issue.


Cheers,
   Matthew

On Nov 2, 2005, at 7:50 AM, Matt Sgarlata wrote:

> Here's the error message:
>
> Can't connect to local MySQL server through socket '/var/lib/mysql/ 
> mysql.sock' (11)
>
> Matt
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.  
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] springframework.org currently down

[Matt S. <sga...@us...>]

Here's the error message:

Can't connect to local MySQL server through socket 
'/var/lib/mysql/mysql.sock' (11)

Matt

Re: [Springframework-developer] Bug in suspend/resume of rolled back transaction wih JOTM?

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

Andy,

 From what I can tell we get a SystemException on the resume call.   
If I trap that exception I get a subsequent RollbackException during  
the final commit processing of the JTA transaction.  I'm not sure  
what the proper semantics are here, but I don't think this matches at  
all what we have seen from other JTA implementations.  I know I did  
not see any of these exceptions using WebLogic in a similar situation  
with a suspended transaction being resumed.

Thomas


On Nov 1, 2005, at 11:38 AM, Andy Depue wrote:

> On Saturday 29 October 2005 07:12 am, Juergen Hoeller wrote:
>
>> ...
>> However, it's not clear to me what such a special  
>> JotmJtaTransactionManager
>> would have to do to enforce a resume. There doesn't seem to be a
>> "forceResume"-style method anywhere in the JOTM API. It might be  
>> worthwhile
>> to check out Jonas's usage of JOTM: The Jonas EJB container  
>> essentially has
>> the same requirement, needing to enforce a resume of a  
>> transaction. I would
>> appreciate any help in finding out how to achieve this.
>>
>
> I've received some initial feedback from JOTM and Jonas developers,  
> and they
> say that for JOTM, you can choose to ignore the RollbackException  
> at the
> point of "resume" to achieve a forced resume (they said that the
> RollbackException is recoverable at this point, and the transaction  
> should
> still properly rollback when it is finished).  However, they are  
> aware of a
> bug in which only the first XA resource is re-enlisted with the  
> transaction
> at resume (because it is after the first "enlist" operation that the
> RollbackException is thrown, thus causing their enlist loop to  
> abort).  They
> are planning on patching this soon.
>
>   - Andy
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.  
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

Re: [Springframework-developer] Bug in suspend/resume of rolled back transaction wih JOTM?

[Andy D. <an...@ma...>]

On Saturday 29 October 2005 07:12 am, Juergen Hoeller wrote:
> ...
> However, it's not clear to me what such a special JotmJtaTransactionManager
> would have to do to enforce a resume. There doesn't seem to be a
> "forceResume"-style method anywhere in the JOTM API. It might be worthwhile
> to check out Jonas's usage of JOTM: The Jonas EJB container essentially has
> the same requirement, needing to enforce a resume of a transaction. I would
> appreciate any help in finding out how to achieve this.

I've received some initial feedback from JOTM and Jonas developers, and they 
say that for JOTM, you can choose to ignore the RollbackException at the 
point of "resume" to achieve a forced resume (they said that the 
RollbackException is recoverable at this point, and the transaction should 
still properly rollback when it is finished).  However, they are aware of a 
bug in which only the first XA resource is re-enlisted with the transaction 
at resume (because it is after the first "enlist" operation that the 
RollbackException is thrown, thus causing their enlist loop to abort).  They 
are planning on patching this soon.

  - Andy

Re: [Springframework-developer] AbstractPerformanceMonitorInterceptor changed for bad in 1.2.5

[Rob H. <rob...@in...>]

This is fixed in the current CVS HEAD ready for 1.2.6

Marc Logemann wrote:

> Hi,
>
> please take a look at that stack:
>
> java.lang.NullPointerException
>     at java.lang.StringBuffer.<init>(StringBuffer.java:80)
>     at 
> org.springframework.aop.interceptor.AbstractPerformanceMonitorInterceptor.createInvocationTraceName(AbstractPerformanceMonitorInterceptor.java:80) 
>
>     at 
> org.springframework.aop.interceptor.JamonPerformanceMonitorInterceptor.invokeUnderTrace(JamonPerformanceMonitorInterceptor.java:57) 
>
> [..]
>
>
> this is the related Spring config:
>
>     <!-- =================================== -->
>     <!--           AutpoProxy Creator        -->
>     <!-- =================================== -->
>     <bean id="proxyCreator" 
> class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator"> 
>
>         <property name="beanNames">
>             <list>
>                 <value>loginService</value>
>             </list>
>         </property>
>         <property name="interceptorNames">
>             <list>
>                 <value>JAMonInterceptor</value>
>             </list>
>         </property>
>     </bean>
>
>     <bean id="JAMonInterceptor" 
> class="org.springframework.aop.interceptor.JamonPerformanceMonitorInterceptor"/> 
>
>
> This configuration worked for months but after upgrading to Spring 
> 1.2.5 i am getting the stack. The reason is quite obvious, Juergen 
> tried to be a good boy and used StringBuffer instead of String 
> concatenation and initialized it with a Prefix, but i dont have a 
> prefix and i dont know if its a good idea to take for granted that 
> there is one.
>
> See the relevant method from Spring _before_ 1.2.5
>
> --- snipp  ---
> protected String createInvocationTraceName(MethodInvocation invocation){
>  String invocationData = 
> invocation.getMethod().getDeclaringClass().getName() + "." + 
> invocation.getMethod().getName();
>  return getPrefix() + invocationData + getSuffix();
> }
> --- snapp ---
>
> Now the current one in 1.2.5:
>
> --- snipp ---
> protected String createInvocationTraceName(MethodInvocation invocation){
>  StringBuffer sb = new StringBuffer(getPrefix());
>  sb.append(invocation.getMethod().getDeclaringClass().getName());
>  sb.append('.').append(invocation.getMethod().getName());
>  sb.append(getSuffix());
>  return sb.toString();
> }
> --- snapp ---
>
> So either we should intitialize the prefix property with "" or just 
> dont use the parametrized constructor of StringBuffer.
>
> Tell me what you think....
>
> Marc Logemann
> http://www.logemann.org
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer


-- 
Rob Harrop
Principal Consultant
Interface21 - Spring Services from the Source
http://www.springframework.com 

Re: [Springframework-developer] Re: TypedMapFactory?

[Rob H. <rob...@in...>]

Exactly that.We can find that a method is declared to return a 
paramerized type and that its arguments are parameterized. Based on this 
we can have something like:

setMyMap(Map<String, Integer>)

And at runtime see the parameterization for the Map.

Oliver Hutchison wrote:

>>On the other hand, when it comes to method signatures, my 
>>understanding is that the bounding information is available 
>>through reflection. So you can tell that a method takes a 
>>List<String> and not a List. I'm not 100% sure on this (and 
>>confirmation by anybody would be good), but I presume this is 
>>what Rob is basing his statement below on.
>>    
>>
> 
>This is correct - Java 1.5 does keep generic type information relating
>to fields and method signatures (accessible using the new #getGeneric*
>methods on Field and Method). I'm taking advantage of this for type
>inference in Spring Rich's data binding system.
>
>Ollie
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the JBoss Inc.
>Get Certified Today * Register for a JBoss Training Course
>Free Certification Exam for All Training Attendees Through End of 2005
>Visit http://www.jboss.com/services/certification for more information
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

-- 
Rob Harrop
Principal Consultant
Interface21 - Spring Services from the Source
http://www.springframework.com 

[Springframework-developer] Fwd: Mailman results for Springframework-developer

[Ahmed A. <sne...@gm...>]

hey guys how can i validate array of data dynamically(the array is created
dynamically by

javascript) knowing that i get error every time saying that it is not a
binded object and it is a

string (the object i am trying to validate it)

the error i get is : java.lang.ClassCastException: java.lang.String

and the validation code that i used to validate the dynamic list is like
this :


private void validateEquality(PaymentDocument document,
Errors errors) {
Long amount=3Ddocument,.getAmount();
Long Sum=3Dnew Long(0);

//where Financialtransactiondetails is the list that contains the dynamic
data

Iterator itr=3Ddocument,.getFinancialtransactiondetails().ite rator();


while(itr.hasNext())
{
Object currenct=3Ditr.next();
Long cashAmount =3D new Long(((FinancialTransactionDetails)currenct).getAm
ount());
log.debug(">>>>>>>>>>>>>>>>>>> cashAmount "+cashAmount);
Sum+=3DcashAmount;
}
//if the sum of all the money =3D the amount that the user entered then eve=
ry
thing is good else i will raise an error

if(!Sum.equals(amount))
errors.rejectValue("amount","Error In Amount","Total Amount Must Be Equal T=
o
Details Amount");

}

--------------------------------------------------END OF
VALIDATION-----------------------------------------------

 *when i enter a wrong amount then i will be prompeted to enter the correct
amount(that is right) and when i enter the correct amount (just to correct
the wrong amount i entred before) i get the CLASS CAST EXCEPTION , if i
entred it correct from the 1st time everything will work just fine......wel=
l
got any idea
<http://forum.springframework.org/editpost.php?do=3Deditpost&p=3D38945>

[Springframework-developer] AbstractPerformanceMonitorInterceptor changed for bad in 1.2.5

[Marc L. <li...@lo...>]

Hi,

please take a look at that stack:

java.lang.NullPointerException
	at java.lang.StringBuffer.<init>(StringBuffer.java:80)
	at 
org.springframework.aop.interceptor.AbstractPerformanceMonitorInterceptor.createInvocationTraceName(AbstractPerformanceMonitorInterceptor.java:80)
	at 
org.springframework.aop.interceptor.JamonPerformanceMonitorInterceptor.invokeUnderTrace(JamonPerformanceMonitorInterceptor.java:57)
[..]


this is the related Spring config:

     <!-- =================================== -->
     <!--           AutpoProxy Creator        -->
     <!-- =================================== -->
     <bean id="proxyCreator" 
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
         <property name="beanNames">
             <list>
                 <value>loginService</value>
             </list>
         </property>
         <property name="interceptorNames">
             <list>
                 <value>JAMonInterceptor</value>
             </list>
         </property>
     </bean>

     <bean id="JAMonInterceptor" 
class="org.springframework.aop.interceptor.JamonPerformanceMonitorInterceptor"/>

This configuration worked for months but after upgrading to Spring 1.2.5 
i am getting the stack. The reason is quite obvious, Juergen tried to be 
a good boy and used StringBuffer instead of String concatenation and 
initialized it with a Prefix, but i dont have a prefix and i dont know 
if its a good idea to take for granted that there is one.

See the relevant method from Spring _before_ 1.2.5

--- snipp  ---
protected String createInvocationTraceName(MethodInvocation invocation){
  String invocationData = 
invocation.getMethod().getDeclaringClass().getName() + "." + 
invocation.getMethod().getName();
  return getPrefix() + invocationData + getSuffix();
}
--- snapp ---

Now the current one in 1.2.5:

--- snipp ---
protected String createInvocationTraceName(MethodInvocation invocation){
  StringBuffer sb = new StringBuffer(getPrefix());
  sb.append(invocation.getMethod().getDeclaringClass().getName());
  sb.append('.').append(invocation.getMethod().getName());
  sb.append(getSuffix());
  return sb.toString();
}
--- snapp ---

So either we should intitialize the prefix property with "" or just dont 
use the parametrized constructor of StringBuffer.

Tell me what you think....

Marc Logemann
http://www.logemann.org

Re: [Springframework-developer] Bug in suspend/resume of rolled back transaction wih JOTM?

[Andy D. <an...@ma...>]

On Saturday 29 October 2005 07:12 am, Juergen Hoeller wrote:
> Hi Andy,
>
> However, it's not clear to me what such a special JotmJtaTransactionManager
> would have to do to enforce a resume. There doesn't seem to be a
> "forceResume"-style method anywhere in the JOTM API. It might be worthwhile
> to check out Jonas's usage of JOTM: The Jonas EJB container essentially has
> the same requirement, needing to enforce a resume of a transaction. I would
> appreciate any help in finding out how to achieve this.
>

Thanks for your help, Juergen!  I've posted a message to the JOTM list (about 
the issue), and another inquiry to the Jonas list asking how they handle this 
case.  I'll try to dig around Jonas source, time permitting.

Thanks,
  Andy

[Springframework-developer] FAILED BUILD: x86-linux2 (last 30 lines included)

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

1130753965
FAILED
    [junit] Testcase: testAutowireWithDefault took 0.068 sec
    [junit] Testcase: testAutowireByConstructor took 0.046 sec
    [junit] Testcase: testAutowireByConstructorWithSimpleValues took 0.352 sec
    [junit] Testcase: testConstructorArgResolution took 0.179 sec
    [junit] Testcase: testConstructorArgWithSingleMatch took 0.161 sec
    [junit] Testcase: testThrowsExceptionOnTooManyArguments took 0.165 sec
    [junit] Testcase: testThrowsExceptionOnAmbiguousResolution took 0.075 sec
    [junit] Testcase: testFactoryBeanDefinedAsPrototype took 0.417 sec
    [junit] Testcase: testDependsOn took 0.98 sec
    [junit] Testcase: testDependsOnInInnerBean took 0.08 sec
    [junit] Testcase: testDependenciesThroughConstructorArguments took 0.067 sec
    [junit] Testcase: testDependenciesThroughConstructorArgumentAutowiring took 0.205 sec
    [junit] Testcase: testDependenciesThroughConstructorArgumentsInInnerBean took 0.042 sec
    [junit] Testcase: testDependenciesThroughProperties took 0.328 sec
    [junit] Testcase: testDependenciesThroughPropertiesWithInTheMiddle took 0.735 sec
    [junit] Testcase: testDependenciesThroughPropertyAutowiringByName took 0.374 sec
    [junit] Testcase: testDependenciesThroughPropertyAutowiringByType took 0.045 sec
    [junit] Testcase: testDependenciesThroughPropertiesInInnerBean took 0.073 sec
    [junit] Testcase: testClassNotFoundWithDefault took 0.077 sec
    [junit] Testcase: testClassNotFoundWithNoBeanClassLoader took 0.055 sec
    [junit] Testcase: testResourceAndInputStream took 0.124 sec
    [junit] Testcase: testClassPathResourceWithImport took 0.06 sec
    [junit] Testcase: testUrlResourceWithImport took 0.048 sec
    [junit] Testcase: testFileSystemResourceWithImport took 0.051 sec
    [junit] Testcase: testLookupOverrideMethodsWithSetterInjection took 3.049 sec
    [junit] 	FAILED
    [junit] null
    [junit] junit.framework.AssertionFailedError
    [junit] 	at org.springframework.beans.factory.xml.XmlBeanFactoryTests.testLookupOverrideMethodsWithSetterInjection(XmlBeanFactoryTests.java:896)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

Re: [Springframework-developer] unable to turn off automatic detection of all handler adaptors?

[Seth L. <set...@gm...>]

On 10/29/05, Juergen Hoeller <ju...@in...> wrote:
> Hi Seth,
>
> Well, I guess HandlerAdapters are practically always detected by type. Bu=
t
> point taken, for completeness, there should be the option to only use a
> single HandlerAdapter bean of name "handlerAdapter" as well.

I agree.  While I'm not sure it's very practical, adding that
functionality does provide balance.

Thanks,
Seth

[Springframework-developer] spring build.368 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20051030231648Lbuild.368

Re: [Springframework-developer] Java Consultant for Hong Kong Project

[Farhan K. <ka...@gm...>]

Issac,

Thank you for contacting me about this. I am interested in talking about
this position in detail with you.

Please contact me through email or phone at 773-412-3293. Thanks.

Farhan Kazmi
email: far...@gm...
phone: 773-412-3293

On 10/27/05, Issac Johnson <iss...@cy...> wrote:
>
>
> Hi, we are looking to hire either a permanent staff or a free lance
> consultant to work on the development of
> new Java based web application. We are looking for people who have
> experience with J2EE, Spring,
> Lucene, MySQL and if possible also NUTCH.
>
> We are developing an exciting new web application in Hong Kong and if you
> would like to help either as a
> remote consultant or permanent staff in Hong Kong. Pls can you let me kno=
w
> and I will send your more details.
>
> Thank you and have a good day.
>
> Issac Johnson
> Research Manager
> Cyberspace Ltd
> http://www.cyberspaceltd.com
> email: iss...@cy...
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] unable to turn off automatic detection of all handler adaptors?

[Juergen H. <ju...@in...>]

Hi Seth,

Well, I guess HandlerAdapters are practically always detected by type. But
point taken, for completeness, there should be the option to only use a
single HandlerAdapter bean of name "handlerAdapter" as well.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Seth Ladd
Sent: Sunday, October 30, 2005 10:30 AM
To: spr...@li...
Subject: [Springframework-developer] unable to turn off automatic detection
of all handler adaptors?

Hello,

The DispatcherServlet can be configured to not automatically detect all view
resolvers, handler mappings, etc.  For some reason, there is no explicit way
to disable automatic detection of all handler adaptors.  Is this a simple
oversight, or is there some reason for this behavior?

Related, there is no default bean name like HANDLER_ADAPTOR_BEAN_NAME
present.

Thanks for your insight,
Seth


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free
Certification Exam for All Training Attendees Through End of 2005 Visit
http://www.jboss.com/services/certification for more information
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] unable to turn off automatic detection of all handler adaptors?

[Seth L. <set...@gm...>]

Hello,

The DispatcherServlet can be configured to not automatically detect
all view resolvers, handler mappings, etc.  For some reason, there is
no explicit way to disable automatic detection of all handler
adaptors.  Is this a simple oversight, or is there some reason for
this behavior?

Related, there is no default bean name like HANDLER_ADAPTOR_BEAN_NAME prese=
nt.

Thanks for your insight,
Seth

[Springframework-developer] spring build.367 Build Fixed

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20051030001618Lbuild.367

Re: [Springframework-developer] Exception not declared in form controllers

[Juergen H. <ju...@in...>]

Point taken. The assumption here is that you're doing a plain
"HttpServletRequest.getParameter()" check, which won't throw an exception.
In general, I would implement isFormSubmission so that it always falls back
to return false if it can't properly detect a form submission.

We can change isFormSubmission to declare an exception to be thrown, but
that will unfortunately affect overriding methods that call
"super.isFormSubmission". As a consequence, we can only do that for a new
major version. That said, I'm not sure whether it's worth the change in the
first place...

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Roberto Cosenza
Sent: Thursday, October 27, 2005 11:55 AM
To: spr...@li...
Subject: [Springframework-developer] Exception not declared in form
controllers

Is there any special reason why the following methods

protected boolean isFormSubmission(HttpServletRequest request) protected
boolean isFormChangeRequest(HttpServletRequest request) respectively in
AbstractFormController and in SimpleFormController, do not throw Exception?

Just using RequestUtils.getStringParameter requires a try catch block...

/Roberto



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free
Certification Exam for All Training Attendees Through End of 2005 Visit
http://www.jboss.com/services/certification for more information
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Bug in suspend/resume of rolled back transaction wih JOTM?

[Juergen H. <ju...@in...>]

Hi Andy,

I do not expect this behavior to change between different Spring versions.
The problem rather lies in the semantics of JOTM's
"TransactionManager.resume()" operation, which does seem to throw an
exception if the transaction to resume has already been marked for rollback.
Unfortunately, the JTA spec is not clear on how that operation should behave
in such a case; as a consequence, JTA providers differ in that respect.

As Thomas says, we know that issue from WebLogic, where the JTA
"TransactionManager.resume()" operation has the same semantics. WebLogic
provides a separate "forceResume()" operation (on its extended
TransactionManager interface) that will also resume a transaction that has
already been marked for rollback.

We simply provide a special WebLogicJtaTransactionManager now (a subclass of
our standard JtaTransactionManager), calling WebLogic's "forceResume()" and
also providing a couple of WebLogic-specific extensions. This works nicely
on both WebLogic 8.1+ and 7.0 now. I guess we will have to provide such a
special JtaTransactionManager for JOTM as well then.

However, it's not clear to me what such a special JotmJtaTransactionManager
would have to do to enforce a resume. There doesn't seem to be a
"forceResume"-style method anywhere in the JOTM API. It might be worthwhile
to check out Jonas's usage of JOTM: The Jonas EJB container essentially has
the same requirement, needing to enforce a resume of a transaction. I would
appreciate any help in finding out how to achieve this.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Andy Depue
Sent: Saturday, October 29, 2005 12:23 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Bug in suspend/resume of rolled
back transaction wih JOTM?

I should note that I've just tested this against Spring 1.2.5, which does
not change the result in any way.

  - Andy

On Friday 28 October 2005 01:32 pm, Andy Depue wrote:
> I've run into a problem with Spring and JOTM concerning suspending and 
> later resuming a rolled back JOTM transaction.  I'm not certain yet if 
> the problem lies in JOTM, Spring, or my usage of Spring.  I've created 
> a test that reproduces the problem.  See this thread in the forums for 
> full detail, including the test and related files:
> http://forum.springframework.org/showthread.php?t=19263
> I'm using Spring v 1.2.4 and JOTM v. 2.0.10.
> Should I create a new JIRA issue, or is this just me not using Spring 
> properly?
>
>   - Andy
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course Free 
> Certification Exam for All Training Attendees Through End of 2005 
> Visit http://www.jboss.com/services/certification for more information 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free
Certification Exam for All Training Attendees Through End of 2005 Visit
http://www.jboss.com/services/certification for more information
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Akshay K Pandit is out of the office 8th july 05- 11th july 05

[Akshay K P. <aks...@in...>]

I will be out of the office starting  10/29/2005 and will not return until
11/07/2005.

I will be out of office from 28th of Oct '05 and will not return till 6th
of Nov '05. Rajni Klair and Sachin Popli would be my back up for CSA
related Work. So please co-ordinate with them, In case of any urgency

Re: [Springframework-developer] Bug in suspend/resume of rolled back transaction wih JOTM?

[Andy D. <an...@ma...>]

I should note that I've just tested this against Spring 1.2.5, which does not 
change the result in any way.

  - Andy

On Friday 28 October 2005 01:32 pm, Andy Depue wrote:
> I've run into a problem with Spring and JOTM concerning suspending and
> later resuming a rolled back JOTM transaction.  I'm not certain yet if the
> problem lies in JOTM, Spring, or my usage of Spring.  I've created a test
> that reproduces the problem.  See this thread in the forums for full
> detail, including the test and related files:
> http://forum.springframework.org/showthread.php?t=19263
> I'm using Spring v 1.2.4 and JOTM v. 2.0.10.
> Should I create a new JIRA issue, or is this just me not using Spring
> properly?
>
>   - Andy
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] spring Build Failed

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20051029001644

Re: [Springframework-developer] Bug in suspend/resume of rolled back transaction wih JOTM?

[Andy D. <an...@ma...>]

Yes, except you might want to tweak the DataSource settings to use some test 
JDBC driver (I happened to use a local PostgreSQL)... anything that would 
throw a SQLException for a SELECT would work.

  - Andy

On Friday 28 October 2005 01:48 pm, Thomas Risberg wrote:
> We had similar issues with WebLogic 7 - I'll try your code locally to
> see if I can reproduce it.  You are running this as a standalone app,
> right?
>
> Thomas
>
> On Oct 28, 2005, at 4:32 PM, Andy Depue wrote:
> > I've run into a problem with Spring and JOTM concerning suspending
> > and later
> > resuming a rolled back JOTM transaction.  I'm not certain yet if
> > the problem
> > lies in JOTM, Spring, or my usage of Spring.  I've created a test that
> > reproduces the problem.  See this thread in the forums for full
> > detail,
> > including the test and related files:
> > http://forum.springframework.org/showthread.php?t=19263
> > I'm using Spring v 1.2.4 and JOTM v. 2.0.10.
> > Should I create a new JIRA issue, or is this just me not using Spring
> > properly?
> >
> >   - Andy

[Springframework-developer] getObjectById(Class clazz, Object id) in JDOTemplate

[Marc L. <li...@lo...>]

Hi,

it would be nice if we could keep the JDOTemplate JDO-version-agnostic, 
Juergen did this perfectly with the detach/attach methods some time ago 
(1.2.2 or something), so to me it seems straightforward to do the same 
with getObjectById(Class clazz, Object id). I am thinking of something 
like that:

---
[JDOTemplate.java]
...
public Object getObjectById(final Class entityClass, final Object
                                idValue) throws DataAccessException {
  return execute(new JdoCallback() {
   public Object doInJdo(PersistenceManager pm) throws JDOException {
      return getJdoDialect().getObjectById(entityClass, idValue);
   }
  }, true);
}
...


In DefaultJDODialect we could place the JDO detection static initializer 
and we would use it in the same way as before in getObjectById() in 
JDOTemplate. Perhaps it would make sense to also create a protected 
getJDOVersion() in JDODefaultDialect so that custom implementations of 
JDODefaultDialect like MarcJDODialect could ask for the JDO version to 
do special stuff if needed, would be easier than to directly access the 
static attribute to the flag.

All in all we would have a cleaner JDOTemplate without unresolved 
references for JDO1 developers looking at JDOTemplate. All these 
unresolved things are hidden in JDODefaultDialect or not if you use 
custom childs of it.

Tell me what you think.

BTW nice catch regarding JDO version detection ;-) I had to double check 
that there is a difference at all.

I will start looking into the auto-detaching of JDOTemplate when
TransactionSynchronizationManager.hasResource(getPersistenceManagerFactory())
equals false.


Marc Logemann
http://www.logemann.org

Re: [Springframework-developer] Bug in suspend/resume of rolled back transaction wih JOTM?

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

We had similar issues with WebLogic 7 - I'll try your code locally to  
see if I can reproduce it.  You are running this as a standalone app,  
right?

Thomas


On Oct 28, 2005, at 4:32 PM, Andy Depue wrote:

> I've run into a problem with Spring and JOTM concerning suspending  
> and later
> resuming a rolled back JOTM transaction.  I'm not certain yet if  
> the problem
> lies in JOTM, Spring, or my usage of Spring.  I've created a test that
> reproduces the problem.  See this thread in the forums for full  
> detail,
> including the test and related files:
> http://forum.springframework.org/showthread.php?t=19263
> I'm using Spring v 1.2.4 and JOTM v. 2.0.10.
> Should I create a new JIRA issue, or is this just me not using Spring
> properly?
>
>   - Andy
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

[Springframework-developer] Bug in suspend/resume of rolled back transaction wih JOTM?

[Andy D. <an...@ma...>]

I've run into a problem with Spring and JOTM concerning suspending and later 
resuming a rolled back JOTM transaction.  I'm not certain yet if the problem 
lies in JOTM, Spring, or my usage of Spring.  I've created a test that 
reproduces the problem.  See this thread in the forums for full detail, 
including the test and related files: 
http://forum.springframework.org/showthread.php?t=19263
I'm using Spring v 1.2.4 and JOTM v. 2.0.10.
Should I create a new JIRA issue, or is this just me not using Spring 
properly?

  - Andy