| 

.NET C# Java Javascript Exception

Wicket + Groovy

Dies ist das Archiv des ehemaligen Forums zum Thema Groovy, Grails, Griffon und Bean Scripting Framework, welches unter groovy-forum.de existierte. Die neue Adresse des Groovy-Forums ist: http://codekicker.de/fragen/themen/groovy.


Wicket + Groovy

wilhelm.nagy@bfw.gv.at - 09.02.2010 10:11
Hallo Leute,

ich habe mir ein Wicket Buch gekauft.

Das ganze Konzept gefällt mir.

Ich möchte gerne Wicket mit groovy programmieren (genaugenommen groovy Skripte)

1) hat jemand Erfahrungen damit gemacht?
2) mag sich jemand an dem Forschungsprojekt beteiligen?

\^/ili
(Wilhelm Nagy)


Re: Wicket + Groovy

christian - 09.02.2010 10:46
Ich denke in diesem Bereich wird oft die Bedeutung der Öffentlichkeitsarbeit unterschätzt. Jedes etwas umfangreichere Projekt sollte eine ordentliche Website haben, auf der die Vorteile und die Nutzung erklärt werden. Da Programmierer aber lieber Code als Prosa schreiben, sieht es da oft ziemlich mager aus und dann bleiben die Interessenten aus und irgendwann verlieren auch die Initiatoren das Interesse. Es gab auch mal einen Ansatz Wicket und Scala zu kombinieren, aber auch da ist nicht viel bei heraus gekommen.

Gruß
Christian


Re: Wicket + Groovy

manfred - 11.02.2010 09:13
Ok:
In web.xml brauchst Du:
<filter>
    <filter-name>wicket.HelloWorldApp</filter-name>
     <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
    <init-param>
        <param-name>applicationClassName</param-name>
        <param-value>test.HelloWorldApplication</param-value>
     </init-param>
    <init-param>
        <param-name>configuration</param-name>
        <param-value>development</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>wicket.HelloWorldApp</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

dann eine HTML Seite:
Language: HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:wicket="http://wicket.apache.org/" xml:lang="en" lang="en"> <head> <title> Hello World </title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> <span wicket:id="HelloWorldLabel">[hier wird text ersetzt]</span> </body> </html>

Und dann die Companion Seite in Java, Groovy oder Scala:
Language: Groovy
class HelloWorldPage extends WebPage &#123; HelloWorldPage&#40;&#41; &#123; add&#40;new Label&#40;"HelloWorldLabel", "Hello World"&#41;&#41; &#125; &#125;

Und am Schluss noch die Application Subclass:
Language: Groovy
class HelloWorldApplication extends WebApplication &#123; public Class getHomePage&#40;&#41; &#123; return HelloWorldPage.class &#125; &#125;

Das sollte eigentlich funktionieren.
Wobei hier nicht viel Groovy spezifisches drin ist.


Gruss,
Manfred


Re: Wicket + Groovy

manfred - 11.02.2010 10:18
christian schrieb:
-------------------------------------------------------
> Und wie ist deine Erfahrung mit der neuen Technik?
> Was gab es für Probleme? Was ist beim alten Ansatz
> besser oder schlechter gewesen?

Nuja. Erstmal vorweg, mich interessieren Technologien und Computer-Sprachen. Das war wahrscheinlich mit einer der Hauptgründe für den Umbau.
Der Wechsel von JDO auf JPA kommt erstens dadurch dass EJB3/3.1 nur JPA unterstützt. Zweitens ist JDO zwar lange nicht tot, aber JPA wird sich über kurz oder lang eher durchsetzen und dann schadet ein bisschen Erfahrung damit sicherlich nicht.
Zwei unterschiede diesbezüglich sind mir auf gefallen:
1. JPA unterscheidet zwischen persist() und merge(). persist() wird benutzt um neue Objekte zu persistieren, merge() wird benutzt um Änderungen an einem persistenten Objekt zu schreiben und um ein Objekt das "detached" ist wieder zu "attachen".
Bei JDO gibts nur ein makePersistent(), das vereint beide Methoden von JPA.
Ich hab in einem Blog gelesen, das merge() eigentlich selbst rausfinden sollte, ob ein Objekt bereits persistent ist oder nicht und entsprechend handeln, sodass ein persist() nicht umbedingt nötig ist. Hat aber bei mir nicht funktioniert.
2. Das result set bei einem Query war bei JDO einfach ein Objekt der Klasse Object und man musste es entsprechend casten, bei JPA ist es eine "generisierte" Liste.
Für das, was ich brauche an Persistenz machen beide Ihren Job gut. JDO hat sicherlich Vorteile wenn man nicht in eine DB persistieren will sondern nach XML oder so da JDO nicht DBMS spezifisch ist.

