SSL erzwingen in einem Java Application Server

Morgen :-),
so langsam bin ich dabei alle meine Problem gelöst zu bekommen 🙂 – ja wird auch Zeit :-D.
Bezogen auf diesem Post:
Ich bin an der Implementierung mit JAAS noch dran, allerdings habe ich herausgefunden, dass man dem Server einen Filter unterschieben kann, der bei jedem Aufruf überprüft, ob eine SSL Verbindung besteht, und wenn dies nicht der Fall ist, diese per Redirect erzwingt.
Das ganze funktioniert über Filter (wie es ja Ruby on Rails auch macht).
Man erstellt sich eine Klasse, welche javax.servlet.Filter implementiert.
Diese bindet man dann per web.xml ein:

    <filter>
        <filter-name>SSLFilter</filter-name>
        <filter-class>de.hausswolff.cotodo.security.SSLFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>SSLFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

D.h. alle Anfragen, die an die Applikation gesendet werden, werden durch diesen Filter geschickt.
Der Filter im einzelnen vergleicht ob request.getScheme() == “https” ist. ansonsten redirected er einfach auf entsprechnede Seite.
In meinem Fall (da eine nicht-https Verbindung nur bei einem nicht angemeldeten Benutzer vorhanden ist auf eine Login-Seite)
Ich hoffe, dass ich morgen dann meine Anmeldung vervollständigen kann.
Für alle die sich noch näher mit den Feature von JEE 5 befassen wollen:
Unter http://java.sun.com/developer/releases/petstore/  kann man sich mit petstore eine Beispielanwendung herunterladen, die die Neuerungen (inkl. AJAX) demonstriert. Duke’s Bank scheint demnach nicht mehr genutzt zu werden 🙂

Upgrade – Downgrade – Löschen – Upgrade: Läuft

Mal wieder ne Stellungnahme:
Da ich u.a. eine Query machen möchte, ob zum Beispiel ein Benutzer mit einer bestimmten Email schon existiert, hatte ich bisher folgende URI zum Abfragen:
http://localhost:8080/cotodo/resources/users/like/?cat=email&val=Test@test.com/
Das lief auch wunderbar. Wen es interessiert, der Code dazu schaut so aus:

    @HttpMethod("GET")
    @UriTemplate("like/")
    @ProduceMime({"application/xml", "application/json"})
    public UsersConverter getLikeQuery(
            @QueryParam("val") @DefaultValue("") String val,
            @QueryParam("cat") @DefaultValue("email") String cat ) {
          try {
            return new UsersConverter(getEntitiesLike(cat, val), context.getAbsolute());
        } finally {
            PersistenceService.getInstance().close();
        }
    }

Allerdings wäre eine schönere URI ala

 http://localhost:8080/cotodo/resources/users/email/like/philipp@haussleiter.de/

denkbar.
Ich habe mich dann heute mal hingesetzt, um auf eine neuere JSR311 Version (Version 0.5) zu updaten. Eigentlich sollte so allmählich die Final kommen, aber nungut, man weiß ja nicht was für Fehler noch kommen mögen.
Kurzum: Es hat sich einiger geändert. Ist wohl das Problem, wenn man mit nicht spezifizierten Packeten arbeitet :-).
Hier mal ein paar Änderungen:
@HttpMethod ist verkürzt worden:
aus @HttpMethod(“GET”) wird @GET,
aus @HttpMethod(“POST”) wird @POST
usw.

getAbsolute() heißt nun getAbsolutePath(), ansonsten sind mir keine Änderungen aufgefallen.
Der URI Builder (eine statische Klasse, um URIs zusammen zu bauen) wurde umbenannt – was meiner Meinung nach einleuchtender ist nun:
Aus:

 Builder.created(context.getAbsolute().resolve(entity.getUserId() + "/")).build();

wird nun:

 Response.created(context.getAbsolutePath().resolve(entity.getUserId() + "/")).build();

Da in beiden Fällen der Rückgabewert vom Typ Response ist, ist letzteres einleuchtender.
Mit der neuen Version 0.5 ändert sich obige Methode folgendermaßen:

