Nach SVN-Update alle Beans resolved to null

[JustinSane]

Hallo!

arbeiten jetzt schon seit einigen Wochen ohne Probleme zusammen am selben Subversion Repository ohne Probleme. Jedoch ist seit dem letzten Update, bei dem es zu mehreren Konflikten kam, jede Sessionbean (Named-Annotation) immer null (target unreachable, resolved to null).

Haben jetzt mittlerweile schon alles versucht - Repository komplett gelöscht, Projekte komplett gelöscht und lokale Kopie zurückgespielt. Bei dem Rechner an dem die lokale Kopie erstellt wurde, funktioniert auch alles ohne Probleme, jedoch sobald man irgendwo anders das Projekt auschecken will, sind alle Beans null.

Hoffe ihr habt irgend eine Idee wie man dieses Problem vielleicht lösen könnte!

arbeiten mit Glassfish server 2.3.2 und Netbeans 7.1.2

Warnung: StandardWrapperValve[Faces Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw exception
javax.el.PropertyNotFoundException: /pages/cilab/home.xhtml @54,53 value="#{recipeController.allRecipes}": Target Unreachable, identifier 'recipeController' resolved to null
	at com.sun.faces.facelets.el.TagValueExpression.getType(TagValueExpression.java:100)
	at org.primefaces.component.api.UIData.isLazyLoading(UIData.java:170)
	at org.primefaces.component.datatable.DataTableRenderer.encodeMarkup(DataTableRenderer.java:187)
	at org.primefaces.component.datatable.DataTableRenderer.encodeEnd(DataTableRenderer.java:107)
	at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875)
	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1764)
	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1760)
	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1760)
	at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:402)
	at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288)
	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
	at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
	at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
	at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
	at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
	at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
	at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
	at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
	at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
	at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
	at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
	at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
	at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
	at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
	at java.lang.Thread.run(Thread.java:722)

 

[maki]

Hoffe ihr habt irgend eine Idee wie man dieses Problem vielleicht lösen könnte!

Zu den Grundlagen von Subversion gehört auch, dass weiss wie man den letzten Commit "rückgängig" macht, dafür gibt es mehrere Wege, zB. ein Reverse Merge, oder die letzte funktionierende Revision auf den Head kopieren, etc. pp.

Grundsätzlich ist es ja so, dass die Probleme durch den Merge verursacht wurden, die Fehler also manuell eingebaut wurden, das solltest du korrigieren. Wie genau kann dir hier keiner sagen, nur du weisst (hoffentlich) was du gemacht hast.

 

[JustinSane]

ja, das sollte man wissen, und das wissen wir natürlich auch! Haben bereits alles versucht, revert, neuerliches Update, komplettes Löschen des gesamten Repositories usw. Jedoch hat nichts geholfen!

Das Problem existiert scheinbar unabhängig von der Applikation. Haben ja bereits ein altes Backup, das damals ohne Probleme zu verteilen ging wieder zurückgespielt. Jedoch ebenfalls mit dem selben Effekt - die Beans werden nie initialisiert...

 

[maki]

Ein Revert ist nicht dasselbe wie ein Reverse Merge, klöschen des Repos bringt rein gar nix, trial & error sind nicht immer die beste vorgehensweise, wenn ihr die alte funktikonierende Revision wieder hergestellt hättet, wäre das eben die alte funktionierende Revision gewesen...

Ansonsten würde ich an deiner Stelle entweder die alte, funktionerende Revision wieder herstellen, oder die Fehler in der aktuellen korrigieren, mehr als das offensichtliche kann man hier nicht empfehlen IMHO.

Nebenbei, mit autom. Tests und einem CI Sever kann man solche Probleme sehr schnell erkennen und dann weiss man noch eher was man gerade geändert hat.