- Apple Watch
- Honor Magic8 Pro - bevált recept kölcsönvett hozzávalókkal
- iPhone topik
- Google Pixel topik
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Brutál külső akku, túlzásba vitt töltőfej - Anker újdonságok tesztje
- Yettel topik
- Rég várt frissítést kap az Android tárcsázója
- Android szakmai topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
Új hozzászólás Aktív témák
-
"Amúgy hol vannak a resteasy lib-ek? WEB-INF/lib-ben van mindkét war-ban ugyanaz a verzió?"
Igen, mindkér war WEB-INF/lib könytárában vannak a jarok. Ugyanaz a verzió, bár szerintem ez már nem sokat számít.
"Én a "-verbose:class" -t is megnézném, hátha valami összefüggés kiolvasható belőle."
Jaja, tegnap már mentem vele egy kört, de elég nagyok ezek a warok, hogy az eclipse console 2 war esetén is kifusson a maxra húzott pufferből.Köszönöm mindenkinek a tippeket, még szenvedek vele egy kicsit.
Legrosszabb esetben majd futnak külön jettyben.Érdekességképpen:
Thread.currentThread().getContextClassLoader()
/* WebAppClassLoader=webapp2 */
org.jboss.resteasy.specimpl.ResteasyUriBuilder.class.getClassLoader()
/* WebAppClassLoader=webapp2 */
javax.ws.rs.core.UriBuilder.fromUri(absoluteUri).getClass().getClassLoader()
/* WebAppClassLoader=webapp1 */
javax.ws.rs.core.UriBuilder.class.getClassLoader()
/* sun.misc.Launcher$AppClassLoader@74f2ff9b */
javax.ws.rs.ext.RuntimeDelegate.class.getClassLoader()
/* sun.misc.Launcher$AppClassLoader@74f2ff9b */
javax.ws.rs.ext.RuntimeDelegate.getInstance().getClass().getClassLoader()
/* WebAppClassLoader=webapp1 */org.jboss.resteasy.core.ThreadLocalResteasyProviderFactory (ami egy RuntimeDelegate) rendelkezik egy "org.jboss.resteasy.spi.ResteasyProviderFactory defaultFactory" field-del (ami szintén egy RuntimeDelegate). Bár threadlocal az osztály neve, de azt a funkcióját épp nem használja semmire, hanem a defaultFactory-val dolgozik, amihez a webapp1 anno már készített egy példányt. Ezen a példányon keresztül gyűrűzik be a rossz classloader a másik webapp-ba.
Az UriBuilder mélyén minden a webapp1 classloaderével készült.
org.jboss.resteasy.specimpl.ResteasyUriBuilder.class.getClassLoader()
/* WebAppClassLoader=webapp1 */
new org.jboss.resteasy.specimpl.ResteasyUriBuilder().getClass().getClassLoader()
/* WebAppClassLoader=webapp1 */Feltételezem, úgy lenne ez szép, ha a közös libek közös classloaderrel töltődnének be (külön webapp-ban?), csak hát erős a gyanúm, hogy a sok war libjei más-más közös részhalmazzal rendelkeznek.
Vaaagy, kicsomagolom a warokat egy helyre, és minden fusson a system classloaderrel.
Ez már nagyon hekkes lenne. -
Aethelstone
addikt
"Amúgy hol vannak a resteasy lib-ek? WEB-INF/lib-ben van mindkét war-ban ugyanaz a verzió?"
Igen, mindkér war WEB-INF/lib könytárában vannak a jarok. Ugyanaz a verzió, bár szerintem ez már nem sokat számít."Én a "-verbose:class" -t is megnézném, hátha valami összefüggés kiolvasható belőle."
Jaja, tegnap már mentem vele egy kört, de elég nagyok ezek a warok, hogy az eclipse console 2 war esetén is kifusson a maxra húzott pufferből.Köszönöm mindenkinek a tippeket, még szenvedek vele egy kicsit.
Legrosszabb esetben majd futnak külön jettyben.Érdekességképpen:
Thread.currentThread().getContextClassLoader()
/* WebAppClassLoader=webapp2 */
org.jboss.resteasy.specimpl.ResteasyUriBuilder.class.getClassLoader()
/* WebAppClassLoader=webapp2 */
javax.ws.rs.core.UriBuilder.fromUri(absoluteUri).getClass().getClassLoader()
/* WebAppClassLoader=webapp1 */
javax.ws.rs.core.UriBuilder.class.getClassLoader()
/* sun.misc.Launcher$AppClassLoader@74f2ff9b */
javax.ws.rs.ext.RuntimeDelegate.class.getClassLoader()
/* sun.misc.Launcher$AppClassLoader@74f2ff9b */
javax.ws.rs.ext.RuntimeDelegate.getInstance().getClass().getClassLoader()
/* WebAppClassLoader=webapp1 */org.jboss.resteasy.core.ThreadLocalResteasyProviderFactory (ami egy RuntimeDelegate) rendelkezik egy "org.jboss.resteasy.spi.ResteasyProviderFactory defaultFactory" field-del (ami szintén egy RuntimeDelegate). Bár threadlocal az osztály neve, de azt a funkcióját épp nem használja semmire, hanem a defaultFactory-val dolgozik, amihez a webapp1 anno már készített egy példányt. Ezen a példányon keresztül gyűrűzik be a rossz classloader a másik webapp-ba.
Az UriBuilder mélyén minden a webapp1 classloaderével készült.
org.jboss.resteasy.specimpl.ResteasyUriBuilder.class.getClassLoader()
/* WebAppClassLoader=webapp1 */
new org.jboss.resteasy.specimpl.ResteasyUriBuilder().getClass().getClassLoader()
/* WebAppClassLoader=webapp1 */Feltételezem, úgy lenne ez szép, ha a közös libek közös classloaderrel töltődnének be (külön webapp-ban?), csak hát erős a gyanúm, hogy a sok war libjei más-más közös részhalmazzal rendelkeznek.
Vaaagy, kicsomagolom a warokat egy helyre, és minden fusson a system classloaderrel.
Ez már nagyon hekkes lenne.Vagy a két WAR tartalmát egybe rakod
-
Nincs általános válasz, normálisan nem kéne ilyen probléma legyen két war között. A frameworköknek és konténereknek kéne megoldani, hogy ilyen ne legyen, mégis gyakran előfordulnak ehhez hasonló érdekességek.
A RuntimeDelegate lehet speciális, mivel javax-es package-ben van, és elképzelhető, hogy ezt a jetty a system classloaderrel tölti. Valami közös szülő classloadernek lennie kéne a két alkalmazás között, ami okozza a problémát, másként érvényesülne az, hogy a szóban forgó osztályok a war-ok WEB-INF/lib WEB-INF/classes-eiből töltenek, mivel ez prioritást élvez, és a két "különböző" verzió nem akadna össze.Meg egyáltalán... nem a thread contextclassloaderét kellene használnia egy objektum legyártásakor? Vagy ilyenkor a legyártást végző osztály classloaderét örökli az új objektum? Ezekszerint az utóbbi.
Utóbbi. A createUriBuilder működhetne úgy is, hogy a thread context classloaderrel tölt be egy implementációt, de a bemásolt kód nem ezt teszi (az se biztos, hogy ez a sor indukálja a class betöltését).
Amúgy hol vannak a resteasy lib-ek? WEB-INF/lib-ben van mindkét war-ban ugyanaz a verzió?
Én a "-verbose:class" -t is megnézném, hátha valami összefüggés kiolvasható belőle."Amúgy hol vannak a resteasy lib-ek? WEB-INF/lib-ben van mindkét war-ban ugyanaz a verzió?"
Igen, mindkér war WEB-INF/lib könytárában vannak a jarok. Ugyanaz a verzió, bár szerintem ez már nem sokat számít."Én a "-verbose:class" -t is megnézném, hátha valami összefüggés kiolvasható belőle."
Jaja, tegnap már mentem vele egy kört, de elég nagyok ezek a warok, hogy az eclipse console 2 war esetén is kifusson a maxra húzott pufferből.Köszönöm mindenkinek a tippeket, még szenvedek vele egy kicsit.
Legrosszabb esetben majd futnak külön jettyben.Érdekességképpen:
Thread.currentThread().getContextClassLoader()
/* WebAppClassLoader=webapp2 */
org.jboss.resteasy.specimpl.ResteasyUriBuilder.class.getClassLoader()
/* WebAppClassLoader=webapp2 */
javax.ws.rs.core.UriBuilder.fromUri(absoluteUri).getClass().getClassLoader()
/* WebAppClassLoader=webapp1 */
javax.ws.rs.core.UriBuilder.class.getClassLoader()
/* sun.misc.Launcher$AppClassLoader@74f2ff9b */
javax.ws.rs.ext.RuntimeDelegate.class.getClassLoader()
/* sun.misc.Launcher$AppClassLoader@74f2ff9b */
javax.ws.rs.ext.RuntimeDelegate.getInstance().getClass().getClassLoader()
/* WebAppClassLoader=webapp1 */org.jboss.resteasy.core.ThreadLocalResteasyProviderFactory (ami egy RuntimeDelegate) rendelkezik egy "org.jboss.resteasy.spi.ResteasyProviderFactory defaultFactory" field-del (ami szintén egy RuntimeDelegate). Bár threadlocal az osztály neve, de azt a funkcióját épp nem használja semmire, hanem a defaultFactory-val dolgozik, amihez a webapp1 anno már készített egy példányt. Ezen a példányon keresztül gyűrűzik be a rossz classloader a másik webapp-ba.
Az UriBuilder mélyén minden a webapp1 classloaderével készült.
org.jboss.resteasy.specimpl.ResteasyUriBuilder.class.getClassLoader()
/* WebAppClassLoader=webapp1 */
new org.jboss.resteasy.specimpl.ResteasyUriBuilder().getClass().getClassLoader()
/* WebAppClassLoader=webapp1 */Feltételezem, úgy lenne ez szép, ha a közös libek közös classloaderrel töltődnének be (külön webapp-ban?), csak hát erős a gyanúm, hogy a sok war libjei más-más közös részhalmazzal rendelkeznek.
Vaaagy, kicsomagolom a warokat egy helyre, és minden fusson a system classloaderrel.
Ez már nagyon hekkes lenne. -
floatr
veterán
A Jbossnál ez úgy megy(ahogy emléxem), hogy megadható, hogy a különféle EAR fájlokat ugyanazzal a classloaderrel töltse be. Ami azért fancy, mert a cucc innentől fogva semmilyen más app szerverbe nem telepíthető
Amennyiben a kód kihasználja ezt a remek feature-t Legalábbis a 4-es JBoss tudta ezt, azzal találkoztam utoljára.Egyébként szerintem nem túl szerencsés, hogy a WAR-okat ugyanaz a classloader töltse.
-
Szoktatok több wart közös jvm-ben futtatni?
Én most egy embedded jettyvel küzdök. Adott néhány war, egy jettyben, de külön contextHandlerben. Látszik, hogy mindegyik war kap saját classloadert, még jó is lenne, ha ezek nem akadnának össze úton útfélen.
A probléma gyökere, hogy a resteasy egy uri feloldásakor a javax.ws.rs.core.UriBuilder-t használja (pontosabban annak egy resteasy-féle leszármazottját), az pedig a (szintén resteasy-féle) javax.ws.rs.ext.RuntimeDelegate kvázi-singletonhoz. Itt borul a bili, mivel a webapp1 már létrehozta ezt a singletont a saját classloaderével. Lazy init, hurrá!
public UriBuilder createUriBuilder() {
return new ResteasyUriBuilder();
}Érdekes, hogy amikor ráhívunk ennek a példánynak a createUriBuilder() metódusára, akkor az a webapp1 classloaderével betöltött objektumot gyártja le, függetlenül attól, hogy a metódus hívásakor a webapp2 környezetében járunk, a currentThread contextClassLoadere is a webapp2 classloaderére mutat.
Nem volt még alkalmam megismerkedni a classloaderek világával, valakinek van ebben tapasztalata? Hogyan is kellene - illene - több wart futtatni 1 embedded jetty alól?
Meg egyáltalán... nem a thread contextclassloaderét kellene használnia egy objektum legyártásakor? Vagy ilyenkor a legyártást végző osztály classloaderét örökli az új objektum? Ezekszerint az utóbbi.És persze a problémát az okozza, hogy a visszakapott UriBuilder objektumot ez a szerencsétlen castolná önmagára... vagyis majdnem, hiszen az cast során már képes a webapp2 által betöltött típust használni.
Eredmény: ClassCastException -
Aethelstone
addikt
JBoss tud olyant, hogy egy közös war-ba lehet telepíteni a közösen használt libeket. Mondjuk az sem sokkal jobb megoldás, de kicsit furcsállom ezt a classloader összeakadást. Most nézem, hogy maven plugin is van arra, hogy egy konkrét war-ból kimásolja a libeket az újba jettyhez.
Én mondjuk tutira kitesztelném ezt a dolgot egy saját jarba forgatott singletonnal, ami logol mindent, ami az életciklusával kapcsolatos.
A Jbossnál ez úgy megy(ahogy emléxem), hogy megadható, hogy a különféle EAR fájlokat ugyanazzal a classloaderrel töltse be. Ami azért fancy, mert a cucc innentől fogva semmilyen más app szerverbe nem telepíthető
Amennyiben a kód kihasználja ezt a remek feature-t Legalábbis a 4-es JBoss tudta ezt, azzal találkoztam utoljára.Egyébként szerintem nem túl szerencsés, hogy a WAR-okat ugyanaz a classloader töltse.
-
Szoktatok több wart közös jvm-ben futtatni?
Én most egy embedded jettyvel küzdök. Adott néhány war, egy jettyben, de külön contextHandlerben. Látszik, hogy mindegyik war kap saját classloadert, még jó is lenne, ha ezek nem akadnának össze úton útfélen.
A probléma gyökere, hogy a resteasy egy uri feloldásakor a javax.ws.rs.core.UriBuilder-t használja (pontosabban annak egy resteasy-féle leszármazottját), az pedig a (szintén resteasy-féle) javax.ws.rs.ext.RuntimeDelegate kvázi-singletonhoz. Itt borul a bili, mivel a webapp1 már létrehozta ezt a singletont a saját classloaderével. Lazy init, hurrá!
public UriBuilder createUriBuilder() {
return new ResteasyUriBuilder();
}Érdekes, hogy amikor ráhívunk ennek a példánynak a createUriBuilder() metódusára, akkor az a webapp1 classloaderével betöltött objektumot gyártja le, függetlenül attól, hogy a metódus hívásakor a webapp2 környezetében járunk, a currentThread contextClassLoadere is a webapp2 classloaderére mutat.
Nem volt még alkalmam megismerkedni a classloaderek világával, valakinek van ebben tapasztalata? Hogyan is kellene - illene - több wart futtatni 1 embedded jetty alól?
Meg egyáltalán... nem a thread contextclassloaderét kellene használnia egy objektum legyártásakor? Vagy ilyenkor a legyártást végző osztály classloaderét örökli az új objektum? Ezekszerint az utóbbi.És persze a problémát az okozza, hogy a visszakapott UriBuilder objektumot ez a szerencsétlen castolná önmagára... vagyis majdnem, hiszen az cast során már képes a webapp2 által betöltött típust használni.
Eredmény: ClassCastException -
Sk8erPeter
nagyúr
-
Szmeby
tag
Szoktatok több wart közös jvm-ben futtatni?
Én most egy embedded jettyvel küzdök. Adott néhány war, egy jettyben, de külön contextHandlerben. Látszik, hogy mindegyik war kap saját classloadert, még jó is lenne, ha ezek nem akadnának össze úton útfélen.
A probléma gyökere, hogy a resteasy egy uri feloldásakor a javax.ws.rs.core.UriBuilder-t használja (pontosabban annak egy resteasy-féle leszármazottját), az pedig a (szintén resteasy-féle) javax.ws.rs.ext.RuntimeDelegate kvázi-singletonhoz. Itt borul a bili, mivel a webapp1 már létrehozta ezt a singletont a saját classloaderével. Lazy init, hurrá!
public UriBuilder createUriBuilder() {
return new ResteasyUriBuilder();
}Érdekes, hogy amikor ráhívunk ennek a példánynak a createUriBuilder() metódusára, akkor az a webapp1 classloaderével betöltött objektumot gyártja le, függetlenül attól, hogy a metódus hívásakor a webapp2 környezetében járunk, a currentThread contextClassLoadere is a webapp2 classloaderére mutat.
Nem volt még alkalmam megismerkedni a classloaderek világával, valakinek van ebben tapasztalata? Hogyan is kellene - illene - több wart futtatni 1 embedded jetty alól?
Meg egyáltalán... nem a thread contextclassloaderét kellene használnia egy objektum legyártásakor? Vagy ilyenkor a legyártást végző osztály classloaderét örökli az új objektum? Ezekszerint az utóbbi.És persze a problémát az okozza, hogy a visszakapott UriBuilder objektumot ez a szerencsétlen castolná önmagára... vagyis majdnem, hiszen az cast során már képes a webapp2 által betöltött típust használni.
Eredmény: ClassCastException -
Aethelstone
addikt
-
floatr
veterán
Én egy Socket szervert csinálnék, ahol az autók SSL/TLS titkosítással elküldenék az indulási időt, útvonaltervet, a szerver pedig OpenMaps-on követné őket
Pl. Akkor egy mongodb elég lesz alá. Vagy clusterben gondoltad?
-
A magam részéről feleslegesnek tartom ennyire túlbonyolítani a dolgot. Ha statikus szövegről van szó, akkor annak a pártján vagyok, hogy tároljuk property fájlban, nyelvenként külön-külön:
messages_hu_HU.properties
messages_en_US.properties
stb...
Egy új nyelv bevezetése pofonegyszerű... persze ehhez matatni kell a fájlrendszeren.Amennyiben vannak olyan szövegek, amelyek gyakran változnak, akkor azok lehetnek adatbázisban (akár in-memory db, akár ennek rendszeres backup-jával). Igazából attól függ, hogy mi a célja, mire használod a szövegeket, mennyire érzékeny adatok ezek, stb.
Azzal, hogy két helyen tárolod a cuccokat, magadra vetted ezek szinkronban tartásának terhét. Ha ez az igény, akkor nincs mit tenni. Gondoltál a teljesítmény problémákra is, csinálsz hozzá pár komponens tesztet, ezeket akár egy CI rendszerben, akár időnként kézzel megfuttatod, és nincs vele teendő. Legfeljebb majd később átírod, a szoftver úgyis mindig fejlődik.
Sosincs jó megoldás, mindig a körülményektől, a felhasználási módtól függ. Mindig kell kompromisszumokat kötni, de ha már ezt teszem, igyekszem úgy, hogy a lehető legegyszerűbb maradjon a végeredmény. Csak ezt tudom tanácsolni neked is.Én is túlbonyolításnak érzem, de hát kísérletezek
A csak db-be tárolással az a gondom, hogy ha MVC-ben vagyok, akkor a modelhez mindig adjam hozzá azt a szöveget ami ott megjelenik ez sok-sok model.add sor is lehet vagy nem tudom, hogy lehetne máshogyan.Az új nyelv futásidőben való hozzáadás az én megoldásomnál bonyolult, mert entitáson keresztül kezelem a db-t és ha új nyelvet akarok, akkor bővítenem kéne az entitásomat és erről fogalmam nincs, hogy lehetne futásidőben, vagy teljesen máshogyan kéne felépítenem az entitás rendszert, tuti lehetne trükközni, de még nem jöttem rá.
-
Na megcsináltam.
Fejlesztés közben a tokeneket tárolom 1db properties fájlban, lehet 10 nyelv, akkor is csak egyben tárolom.
Írtam egy fv-t, ami a property fájl alapján a tokeneket felveszi db-be, ha van értéke a fájlban, akkor az értéket beszúrja, ha nincs akkor az értékhez a token kerül be maga.
A másik fv az adott nyelvhez tartozó property fájlt módosítja a db tartalma alapján. Ha ezt meghívom, akkor vagy 1db token értékét cseréli az adott nyelv property fájlban, vagy a db-ben tárolt összes értéket kiírja a fájlba.
A db-be kerüljenek tokeneket csak akkor kell lefuttatni ha új token kerül a property-be, ekkor az új token bekerül db-be. Innentől csak a 2. fv dolgozik.
Erre írtam egy felületet, ami onblur műveletre ajaxosan frissíti az adott property fájlban és db-ben szereplő értéket is.
A cacheSeconds 1-re van állítva. Jelenleg 100 tokennel nagyon gyorsan változtatva a frontenden az értékeket remekül működik, a context újratöltéstől semmi memória nem növekszik.
Ugye ez által futás közben bármikor beletudok nyúlni a token értékekbe, de a rendszer mégis a property fájlok alapján dolgozik, amihez gondolom valami gyors fa van építve, nem kell szarakodnom folyamatos db basztatás, cachelés dolgokkal.
Azt még nem találtam ki, hogy ezzel a megoldással futás közben új nyelvet, hogy tudok hozzácsapni, de majd még agyalok rajta.
A hibája ennek amit jelenleg látok, hogy a property fájl frissítéskor a fájl egésze újraírodik, ez ha nagyon sok token van lehet sokáig tartana. Ezt letesztelem hamarosan mennyi idő lehet 1milla tokent fájlba írni. A másik pedig az lehet, ha sok ember nagyon gyorsan sok tokent módosít egyszerre, de hát ezt nem tudom egymagam leszimulálni
A db réteg fölöslegesnek tűnik és majdnem, hogy az is, de ha cserélem a war-t a tomcatemben és közben egyik token értékét átírtam, akkor a régi propertiekkel felül csapom a jelenlegit és elveszett a módosítás, ha nem szedem le előtte a property fájlt.
Vélemény?A magam részéről feleslegesnek tartom ennyire túlbonyolítani a dolgot. Ha statikus szövegről van szó, akkor annak a pártján vagyok, hogy tároljuk property fájlban, nyelvenként külön-külön:
messages_hu_HU.properties
messages_en_US.properties
stb...
Egy új nyelv bevezetése pofonegyszerű... persze ehhez matatni kell a fájlrendszeren.Amennyiben vannak olyan szövegek, amelyek gyakran változnak, akkor azok lehetnek adatbázisban (akár in-memory db, akár ennek rendszeres backup-jával). Igazából attól függ, hogy mi a célja, mire használod a szövegeket, mennyire érzékeny adatok ezek, stb.
Azzal, hogy két helyen tárolod a cuccokat, magadra vetted ezek szinkronban tartásának terhét. Ha ez az igény, akkor nincs mit tenni. Gondoltál a teljesítmény problémákra is, csinálsz hozzá pár komponens tesztet, ezeket akár egy CI rendszerben, akár időnként kézzel megfuttatod, és nincs vele teendő. Legfeljebb majd később átírod, a szoftver úgyis mindig fejlődik.
Sosincs jó megoldás, mindig a körülményektől, a felhasználási módtól függ. Mindig kell kompromisszumokat kötni, de ha már ezt teszem, igyekszem úgy, hogy a lehető legegyszerűbb maradjon a végeredmény. Csak ezt tudom tanácsolni neked is. -
WonderCSabo
félisten
-
Sziasztok!
Selenium-os kérdésem volna. Találkozott-e már valaki olyan problémával, hogy az abszolút xPath nem működik?
org.openqa.selenium.NoSuchElementException: Unable to locate element: {"method":"xpath","selector":"html/body/div[1]/div[2]/div[1]/div/div[1]/div/div/div/div[2]/div/div/div[1]/table[4]/tr/td/div/div/button[2]"}
Command duration or timeout: 20.05 secondsKipróbáltam prohardveren, facebookon, google-n, ha a relatív xPath-t kicserélem abszolút xPath-ra, gond nélkül megy. De a tesztelni kívánt oldalnál a fenti hibát dobja.
Thread.sleep-et tettem bele, wait-et is, de semmi.Sajnos csak az abszolút xPath jöhet szóba, mert a felületen lehetnek azonos nevű elemek, pl. gombok, azonos css-el, azonos class-al, és bizonyos részben random ID-val. Pl. név+random szám. Semmi más nem különböztet meg 2 vagy több elemet, csak az abszolút xPath.
-
Aethelstone
addikt
Én első körben egy springet húznék alá, és a garázs management-et egy megfelelő perzisztenciával támogatott szolgáltatás végezné, a garázst elhagyó járműveket a fizetési felszólítás státuszba rakná, vagy archiválná
Én egy Socket szervert csinálnék, ahol az autók SSL/TLS titkosítással elküldenék az indulási időt, útvonaltervet, a szerver pedig OpenMaps-on követné őket
Pl. -
floatr
veterán
Lehet, hogy nem vagyok ideológiailag elég képzett, de ha Java-ban egy példánynak adunk egy remek null értéket, akkor az egy dolog, hogy azonnal nem lesz legyalulva, majd a GC elintézi vmikor, de onnantól fogva az a példány már nem használható szerte szana az alkalmazásban...innentől nem értem ezt a felhajtást...vagy rosszul olvastam el a hozzászólásokat?
Én első körben egy springet húznék alá, és a garázs management-et egy megfelelő perzisztenciával támogatott szolgáltatás végezné, a garázst elhagyó járműveket a fizetési felszólítás státuszba rakná, vagy archiválná
-
Ez esetben egy rendkívül ronda trükkel bár elérheted amit akarsz,viszont ez nem megbízható, ugyanis a GC-re hagyatkozol, arra meg nem nagyon vagy befolyással, és őszintén kétlem, hogy a feladatban ilyet kérnének, tekintve a körítést. Lényeg a lényeg, ha felülírod a finalize() metódust, akkor amikor a GC megszünteti az objektumot, akkor ez a fv 1x meghívódik. Ismétlem, nem tartom valószínűnek hogy ez a feladat célja,ugyanis erre nem lehet építkezni, mivel ilyenkor a számláló csökkentésének időzítése nem determinisztikus a program szempontjából. Gyanítom egy destruktorral rendelkező programnyelvhez való példát próbál a tanár Java-ra erőltetni, ez így kicsit veszélyes dolog.
-
Aethelstone
addikt
Ez esetben egy rendkívül ronda trükkel bár elérheted amit akarsz,viszont ez nem megbízható, ugyanis a GC-re hagyatkozol, arra meg nem nagyon vagy befolyással, és őszintén kétlem, hogy a feladatban ilyet kérnének, tekintve a körítést. Lényeg a lényeg, ha felülírod a finalize() metódust, akkor amikor a GC megszünteti az objektumot, akkor ez a fv 1x meghívódik. Ismétlem, nem tartom valószínűnek hogy ez a feladat célja,ugyanis erre nem lehet építkezni, mivel ilyenkor a számláló csökkentésének időzítése nem determinisztikus a program szempontjából. Gyanítom egy destruktorral rendelkező programnyelvhez való példát próbál a tanár Java-ra erőltetni, ez így kicsit veszélyes dolog.
-
Aethelstone
addikt
-
M_AND_Ms
veterán
Azt lehet, viszont az teljesen rossz irányba tanít akkor... Eleve a kinullázásnak semmi értelme így.
-
WonderCSabo
félisten
-
skoda12
aktív tag
Így ezt nem lehet megoldani, ha null-al teszel egyelővé referenciát, annak egyéb eseménye nincs.
Nem írta a feladat, hogy automatikusan működjön. Legyen public a static számláló és akkor lehet kézzel csökkenteni nullozás után.
-
WonderCSabo
félisten
-
DNReNTi
őstag
Őszintén szólva annyira nem jó ez a feladatkiírás. Én konkrétan nem is értem, hogy milyen null hozzárendelésre gondol.
-
geckowize
őstag
Őszintén szólva annyira nem jó ez a feladatkiírás. Én konkrétan nem is értem, hogy milyen null hozzárendelésre gondol.
-
WonderCSabo
félisten
Sziasztok
Elég beginner levelen vagyok Java-ból és gyakorlok egy könyv segítségével (Gál Tibor: Java programozás, Műegyetemi kiadó, 2002) és elakadtam egy feladatnál, amelyet hosszas guglizás követett, de mégsem jutok semmire.
A feladat a következő:
Konstruáljon meg egy osztályt egy parkolóban lévő autók nyilvántartására! Az
osztály tartalmazzon két példányváltozót a rendszám és a belépési idő, tovább
egy statikus változót a parkolóban jelen lévő autók számának tárolására. Az
utóbbit mindig növeljük eggyel, ha egy autó belépésekor létrehozunk egy új
autó objektumot, illetve csökkentsük eggyel, ha megszüntetünk egy autó
objektumot a null hozzárendeléssel.Ebből az utolsó rész nem megy, azaz, nem tudom a csökkentést hol végezzem. Mainben persze meg tudnám írni (simán meghívok egy függvényt a nullá tétel után), de nyilván nem ez a cél, a Car osztályban kellene valahogy megvalósítani, azonban mivel ez nem C++ és nincs destruktor, a finalize()-nak meg nem garantált a lefutása, nem tudom hogyan kellene figyelni, hogy egy-egy példányt null-á teszek.
Eddig a kód a következőképpen néz ki:
Car.java:
import java.util.Date;
public class Car {
private String licensePlate;
private Date arrival;
private static int numOfCars;
public Car(String lp, Date arr) {
this.licensePlate = lp;
this.arrival = arr;
numOfCars++;
}
public static int getNumOfCars() {
return numOfCars;
}
}Main.java:
import java.util.Date;
public class Main {
public static void main(String[] args) {
Date da = new Date();
Car a = new Car("AAA-111", da);
Date db = new Date();
Car b = new Car("BBB-222", db);
System.out.println(Car.getNumOfCars());
a = null;
b = null;
System.out.println(Car.getNumOfCars());
}
} -
Hola,
Szeretném inicializálni az alábbit:
JetBrains IDEA + Maven + PrimeFaces + jBoss.Már hajam kitépem, mert egyszerűen képtelen vagyok egy ilyen project-et legalább a "hello world"-ig eljuttatni. Az eddig legjobb eredmény, hogy Maven kivételével ment minden, de akkor meg a PrimeFaces p: tag-ekkel nem tudott mit kezdeni a deploy, mivel Maven ekkor nem volt, a függőségeket nem tudtam behúzni. Szétolvastam már az internetet, találtam is példát, olyat is ami letölthető forrást ad, de azzal sem vagyok előrébb, az output üres, pedig változtatás nélkül letoltam. Próbáltam Tomcat-et is, azzal totális kapufa voltam.
Kicsit vakon vagyok még a Java világában, bocsi ha szakmailag nem helyes a fogalmazásom. Tehát magyarul: hogyan kezdjek egy java projektet, amiben PF-et szeretnék használni, és legalább odáig el tudok jutni, hogy kiírjak egy betűt?
Köszi! -
Na megcsináltam.
Fejlesztés közben a tokeneket tárolom 1db properties fájlban, lehet 10 nyelv, akkor is csak egyben tárolom.
Írtam egy fv-t, ami a property fájl alapján a tokeneket felveszi db-be, ha van értéke a fájlban, akkor az értéket beszúrja, ha nincs akkor az értékhez a token kerül be maga.
A másik fv az adott nyelvhez tartozó property fájlt módosítja a db tartalma alapján. Ha ezt meghívom, akkor vagy 1db token értékét cseréli az adott nyelv property fájlban, vagy a db-ben tárolt összes értéket kiírja a fájlba.
A db-be kerüljenek tokeneket csak akkor kell lefuttatni ha új token kerül a property-be, ekkor az új token bekerül db-be. Innentől csak a 2. fv dolgozik.
Erre írtam egy felületet, ami onblur műveletre ajaxosan frissíti az adott property fájlban és db-ben szereplő értéket is.
A cacheSeconds 1-re van állítva. Jelenleg 100 tokennel nagyon gyorsan változtatva a frontenden az értékeket remekül működik, a context újratöltéstől semmi memória nem növekszik.
Ugye ez által futás közben bármikor beletudok nyúlni a token értékekbe, de a rendszer mégis a property fájlok alapján dolgozik, amihez gondolom valami gyors fa van építve, nem kell szarakodnom folyamatos db basztatás, cachelés dolgokkal.
Azt még nem találtam ki, hogy ezzel a megoldással futás közben új nyelvet, hogy tudok hozzácsapni, de majd még agyalok rajta.
A hibája ennek amit jelenleg látok, hogy a property fájl frissítéskor a fájl egésze újraírodik, ez ha nagyon sok token van lehet sokáig tartana. Ezt letesztelem hamarosan mennyi idő lehet 1milla tokent fájlba írni. A másik pedig az lehet, ha sok ember nagyon gyorsan sok tokent módosít egyszerre, de hát ezt nem tudom egymagam leszimulálni
A db réteg fölöslegesnek tűnik és majdnem, hogy az is, de ha cserélem a war-t a tomcatemben és közben egyik token értékét átírtam, akkor a régi propertiekkel felül csapom a jelenlegit és elveszett a módosítás, ha nem szedem le előtte a property fájlt.
Vélemény? -
DNReNTi
őstag
Hola,
Szeretném inicializálni az alábbit:
JetBrains IDEA + Maven + PrimeFaces + jBoss.Már hajam kitépem, mert egyszerűen képtelen vagyok egy ilyen project-et legalább a "hello world"-ig eljuttatni. Az eddig legjobb eredmény, hogy Maven kivételével ment minden, de akkor meg a PrimeFaces p: tag-ekkel nem tudott mit kezdeni a deploy, mivel Maven ekkor nem volt, a függőségeket nem tudtam behúzni. Szétolvastam már az internetet, találtam is példát, olyat is ami letölthető forrást ad, de azzal sem vagyok előrébb, az output üres, pedig változtatás nélkül letoltam. Próbáltam Tomcat-et is, azzal totális kapufa voltam.
Kicsit vakon vagyok még a Java világában, bocsi ha szakmailag nem helyes a fogalmazásom. Tehát magyarul: hogyan kezdjek egy java projektet, amiben PF-et szeretnék használni, és legalább odáig el tudok jutni, hogy kiírjak egy betűt?
Köszi! -
Na megcsináltam.
Fejlesztés közben a tokeneket tárolom 1db properties fájlban, lehet 10 nyelv, akkor is csak egyben tárolom.
Írtam egy fv-t, ami a property fájl alapján a tokeneket felveszi db-be, ha van értéke a fájlban, akkor az értéket beszúrja, ha nincs akkor az értékhez a token kerül be maga.
A másik fv az adott nyelvhez tartozó property fájlt módosítja a db tartalma alapján. Ha ezt meghívom, akkor vagy 1db token értékét cseréli az adott nyelv property fájlban, vagy a db-ben tárolt összes értéket kiírja a fájlba.
A db-be kerüljenek tokeneket csak akkor kell lefuttatni ha új token kerül a property-be, ekkor az új token bekerül db-be. Innentől csak a 2. fv dolgozik.
Erre írtam egy felületet, ami onblur műveletre ajaxosan frissíti az adott property fájlban és db-ben szereplő értéket is.
A cacheSeconds 1-re van állítva. Jelenleg 100 tokennel nagyon gyorsan változtatva a frontenden az értékeket remekül működik, a context újratöltéstől semmi memória nem növekszik.
Ugye ez által futás közben bármikor beletudok nyúlni a token értékekbe, de a rendszer mégis a property fájlok alapján dolgozik, amihez gondolom valami gyors fa van építve, nem kell szarakodnom folyamatos db basztatás, cachelés dolgokkal.
Azt még nem találtam ki, hogy ezzel a megoldással futás közben új nyelvet, hogy tudok hozzácsapni, de majd még agyalok rajta.
A hibája ennek amit jelenleg látok, hogy a property fájl frissítéskor a fájl egésze újraírodik, ez ha nagyon sok token van lehet sokáig tartana. Ezt letesztelem hamarosan mennyi idő lehet 1milla tokent fájlba írni. A másik pedig az lehet, ha sok ember nagyon gyorsan sok tokent módosít egyszerre, de hát ezt nem tudom egymagam leszimulálni
A db réteg fölöslegesnek tűnik és majdnem, hogy az is, de ha cserélem a war-t a tomcatemben és közben egyik token értékét átírtam, akkor a régi propertiekkel felül csapom a jelenlegit és elveszett a módosítás, ha nem szedem le előtte a property fájlt.
Vélemény?Ja és az ékezetes betűket már nem kell konvertálgatni a property fájl kiterjesztése miatt a db vhogy megoldja
Na meg a "nincs adatbázis kapcsolat" is megy db nélkül, de mégis módosíthatom felületről ha akarom
-
"A másik mód az lenne, hogy db-ben tárolok minden token és értéket..."
Ismerek olyan rendszert, ahol adatbázisban tárolják az üziket. Megvan az előnye és a hátránya, ahogy a property fájlnak is. Megjegyzem, ott nem a Properties osztályt használják erre, hanem van rá egy egyedi megoldás.Én a magam részéről a property fájlt favorizálom, mert nem látom azt az üzleti esetet, hogy ezeknek az üzeneteknek futásidőben változniuk kéne. Van egy programod, támogat 30 különböző nyelvet. Az jó esetben 30 property fájl, csókolom.
Ha adatbázisban lenne, akkor tuti készítenél hozzá valamit, amivel menet közben szerkeszteni is lehet. Az 30 db textarea. Ilyenkor történik az, hogy "ó, csak a magyar/angol nyelvűt írom át, a többi nem érdekes". És elszabadul a pokol.
Vagy pl. hogyan tervezed kiírni a "Nincs adatbázis kapcsolat" hibaüzit, ha azt adatbázisban tárolod?
Jó, persze a kivételeket bele lehet tolni a kódba, vagy property-be...Természetesen lehet olyan szöveg, ami gyakran változik, annak valóban nem property fájlban a helye, de a labelek, hibaüzik, stb. szerintem nem ilyenek.
Na megcsináltam.
Fejlesztés közben a tokeneket tárolom 1db properties fájlban, lehet 10 nyelv, akkor is csak egyben tárolom.
Írtam egy fv-t, ami a property fájl alapján a tokeneket felveszi db-be, ha van értéke a fájlban, akkor az értéket beszúrja, ha nincs akkor az értékhez a token kerül be maga.
A másik fv az adott nyelvhez tartozó property fájlt módosítja a db tartalma alapján. Ha ezt meghívom, akkor vagy 1db token értékét cseréli az adott nyelv property fájlban, vagy a db-ben tárolt összes értéket kiírja a fájlba.
A db-be kerüljenek tokeneket csak akkor kell lefuttatni ha új token kerül a property-be, ekkor az új token bekerül db-be. Innentől csak a 2. fv dolgozik.
Erre írtam egy felületet, ami onblur műveletre ajaxosan frissíti az adott property fájlban és db-ben szereplő értéket is.
A cacheSeconds 1-re van állítva. Jelenleg 100 tokennel nagyon gyorsan változtatva a frontenden az értékeket remekül működik, a context újratöltéstől semmi memória nem növekszik.
Ugye ez által futás közben bármikor beletudok nyúlni a token értékekbe, de a rendszer mégis a property fájlok alapján dolgozik, amihez gondolom valami gyors fa van építve, nem kell szarakodnom folyamatos db basztatás, cachelés dolgokkal.
Azt még nem találtam ki, hogy ezzel a megoldással futás közben új nyelvet, hogy tudok hozzácsapni, de majd még agyalok rajta.
A hibája ennek amit jelenleg látok, hogy a property fájl frissítéskor a fájl egésze újraírodik, ez ha nagyon sok token van lehet sokáig tartana. Ezt letesztelem hamarosan mennyi idő lehet 1milla tokent fájlba írni. A másik pedig az lehet, ha sok ember nagyon gyorsan sok tokent módosít egyszerre, de hát ezt nem tudom egymagam leszimulálni
A db réteg fölöslegesnek tűnik és majdnem, hogy az is, de ha cserélem a war-t a tomcatemben és közben egyik token értékét átírtam, akkor a régi propertiekkel felül csapom a jelenlegit és elveszett a módosítás, ha nem szedem le előtte a property fájlt.
Vélemény? -
Aethelstone
addikt
Sajnos a szabadidőm érdeklődés hiányában egy ideje elmaradt, így nem tudok írni. Ha most sikerülne megoldani, hogy háromfelé osztódjak, akkor sem lenne elég, és ráadásul össze is vesznék magammal úgy, hogy egy ideig nem beszélnénk egymással
(#6858) Aethelstone naja, volt hogy dBase-ben ment az "ügyviteli" alkalmazás. Abban az időben a réteg a nikotin volt a billentyűzeten, amit kézhez kaptam.
Nekem 87-es clipper volt az első
-
floatr: Az oldaladon nem lesznek már újabb mesék?
Szívesen olvasnám, jó a stílus és a témák is érdekesekSajnos a szabadidőm érdeklődés hiányában egy ideje elmaradt, így nem tudok írni. Ha most sikerülne megoldani, hogy háromfelé osztódjak, akkor sem lenne elég, és ráadásul össze is vesznék magammal úgy, hogy egy ideig nem beszélnénk egymással
(#6858) Aethelstone naja, volt hogy dBase-ben ment az "ügyviteli" alkalmazás. Abban az időben a réteg a nikotin volt a billentyűzeten, amit kézhez kaptam.
-
Aethelstone
addikt
-
floatr
veterán
Itt nem a sebességről szól csak a történet. Elvi kérdés. Szerintem gányolás, szerinted nem
Pont a részletezett okok miatt is. Tudod, kódkarbantartás, design patternek, stb Szerintem az a gányolás, amikor összevissza kell konvertálgatni, hogy kiküszöböljük az egyik rétegben a másik rétegből adódó problémákat
-
Aethelstone
addikt
Lehet h nem jött le, de szabályozott init-re gondoltam, nem AS módszer szerint.
Annyi felesleges kört futottunk már ezekkel a dolgokkal, és mindig csak magunkat szívattuk meg azzal, hogy még ezt is optimalizálni akartuk. Ha annyira teljesítménykritikus az alkalmazás, hogy nem bír kivárni egy connection-nel annyit, hogy a jsp legyártja az output-ot -- ugye lefordított classról beszélünk itt is, akár egy controller/service esetében -- akkor ott már nem ezen fog múlni a dolog, hanem már magán a perzisztencián és az adatbázison. A jsp nagyságrendileg hamarabb végez, mint amennyi ideig tart az adat előállítása.Ha most egymás után lerajzolgatod egy grafikonra, hogy mi mennyi ideig tartott: pl. entity lekérdezés, 2-3 külön init, beanmap/reflection alapú konverziók kontra entity, 1-2 init, rakat println meg még 1-2 init, akkor az esetek nagy részében azt fogod látni, hogy a grafikonon a 100%-ból elég kis szeletet harap ki a JSP, akárcsak a konverziók. Ismerek olyanokat, akik képesek nagyon lassú JSP-ket gyártani, de ez szerencsére a ritkábbik eset. Még a velocity/freemarker feldolgozás is lényegesen gyorsabb, mint az IP alapú adatműveletek.
Itt nem a sebességről szól csak a történet. Elvi kérdés. Szerintem gányolás, szerinted nem
Pont a részletezett okok miatt is. Tudod, kódkarbantartás, design patternek, stb -
floatr
veterán
Azért kb. nem ugyanaz. Mivel az üzleti logika szerint megesik, hogy az entitás bizonyos getterei meghívódnak, bizonyos getterei meg nem. A reflectionos okoskodás nem bután csak végigmegy.
-
Aethelstone
addikt
-
Hola,
Állásinterjúm lesz frontend pozícióra, egy cégnél ahol java-t használnak. A frontend része miatt nem is aggódok, de a java miatt igen. (Belső info: lesz szó java-ról az interjún). Na most van egy bő heten a randevúig, kérdés: hogyan rázzam gatyába magam java-ból addig? Ajánlott olvasmány, doksik, szoftverek, bármi?
Thx. -
DNReNTi
őstag
Hola,
Állásinterjúm lesz frontend pozícióra, egy cégnél ahol java-t használnak. A frontend része miatt nem is aggódok, de a java miatt igen. (Belső info: lesz szó java-ról az interjún). Na most van egy bő heten a randevúig, kérdés: hogyan rázzam gatyába magam java-ból addig? Ajánlott olvasmány, doksik, szoftverek, bármi?
Thx. -
Mukorka
addikt
Rosszul érted.
public class FooEntity {
private Set<String> names;
private Set<Integer> values;
}
public class FooBean {
private Set<String> names;
private Set<Integer> values;
private List<Bar> bars;
}Nos, ebben az esetben a FooEntity-ből FooBean lesz, de csak azok a property-k kapnak értékek a Bean-ben, ahol az Entity-ben is van. Nyilván a FooBean bars tagja nem kap semmilyen értéke by default, mivel nincs megfelelő Entity tag. Semmi köze a DAO osztályokhoz.
-
Aethelstone
addikt
Hát nálunk a DAO és a business réteg egyben van. Minden logika ejb-ben van de konkrét crud műveletek nincsenek kiszervezve dao rétegbe hanem benne vannak a releváns ejb-ben.
A te példád szerint tehát ha van egy entitásom 5 lazy collection-el és 3 féle logika alapján dőlhet el hogy épp mit fetchelek fel akkor a service rétegedben 3 tök különböző (nyílván egymás leszármazottjai) dto osztályod lesz hogy a reflectionös cucc működjön? Ez elég gázul hangzik
(#6847):
Riporthoz írsz viewt amit felmappelsz és kész. nyílván ez globlális riportokhoz jó, ha sok az adat és bemenő paraméterrel kell dolgozni akkor valóban kell rendes sql-t írni.
-
Mukorka
addikt
Egyébként a Serialization policy is jó, de mi inkább azt az utat választottuk, hogy bean transzformálási szabályokkal korlátozunk. Egy kvázi automata eszközt használunk, ami reflectionnal megy végig és az azonos nevű tagokat transzformálja. Ami pedig nincs benne a Bean-ben vagy máshogy hívják, azt nem transzformálódik.
-
Azt szoktam olvasni, hogy aki nem tud rendesen SQL-t írni, annak jó lesz az ORM, mert úgyis lassú utasításokat írna. Aki meg az ORM-t használja gány módon, akkor az is borzasztó lassú tud lenni.
Alapvetően az sql, pl/sql sose ragadott magával, de az orm tetszik, ezért inkább ezt tanulmányozom jobban
Én itthon nyilván 50soros 4-5táblás dolgokkal szórakozok, ezért az eager-t se érzem, de azt látom, hogy csak azt használni rossz koncepció lenne komolyabb dolognál.
Ha egy alkalmazásnak 1-2részét annyira optimalizálni kell, hogy az ORM nem elég, akkor a dao-ban írnak csak sql-t vagy akkor az hol helyezkedne el és hogyan?Ennek a JTA, DTO dolgoknak utána nézek, ezek teljesen ismeretlen fogalmak számomra.
-
Spring mvc még mindig
A stringeket az oldalakról kihelyeztem properties fájlokba(messages_hu,en stb), ez egyrészt elég borzalmas a karakterkódolás miatt, de perpill se xml, se db-be nem bírtam áthelyezni, ezért túlteszem magam rajta.Ezt már nem rég kérdeztem, hogy lehetne módosítani futás időben ezeket a tokeneket és most foglalkoztam vele. Úgy oldottam meg, hogy a spring.xml-ben a ReloadableResourceBundleMessageSource bean-ben a cacheSeconds-t beállítottam egy számra. A kódban pedig a Properties osztály segítségével manipuláltam az értékeket. Ez működik is, megváltozik az érték, de azt nem bírtam megcsinálni, hogy direktbe a fájlt is felülírja amiből olvas, de az értéket mégis megváltoztatja az oldalon.
Ezzel az a baj, ha újraindítom appot, akkor maradnak a fájlban lévő értékek. Erre azt tudom csinálni, hogy kiíratom minden módosításkor(mondjuk félóránként, hogy ne minden egyes átíratásnál) egy fájlba az értékeket és azt bemásolom a properties fájlba, amikor indítom. Ezzel egyrészt meglennének a változtatások is, aminek nem tudom van-e értelme.A másik mód az lenne, hogy db-ben tárolok minden token és értéket, majd változáskor ez alapján töltöm fel a properties fájlokat, de ezt nem bírtam megcsinálni, semmi értelmes példát nem találtam erre még.
Azt olvastam, hogy ezeket a properties fájlokat egy futó alkalmazásnál újratölteni nagyon nem ajánlott.
Ez igaz erre az esetre is? Vagy ez a context újratöltögetés teljesítmény igényes tud lenni?"A másik mód az lenne, hogy db-ben tárolok minden token és értéket..."
Ismerek olyan rendszert, ahol adatbázisban tárolják az üziket. Megvan az előnye és a hátránya, ahogy a property fájlnak is. Megjegyzem, ott nem a Properties osztályt használják erre, hanem van rá egy egyedi megoldás.Én a magam részéről a property fájlt favorizálom, mert nem látom azt az üzleti esetet, hogy ezeknek az üzeneteknek futásidőben változniuk kéne. Van egy programod, támogat 30 különböző nyelvet. Az jó esetben 30 property fájl, csókolom.
Ha adatbázisban lenne, akkor tuti készítenél hozzá valamit, amivel menet közben szerkeszteni is lehet. Az 30 db textarea. Ilyenkor történik az, hogy "ó, csak a magyar/angol nyelvűt írom át, a többi nem érdekes". És elszabadul a pokol.
Vagy pl. hogyan tervezed kiírni a "Nincs adatbázis kapcsolat" hibaüzit, ha azt adatbázisban tárolod?
Jó, persze a kivételeket bele lehet tolni a kódba, vagy property-be...Természetesen lehet olyan szöveg, ami gyakran változik, annak valóban nem property fájlban a helye, de a labelek, hibaüzik, stb. szerintem nem ilyenek.
-
werszomjas
addikt
-
jetarko
csendes tag
Spring mvc még mindig
A stringeket az oldalakról kihelyeztem properties fájlokba(messages_hu,en stb), ez egyrészt elég borzalmas a karakterkódolás miatt, de perpill se xml, se db-be nem bírtam áthelyezni, ezért túlteszem magam rajta.Ezt már nem rég kérdeztem, hogy lehetne módosítani futás időben ezeket a tokeneket és most foglalkoztam vele. Úgy oldottam meg, hogy a spring.xml-ben a ReloadableResourceBundleMessageSource bean-ben a cacheSeconds-t beállítottam egy számra. A kódban pedig a Properties osztály segítségével manipuláltam az értékeket. Ez működik is, megváltozik az érték, de azt nem bírtam megcsinálni, hogy direktbe a fájlt is felülírja amiből olvas, de az értéket mégis megváltoztatja az oldalon.
Ezzel az a baj, ha újraindítom appot, akkor maradnak a fájlban lévő értékek. Erre azt tudom csinálni, hogy kiíratom minden módosításkor(mondjuk félóránként, hogy ne minden egyes átíratásnál) egy fájlba az értékeket és azt bemásolom a properties fájlba, amikor indítom. Ezzel egyrészt meglennének a változtatások is, aminek nem tudom van-e értelme.A másik mód az lenne, hogy db-ben tárolok minden token és értéket, majd változáskor ez alapján töltöm fel a properties fájlokat, de ezt nem bírtam megcsinálni, semmi értelmes példát nem találtam erre még.
Azt olvastam, hogy ezeket a properties fájlokat egy futó alkalmazásnál újratölteni nagyon nem ajánlott.
Ez igaz erre az esetre is? Vagy ez a context újratöltögetés teljesítmény igényes tud lenni? -
jetarko
csendes tag
Azt szoktam olvasni, hogy aki nem tud rendesen SQL-t írni, annak jó lesz az ORM, mert úgyis lassú utasításokat írna. Aki meg az ORM-t használja gány módon, akkor az is borzasztó lassú tud lenni.
Alapvetően az sql, pl/sql sose ragadott magával, de az orm tetszik, ezért inkább ezt tanulmányozom jobban
Én itthon nyilván 50soros 4-5táblás dolgokkal szórakozok, ezért az eager-t se érzem, de azt látom, hogy csak azt használni rossz koncepció lenne komolyabb dolognál.
Ha egy alkalmazásnak 1-2részét annyira optimalizálni kell, hogy az ORM nem elég, akkor a dao-ban írnak csak sql-t vagy akkor az hol helyezkedne el és hogyan?Ennek a JTA, DTO dolgoknak utána nézek, ezek teljesen ismeretlen fogalmak számomra.
-
Aethelstone
addikt
Elbaxtam. Nyilván JTA-s a cucc. A service és controller réteg között megy a DTO(bean). És a service rétegben lesz az entitásból DTO.
Fáradt vagyok egy cseppet. Ezzel együtt JSP-ben lazy init meg nálam nem menne át a review-en -
Aethelstone
addikt
Magyarán DTO-t használsz két réteg közt a backenden. Nálam a review-n nem menne át
Mostanában legtöbbször SOA alapú rendszereket fejlesztünk, ahol web service-szerű cuccokig utazik az entitás. Ott a serialization-nel le van szabályozva, hogy mi mehet tovább. Szerintem bűn másodlagos, harmadlagos adatábrázolást ráhúzni egy működő struktúrára, ha van eszközöd normális módon kezelni a meglévőt, ráadásul épp ezzel csapod agyon az ORM-et, hogy a service-ig nem jut el a lényeg.
A teljesítményproblémákra azt tudom mondani, hogy persze hogy gyorsabb a háttérben egy SQL végrehajtása, mint többé (eager kontra lazy init), de csak mondom, hogy a hibernate/jpa önmagában egy nagy teljesítményprobléma.
A prezentációs réteggel kapcsolatban viszont nem értem mire gondolsz. Ha a kliens oldalra, akkor nyilván, de JSP-ben simán elfér egy implicit lazy init, amikor oda jut a sor.
Elbaxtam. Nyilván JTA-s a cucc. A service és controller réteg között megy a DTO(bean). És a service rétegben lesz az entitásból DTO.
Fáradt vagyok egy cseppet. Ezzel együtt JSP-ben lazy init meg nálam nem menne át a review-en -
floatr
veterán
Nos, nyilván a sessiont nem lehet a prezentációs rétegig elvinni, de mi úgy szoktuk, hogy a dao és a service között már Bean-ra fordítjuk és kell a francnak a session
Magyarán DTO-t használsz két réteg közt a backenden. Nálam a review-n nem menne át
Mostanában legtöbbször SOA alapú rendszereket fejlesztünk, ahol web service-szerű cuccokig utazik az entitás. Ott a serialization-nel le van szabályozva, hogy mi mehet tovább. Szerintem bűn másodlagos, harmadlagos adatábrázolást ráhúzni egy működő struktúrára, ha van eszközöd normális módon kezelni a meglévőt, ráadásul épp ezzel csapod agyon az ORM-et, hogy a service-ig nem jut el a lényeg.
A teljesítményproblémákra azt tudom mondani, hogy persze hogy gyorsabb a háttérben egy SQL végrehajtása, mint többé (eager kontra lazy init), de csak mondom, hogy a hibernate/jpa önmagában egy nagy teljesítményprobléma.
A prezentációs réteggel kapcsolatban viszont nem értem mire gondolsz. Ha a kliens oldalra, akkor nyilván, de JSP-ben simán elfér egy implicit lazy init, amikor oda jut a sor.
-
Aethelstone
addikt
-
Mukorka
addikt
Nos, nyilván a sessiont nem lehet a prezentációs rétegig elvinni, de mi úgy szoktuk, hogy a dao és a service között már Bean-ra fordítjuk és kell a francnak a session
Nem tetszem érteni amire gondolsz.
-
Aethelstone
addikt
De ha már nincs session akkor hiába hivatkozik rá.
Nálunk egyébként lazy minden és ahol olyan eset van ahol kell valami ott van rá külön fv ami azt is betölti amit kell.Nos, nyilván a sessiont nem lehet a prezentációs rétegig elvinni, de mi úgy szoktuk, hogy a dao és a service között már Bean-ra fordítjuk és kell a francnak a session
-
OpenSessionInViewFilter?
Már látom a tiltakozó kezeket, mert vannak rá elméletek, hogy ez miért nem tudományos, de nálunk majdnem mindegyik projektben ez van, vagy az EntityManager-es párja.
Sokat próbálkoztunk olyan paraméterekkel, ahol megadod, hogy melyik collection-t kéne szintén betölteni a dao-ban, de aztán mindig belefutottunk olyan esetekbe, ahol nem lehetett előre tudni, hogy melyikre lesz szükség, és melyikre nem, aztán betöltöttük mindegyiket - elég tudományos ez is.
-
Mukorka
addikt
Nem teljesen értem, de a lazy-nek nem pont az lenne az értelme, hogy csak azt tölti be, amire szükség van éppen? Ha nem hivatkozol arra a Collectionra, akkor nem töltődik be, ha meg igen, akkor behúzza. Persze, nyilván nem szabad detacholni, de ez már egy másik kérdés.
-
Aethelstone
addikt
Eddig mindig elvoltam eager fetch-el, de most már rendesen akarom írni ezeket, ezért ahol kell áttérek lazy-re. Az jó elképzelés, hogy annyi dao fv-t írok, amennyi esetem van?
Pl entitásban van 10 onetomany lista és az egyikben csak egyiket töltöm meg (Hibernate.initialize), a másikban 2-t és így tovább, ahogy a logika kívánja. Vagy van ennél optimálisabb megközelítés is? Hibernate+Spring -
Eddig mindig elvoltam eager fetch-el, de most már rendesen akarom írni ezeket, ezért ahol kell áttérek lazy-re. Az jó elképzelés, hogy annyi dao fv-t írok, amennyi esetem van?
Pl entitásban van 10 onetomany lista és az egyikben csak egyiket töltöm meg (Hibernate.initialize), a másikban 2-t és így tovább, ahogy a logika kívánja. Vagy van ennél optimálisabb megközelítés is? Hibernate+Spring -
Sziasztok!
Tudtok valami forrást ahol vannak java gyakorlati feladatok esetleg tutorialokkal/megoldásokkal együtt? Az utóbbi fél évben nem volt java-s tárgyam de most fel szeretném frissíteni a dolgokat. Keresgéltem neten de nem találtam olyan feladatgyűjteményt vagy tutorial sorozatot ami alapoktól indul (mondjuk annak nagy részét csak átgörgetném) és esetleg megoldás vagy segítség is van mellette.Amire konkrétan gondolok:
-Feladat leírása
-Esetleg részletkód a feladat elejéből de ez nem fontos
-Több feladat ami végigmegy a java alap vagy közép szintjéig (öröklődés, interfészek, kivételkezelés, absztrakt osztályok, jó kis listás feladatok rendezésekkel, stb).
-Olyan szintű megoldás vagy magyarázat amivel biztosan meg tudom oldani az adott feladatot akkor is ha előtte nem tudtam mit kellene csinálnom.Az angollal nincs probléma tehát jöhetnek nyugodtan olyan linkek is.
Lehet, hogy az ilyen típusú tutorial csak a fejemben létezik, de gondoltam egy kérdést megér itt a topikban.
Addig is marad nekem a Thinking in Java jobb híján (bár sokak szerint nem is kell jobb de én a gyakorlati dolgokat szeretném fejleszteni most).
LMGFY linkeket nem kérek köszönöm. -
Dyingsoul
veterán
Sziasztok!
Tudtok valami forrást ahol vannak java gyakorlati feladatok esetleg tutorialokkal/megoldásokkal együtt? Az utóbbi fél évben nem volt java-s tárgyam de most fel szeretném frissíteni a dolgokat. Keresgéltem neten de nem találtam olyan feladatgyűjteményt vagy tutorial sorozatot ami alapoktól indul (mondjuk annak nagy részét csak átgörgetném) és esetleg megoldás vagy segítség is van mellette.Amire konkrétan gondolok:
-Feladat leírása
-Esetleg részletkód a feladat elejéből de ez nem fontos
-Több feladat ami végigmegy a java alap vagy közép szintjéig (öröklődés, interfészek, kivételkezelés, absztrakt osztályok, jó kis listás feladatok rendezésekkel, stb).
-Olyan szintű megoldás vagy magyarázat amivel biztosan meg tudom oldani az adott feladatot akkor is ha előtte nem tudtam mit kellene csinálnom.Az angollal nincs probléma tehát jöhetnek nyugodtan olyan linkek is.
Lehet, hogy az ilyen típusú tutorial csak a fejemben létezik, de gondoltam egy kérdést megér itt a topikban.
Addig is marad nekem a Thinking in Java jobb híján (bár sokak szerint nem is kell jobb de én a gyakorlati dolgokat szeretném fejleszteni most).
LMGFY linkeket nem kérek köszönöm. -
Aethelstone
addikt
"process ütemezés, memória management, I/O is jól odaver a Windowsnak. Tisztességesen scriptelhető, parancssorból is jól használható"
OMG, semmi baj nincs azzal, ha van preferenciad, etc., de attol, hogy nem ismersz egy adott rendszert, az teged minosit, es nem a rendszert.
Mindket rendszer tokeletesen scriptelheto, parancssorbol hasznalhato, az I/O meg memoriamenedzsment dolgokat inkabb hagyjuk is.Azert tanulja meg a Linuxot, mert nagyon elterjedt szerveroldalon, van, amire kenyelmesebb hasznalni, es tagitja a latokort, ne pumpaljuk mar a hulyeseget a fejebe az elejen, hogy 'az jobb, es kesz'.
-
A Linuxban jóval több lehetőség van mint a Windowsokban. Az alap dolgokban, mint process ütemezés, memória management, I/O is jól odaver a Windowsnak. Tisztességesen scriptelhető, parancssorból is jól használható. A szoftverek installálása, törlése, kultúráltan, csomagkezelővel történik.
Csak akkor vágj bele, ha van türelmed hozzá. A kezdeti lépések nehezek lehetnek, mert a Windows-os gányolás linuxon általában nem működik. Más szemlélet kell hozzá. Sokat kell kezdetekben guglizni, kérdezni, kisérletezni.
Nekem a kedvenc disztróm a Fedora, szerintem annak a legjobb a csomagkezelője (rpm, yum). Az Ubuntu viszont jobban támogatot (két gépemen is az van), több mindenen elfut.
Linuxnál még az is szívás lehet, hogy gyakran újjítanak, cserélgetnek komponenseket, technológiákat, amikkel ugyanazokat a dolgokat lehet megcsinálni, csak másképp. Ez további tanulást és utánnajárást igényel és sokszor akkor amikor az embernek marhára nincs kedve és ideje foglalkozni vele.
Linuxon nagyobb a szabadság. Pl. az ablakezelőt is megválaszthatod. A fő disztrók alapból vmi trendi ablakkezelővel érkeznek (Unity, gnome-3). Azonban ezeknek más a filozófiájuk, mint a megszokott Windows-os GUI-nak, és nem is annyira produktívak (hiába hazudják azt róluk). Ezért érdemes lehet vmi hagyományos ablakkezelővel installálni a rendszert, mint pl. XFace, gnome-mate. A könnyítés kedvéért vannak olyan install médiumok, amik default-ból ezekkel teszik fel a rendszet, pl: Fedora XFCE spin, xUbuntu.
"process ütemezés, memória management, I/O is jól odaver a Windowsnak. Tisztességesen scriptelhető, parancssorból is jól használható"
OMG, semmi baj nincs azzal, ha van preferenciad, etc., de attol, hogy nem ismersz egy adott rendszert, az teged minosit, es nem a rendszert.
Mindket rendszer tokeletesen scriptelheto, parancssorbol hasznalhato, az I/O meg memoriamenedzsment dolgokat inkabb hagyjuk is.Azert tanulja meg a Linuxot, mert nagyon elterjedt szerveroldalon, van, amire kenyelmesebb hasznalni, es tagitja a latokort, ne pumpaljuk mar a hulyeseget a fejebe az elejen, hogy 'az jobb, es kesz'.
-
Egy ideje már nagyon úgy érzem váltani kéne linuxra. Eddig nem tetszett és nem is igazán ismerem a linuxot, de pl a directory átnevezés windowson nem ment, linuxon azonnal. Az éles rendszerek elvileg linuxon futnak, ezért gondolom értelmes lenne fejleszteni is azon, amin fut majd. Tudom h run anywhere , de mégis itt van a példa, hogy nem igaz ez teljes mértékben.
Ha nem csak java-zom, akkor főleg egyre jobban érzem, hogy ez a windows szenvedős tud lenni.
Írtátok korábban, hogy azon érdemes fejleszteni, ami jobban fekszik embernek, de a kérdés, hogy megérné-e szenvedni heteket h váltsak? -
Egy ideje már nagyon úgy érzem váltani kéne linuxra. Eddig nem tetszett és nem is igazán ismerem a linuxot, de pl a directory átnevezés windowson nem ment, linuxon azonnal. Az éles rendszerek elvileg linuxon futnak, ezért gondolom értelmes lenne fejleszteni is azon, amin fut majd. Tudom h run anywhere , de mégis itt van a példa, hogy nem igaz ez teljes mértékben.
Ha nem csak java-zom, akkor főleg egyre jobban érzem, hogy ez a windows szenvedős tud lenni.
Írtátok korábban, hogy azon érdemes fejleszteni, ami jobban fekszik embernek, de a kérdés, hogy megérné-e szenvedni heteket h váltsak? -
Egy ideje már nagyon úgy érzem váltani kéne linuxra. Eddig nem tetszett és nem is igazán ismerem a linuxot, de pl a directory átnevezés windowson nem ment, linuxon azonnal. Az éles rendszerek elvileg linuxon futnak, ezért gondolom értelmes lenne fejleszteni is azon, amin fut majd. Tudom h run anywhere , de mégis itt van a példa, hogy nem igaz ez teljes mértékben.
Ha nem csak java-zom, akkor főleg egyre jobban érzem, hogy ez a windows szenvedős tud lenni.
Írtátok korábban, hogy azon érdemes fejleszteni, ami jobban fekszik embernek, de a kérdés, hogy megérné-e szenvedni heteket h váltsak? -
WonderCSabo
félisten
"Igen az utóbbira gondoltam én is, csak a megvalósításában még nem vagyok annyira perfekt"
Nem nagy művészet:
http://prohardver.hu/tema/java_topic/hsz_6769-6769.htmlEmlékeztem rá, csak lusta voltam kikeresni, köszi.
-
Sk8erPeter
nagyúr
-
_kovi_
aktív tag
Akkor szépen végig kell iterálni a String-en. És ha valahol !isDigit(), akkor nem is kell továbbmenni. Pl.
Másik megoldásként lehet a String-ből Integert vagy valami más, szám típusú adatot parseolni és lehet figyelni a NumberFormatException-t.Köszi!
Igen az utóbbira gondoltam én is, csak a megvalósításában még nem vagyok annyira perfekt.
-
Aethelstone
addikt
-
_kovi_
aktív tag
Köszi !
De az args[] az String, ergó nem eszi meg a char-t.. -
WonderCSabo
félisten
-
glutamin
őstag
Kipróbáltam. Tényleg nem szereti az első sort. De utána már mehet. Valamint a HTML kommentformátum is jó volt. Felkiáltójelet kihagytam az előbb. Most már nyugodtan alszom
Köszi a segítséget -
WonderCSabo
félisten
-
glutamin
őstag
Nem valszeg volt ott a hiba, hanem biztos ott volt a hiba, hiszen az error trace pontosan le is írta. Még azt is, hogy az első sorban a prolog előtt van valami felesleges adat.
Java 1.6-ra vissza váltás mondjuk szerintem annyira nem jó ötlet, minek? Ez oldotta meg a problémát? -
WonderCSabo
félisten
Na sikerült. Még mindig vannak hibaüzenetek, de a tutorial szerint ez most nem érdekes. Valszeg a hibernate.cfg.xml fájlban volt hiba. Kommentezést kiszedtem. Projektben a JAVA környezetet átkapcsoltam 1.7-ről 1.6-ra. Utána már csatlakozott. Akkor még egy adatbázisjelszó javítás volt és most itt tartok:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Hibernate: insert into UserDetails (userName, userId) values (?, ?)Hétvégén nekifekszem és végigzongorázom az alap SQL műveleteket, aztán lassan megnézem mi az a Maven
-
Pont ellenkezőleg, ott akad el először. Az a root cause.
Mikor hiba történik az pl. kivételt (exception) generál, ez megszakítja az adott blokk végrehajtását, a kivétel elkezd visszafelé vándorolni a stack-en. Teszi ezt addig a pontig, amíg azt egy catch ág el nem kapja. Normális esetben a catch blokk csinál is valamit, vagy feloldja a hibát és minden megy tovább onnantól a maga medrében, vagy pl. tovább dobja azt akár egy másik kivételbe csomagolva. Az ilyen elkapom-továbbdobom megoldások eredményezik a "caused by" blokkokat a stacktrace-en. Mire a felhasználó/fejlesztő találkozik a hibával, a kiváltó oka sokszor el is tűnik a felszínen. Ezért érdemes először alul keresni az igazi okot.
Itt ragadnám meg az alkalmat, hogy megjegyezzem, ne csináljatok üres catch blokkokat, mert ott elveszik a hiba, és később nehéz lesz megtalálni.Na sikerült. Még mindig vannak hibaüzenetek, de a tutorial szerint ez most nem érdekes. Valszeg a hibernate.cfg.xml fájlban volt hiba. Kommentezést kiszedtem. Projektben a JAVA környezetet átkapcsoltam 1.7-ről 1.6-ra. Utána már csatlakozott. Akkor még egy adatbázisjelszó javítás volt és most itt tartok:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Hibernate: insert into UserDetails (userName, userId) values (?, ?)Hétvégén nekifekszem és végigzongorázom az alap SQL műveleteket, aztán lassan megnézem mi az a Maven
-
Pont ellenkezőleg, ott akad el először. Az a root cause.
Mikor hiba történik az pl. kivételt (exception) generál, ez megszakítja az adott blokk végrehajtását, a kivétel elkezd visszafelé vándorolni a stack-en. Teszi ezt addig a pontig, amíg azt egy catch ág el nem kapja. Normális esetben a catch blokk csinál is valamit, vagy feloldja a hibát és minden megy tovább onnantól a maga medrében, vagy pl. tovább dobja azt akár egy másik kivételbe csomagolva. Az ilyen elkapom-továbbdobom megoldások eredményezik a "caused by" blokkokat a stacktrace-en. Mire a felhasználó/fejlesztő találkozik a hibával, a kiváltó oka sokszor el is tűnik a felszínen. Ezért érdemes először alul keresni az igazi okot.
Itt ragadnám meg az alkalmat, hogy megjegyezzem, ne csináljatok üres catch blokkokat, mert ott elveszik a hiba, és később nehéz lesz megtalálni. -
Ez pl eszembe sem jutott hogy az utolsó hibaüzenettől kezdjem el nézni. Gondolom ott akad el végleg.
Még nagyon az elején vagyok ennek a HIBERNATE-es dolognak. Korábban PHP/ASP, MySQL/JET Database vonalon már foglalkoztam webes adatbázisos alkalmazással, de most ez nekem még elég kínai.
-
Ha hiba van, az ajánlott megoldás:
Megkérdezni a guglit az utolsó caused by hibaüzenetről.
Első találat. -
Sziasztok!
Egy kis segítséget szeretnék kérni, mert nagyon elakadtam. Egy alap HIBERNATE programocskát szeretnék beüzemelni. Eddig ott tartok, hogy:
- van egy USBWebserver a gépemen, MySQL adatbáziskezelővel, amit webes felületen elérek
- Eclispe környezetet használok
- csináltam egy projektet, benne package
- van hibernate.cfg.xml konfigurációs fájlom
- van egy mapping fájlom
- van egy rövid java osztályom, ami rácsatlakozni az adatbázisra
- valamint a szükséges java osztályok be vannak konfigurálvaA fentieket youtube-os tutorial alapján állítottam össze lépésről lépésre.
A teszt osztál yfuttatásakor viszont a lenti hibaüzenetet kapom. Feltehetően már az adatbázishoz kapcsolódáskor elakad a dolog. Gondolom valamelyik java osztály importálása nem volt jó.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Exception in thread "main" org.hibernate.HibernateException: Could not parse configuration: /hibernate.cfg.xml
at org.hibernate.cfg.Configuration.doConfigure(Configuration.java:2246)
at org.hibernate.cfg.Configuration.configure(Configuration.java:2158)
at org.hibernate.cfg.Configuration.configure(Configuration.java:2137)
at MyMarket.HibernateTest.main(HibernateTest.java:24)
Caused by: org.dom4j.DocumentException: Error on line 1 of document : Content is not allowed in prolog. Nested exception: Content is not allowed in prolog.
at org.dom4j.io.SAXReader.read(SAXReader.java:482)
at org.hibernate.cfg.Configuration.doConfigure(Configuration.java:2238)
... 3 moreMit lenne érdemes ellenőrizni? Mik a főbb komponensek, amiken végig kéne mennem, hogy mi van szarul beállítva/ kimaradt?
Köszi!
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Apple MacBook
- Házimozi belépő szinten
- MasterDeeJay: Low budget (50.000 forint) light gémer gép összerakása
- Milyen alaplapot vegyek?
- HiFi műszaki szemmel - sztereó hangrendszerek
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- One otthoni szolgáltatások (TV, internet, telefon)
- Miskolc és környéke adok-veszek-beszélgetek
- Elektromos autók - motorok
- További aktív témák...
- Apple MacBook Pro 14 M3 Pro (2023) 18GB/512GB SSD karcmentes állapotban 98% akku 94 ciklus
- Motorola Edge 50 Pro 512GB Black Beauty Karcmentes állapot 12GB RAM 6 hónap garancia
- Dell Precision 5530 15,6" FHD, i7 8850H, 16GB RAM, Quadro 4GB VGA, 512GB SSD, jó akku, számla, gar
- ÁRGARANCIA! Épített KomPhone i5 12400F 16/32/64GB RAM RX 9060 XT 16GB GAMER PC termékbeszámítással
- Dell UltraSharp U2415 monitor/ 2 év garancia
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest