Hirdetés
- Feháborodott az Apple, a Meta az iPhone-felhasználók üzeneteit akarja olvasgatni
- A luxusmárkáknak kell a bitcoin, az USA jegybankjának nem
- Letiltja az USA a politikusokat a telefonhívásokról és szöveges üzenetekről
- Nagy áttörés jön a napelemek piacán, nem kell annyi hely a paneleknek
- Belenyúlt az USA az Epic Games igazgatótanácsába, nyomoz az NVIDIA
Új hozzászólás Aktív témák
-
Lortech
addikt
válasz
togvau
#11714
üzenetére
Egy spring alkalmazásban (is) a session életciklusa beállítás kérdése. Amit írsz, azt szerintem benézed, vagy spéci beállításod van (tehát nem szűz spring boot app ), nem ez a default működés.
Egy request feldolgozás viszonyában a session (id) alapvetően attól függ, hogy a böngésződ küldött-e a requestben session id-t (JSESSIONID cookie (default)) , és hogy mi a spring appod sessionCreationPolicy-je, ezektől függően fogja a Spring (újra)használni a kapott sessionid alapján a meglévő sessiont (az objektumot, nem az id-t) vagy újat gyártani vagy nem gyártani vagy teljesen ignorálni a sessiont (springen kívül továbbra is létrehozható session).a session.setAttribute-ban állított dolog pedig mindegyik globális, mindegy milyen böngészőről/kliensről van a beállító kérés, mindegyiknek ugyan az lesz a getattribute valami értéke amit az egyik legutoljára settelt
Ez nem így működik, pont az a session lényege, hogy egy session példányhoz és állapothoz (így a session attribútumaihoz) csak azok a kliensek férnek hozzá, amelyek azonos session id-val rendelkeznek.
Szerinted téged a spring session fixation védelme zavarhat meg, emiatt látsz különböző session id-kat és emiatt tűnik úgy, hogy a sessionök különbözőek (valójában ugyanazok a sessionök különböző session id-val), mégis ugyanazok az attribútumai.[ Szerkesztve ]
Thank you to god for making me an atheist
-
-
Lortech
addikt
válasz
togvau
#11708
üzenetére
Magától értetődően legegyszerűbb maga a session (HttpSession), ha tényleg van... Ugye ez nem egyértelmű RESTful API-nál és JWT authentikációnál, aminek statelessnek kéne lennie.
Komolyabb alkalmazásnál floodot még az alkalmazás előtt célszerű megfogni, api gatewayen, proxyn, load balanceren stb.[ Szerkesztve ]
Thank you to god for making me an atheist
-
-
-
válasz
togvau
#11651
üzenetére
Szinkron vagy aszinkron megoldás kell? Kapsz egy requestet egy végpontra, ahol meg is várja a hívó fél a kimenetet vagy vissza kell szólond majd ha megvan a válasz?
Ehhez nem feltétlenül kell aws, ott az ingyenes heroku is. De lokálban is megcsinálhatod docker segítségével.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
bambano
titán
válasz
togvau
#11596
üzenetére
nem ismerem, hogy a jáva ezt hogy csinálja, de a rendes eredeti hash tárolási struktúra egyáltalán nem keres hash értéket. ettől gyors.
és úgy tartják fenn az elemek növekedése ellenére a gyorsaságot, hogy módosítják a hash függvényt.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Lortech
addikt
válasz
togvau
#11442
üzenetére
Áh, mavenes a projekt, ott a bibi, használj gradle-t, az ezt is megoldja.
Nyilván pontos válaszhoz kéne egész pontos infó, hogy a TLS handshake melyik ponton döglik, pl. openssl s_client kimenet, de ágyúval verébre megoldás itt:
https://stackoverflow.com/a/45444355Thank you to god for making me an atheist
-
Szmeby
tag
válasz
togvau
#11317
üzenetére
Sajnálattal hallom. Az én emlékezetem is egy aranyhaléval vetekszik. Javaslok egy jelszókezelőt, nekem bevált.
Bizonyára megtehetné, hogy mindkettőt nézi, persze. Csak ez az extra kényelem a háttérben iszonyatos komplexitást generál. A fejlesztők hoztak egy döntést, hogy ez a kényelem nem tesz hozzá annyit, hogy emiatt a framework mondjuk lomha legyen.
Persze ha tudsz egy olyan megoldást, ami nem rontja a framework hatékonyságát, mégis kényelmes, javaslom, beszélgess a hibernate készítőkkel, talán vevők lesznek az ötletre. A hibaüzi mondjuk jól hangzik.
-
floatr
veterán
válasz
togvau
#11315
üzenetére
https://docs.jboss.org/hibernate/orm/5.1/userguide/html_single/chapters/domain/access.html
Azért használ eltérő módszert a két elérésre, mert field access esetében kell proxy/introspection/reflection. A hiányosság itt a framework és a technológia ismeretében van.[ Szerkesztve ]
-
Szmeby
tag
válasz
togvau
#11315
üzenetére
Én például onnan tudom, hogy valamikor régen olvastam a hibernate dokumentációjában. Szerintem elég közismert dolog... legalábbis a dokumentációba belelapozó emberek között. Én úgy vagyok vele, hogy ha igényes munkát akarok végezni, akkor érdemes megismerni a használt frameworkot kicsit közelebbről is. Így amikor fikázom, talán kisebb eséllyel teszem magamat nevetségessé.
szerk.: A jelenség a transient módosítótól teljesen független.
[ Szerkesztve ]
-
floatr
veterán
válasz
togvau
#11313
üzenetére
A hibernate az @Id annotáció alapján választ stratégiát arra, hogyan kezelje a bean adatait. Ha field-en van, akkor reflection-t használ mindenre, ha getteren, akkor a metódusokat. Vegyesen csak akkor lehet használni, ha felülcsapod a default stratégiát egy
@Access(AccessType.FIELD)annotációval, amit a field-re akasztasz rá.Imádkozás helyett specifikáció, vagy tutorial. Ez a középkorban is sokszor bevált volna.
-
togvau
senior tag
válasz
togvau
#11309
üzenetére
Látom, elég csak a kimenetnél megszabni a korlátozást, és az a bemenetre is vonatkozik.
De újabb probléma: a newClass-nak vannak tételei is listában, minden invoice-nak saját fajta... azok is egy közös abstract osztályból származnak, de hogy tudok nem fixen létrehozni tétel osztályt?
kimeno.callTetelekLista().getClass().getGenericSuperclass(); talán így meg van a listaelemek osztálya (már ha akkor is működik ha a call null-t ad vissza, mert nincs list még hozzáadva)
(mert futás időben nincs generikus)De hogy ha van egy metódus, hogy getItemType és abba egyenként fixen meg van adva entitynként, hogy mi tartozik hozzá, akkor be tudom szerezni a classt. Viszont hogy hozom létre, hogy hozzáadhassam a listához? newInstance oké
hitler, sztálin, micro usb
-
disy68
aktív tag
válasz
togvau
#11306
üzenetére
protected static <T extends AbstractInvoiceEntity> T getInvoiceEntity(AbstractInvoiceEntity originalEntity, Class<T extends AbstractInvoiceEntity> newClass) {T newInvoice = newClass.newInstance();(...)return newInvoice;}
valami ilyesmi vagy átadsz egy factory-t, ami létrehozza a kívánt objektumot[ Szerkesztve ]
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
-
disy68
aktív tag
válasz
togvau
#11296
üzenetére
ha a fetch mód subselect, akkor n db kapcsolódó entity-vel n+1 query-t generál a hibernate, ez működik eager és fetch betöltésnél is, viszont a join fetch mód esetében 1 db query-t generál a hibernate, amivel lekéri a kapcsolódó entity-ket is, így ez instant eager betöltést jelent fetch type-tól függetlenül
én alapvetően a @NamedEntityGraph irányba mentem volna, ha nincs mód nagyobb refaktorra (bár ha ezt force-olja a projekt struktúra, akkor kb. mindegy, mert eager betöltés lesz a vége)
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
disy68
aktív tag
válasz
togvau
#11294
üzenetére
"ott sem volt jó egyik dolog sem az EAGER-t leszámítva, amit a google kidob erre a hibára"
aham, mint ez meg ez, amikben kifejezetten azt írják, hogy ne használj eager-t ilyen helyzetben (első 2 találat)
Vlad Mihalcea blogját amúgy tudom ajánlani, ha hibernate és/vagy jpa a témakör.
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
-
Szmeby
tag
válasz
togvau
#11273
üzenetére
Kicsomagolod, castolod a belét, becsomagolod. Mondjuk, amit az Optional.map() csinál, ha már az Optional a példa.
disclaimer: Remélem azt nem kell mondanom, hogy ha a kalapács nyelével akarod beverni a szöget, akkor ne csodálkozz, ha körülményes. Ha mondanom kell, akkor egy java software design témájú könyv elolvasása szerintem hasznos lenne. Valami a nagyoktól: Josh Bloch, Bob Martin, Kent Beck, Fowler, ...
Ja igen, zavarbaejtően sok állítmány és szleng került a mondataidba, nem vagyok benne biztos, hogy jól értem a problémát, de van egy olyan érzésem, hogy máshogyan illene struktúrálni azt a kódot.
-
disy68
aktív tag
válasz
togvau
#11260
üzenetére
"Valami maven wrappert írt, hogy be kell rakni a projektbe, az benn is van."
docker-maven-plugin? hogy néz ki hozzá a konfig a pom.xml-ben?"Igen rákerestem, a java írja, hogy nem jó a jar."
ha rákeresel a hibaüzenetre és hozzácsapod, hogy docker, akkor láthatod, hogy másoknak is volt ilyen problémájuk, a legtöbb esetben az argumentum átadással volt a gond, ami miatt a
JAR_FILEváltozó értéke üres, így a copy nem fut le jól"Megnéztem az argumentumot, de nem találja, mivel a docker linux fájlrendszerében keresi, nem az igaziban."
wut?
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
disy68
aktív tag
válasz
togvau
#11257
üzenetére
A docker image-et hogyan hozod létre? Használsz-e maven/gradle plugint? Rákerestél-e a hibaüzenetre? Nézted-e hogyan kell argumentumot használni a dokumentációban?
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
válasz
togvau
#11180
üzenetére
Ezt meg kéne tudni csinálni szerintem nativ query nélkül is. Régen csináltam hasonlót:
Optional<Deck> findByIdAndGame_Id(int id, int gameId);A
deckentity-nek pedig volt egy ilyen tulajdonsága:@OneToOne
@JoinTable(
name = "games_decks",
joinColumns = @JoinColumn(name = "deck_id"),
inverseJoinColumns = @JoinColumn(name = "game_id")
)
@JsonIgnore
private Game game;[ Szerkesztve ]
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
floatr
veterán
válasz
togvau
#11188
üzenetére
Ha most jobban végiggondolod, ezt SQL-ben sem lehet normálisan megcsinálni. SQL Server-nek van valami JSON-ös megoldása erre, de sosem használtam. Vagy egy nagy JOIN-ba pakolsz mindent, de akkor ismétlődés lesz, amit kézzel kell aggregálni stream-collector alapon, vagy külön kérdezed le, úgy viszont neked kell összekalapálnod az összetartozó adatokat, ha a lazy initet nem szereted.
Igazság szerint, ha ilyen adatmodelled van, érdemes elgondolkodni egy NoSQL DB-n, mint pl. a Mongo.
A H2/HSQL/Derby nem production-ready DBMS. Helyette inkább MySQL/MariaDB egy docker konténerben.
-
floatr
veterán
válasz
togvau
#11186
üzenetére
Egyrészt jó lenne, ha kicsit jobban leírnád a kérdéseidet, mert nem lehet követni, annyira csapongsz.
A JOIN FETCH egy JPA specifikus dolog, a Spring Data nem tehet róla, hogy néha kell. Ha használsz @Transactional-t, vagy open session in view filtert, akkor egy tranzakción belül, több dolgot is fel tud szippantani, mint szeretnéd.
Ha DTO-t használsz, akkor eleve máshogy fognak működni a dolgok.
Ha csak bizonyos mezőket szeretnél használni, arra ott vannak az implicit és explicit projekciók.
A fenti query a legtöbb DBMS-ben értelmezhetetlen. -
Szmeby
tag
válasz
togvau
#11180
üzenetére
Én inkább a Hibernate-re gyanakszom (vagyis az általad választott aktuális JPA implementációra), ő rakja össze az sql-t. A spring csak egy plusz réteget húz köré. Ezért is gondoltam azt, hogy az egyik megoldás egyből a hibernate-et szólítja meg, míg a másik átfolyik még néhány springes optimalizáción. Habár a spring egyik és másik modulja is képes gyökeresen eltérő "optimalizációkat" végrehajtani ugyanabból a kiindulópontból.
Szerintem sem sikerültek a legjobbra a hibernate default működési módjai ilyen-olyan esetekben, de tudod, ez ízlés dolga. A kedvencem, hogy Set, List, Collection, stb típusok esetén ceteris paribus teljesen eltérő lekérdezéseket rak össze végül. Külön öröm volt ezt debugolni.
Más fejlesztő más problémával meg örül neki, hogy pont úgy működik az általa összerakott izé, ahogy azt elvárja. A show_sql-nek nincs oka, hogy hazudjon.Megtanultam már, hogy minden hibernate által összeállított query-t le kell ellenőrizni, mert orbitális hülyeségeket, optimalizálatlan megoldásokat tud összerakni a háttérben. Vagy csak nekem vannak furcsa igényeim, ki tudja.
Örülök, hogy a fetch megoldotta a problémát.
Optimalizálj és jó lesz. -
floatr
veterán
válasz
togvau
#11172
üzenetére
Belepakolsz egy @Transient annotációval jelölt metódust, ami get***Id néven visszaadja a kapcsolt entity azonosítóját.
De használhatod a gyerek-szülő kapcsolatban a JsonManagedReference és JsonBackReference annotációkat is, ami csak egyik irányban engedi a szerializációt kifejteni
[ Szerkesztve ]
-
disy68
aktív tag
-
Ezekiell
veterán
válasz
togvau
#11141
üzenetére
Ha nem akarsz módosítani a Jaron, akkor vissza a java8, vagy adsz classpathot neki system envben. Vagy dockerben indítod java8al, és mehet a java11 a rendszerre.
[ Szerkesztve ]
Aki mibennünk nem bízik, az önmagában sem bízik. Aki mibennünk nem bízik, az a mi fényes békénkben sem bízik. És aki a mi boldog, fényes békénkben nem bízik, az áruló.
-
-
válasz
togvau
#11078
üzenetére
Ez az egész nekem nagyon nem kerek. Ezt a részt hogy érted? "JSF managedbean (ami a spring miatt inkább @Component)"
A JSF managed beannek @ManagedBeannek kellene lennie, nem @Componentnek. JSF-et és Springet ilyen formában nem szabad keverni. Itt le van egy jó példa, hogy hogyan kellene a Spring+JSF-nek kinéznie: https://www.baeldung.com/spring-jsf -
disy68
aktív tag
válasz
togvau
#11043
üzenetére
Nem írsz arról, hogy a MockMvc-t hogyan használod (a test class hogyan van annotálva). Ha
@SpringBootTestannotációval használod, akkor explicit be kell konfigurálni a security-t.
részlet a korábbi baeldung cikkből:@Autowiredprivate WebApplicationContext context;private MockMvc mvc;@Beforepublic void setup() {mvc = MockMvcBuilders.webAppContextSetup(context).apply(springSecurity()).build();}(...)De én továbbra is TestRestTemplate használatát javaslom, ehhez itt egy kis egyszerű minta.
A DB-s problémád pedig kicsit zavaros, az az "application.properties" részlet meg egy controller post methodja..
[ Szerkesztve ]
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
disy68
aktív tag
válasz
togvau
#11041
üzenetére
Ok, azt hiszem értem mi a félreértés. Ezt írtad: "maradjon futva a junit tesztek lefutása után". Ebből én unit testre asszociáltam és erről is beszéltem.
Erősen kétlem, hogy támogatná bármilyen test framework alapból, hogy utána fusson tovább az alkalmazás, ami a tesztek futtatása miatt indult.
A springboot junit test az meg nem csal, hanem azt csinálja, amit "mondasz" neki. Hogyan hívod most a tesztekben a "rest szolgáltatásokat"? Itt egy baeldung a témakörben. Meg egy TestRestTemplate részletesebb.
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
disy68
aktív tag
válasz
togvau
#11039
üzenetére
A unit test-eknek van valami futtató keretrendszere, ami segítségével futtatod a teszt osztályok metódusait, amiben használod az alkalmazásod elemeit. Ilyenkor nem fut a teljes alkalmazás, szóval nincs sok értelme így a kérdésnek. Mi a tényleges probléma, mit szeretnél elérni?
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
-
floatr
veterán
válasz
togvau
#10991
üzenetére
Nézd nem mondom, hogy hibátlan a framework. Tele van apróbb hiányosságokkal, dokumentálatlan sok helyen, és a dobott hibák félrevezetőek.
De ha alaposan ismered, nem csupán a tutorialokat bújod, akkor fel fogod ismerni az alapvető összefüggéseket. A fenti lazy init probléma nem bug. Így működik a JPA, és ha a @Transactional használata problémát okoz, akkor nagyon gyorsan igyekezz elsajátítani, mert mint mondtam: alap.Az iménti kódrészlettel van egy baromi nagy baj, nem is csupán a paraméterek száma miatt. A query, amit leírtál, egy JPQL SELECT. Annyiban különbözik az SQL-től, hogy objektumokat kezel (többek között). A
p.user=?1nem a táblában lévő oszlopra vonatkozik, hanem a Photo entitás user adattagjára, ami gondolom User típusú. A JPQL nem long értéket vár, hanem egy User objektumot. Helyesen így lenne:select p.id from Photo p where p.user.id = ?1
feltételezve, hogy a user azonosítója az id nevű property, így lehetne Long paraméterrel hívni. A restricteddel az a baj, hogy feltételesen csapod a query-hez a criteria API-s implementációjával. Ilyet @Query annotációval nem lehet. Ott fixen meg kell adni a JPQL-t, amit nem módosíthatsz, magyarán:select p.id from Photo p where p.user.id = ?1 and p.restricted=?2
lenne a végső JPQL (ha el nem néztem még valamit).Ne ess abba a hibába, hogy a frameworkben keresed a bugot, miközben helytelenül kódolsz.
[ Szerkesztve ]
-
floatr
veterán
válasz
togvau
#10989
üzenetére
Relatív, hogy mi a csúnya
van egy interface a Data metódusoknak, meg egy custom implementációhoz, már ha kell egyáltalán.Annyit azért nem árt fejben tartani, hogy a @Transactional alap. Nem hozunk létre tranzakciót kézzel, nem nyitunk db kapcsolatot. EntityManager-t a legvéső esetben szabad csak babrálni. Helyette érdemes a projekciókkal csinálni, amit lehet.
-
floatr
veterán
válasz
togvau
#10985
üzenetére
Namost ez egy elég hosszú téma, de röviden itt van egy példa, ami alapján tudsz hozzácsapni összetetteb dolgokat egy JPA repo-hoz. Ezt most csak egy text editorban dobtam össze, de a lényeg itt van. Van egy JPA repository-d, amit a framework majd implementál magának. Kell egy új interface, amiben a saját új metódusaid vannak. Ezt implementálod egy külön osztályban, valamint az új interface-t hozzácsapod a JPA repo-hoz az extends-ben. Innentől kezdve a PhotosRepo típust injektálod be mindenhová, mert a Spring ez alapján készít saját implementációt.
// létrehozol egy inteface-t a saját metódusaidnak
public interface PhotosRepoCustom {...}// meghagyod a Spring Data repository-dat is, de hozzácsapod a saját interface-t is
@Repository
public interface PhotosRepo extends CrudRepository<Photo, Long>, PhotosRepoCustom {...}// implementálod az új interface-t
public class PhotosRepositoryImpl implements PhotosRepoCustom {
@PersistenceContext
EntityManager em;
public List<A> findAllCustom() {
....
}
}De a @Query annotációval használhatsz JOIN FETCH-et is egy query metódusban pl.:
@Repository
public interface PhotosRepo extends CrudRepository<Photo, Long> {
...
@Query("SELECT a FROM A a INNER JOIN FETCH a.b b")
public List<A> find();
}[ Szerkesztve ]
-
floatr
veterán
válasz
togvau
#10983
üzenetére
Amikor meghívod a lekérdezést a Repository metódusban, az elkér egy aktuális sessiont az EntityManager-től. Mivel lazy, azon a ponton nem oldja fel a hivatkozást, csak egy B proxy-t kap az A objektum. Amikor visszakapod A-t, a session már ment a lecsóba, és hiába hívod meg a gettert, a proxy már nem találja a session-t.
Na többek között erre is való a @Transactional, mert megmondja az EntityManager-nek, hogy hol kezdődik a session lifecycle. Ha nincs @Transactional, akkor a Repository metódusban kéne inícializálni a lazy relációkat. -
-
Drizzt
nagyúr
válasz
togvau
#10905
üzenetére
A streammel nincs baj, az Arrays.asListet használod rosszul. Az listát csinál a megadott tömb elemeiből. Jelen esetben egy egy elemű listád lesz, aminek az az egy eleme egy int[] lesz.
int[] ints = new int[]{0, 1, 2, 3};Arrays.asList(ints).stream().forEach(System.out::println);Arrays.asList(1, 2, 3).stream().forEach(System.out::println);Arrays.stream(ints).forEach(System.out::println);Eredménye:
[I@1218025c123
0123I am having fun staying poor.
-
Lortech
addikt
Most tényleg kérdőjel van az exceptionben, vagy csak nem akartad leírni a konkrét hibát?
Én először megnézném, hogy az adott requestre adott válasz érvényes-e a wsdl-re.
Pl. Soapui megmondja a response-on jobb klikkre.
Aztán leellenőrizném, hogy a wsdl nem változott-e időközben, ugyanazt a wsdl-t implementálja-e a végpont, mint amiből a kliens lett generálva (?).
Ha már muszáj debuggolni, akkor IDE-ben be tudsz állítani exception breakpointot az exception típusra.Thank you to god for making me an atheist
-
MrSealRD
veterán
Hát ha van public része a exceptionnek, akkor azt az 1-2 sort bedobhatod... Nekem legutóbb attól volt unmarshalling exception, hogy jött egy adatstruktúra amiben az egyik elem típusa date volt, és sima záró tag-et, küldtek érték nélkül. Na ezen totál eldobta magát... Először elkezdtem keresgélni, hogy hol tér el a séma, aztán végül ott volt benne, hogy nem tudta parseolni...nyilván mivel nem volt benne semmi.
Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage
-
MrSealRD
veterán
Hát lehet én tudok valamit rosszul, de nálunk ha ilyen séma eltérés van, akkor az unmarshalling nagyjából kidobja, hogy hol volt gondja... De én visszalépnék egyet. WSDL+XSD-k elvileg ott vannak. Abból meg kiderül, hogy mi kötelező és mi opcionális.
Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage
-
-
Lortech
addikt
Pedig a standalone/domain.xml-ben kell beállítanod a security domainedet. A security domain / realm az nem 1:1 egy alkalmazáshoz kapcsolt, hanem alkalmazások fölött álló koncepció. JAAS infrastruktúra és Java EE pedig nem ad standard megoldást arra, hogy hogyan kell az alkalmazáshoz security domaint rendelni. Ezért van az, hogy jboss-web.xml-ben kell megadni. Vagy standalone/domain.xml-ben default security domainnek beállítani.
jboss-web konfiguráció itt van említve: [link]
security subsystem pedig itt van leírva: [link]
Ebből látszik, hogy a Database / DatabaseUsers modul a webes admin konzolon
a org.jboss.security.auth.spi.DatabaseServerLoginModul-t jelenti.
Tutorial: [link]Fontos, hogy wildfly 11-től elytron alrendszer van és önmagában kevés a fenti legacy konfiguráció.
Migráció: [link][ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
UsersRolesLoginModule az egy fapad login module, property fájl alapú, nem tud db-ből authentikálni.
Amit én linkeltem, az direktben a datasource-on keresztül jdbc-zik, de simán lehet írni JPA alapú login module-t, írtam is már wildflyra, weblogicra.. Nem triviális, de nem is ördöngősség.
Pl. csinálsz egy EJB szolgáltatást ami JPA-n keresztül elvégzi az authentikációhoz szükséges ellenőrzést. A loginmodule-ból pedig JNDI-n keresztül lookupolod az EJB-det. A loginmodule-t csomagolhatod az alkalmazásodhoz is, nem muszáj külön modulként telepíteni.
Belépés után httpservletrequestből (JSF-ben facescontexten keresztül) elérhető a felhasználó a getUserPrincipal metódussal (getName normálisan a felhasználó nevét adja vissza), ezzel bekérdezhetsz az adatbázisodba. Van még isUserInRole is ugyanitt.[ Szerkesztve ]
Thank you to god for making me an atheist
-
-
Lortech
addikt
Nem definiáltál az entitásaidba relációkat, legalábbis nem látszik. Anélkül nem nagyon fog menni és FK be fog utagni, meg nyilván generátor se fog tudni jó db sémát generálni így. Ajánlott olvasmány: JPA relációk, de úgy általában JPA.
EntityManager em= getFactory().createEntityManager();
em.getTransaction().begin();
Event evt= new Event(new Date(),em.merge(getGod()),event, success);
em.persist(evt);
em.getTransaction().commit();
em.close();Ezzel itt az (lehet) a baj, hogy amint lezárod az EntityManagert, az összes managed entitás példányod, amit a persistence contextben használtál, detached lesz. Ennek pedig az a következménye, hogy a még be nem töltött, lazy load relációk nem tudnak majd betöltődni, ill. az objektumok módosítása esetén nem lesznek automatikusan perzisztálva sem.
Thank you to god for making me an atheist
-
Lortech
addikt
Azt értettem alatta, hogy az entitásban/db-ben a probléma mezőt/oszlopot nem jól definiáltad.
Pl. nem jó oszlopnevet adtál meg.
Detached entity passed to persistnek számos oka lehet. Kézzel állítasz be kulcs mezőket mentés előtt? Másodjára persisttel már nem fog menni, mert már létezik adott kulcsú mező, viszont az entity detached állapotban van, mivel még a persistence contextedbe nem töltődött be (pl. merge-dzsel tudod manageddé tenni). Látatlanban okosabbat nem tudok mondani.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Valószínűleg rossz az entity-db mappinged, de ez abból amit írtál, nem látszik.
Logolás: org.hibernate (vagy specifikusabb) kategóriára fel kell venni egy loggert és hozzá egy handlert:
[link]
Jboss logging teljesen oké, nem kell log4j vagy egyéb implementáció.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Na ez az az irány, amit nem kéne erőltetni.
Javaslom, szervezd EJB-be az üzleti logikádat és az adathozzáférést, és azt injektáld a JSF managed beanbe. Mert az nem arra való, hogy direktben JPA-zz és tranzakciót kezelj benne.
AZ EJB-be pedig injektáld az entitymanageredet pl. az általam fentebb írd módon. Így nem kell foglalkoznod az entitymanager létrehozásával, életciklusával (pl. hogy többször létrehozod a factory-t, mint ahogy tetted).
BalusC tutorialjait, megoldásait érdemes olvasni, ő jó forrása a JSF-fel kapcsolatos megoldásoknak: [link]JAAS-hoz: a login-config.xml az jboss szerinti leíró, wildfly-on máshogy néz ki.
wildfly login module pl (standalone.xml vagy domain.xml megfelelő profiljában):<security-domain name="xysecdomain">
<authentication>
<login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
<module-option name="dsJndiName" value="ds jdni név"/>
... többi opció ...
</login-module>
</authentication>
</security-domain>De mindez megtehető webes admin konzolból is.
Aztán jboss-web.xml-ben kell egy <security-domain>xysecdomain</security-domain> hivatkozás, ami a webalkalmazásodat összekapcsolja a security domainnel wildfly-ban.selectItem vs enum passz, szerencsére már rég JSF-eztem.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Wildfly picketboxot használ jaasra, van olyan login module, hogy
DatabaseServerLoginModule.
Meg lehet adni neki datasource-ot paraméterként és jdbc-vel hozzáfog férni a db-dhez. Nem tudom, friss-e a leírás, de bele lehet nézni a login module forrásába.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Kézzel úgy tudtad feloldani helyesen a jsf-et, hogy a wildfly-odban lévő verziót (az appszerverben lévő verzióval pontosan megegyező) adtad hozzá, bármely más jsf lib hozzáadása lehet, hogy elfedi a hibaüzenetet, de problémát okozhat (és semmiképp se csomagold bele az elkészült artifactodba függőségként)
Hibernate a jpa implementáció wildflyban. Provider helyére: org.hibernate.ejb.HibernatePersistence kell.
A Wildfly szervereden definiálsz egy datasource-ot (standalone/domain.xml-ben kézzel
![;]](//cdn.rios.hu/dl/s/v1.gif)
, vagy jboss-cli-ben vagy webes admin konzolon), majd a persistence.xml-ben (ear-ban META-INF könyvtárba, war-ban WEB-INF/classes/META-INF könyvtárba) beállítod a datasource-ot.<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence
http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"
version="2.1">
<persistence-unit name="mysqlpu" transaction-type="JTA">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>java:jboss/datasources/mysqlds</jta-data-source>
<properties>
<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>
</properties>
</persistence-unit>
</persistence>Ezután a managed beanekből már tudod injektálni az em-et:
@PersistenceContext(unitName = "mysqlpu")
protected EntityManager em;[ Szerkesztve ]
Thank you to god for making me an atheist
-
togvau
senior tag
Ok, rájöttem, hiányzott a form keret
De most jött a "No Persistence provider for EntityManager named".Mit írjak a persistence-be a provider helyre? Csak hibernate-s provider stringeket találok ha ráguglizok, de nem működik. Vagy milyen JPA implementációt használ ez a wildfly?
Eclipse data source-ként be van állítva, de gondolom az egy másik rendszer rendszerének a rendszere, és nincs átjárás
[ Szerkesztve ]
hitler, sztálin, micro usb
-
Lortech
addikt
Húzd be a wildfly jsf függőséget (wildfly 11.0.0 verziót feltételezve):
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-jsf</artifactId>
<version>11.0.0.Final</version>
</dependency>Vagy telepíts jboss tools az eclipse-edbe, és add hozzá a runtime-ot.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
"Nem a maven a bloatware, hanem a többi. A maven csak felesleges faxni."
Ez a mondatod után kérlek fejezd be te és a többiek is ezt a témát. Nem lesz egyetértés csak felesleges feszültség keltés.
Ez mindenkinek szól, nem akarok törölgetni.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
floatr
veterán
Szóval JSF, JPA meg mysql... A JPA nem bloatware? Az igazi profik JSP-ből SQLeznek direkt connectionökkel. Minek ez a nagy felhajtás a frameworkökkel?!
Kissé odaver ez a vélemény minden fejlesztési metodikának. Hidd el, nem poénból találták ki őket, egyszerűen csak az a gond, hogy a szoftverfejlesztések kis százaléka szól arról, hogy van egy tetszőlegesen kis scope, azt lefejleszted, aztán felejtős. Az igények változnak, a kódbázis nő, újabb modulokra van szükség, integrálni kell más rendszerekkel... és itt jön a cost of change görbe, ami egy ilyen hozzáállással pár lépés után az egekbe szökik. Az a vicc, hogy erre már a PHP Group is régen rájött
-
Lortech
addikt
A maven nem bloatware, a Javás világ jelentős része használja, nem azért, hogy szívassa magát, hanem hogy megkönnyítse vele a saját életét.
Az elkészült artifactok méretét nem befolyásolja érdemben (opcionális maven leírókat leszámítva), hogy mavent használsz, ellenben 2 perc alatt lehet egy működő webalkalmazás vázad egy megfelelő archetípusból generálva, ami azonnal telepíthető, war/ear release-t készít. Sőt 1 perc bekonfigurálni egy maven plugint, ami deployol is neked a wildflyra. Csak érteni kell hozzá.
De a te kézzel összevadászott librarys gányolásod biztos gyorsabb, hibamentesebb, profibb lesz.Thank you to god for making me an atheist
-
cucka
addikt
Amire itt vered a melled, az pusztán annyi, hogy eddig csak sufniprojekteket láttál, ahol 1-2 ember összekalapál valamit és a deployment annyiból áll hogy felmásolod a gépre a pendriveról.
Egy normális méretű projekten fel sem merül ilyen kérdés, hogy mennyi diszket foglal a keretrendszer.
Ha ez egy létező probléma lenne, akkor mondjuk össze kéne trombitáljak két senior arcot, hogy megbeszéljük a problémát és kitaláljunk egy megoldást. Egy ilyen egy órás meeting költsége órabérben kiszámolva drágább lenne, mint egyszerűen csak venni egy nagyobb diszket.De na, majd ha egyszer olyan cuccokon dolgozol, ahol egy tucat fejelsztő dolgozik ugyanazon a kódbázison és az alkalmazást 10-15 évig karban kell majd tartani és továbbfejleszteni, akkor majd olvasd ezt visssza és röhögj magadon hogy mekkora amatőr voltál..
[ Szerkesztve ]
![;]](http://cdn.rios.hu/dl/s/v1.gif)
, vagy jboss-cli-ben vagy webes admin konzolon), majd a persistence.xml-ben (ear-ban META-INF könyvtárba, war-ban WEB-INF/classes/META-INF könyvtárba) beállítod a datasource-ot.
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- AMD Navi Radeon™ RX 6xxx sorozat
- Linux kezdőknek
- Asszociációs játék. :)
- Nvidia GPU-k jövője - amit tudni vélünk
- AMD Navi Radeon™ RX 7xxx sorozat
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Soundbar, soundplate, hangprojektor
- Milyen GPS-t vegyek?
- Digitális Állampolgárság Program
- Autós topik
- További aktív témák...
- HP 630 laptop (15,6/i3-G2/4GB/500HDD/Magyar/Windows7)
- GAMER Ryzen 5 3600 / RX 6600 XT 8GB / 16GB DDR4 / 512GB NVME / Beszámítás / Garancia
- Dell Latitude 3490 laptop (14/i3-G7/8GB/128SSD/AkkuX)
- Meta Quest 3 128gb +kiegészítők! (Garanciális)
- Volkswagen Passat Variant 2.0 TDI DSG LED facelift, új vezérlés, sérülésmentes
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Axon Labs Kft.
Város: Budapest