Vorher hatte ich sowas ähnliches wie eine Stateless Session Bean als persistenz Service, davon gab es dann pro HTTP Session jeweils ein Objekt. Das Transaktions-Management musste ich selbst gemacht.
Mit EJB3.1 macht das Transaktions-Management nun der Container und erstellt das Session Bean nach bedarf, welches nun nicht mehr zwingend an die HTTP Session gekoppelt ist.
Mehrere Tage hat mich hier die Dependency-Injection gekostet bzw. das Session Bean brauche ich ja in den View/Wicket Page Klassen bzw. dort wo die Daten-Views generiert werden.
DI in JavaEE6 funktioniert nur in "Managed" Objekten, das sind Servlets, JSF beans usw. In anderen Objekten, wie z.B. Wicket Klassen funktioniert das nicht und man muss hier leider mit JNDI gefrikel anfangen und sich das Session Bean selbst holen - was mich ziemlich frustriert hat, da es Anfangs einfach nicht funktioniert hatte.
Um dann doch DI zu haben mache ich das nun per Google Guice. Funktioniert soweit ganz OK.
BTW: da bin ich auf interessante Dinge bezüglich Dependency-Injection mit Scala gestoßen: DI mit Scala

Das ganze EJB3 gedöns macht nun einen richtigen JavaEE Stack notwendig (naja ginge wohl auch mit OpenEJB in Tomcat). Aber gerne hab ich mit GlassFish angeschaut und bin soweit auch echt zufrieden damit. GlassFish unterstützt auch Apache's mod_jk bringt eine Derby Datenbank, die Administrations-Console ist gut gelungen und Performant ist er auch noch - der GlassFish.
Von GlassFish bin ich wirklich angenehm überrascht. Weit weniger stöpselei als mit Tomcat.

Soweit war das mein erster Kontakt mit "richtigem" JavaEE. Bisher hatte ich ja mehr oder minder nur mit Servlets und JSP zu tun.
Es gibt sicherlich noch einiges zu tun an den Spezifikationen. Was ich so gelesen hab ist aber JavaEE5/6 um Welten einfacher als J2EE.
Zwecks der Probleme mit DI hab ich mir Spring auch mal näher angeschaut und muss gestehen das Spring wohl noch das bessere und vor allem komplettere JavaEE ist. DI ist durchgängig in POJOs zu haben. Persistenz gibts für eine ganze reihe an Providern (JDO, JPA, Hibernate, ...) und das ganze läuft auch in einem Container wie Tomcat oder Jetty.

Alles in allem muss ich sagen das mein alter Ansatz auch in Ordnung war. Das Transaktions-Management ist nun so dramatisch auch wieder nicht. Für kleinere Projekte kann man das sicherlich selbst machen. Bei Gross-Projekten, für welche JavaEE ja gedacht ist, ist es sicherlich gut das nicht selbst machen zu müssen und es dem Container zu überlassen.
Auch hatte ich weniger Abhängigkeiten.


Ich denke das war soweit erstmal.

Gruss,
Manfred


Wicket und Java EE

christian - 11.02.2010 10:44
Hallo Manfred,

danke für deinen interessanten Erfahrungsbericht.

> 1. JPA unterscheidet zwischen persist() und
> merge(). [...]
> Ich hab in einem Blog gelesen, das merge()
> eigentlich selbst rausfinden sollte, ob ein Objekt
> bereits persistent ist oder nicht und entsprechend
> handeln, sodass ein persist() nicht umbedingt
> nötig ist. Hat aber bei mir nicht funktioniert.

Von dieser Theorie habe ich auch gehört, hat bei mir aber auch nicht funktioniert.

> DI in JavaEE6 funktioniert nur in "Managed"
> Objekten,

DI funktioniert prinzipbedingt immer nur mit Objekten, die von dem DI-Mechanismus verwaltet werden - das ist bei Guice und Spring genauso. In Java EE kann prinzipiell jedes Objekt zu einem verwalteten Objekt werden und DI nutzen. Siehe JSR 299 Contexts and Dependency Injection (CDI). JBoss Weld ist die Referenzimplementierung, die auch eine gute Doku hat.

> Zwecks der Probleme mit DI hab ich mir Spring auch
> mal näher angeschaut und muss gestehen das Spring
> wohl noch das bessere und vor allem komplettere
> JavaEE ist.

