org.jboss.weld.exceptions.UnproxyableResolutionException wegen Parametern im Superclass-Kontruktor

Dieses Thema org.jboss.weld.exceptions.UnproxyableResolutionException wegen Parametern im Superclass-Kontruktor im Forum "Application Tier" wurde erstellt von moonermo, 18. Sep. 2012.

Thema: org.jboss.weld.exceptions.UnproxyableResolutionException wegen Parametern im Superclass-Kontruktor Hallo Leute, ich habe ein kleines Problem mit einer Exception: SEVERE: Exception while loading the app SEVERE:...

  1. Hallo Leute, ich habe ein kleines Problem mit einer Exception:
    Code (Java):
     
    Folgende Klassen sollten eine Rolle spielen:
    Code (Java):
    public abstract class AbstractService<T> implements AbstractServiceInterface<T>{
        protected final Class<T> persistentClass;
       
        @PersistenceContext
        protected EntityManager em;
       
        public AbstractService(Class<T> persistentClass){
            this.persistentClass = persistentClass;
        }

        @Override
        public void create(T entity) {
            em.persist(entity);
        }

        @Override
        public T update(T entity) {
            return em.merge(entity);
        }

        @Override
        public void remove(T entity) {
            em.remove(em.merge(entity));
        }
       
        @Override
        public T find(long id) {
            return em.find(persistentClass, id);
        }
    }
    Das implementierte Interface AbstractServiceInterface<T> deklariert lediglich die per @Override annotierten Methoden

    Code (Java):
    @Named
    @SessionScoped
    public class MitarbeiterService extends AbstractService<Mitarbeiter> implements Serializable{

        public MitarbeiterService() {
            super(Mitarbeiter.class);
        }

        @Override
        public List<Mitarbeiter> findAll() {
            return em.createNamedQuery(Mitarbeiter.FIND_ALL, persistentClass).getResultList();
        }

        @Override
        public void removeAll() {
            em.createNamedQuery(Mitarbeiter.REMOVE_ALL, persistentClass);
        }
    }
    Die Fehlermeldung an sich ist ja schlüssig: AbstractService soll einen parameterfreien Konstruktor anbieten, um die Proxyklasse erstellen zu können. Allerdings brauche ich den parameterisierten Konstruktor. Außerdem möchte ich nur Objekte der Klasse MitarbeiterService per @EJB-Annotation injecten lassen, die Oberklasse sollte also eigentlich keine große Rolle spielen, oder?

    Eine Google-Suche ergab schon folgenden Treffer:
    https://community.jboss.org/thread/197534
    Dies brachte mich aber nicht weiter...

    Hat hier irgendjemand eine Idee, wie ich die Superklasse mit einem Kontruktor mit Parametern behalten kann?
     
  2. Vielleicht hilft dir das Java-Tutorial weiter. Hier klicken --> (Klick)
  3. Dann mach es auch ohne Konstruktor:
    Code (Java):

    public abstract class AbstractService<T> implements AbstractServiceInterface<T>{
        protected final Class<T> persistentClass;
       
        @PersistenceContext
        protected EntityManager em;
       
        public AbstractService(){
            this.persistentClass = (Class<T>)   ((ParameterizedType)getClass().getGenericSuperclass()).getActualTypeArguments()[0];
        }

     
    Code (Java):

    //@Named
    //@SessionScoped -> soll wirklich eine WebBean sein oder eine Service (EJBean??? ->@Stateless)
     
    public class MitarbeiterService extends AbstractService<Mitarbeiter> implements Serializable{

       }
     
     
  4. Gemanagte Beans müssen bestimmten Vorgaben entsprechen. Sie haben einen Lebenszyklus, der vom Container vorgegeben wird. Voraussetzung ist also z.B. ein parameterloser Konstruktor. Das Bean ist zum Zeitpunkt der Erstellung u.U. noch nicht konsistent, aber das macht nichts. Ich glaube ein privater Konstruktor reicht hier schon aus.
     
  5. @JimPanse:
    Danke für deinen Vorschlag, damit habe ich es auch schon mal probiert, habe aber immer eine ClassCastException bekommen und wollte dann da garnicht weiter forschen, nachdem die ersten Korrekturversuche schief liefen.

    Code (Java):
     
    @FArt:
    Wie genau meinst du das mit dem privaten Konstruktor?

    Achja, komischerweise ging es jetzt, nachdem ich es auf Stateless gesetzt habe (hatte ich vorher auch schon probiert, naja vlt. ging da noch was anderes schief)
     
  6. Weißt du überhaupt was du machst oder einfach auf trail & error probiert?


    Ich habe nochmal nachgeschaut, in einem altem Projekt haben wir das so gemacht:
    Code (Java):

    public abstract class AbstractService<T> implements AbstractServiceInterface<T>{

    protected final Class<T> refClass = (Class<T>) ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0];

    }
     
    ohne Konstruktor! Das funktionierte ohne Probleme.

    Grüße
     
  7. Ist klar. Ohne Konstruktor heißt ja, dass automatisch ein parameterloser existiert.
     
  8. Sym
    Sym
    Kommt es bei dieser Lösung nicht stark auf den Classloader an?
     

  9. Verstehe ich nicht?
     
  10. Sym
    Sym
    Der Classloader im Enterprise-Server entscheidet doch, ob ((ParameterizedType)getClass().getGenericSuperclass()).getActualTypeArguments()[0]; ausgewertet werden kann. Ich meine jedenfalls, dass dies nicht immer funktioniert.
     
  11. Hallo, sorry, dass ich mich jetzt erst melde:)
    Ich habe die EJB jetzt doch als Stateless definiert und dem super-Klassen-Konstruktor die Class übergeben.
    @Sym:
    Das würde jedenfalls zu meinen Beobachtungen passen :)

    Danke td für eure Bemühungen
     
  12. Ich frag mich eher was das für ein Design ist.

    Für jede persistente Klasse ein "Service", und jeder konkrete Service macht genau nicht's außer eine NamedQuery auszuführen (oder zwei NamedQuerys)?

    Der Sinn erschließt sich mir jedenfalls nicht so ganz warum man das so tut...aber mit dem letzten Kommentar über getParameter... scheint es ja zu tun
     
  13. Schau dir jetzt hier den Kurs an und lernen Java zu programmieren: --> Hier klicken, um mehr zu erfahren (Klick)