@GET
@Path("{cat}/like/{val}/")
@ProduceMime({"application/xml", "application/json"})

public UsersConverter getLikeQuery(
    @UriParam("val") @DefaultValue("") String val,
    @UriParam("cat") @DefaultValue("email") String cat
) {
    try {
        return new UsersConverter(getEntitiesLike(cat, val), context.getAbsolutePath());
    } finally {
        PersistenceService.getInstance().close();
    }
}

Und tut nun auch direkt was sie soll. Ein unschönes (weil sicherheitskritisches) Problem habe ich allerdings in der getEntitiesLike Methode:
Ich muss in den JPQL-Query-String die variabel cat direkt einfügen, über parameter scheint es nicht zu gehen (ist wohl wirklich nur für variable werte vorgesehen). Ich muss noch mal suchen, ob es eine Art SQL_escape methode gibt. Ich will ja nun keine SQL-Injektion hinauf beschwören.
Abschließen hat mich das Update einen guten Teil des Morgens gekostet.
Letztendlich war wohl eine Jar version von ASM (wird u.a. von maven2 benutzt, aber von glassfish benötigt) fehlerhaft.
Es kam andauernd:

java.lang.NoClassDefFoundError: org/objectweb/asm/ClassVisitor

Obwohl die Klasse definitiv im vorhandenen jar zu finden ist!
Letztendlich habe ich dann alle meine jars mal gelöscht und Schritt für Schritt neu hinzugefügt.
Es hat wohl tatsächlich etwas mit fehlerhaften Referenzen zu tun. Das gleiche Problem triff wohl auch bei der Benutztung von Hibernate auf.
Heute Abend, oder morgen schreibe ich dann noch etwas dazu, wie ich ein skizziertes HTML Formular per JS DOM Anweisungen erstelle.
Braucht ein wenig Übung, ist aber sauberer und schneller als sich Strings zusammen zu bauen und außerdem bleibt einem in Hinsicht auf AJAX und callback functions eh nichts anderes übrig.

1. GUI und die Sicherheit

Die letzte Zeit habe ich mehr mit Schreiben verbracht. Nachdem ein JavaScript-Unterbau soweit lauffähig ist, habe ich angefangen, meine GUI-Skizzen soweit wie möglich einzubauen:

Ich bin dazu übergangen, anstatt statischen HTML-Code als String zusammen zu bauen (was eh langsam ist), alle Inhalte aus DOM Objekte zusammen zu setzen. Das hat den großen Vorteil, dass ich Elemente auch im Nachhinein per JavaScript mit Hilfe von Callback-Funktionen verändern kann.

Bisher muss man den Benutzer noch “per Hand” abrufen. Ich hoffe, dass ich bald mit einem laufenden Login aufwarten kann, sodass dem Client quasi ein User gesetzt wird.

Hierbei bin ich jetzt davon weg, eine der eingebauten Funktionen von Tomcat/Glassfish zu nutzen. Letztendlich habe ich meine Benutzerdaten in meiner Datenbank und kann diese ja auch ohne weiteres überprüfen. Ich möchte also die Sicherheitsfragen von der Serverebene auf die Applikationsebene verschieben.

Ich habe nun zwei Probleme zu lösen:

  1. Alle Abfragen, die nicht über HTTPS laufen, sollen umgeleitet werden (klassischer Redirekt) – wenn möglich könnte ich das noch nach Mime Type filtern (weil z.B. Bilder und CSS/JS ruhig über normales HTTP laufen können).Es gibt dafür die Methode response.isSecure(). Ich habe jetzt aber mehrmals gelesen, dass man das tunlichst nicht mit einem Scriptlet in JSP machen soll, sondern das ganze über ein Servlet abhandeln sollte. Es wäre ja auch notwendig, die alte Anfrage so um zubauen, dass der Inhalt (welche Datei angefragt wird), gleich bleibt, aber der Empänger auf SSL gelenkt wird. (und ggf. auf einen anderen Port).
  2. Es soll vor jeder Anfrage geprüft werden, ob die SSL-Verbindung einem angemeldeten Benutzer gehört. So dies nicht der Fall ist, soll auf eine Loginseite weitergeleitet werden.

