Community
Participate
Working Groups
While working on some JBoss Tools code, I stumbled upon this glitch... 1) Create a new Dynamic Web Project 2) Create a web service (i.e. create a package, annotated class, and add a servlet and servlet mapping to the web.xml in the project) 3) Load org.eclipse.jst.j2ee.model.ModelProviderManager and do something like this: IModelProvider provider = ModelProviderManager.getModelProvider(project); Object object = provider.getModelObject(); if (object instanceof WebApp) { WebApp webApp = (WebApp) object; List<?> theServlets = webApp.getServlets(); // check to see that your servlet was added } 4) Now go back into your web project... Delete the servlet and servlet mapping from your web.xml. 5) Do the same thing - and the Model Provider doesn't seem to be getting updated when the workbench changes. You end up with the same servlet that you deleted still being in the WebApp instance. I tried finding some way to refresh the Model Provider, but couldn't see anything obvious. I even tried refreshing the project (refreshLocal(xx,xx)) and that didn't help either. Any ideas? This is in org.eclipse.jst.j2ee_1.1.400.v201005271900.jar, which I believe is the one in the latest Helios version of WTP (prior to Helios SR1).
The workaround I've found seems to be to close the project and reopen it after deleting the web.xml servlet/servlet-mapping bits. If you do that, it seems to refresh it and work fine. But obviously this is a seriously clunky workaround for users.
Brian, what version of Web project are you creating? This should be fully supported for Web 2.2-2.4, but other factors come into play for Web 2.5 & 3.0.
(In reply to comment #2) > Brian, what version of Web project are you creating? This should be fully > supported for Web 2.2-2.4, but other factors come into play for Web 2.5 & 3.0. 2.5, the default version for the wizard in the Helios JEE package.
Brian after deletion is the servlet present in the Deployment Descriptor tree node?
(In reply to comment #4) > Brian after deletion is the servlet present in the Deployment Descriptor tree > node? Not sure I understand the question. What's the easiest way to check?
(In reply to comment #5) > (In reply to comment #4) > > Brian after deletion is the servlet present in the Deployment Descriptor tree > > node? > > Not sure I understand the question. What's the easiest way to check? Never mind... Yes, the servlet and mapping still appear in the Deployment Descriptor tree. It doesn't get updated.
Brian, can you attach some example project, since I cannot reproduce it with latest helios release.
In a raw Helios JEE installation I can't duplicate it either... So I'm guessing it's something we're doing in JBoss Tools to not properly update the in-memory model of the Deployment Descriptor somehow. Is there a way to force the ModelProviderManager to refresh based on workspace changes? Obviously with the workaround to close and reopen the project, there's some kind of caching there that's not getting refreshed properly.
Hi guys, I tested this issue again. Yes, if you use xml editor to edit web.xml. It is always ok. You can add a servlet, remove it, then readd one ,delete it. All are ok. But if use jboss ws codes to add the servlet and servletmap to a web.xml like the steps like Brian. These servlet and servletmap still appear in the Deployment Descriptor tree. Maybe it is our jboss codes problem, but I looked into these codes, they are same some codes from wtp. No problems. And I try again. After I add one servlet adn one serletmap to web.xml, open the web.xml, remove the servlet,save it. The servlet is still in Deployment Descriptor tree. But if I go on removing servletmap, save it. The servletmap and the servlet both disaappear from the Deployment Descriptor tree. It is very weird. Thay is to say, if I make twice changes and save twice, the Deployment Descriptor tree will be updated.
I think we had similar problem in our developer studio. If I recall it right the problem was in exception in one of the model listeners, and thus the event never made it to the DD tree. Can you try to debug if event for model change is received in the Web node. I think the class was called: JEE5ContentProvider this is in org.eclipse.jst.jee.ui plugin.
(In reply to comment #10) > I think we had similar problem in our developer studio. If I recall it right > the problem was in exception in one of the model listeners, and thus the event > never made it to the DD tree. > > Can you try to debug if event for model change is received in the Web node. I > think the class was called: JEE5ContentProvider this is in > org.eclipse.jst.jee.ui plugin. Hi Dimitar, I debug into the JEE5ContentProvider. I found when I use the codes:IModelProvider to add the servlet, JEE5ContentProvider.projectChanged(final IProject project) is called. So you can find the added servlet in the DD tree at once. But when I delete the servlet from web.xml in web.xml editor source tab, then save web.xml, JEE5ContentProvider.projectChanged(final IProject project) is not called. And I change something in the web.xml again, the JEE5ContentProvider.projectChanged(final IProject project) is clalled.
Ok so next step would be to check if the event is dispatched to the Tree listener, check if the listeners are prevented successfully on dispose of the model. On the *MergedModelProvider there should be mechanism that on dispose keeps alive the listeners that are already registered to the model. Check if these listeners are the same amount (and the same Listeners in both cases). If yes put a breakpoint on the fire event method, to check if all listeners get the change event.
(In reply to comment #12) > Ok so next step would be to check if the event is dispatched to the Tree > listener, check if the listeners are prevented successfully on dispose of the > model. The model changed event has been dispatched to the tree listener(JEE5ContentProvider), as if at my scene, it use Web25MergedModelProvider, but when I checkout it from wtp cvs, the model folder is empty of org.eclipse.jst.jee. I can't access this Web25MergedModelProvider to look into it. > On the *MergedModelProvider there should be mechanism that on dispose keeps > alive the listeners that are already registered to the model. > > Check if these listeners are the same amount (and the same Listeners in both > cases). > If yes put a breakpoint on the fire event method, to check if all listeners get > the change event.
Created attachment 182184 [details] Unit-test to verify if ModelProvider is refreshed when web.xml is updated This unit test verifies if ModelProvider is refreshed when web.xml is updated (Currently this test fails) * The test writes a filter X to web.xml (using a TextFileBuffer in this case) * It then tries to delete that filter from web.xml using ModelProvider. Expected Results: This newly added filter should be successfully removed. Actual Results: This newly added filter is not found in the web.xml model.
That is to say, you have reproduce this issue in your unit test? What reason do you think cause the issue? > Created an attachment (id=182184) [details] > Unit-test to verify if ModelProvider is refreshed when web.xml is updated > > This unit test verifies if ModelProvider is refreshed when web.xml is updated > (Currently this test fails) > > * The test writes a filter X to web.xml > (using a TextFileBuffer in this case) > > * It then tries to delete that filter > from web.xml using ModelProvider. > > > Expected Results: > This newly added filter should be successfully removed. > > Actual Results: > This newly added filter is not found in the web.xml model.
This means that the merged model does not get notification for change from XML model. When the change is done without using the model API. I currently on eclipse summit, but I will try to investigate the issue this week and I will get back to you.
Created attachment 182604 [details] Jee models reload if the DD file is changed from outside. ok what I have found out is that when you call the model modify the web.xml model is loaded. After that the model is changed from outside no emf notification is triggered and thus no unload and then load of the model occurs. Finally the merged model works with inconsistent instance of the model. What I have done is to check for DD file timestamp change and if the timestamps are different force model reload. Next steps is thorough testing and integrating your test in Java EE model tests.
Created attachment 182605 [details] version 2 - optimized and now working
Created attachment 182708 [details] version 3 added model unload for the xml model
Created attachment 182709 [details] added junit tests
Created attachment 182710 [details] binary zip containing the tests project
The problem was on 2 levels: 1. One is that Merged providers cache the model and do not detect change since the there is no model change event (xml is edited from outside) 2. The XML model is also nor reloaded on change from outside ModelProvider API. To force reload model unload is called. @Chuck can you review the change? I have tried all junit for the models and there is no regression, manual testing also shows no regression. I somehow think that there should be a better way to do this, but I ran out of ideas.
approved
Thanks guys. This will resolve a few bugs we have open for JBoss Tools web service support. :) So this is targeted for 3.2.3 - does that mean it's going to be in the Helios SR2 release? Or will this instead be appearing in the Indigo release?
committed and released in 3_2_maintenance and head
This fix has caused another issue. Please see bug 331611. With the patch (version 3), only the first modify call is successful, subsequent ones fail silently, as though they were never performed at all. If I reverse the patch, subsequent modify calls work as expected.
We would appreciate an early response to the issue caused by the bug fix.
Created attachment 184455 [details] does not artificially reload the model when the changes are made from model API The fix will reduce the calls for artificial model reload. And thus call forced model reload only when the change is not made with model API. I have run the JSF and J2ee tests. The failing JSF tests are now passing. @Chuck - can you review the change.
switching flag
Committed and Released in HEAD and 3_2_Maintenance
