Abban szeretnék segítséget kapni, hogy a mellékelt képen látható képernyőképen a Swing melyik verziójáig lehet? A mostani verziókban teljesen más a button textúrája és más is...
ebből van még 3 másik, és csak az ns7 van tényleg használatban
Spring Web Services 2.4.0.RELEASE-et használok
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
ezzel generáltam java osztályokat a rendelkezésre álló fix wsdl fájlokból, egy folderbe
kb 7 wsdl fájl van, amikor megpróbáltam őket külön folderbe generálni, akkor viszont a binding.yml -re hibát dobott a maven, és az egyik enumot nem generálta kis jól. A binding-ban lett volna az az override amire ehhez szüksége van.
És most az kéne, hogy ugyanazon az url-en, és ugyanazon az @Action("/akarmi")-n két külön protokollt is meg tudjak valósítani, tehát a spring namespace, vagy a fogadott paraméter alapján ki tudja választani hogy melyik végpont metódust kell meghívnia.
Eddig csak annyit tudtam elérni, hogy @PayloadRoot namespace alapján választ, és úgy meg tudok hívni két külön metódust, de ennek a válaszában nem lesz benne a ws-addressing fejléc :(
Ahogy röviden beledebugoltam, az @Action-t úgy használja, hogy egy Map<String,...> be tenné be a következő végpontot, hogy mappelje, ezek viszont azonosak, és ütközik. A feldolgozandó üzenetek tartalma adottság, és abban fix az Action tartalma.
Én most dolgozok először Spring Boot-al is, meg WebService-el is, leginkább olyan választ várnék aki már dolgozott ezzel, és van gyakorlati tapasztalata. A google nem nagyon jó ilyen komplex kérdések feltevésére, ami két stackoverflow találatom volt, és releváns lenne, arra meg nincsenek válaszok.
Async/await már van vagy négy éve a C#-ban, és azt látom, hogy egyre jobban erőltetik, de nem látom, hogy annyi pluszt adna, amennyivel nehezíti az ember dolgát. Az érdekelne, hogy Javaban ez hogy van. Van-e egyáltalán igény erre.
Az egyetlen értelmes helye ennek szvsz a nagyteljesítményű webkiszolgálásnál lehet, ahol jó, ha a threadpool véges erőforrásaira optimalizáció van, azaz egy IO művelet nem blokkol threadet, az IO művelet idejére a thread visszatér a threadpoolba. De ez elég szűk felhasználási terület.
ez lehet az egyik oka hogy ennyire elterjedt az anemic modell, az OO logika eleve idegen az adatbázisoktól, és minden ORM framework igyekszik mindenféle viselkedésektől megfosztva, külső operátorként dolgozni az osztályokon
vagy legalábbis amit ismerek, a hibernate ezt csinálja, a JPA szabvány is erre a logikára épül, és a többi implementációja is nyilván bár azokkal nem dolgoztam
jdbc-vel lehet orm framework nélkül, de az meg fapados és drága lesz
az eredeti wiki cikk alján van link az ellenérvelésre is
abba beleolvastam, de csak futólag
azt hozza fel az anemic mellett érvként, hogy jobb a single responsibility elv szempontjából, és hogy könnyebb tesztelni, mert a singleton service osztályokat könnyű cserélgetni, mock-ot betenni a helyére
(Ez szerintem megint egy átverés, attól hogy a kódot átmozgattam service osztályba, majd elrejtettem interface mögé, meg xml-ekbe hogy melyik service-t használom, a dependencia a domain objektumra megmaradt, és ha a domain objektum változik mindenki borul, ha egy hívási láncban bug van akkor is továbbmehet a bug és nem vár helyen fejti ki a hatását)
a mindenféle ORM frameworkok azért használnak buta POJOkat, mert a framework adta logika az generikus, nincs helye a domain osztályokban, a többi logikát meg már az user adja hozzá, a felelősségek elválasztása okán hasznos rendesen elkülöníteni.
a wikis cikkben az nem tetszik, hogy nem próbálkozik meg a funkciók csoportosításával. az eredeti szerző nyíltan vállalja, hogy nem minden funkciót akar a domain osztályokba tolni, csak ami oda való. ezzel eléri hogy az üzleti logikát megvalósító osztály vékony marad, a domain specific dolgok meg újrafelhasználhatóak lesznek.
kb ezért rühellem a Spring-et mert erre az anemic modellre kényszerít, miközben én OO programozást szeretnék folytatni, tehát nyakig teletömni a domain objektumokat azzal a kóddal ami a saját adatain fut
régebben olvastam egy cikket többszálú végrehajtásról, és azon belül is a lockless multithreadingről, elcsodálkoztam a címen hogy lehet lock nélkül többszálúan programozni
az volt a lényeg, hogy kiiktat minden olyan közös program komponenst amin szálak osztozhatnak, és amin ütközhetnek, aminek lehet állapota
ehelyett csak a domain objektumnak amin a szál műveleteket végez, van állapota, az viszont nem ütközik más objektumokéval, illetve legfeljebb akkor ha az szándékos, mert két objektum valamilyen interakcióját kell egyeztetni
ebből a lockless logikából következik, hogy Singleton objektumokat, vagy statikus tulajdonságokat felvenni egy osztályhoz halálos bűn, mert akkor ezek lesznek a kereszteződések ahol ki kell tenni a szemafort
az anemic modell meg pont ilyenekre épít
persze most bejött a funkcionális programozás, az lehet hogy teljesen más megoldásokat kínál a többszálúságra, sajnos keveset tudok annak az elméletéről
The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented designing; which is to combine data and process them together. The anemic domain model is just a procedural style design, exactly the kind of thing that object bigots like me ... have been fighting since our early days in Smalltalk. What's worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about.
ha programoztál már más nyelven, akkor keress egy ahhoz hasonló fejlesztőkörnyezetet. ezeket a nyűgöket leveszi a válladról. eclipse, netbeans, jdeveloper, intellij
