DWR

Jim, I am not a Spring expert but from my understanding shouldn't you be using an aop:scoped-proxy to alleviate this issue?

http://static.springsource.org/spring/docs/2.0.x/reference/beans.html (3.4.4.5. Scoped beans as dependencies).

We also briefly mention this in our Spring docs:
http://directwebremoting.org/dwr/documentation/server/integration/spring.html (Scoped Beans).

I've added a test case that shows the problem.

Run with maven jetty:run and access index.html. Set a break point in ScopedBean.afterPropertiesSet to see the problem reproduced. Note this only happens once when the web app has just been started.

So the main issue is that beans that have nothing to do with dwr are forced into existance, which can only be considered a bug, especially in big web apps where dwr:remote is only used on a few beans.

Hope this clears things up.

Jim, that helps a lot. I will take a look at this either this week or this weekend. Thank you for taking the time to provide more details and create the test case.

No problem.

The solution I mentioned in the last line of the issue, if applicable, would also speed up the time it takes to initialize the DWR Spring servlet for large web apps.

Thanks,
Jim

Jim, I stepped through this, this morning using the latest DWR. Here is what is happening (a bit different than what you suspected):

Sorry, accidentally saved that last comment. Picking up where I left off:

AbstractContainer.callInitializingBeans

The instanceof check here is not the problem. The bean is being retrieved/instantiated from the Spring Container in URLProcessor.afterContainerSetup where the beans are retrieved from the container and getBean is called. I don't have a solution for this yet just logging my initial findings here.

Agreed that it's not instanceof that's the problem, but it's the reason why getBeans on all bean names is called a few lines before

From what I understand, using ListableBeanFactory.getBeansOfType would be a better and more effective way, and would fix this issue.

Actually, I was incorrect there is a check in place where I mentioned, so get Bean isn't called there either.

You are incorrect, for what I see callInitializing beans only gets called with DWR's internal beans. You can verify this by placing a breakpoint there.

I don't even see the breakpoint in ScopedBean being hit (once again I am using DWR trunk). Have you tried using trunk?

Hmm.. I just ran the test and hit the break point. I'm using jetty:run as mvn target in eclipse. I see that the test case POM refers to 2.0.3 of DWR, so you should at least be able to reproduce it with that version.

Is there a trunk/snapshot version I can add to the test case POM to run against the latest DWR?

I just checked trunk SpringContainer and it has the following getBeanNames method, which doesn't filter to just dwr beans. In other words, it should return the ScopedBean instance along with all other beans in the spring context:

/* (non-Javadoc)

• @see org.directwebremoting.impl.DefaultContainer#getBeanNames()
  */
  @Override
  public Collection<String> getBeanNames()
  {
  List<String> names = new ArrayList<String>();

// Snarf the beans from Spring
if (beanFactory instanceof ListableBeanFactory)
{
try

catch (IllegalStateException ex)

}
else

// And append the DWR ones
names.addAll(super.getBeanNames());

return Collections.unmodifiableCollection(names);
}

I would like for you to try this using RC3-Snaphshot - you can find it in Sonatype's OSS repo - https://oss.sonatype.org/ or RC2. Note the Spring container code is the same as the RC2 release.

I started looking at this in RC2 because you indicated in the JIRA issue that this is an affected version (which does not appear to be the case).

All comments below relate to 3.x and up:
I understand that method returns all of the Bean Names (in your Spring context). I am unsure how we could distinguish a Bean from your context that you want to expose to DWR and one you do not (keep in mind there are many configuration options)? However, the callInitializingBeans in SpringContainer only passes in DWR internal beans to AbstractContainers.callInitializingBeans.

From SpringContainer:

/**

• Avoids initialization of lazy-init beans in Spring context.
  */
  @Override
  protected void callInitializingBeans() { callInitializingBeans(super.getBeanNames()); }

The super will only retrieve DWR internal beans, so callIntializingBeans is not the problem as getBean is only being called on internal DWR beans (Beans from your Spring Context aren't in beanNames). NOTE: this has NOT always been the case! It was originally fixed on 5/29/08 for DWR-254.

So, first I would like you to try things out in RC2 or RC3-Snapshot. The problem should be fixed and if you can upgrade to that version than I will close this issue as a duplicate of DWR-254. If you cannot upgrade I will remove the affects RC2 from this issue, mark it for the next 2.x release and try to get a fix out to you ASAP (IF the fix is not too involved).

Jim, do not use M1. That is not a valid test either. Please use the version from the Sonatype OSS repo OR RC2 from our site (add into your local Maven repo).

Sorry for the confusion. This is due to the fact that we don't build in Maven and in the past have had difficulties getting our artifacts into Maven central. There used to be a manual process for this but it has changed over the years and there was a long period of time where we didn't release artifacts into Maven central because it was simply too difficult. Those issues have been resolved and all releases moving forward will be in Maven central.

As you can see http://bugs.directwebremoting.org/jira/browse/DWR-254 is listed as affecting M1. The fix was after M1 was released.

The fix is the same as the fix for DWR-254, essentially making sure callInitializingBeans is called ONLY with DWR internal beans. This can be accomplished by passing super.getBeansNames() into the callInitialzingBeans call.

Confirmed that it's fixed in 3.0-RC2, but affects M1 and before as you now indicate in the affects versions.

Would be great if the fix is added to 2.0.X since this would be a smaller upgrade for us.

Thanks for your help David. Appreciate it.

I think the fix will be very quick for 2.x. Can you help test it out for me when I get the fix in?

Ok, I made a change. It is on our CI build server - http://ci.directwebremoting.org/bamboo/browse/DWR20-ALL-82/artifact.

Hi David.

Added the jar at http://ci.directwebremoting.org/bamboo/browse/DWR20-ALL-82/artifact/JOB1/dwr.jar/dwr.jar to local rep and ran the test case (which doesn't fail with 3.0-RC2) but it still fails.

I see that there's changes in AbstractContainer but they don't seem to have done the trick.

Sorry Jim. Try again - http://ci.directwebremoting.org/bamboo/browse/DWR20-ALL-84/artifact. This one should do the trick (had time to test it).

Build 84 did the trick. ScopedBean is no longer one of the bean names in AbstractContainer.callInitializingBeans.

Thanks Jim. I will try to release 2.0.10 in the next week or so.

I just pushed out 2.0.10 with this fix. It will be in Maven central in a few hours. I will update the site in the coming days.