Beide Probleme haben gemeinsam, dass die Überprüfung(en) abgehandelt werden müssen, bevor überhaupt etwas anderes passiert.

Ich hatte jetzt überlegt, dass ich ein Servlet einfach auf /* mappe – also ALLE Anfragen an die Applikation über dieses Servlet laufen.

Ich muss jetzt nur rausfinden, wie ich die “guten” Anfragen (die, von eine autorisierten User) an geeignete Stelle weiterleite.

Dazu müsste ich ja u.a. direkt mein Servlet aufrufen, welches für Jersey/REST meine Anfragen abhandelt. Ein HTTP-konformes Redirect würde ja irgendwie eine Endlosschleife verursachen. Ich lese grade EJB3 in Action und bin auch schon auf ein paar interessante Stellen gestoßen. Was fehlt ist einfach noch der “Aha-Effekt”.
Nachbemerkung zu JavaScript:

Durch die ganzen – notwendigen – Callbacks und die Nutzung von DOM-Komponenten, kommt es mir langsam vor, als würde ich Java programmieren. Letztendlich sehr zweischneidig:

  1. Man hat Schemata, die funktionieren (weil aus Java bekannt)
  2. JavaScript verliert so ein bisschen den Charme einer leichten und schnellen Scriptsprache.

Sicherheit über JAAS mit einer MySQL Datenbank

Ich gebe zu, ich habe es lang vor mir her geschoben:

Neben all der schönen REST-fähigen Implementierung, ist Sicherheit ein Bereich, der bisher ein wenig zu kurz kam. Zwar habe ich schon eine schöne Möglichkeit gefunden, wie man mit YUI eine Anmeldung über HTTP AUTH hin bekommt, aber letztendlich fehlt(e) bisher die komplette Serverseite.

Ich habe jetzt einiger Zeit gesucht und bin zu dem Ergebnis gekommen, dass mir der Java Application Server (sei es Tomcat, Glassfish o.a.) bereits mehrere JAAS basierte Module zur Verfügung stellt.
Diese Entscheidung traf ich (da es hierbei sicherlich auch Einschränkungen einzugehen gilt) u.a. nach dem Lesen dieses Artikels.

Darin wird einem abgeraten, eine Logion/Session Verwaltung in Eigenregie zu erstellen, da hierdurch teilweise ein Sicherheitsrisiko eingegangen wird.

Nach weitere Suche kam ich zu einem interessanten Artikel von Shing Wai Chan, in dem er die Einrichtung eines JDBCRealm auf einem GlassFish Server beschreibt. Bis auf das die Standard digest-Algorithmen auf den verschiedenen Application Servern unterschiedlich sind, sollte dies unter den verschiedenen Systemen lauffähig sein.

Aufgrund der Übersichtlichkeit und da ich ungern Systeme in meinen Datentabellen herumfuhrwerken lasse, habe ich mir für die entsprechend benötigten Tabellen 2 Views angelegt:

CREATE ALGORITHM = TEMPTABLE VIEW usertable AS
SELECT u.email AS userid, u.password
FROM Users u
CREATE  ALGORITHM = TEMPTABLE VIEW grouptable AS
SELECT u.email AS userid, g.name
FROM Groups g, Users u, UsersGroups us
WHERE us.user_id = u.user_id
AND g.group_id = us.group_id

Damit kann ich weiterhin sicher sein, dass der Server auch tatsächlich auf die Standard-Variablen zugreifen kann. Natürlich bin ich damit den Nachteil eingegangen, dass ein Benutzer hier nur in einer Gruppe sein kann.
Ich denke aber, dass dies zu verkraften ist, da es sich hierbei nur um den Login handelt und hierbei eigentlich nur interessant ist, ob der Benutzer als Admin oder als User angemeldet wird.
Als Standardgruppen sind in der Datenbank admins und users gesetzt.
So habe ich in meiner Config-Datei (sun-web.xml) folgende Zeilen eingefügt:

<security-role-mapping>
    <role-name>cotodo-admin-login</role-name>
    <principal-name class-name="Users">admin</principal-name>
    <group-name>admins</group-name>
</security-role-mapping>
<security-role-mapping>
    <role-name>cotodo-user-login</role-name>
    <principal-name class-name="Users">admin</principal-name>
    <group-name>users</group-name>
</security-role-mapping>

Also Session Methode werde ich mich dann wohl für eine Cookie basierte Session entscheiden, weil eine URL-encodierte Session die schönen REST-URIs verschandeln würde und dadurch auch den Austausch mit YUI erschweren mag.
Meine beiden letzten Punkte auf der Agenda (die ich diese Jahr noch durch bekommen will (!!!), sind folgende:

  1. Wie gehe ich sicher dass ein User umgeleitet wird, wenn er eine ungültige Session hat und sich einen XML-Resource Stream besorgt? (letztendlich wird es da sicherlich entsprechende Methoden geben, welche vor allen anderen Aufrufen prüfen können, ob Autorisierung und Authentisierung korrekt sind.
  2. HTTPS. Es war erstaunlich einfach, dem Server klar zu machen, dass ich gerne HTTPS benutzen möchte (einfach andere URL :-)) .

Allerdings sollte man nun sicher sein dass:

  1. Alle Anfragen auf HTTP geblockt werden (oder noch besser: auf eine Login-Seite umgeleitet werden)
  2. Sicher gestellt wird, dass sich ein User nur über eine SSL Verbindung anmelden kann (sicherlich auch durch eine Weiterleitung möglich)

Abbilden der Relationen

Nachdem ich alle notwendigen Relationen in der Datenbank abgebildet habe, habe ich jetzt meine Annotations zwischen den Objekten fertig gestellt.
Es gibt ein paar interessante Dinge, so zum Beispiel eine rekursive Relation innerhalb von 2 Tasks (Aufgaben). Das heißt, eine Aufgabe kann n Unteraufgaben haben.


Weiterhin enthält jede Aufgaben ein Array von Empfängern und einen Sender.
Ich sehe grade, dass müsste in dem Fall kein Array sein.
Also ist das eine ManyToOne/OneToMany Beziehung. Werde ich dann noch ändern.

Ich war natürlich wieder einmal vorschnell. Hatte ich ja nicht etwas falsch gemacht
(sowas mache ich ja nicht :D), sondern schlicht etwas vergessen. ich spare mir jetzt
mal, die neuen UMLs hoch zu laden ;-). Letztendlich war die eine ManyToMany
Beziehung zwischen Users und Tasks natürlich die Leute, die Tasks an andere User
weiter delegieren. Das können ja pro Task n sein. Hat alles seine Richtigkeit. Die Welt
steht noch und ich gehe schlafen ^^. Was fehlte war einfach eine
OneToMany/ManyToOne Beziehung zwischen Tasks und Users!
Als letztes kann eine Gruppe (nun habe ich so doch mit rein genommen) 1 bis n Benutzer haben. Genauso kann ein Benutzer in 1 bis n Gruppen sein.
Eine Gruppe wird immer neu erstellt und entsprechender Benutzer hineingepackt, wenn eine Aufgabe mit einem Projekt-Flag (dazu später mehr) zu entsprechendem Benutzer zu geordnet wird. D.h. wenn besagter Benutzer Ersteller oder Verantwortlicher der Aufgabe (und deren Unteraufgaben) ist.
Hier mal das UML der Entitäten:

Wenn Interesse daran besteht, wie man die Abbildung im Einzelnen (im Code) abbildet, kann ich dazu auch noch etwas schreiben.
Und abschließend noch mal eine Übersicht aller Klassen, die ich bislang so habe.
Hierbei steht das E für Entität. Ein S steht für eine Systemklasse. Ein R für eine Klasse für eine einzelne REST Resource und eine R# für eine Resourcenliste.

Gedanken zu EJB3, meiner Welt und Diagrammen

Hello world!
Nachdem ich mit Gerald am vergangen Freitag Abend mich ein wenig ausgetauscht habe und wir über die unsere Ansätze in der Erstellung einer EJB3 JEE Anwendung gesprochen hatten, kamen mir doch schon ein wenig Zweifel, ob denn meine Anwendung nun vollständig rechtfertigt, ein EJB im Titel meiner Arbeit zu führen :-).
Nachdem ich mir dann noch ein mal das Buch über EJB2 und JPA (in dem leider die Konzentration arg auf JPA liegt) zur Brust genommen habe (kann man das bei Büchern so sagen?). Und auch noch mal die EJB3 Specs von Sun (das war übrigens mal JSR220) sowie eine recht gute Zusammenfassung und ein paar Tutorials (u.a. dieses hierangesehen habe, bin ich der Meinung, dass meine bisherigen Bemühungen definitiv in die richtige Richtung gingen (ist doch auch mal schön sowas).
Noch dazu weiß ich nun, dass ich JPA mit Annotation und einer Stateless Session Bean benutzen möchte. (Das Stateless resultiert einzig und alleine aus dem REST Ansatz). Dementsprechend kam mir die Idee, in meiner Arbeit auch definitiv ein paar Sequenzdiagramme benutzen möchte – da Zustandsdiagramme mir – zumindest momentan – eher witzlos erscheinen.
Als weiteren Punkt habe ich aus dem Treffen mitgenommen (sind heute irgendwie lauter Ratgeber-Formulierungen), mir endlich mal eine Gesamtübersicht über meine Funktionen zu erstellen. Da zu einem ordentlichen UseCase auch eine Beschreibung gehört (so habe ich es zumindest gelernt), poste ist jetzt hier erstmal zwei Diagramme unter Vorbehalt (der Beschreibungsteil ist noch in Arbeit und das Packet geht dann alsbald auf Tour, ganz ehrlich Phillip).
Ich habe mich dafür entschieden, jeweils zwei Diagramme, jeweils für den Bereich Aufgaben und für den Bereich Benutzer(-verwaltung) zu erstellen:

  1. Benutzer UseCase(s)

  2. Aufgaben UseCase(s)

Wie schon erwähnt: Die Beschreibungen der einzelnen Cases ist zum größten Teil fertig, da mit aber bis grad noch Dinge einfielen, die noch nicht durch die existierenden UseCases abgedeckt sind, möchte ich noch mal mindestens eine Nacht drüber schlafen. Auch ob ich nicht doch die Möglichkeit für verschiedene Benutzergruppen einbauen möchte schwebt mir noch im Kopf herum. Es wäre im Moment noch eine kleinere Änderung in der Datenbank und würde am Code bisher noch nicht wirkliche viele Umbauten nötig machen.


Offtopic:
Meinen Router habe ich jetzt mal bei Ebay rein gesetzt. Mal schaun was da so rauskommt.
Weiterhin habe ich mich mal mit dem Programm Flock vertraut gemacht. Das basiert auf der Firefox Engine und ist perfekt geeignet, wenn man Dinge bloggen möchte, wenn man Feeds vernüftig lesen will (und interessanten daraus bloggen will) und um Bilder von FlickR oder Videos von Youtube sehen möchte (und interessanten daraus bloggen will ^^). Weil irgendwie stehe ich mit dem Editor hier noch auf Kriegsfuß. Das Programm ist recht gut, funktioniert auch tadellos mit meinem – privaten – WordPress-basiertem Blog, hat allerdings so seine Probleme mit MovableType wie es scheint. Ich bilde mir zwar ein, dass die RPC Schnittstelle richtig ist, aber laufen wills dennoch nicht. Vielleicht nutzt das ja jemand auch und hat es geschafft, Flock zu überreden, auf dieser Blog-Software auch tätig zu werden :-).

[PP] ProblemPost

Soooo da das ja bei den Benutzern schon so wunderbar klappt, hier dann mal meine Probleme:
Wie in einem der letzten Posts erwähnt, möchte ich gerne eine Abhängigkeit meiner Entries untereinander haben. Das heißt, ich möchte unter einem Eintrag n Untereinträge haben. Das Klassendiagramm schaut dann so aus:

Meine Tabelle sieht so aus:

Ja eigentlich recht simpel. Nun bietet JPA im Rahmen von Annotation genau eine solche OneToMany Beziehung an.

@OneToMany(cascade=CascadeType.REMOVE)
private List _child_entries = new Vector();

In dieser Liste würden dann alle Kinder des Eintrages stehen.
Da ich mal einfach annehme, dass es unnötig ist, auf DB Ebene noch Foreign Keys zu erstellen, hoffe ich einfach mal, dass das so laufen wird.
Weiterhin habe ich eine Relations Tabelle, die mir die Benutzter mit den Einträgen verbindet und auch sicherstellt, dass n Benutzer für einen Eintrag zuständig sein können:

Hier beginnt es nun problematisch zu werden.
Okay es gibt in dem EJB Buch eine Beschreibung wie man ManyToMany Beziehungen modelliert, allerdings habe ich hier ja auch ein Attribut “status”, welches ja an sich nichts mit der Relation zu tun hat, allerdings schon logisch von dieser Abhängt.
Es würde sich meiner Meinung nach anbieten, dieses als seperates Objekt zu machen.
Ich habe mir das erstmal durch Netbeans generieren lassen. Es ist nun zugegebenermaßen etwas sperrig (weil Netbeans eine eigene PrimaryKey Class drum generieren will, damit sichergestellt ist, dass bei Neuerstellung alle notwendigen Schlüssel belegt sind), allerdings denke ich, dass es eine hinreichende Funktionalität bietet, um erst einmal weiter zu arbeiten.
Kommen wir nun zum Highlight :-/.
Es geht darum, dass die JDBC Anbindung von MySQL seltsamerweise Schwierigkeiten mit Daten zu haben scheint. Siehe dazu auch MySQL Bug #19274.
Ich werde jetzt mal versuchen, eine aktuelle Version zu installieren, die das Problem nicht mehr haben soll. Es geht halt nur darum, dass MySQL mit leeren Datumsangaben (ala 0000-00-00 00:00:00) nichts anfangen kann und eine exception wirft. Das ist in sofern ja nicht schlimm, als das ich einfach einen Eintrag erstellt habe und dann mal hoffe, dass ich damit den Fehler vermeide.
Ich fand weiterhin eine interessante Übersicht, wie JDBC die DB Attribute nach Java überführt:


aus Sun Java System Application Server 9.1 Developer’s Guide

Zu guter Letzte suche ich eine Möglichkeit, um einen klassischen HTTP Redirect (Status 303/301 usw.) Mit der Jersey Umgebung hin bekomme. Es gibt dazu sogar eine Diskussion in dem Blog von Angry Bill unter JSR 311, JAX-RS: Comment and suggestions. Ich fände eine Lösung mit einer @Location Annotation sehr gut. Bisher fand ich nur folgende Lösung, welche ich aber bisher noch nicht ausgiebig testen konnte:
Philosophical content negotiation aus dem Blog von Paul Sandoz (da steht jede Menge zu REST und JSR311 drin)
Abschließend noch eine Bemerkung zu der letzten Diskussion über die Queries.
Im REST-Test von Sun werden u.a. die Pagination-Settings an die URL angehängt also gibt es dann in etwas folgendes als Aufruf:

Request: GET http://localhost:8080/cotodo/resources/users/start=0&max=10&timestamp=1196991596495

Irgendwie schaut das schon wesentlich unübersichtlicher aus. Aber letztendlich muss ich mich eh noch damit befassen, wie ich die Parameter aus der URI extrahiere. Da ich nicht annehme, dass sich die beiden Möglichkeiten großartig unterscheiden werden, kann man sich ja direkt gleich mit der richtigen Lösung befassen.
Ein Problem was ich sehe, ist allerdings die Eindeutigkeit der Parameter, weil diese ja bei steigender Anzahl einen größeren Teil der URI bilden dürften.
Letztendlich ist es aber das gleich Problem wie bei allen Methodenaufrufen, bei denen man anhand eines Aufrufes auch nicht ohne weiteres sagen kann, wofür welcher Wert nun wirklich steht.

Resource User

Ich bin mittlerweile soweit, dass mir ein
Request: GET http://localhost:8080/cotodo/resources/users
eine Liste ala

<users>
    <user>3</user>
    <user>52</user>
    <user>53</user>
</user>

zurück gibt.
Das gleiche ist auch als JSON Format möglich.
Ein Post von
Test31testtest
wird mit einem status 200 (okay) quittiert.
Der erstellte User sieht dann so aus:

<user>
    <name>Test31</name>
    <hash>5a671c66aefea124cc08b76ea6d30bb</hash>
    <id>54</id>
</user>

(Die ID wird automatisch generiert, das Passwort wird im User Objekt per md5 gehashed)
Soweit die guten Nachrichten… alle meine aktuellen Probleme kommen gleich 🙁

kurzes Statement

Jetzt wo es an die Listen geht:
ist so etwas REST konform?

http://localhost/users?q=sonne

Immerhin müsste ein Listenabruf ja per GET erfolgen, also kann man die query nicht per POST übermitteln.


Was anderes am Rande:
ich bin in der seltsamen Situation, einen Draytek Vigor 2930 VS hier zu haben und ihn nicht zu brauchen…. Was der alles kann (außer Wlan – das was ich eigentlich brauche) steht auf der Produktseite bei Draytek.. Ich wollte mal fragen ob den jemand haben will. Im Moment liegt der Preis bei so 300 EUR. Wenn nicht, dann stelle ich den einfach bei Ebay rein :-).

letzter Stand

Nachdem ich nun meine JRA jar habe und auch die restlet jar habe (Ich denke mir einfach mal, dass die vorausgesetzt wird).
Habe ich mir nun eine einfache Klasse geschrieben (okay sie ist geklaut, aber ich will ja erstmal testen, wie was geht ^^):

package de.hausswolff.cotodo.test;
import java.util.List;
import org.codehaus.jra.*;
@HttpResource(location="/customers")
public class Customers {
    private List registry;

    public Customers(){
        this.registry.add(new Customer("bob"));
        this.registry.add(new Customer("alice"));
        this.registry.add(new Customer("carol"));
        this.registry.add(new Customer("dave"));
    }
   
    @Get
    List get(){
        return registry;
    }

    @Post
    void add(Customer customer){
    }
}

Okay… die Klasse wird anstandslos kompiliert und auch Eclipse kennt alle Annotation (dient wahrscheinlich nur zu meiner Beruhigung, sagt es mir doch, dass die jar richtig eingebunden ist 😀 ).
Was ich mich jetzt allerdings frage ist, wie ich das schöne Teil nun einbinde.
Da es ja von Aufbau her nicht wirkliche eine Bean ist.
Ich habe versuchsweise in der web.xml folgendes eingefügt:

<servlet>
    <servlet-name>JRACustomers</servlet-name>
    <servlet-class>de.hausswolff.cotodo.test.Customers</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>JRACustomers</servlet-name>
    <url-pattern>/customers*</url-pattern>
</servlet-mapping>

Allerdings half das auch nicht. Unter /customers ist nix :-(. Ich werde mich damit morgen in aller Ruhe noch mal befassen.
Als weiter Möglichkeit, dachte ich mir, dass ich die Class per jsp useBean Tag einbinden kann, aber ist ja auch keine wirkliche Bean. Ich hoffe, dass ich da morgen weiter mit komme. Im Netz fand sich bisher auch nix. Und auf der JRA Page wird nur nach paranamer verwiesen. Was das nun schon wieder ist, werd ich mir morgen/gleich mal anlesen.