Spring ist eher ein Baukasten mit dem man sich alles von Hand zusammen suchen kann bzw. muss. Mir gefällt zwar auch, dass die beiden Grundprinzipien DI und AOP einfach durchgängig und einheitlich auf alles angewendet werden, aber die Spring-Konfiguration finde ich total ätzend! Den XML-Ansatz ohne Typsicherheit finde ich grundverkehrt. Mit der Spring Expression Language verschlimmern sie das eher noch. Die Spring-Konfiguration ist schrecklich aufgeblasen und umständlich. Es gibt zwar auch eine Java-Konfiguration für Spring, aber die ist auch nicht gerade state-of-the-art und endet außerdem wenn man weitere Module wie Spring Security verwenden will.

Gruß
Christian


Re: Wicket und Java EE

manfred - 16.02.2010 00:35
christian schrieb:
-------------------------------------------------------
> manfred schrieb:
>
> > Bei Beiden wird OpenJPA verwendet.
> > Provider in persistence.xml wurde explizit auf
> > OpenJPA gesetzt.
>
> Ok, das hatte ich nicht erwartet, weil in
> GlassFish EclipseLink verwendet wird.

EclipseLink, ist das nun die OpenSource Variante von TopLink?
EclipseLink hat enorm Probleme bei "RESOURCE_LOCAL" bereitet, deswegen bin ich auf OpenJPA umgestiegen, Dort hats auf Anhieb funktioniert.
Ich hätte auch recherchieren können, hatte aber, da mir Eclipse eh unsympathisch ist wenig Probleme beim Umstieg. :)
Ob nun JPA2 oder 1 macht bei dieser konkreten Anwendung keinen Unterschied. Ist JPA 2 eigentlich schneller?

> > > Und wie sieht die
> > > Verwaltung der EntityManager bei der
> > > Nicht-Container-Lösung aus? Ist das
> > > Cluster-tauglich? Wird das
> >
> > Ein EntityManager pro HTTP Session.
> > An Cluster-Tauglichkeit hab ich nicht im
> > Entferntesten gedacht.
> > Mit einem EntityManager pro Session sollte es
> das
> > aber sein.
>
> Ich wollte darauf hinaus, dass dieser Mechanismus
> bei EJB und einem Servlet-basierten Ansatz etwas
> anders aussieht und eben nur für ein bestimmtes
> Szenario direkt vergleichbar ist.

Meinst Du dass eine HTTP Session bei einem Servlet-basierten Ansatz wenig mit dem Session Management bei EJB zu tun hat?
Trotzdem gibt es da ja einen Zusammenhang denn die EJB Session Objekte werden ja aus den User Sessions heraus benutzt.
Bei meinem konkreten Test fehlt eben einmal das EJB Session Management und einmal ist es da.
Vergleichbar ist das denke ich schon, und der Unterschied ist sicherlich messbar.

> > Aber da die Bibliotheken die gleichen sind
> > (Datenbank, JPA), zweifel ich da jetzt
> eigentlich
> > nicht so an der Aussagekraft.
>
> Performance-Tests sind ein extrem schwieriges
> Thema, wo man oft ganz andere Sachen testet als
> man glaubt. Aber das sind jetzt eher
> grundsätzliche Überlegungen und weniger konkrete
> Zweifel an deinem Test.

Stimmt, schwieriges Thema. Meine Diplomarbeit ging über Performance Tests. Übrigens auch über Java in einem eingebetteten System,
Ist aber schon ne ganze weile her.


Gruss,
Manfred


Re: Wicket und Java EE

manfred - 16.02.2010 09:02
Übrigens, hätte eigentlich direkt erwähnt gehört:
Die Tests liefen als Unit-Tests ab.
Ohne EJB Container wurde der Service-Klasse, die sonst EJB ist, der EntityManager manuell eingeschoben.
Als EJB Container wurde der embedded EJBContainer von GlassFish verwendet.


Stelle deine Groovy-Frage jetzt!


Diese Seite zeigt den Thread "Wicket + Groovy" der ehemaligen Webseite groovy-forum.de, welche durch einen Serverunfall zerstört wurde. codekicker.de hat viele Konversationen über die beliebte Programmiersprache Groovy und zugehörige Frameworks wie das Grails-Framework retten können.

Hast Du eine Frage zum Thema Groovy, Grails oder allgemein Java? Viele ehemalige groovy-forum.de Mitglieder beantworten dir auf codekicker.de deine Frage! Stelle jetzt eine Frage!

Viele weitere Diskussionen zu Grails und Groovy befinden sich auf der Threadübersicht des alten groovy-forum.de.