- Poco F8 Ultra – forrónaci
- iPhone topik
- Xiaomi 17 Ultra - jó az optikája
- Apple Watch
- Samsung Galaxy S26 Ultra - fontossági sorrend
- Nagy bemutatóra készül az Oppo
- Szaporodik és sokasodik a One UI 8.5
- Huawei Watch Fit 5 Pro - jó forma
- Okosóra és okoskiegészítő topik
- Rég várt frissítést kap az Android tárcsázója
Új hozzászólás Aktív témák
-
Aethelstone
addikt
-
Itt a gc egy példányszintű metódus (instance method), ami késői kötést (late/dynamic binding) használ, így a Counter futásidejű típusa határozza meg, hogy melyik gc() metódus implementáció hívódik meg (polimorfizmus). Ha SubCounter újradefiniálta (override) a gc()-t, akkor ha a list változód futás idejű típusa SubCounter, akkor az override-olt változat fog hívódni, nem tudod meghívni a Counter gc() metódusát azon a példányon keresztül.
(azért írtam zárójeleket, hogy jobban utána tudj nézni ezeknek a fogalmaknak)
-
Intellij megmondja neked, hogy írva vagy olvasva volt a field, setter meglététől függetlenül.
Tényleg
Android Studio-t használom nagy ritkán hobbi projectre.
Ma úgyis elnyomoztam vagy fél napot mert memóriaszivárgásom volt.
Ahelyett hogy 15 perc alatt méltóztattam volna átnézni a szóban forgó kódot.
Persze pár napja beleírtam valami új dolgot, a takarítás meg elfelejtődött. :facepalm:
Viszont ez újdonság volt, mert nem a heap hízott, hanem a Windows folyamat memóriája. -
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. -
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. -
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. -
Á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/45444355Gradle script, ami telepíti a certificate-et?
-
Á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/45444355 -
Na, ki tud nagyobbat mondani a fentieknél, szakmaiságban és megalapozottságban?
Viccet félretéve, egy okból váltanám le a mavenes projektjeinket gradle-re, ha olyan jellegű performancia problémánk lenne, amin a gradle segítene, és a probléma elérne olyan szintet, hogy megérné kidobni kb. 1 hónapot az egyébként jól működő, maintenance és problémamentes projektjeink migrációjára.
Jó én ebből a vitából kiszállok. Nem fogom megérteni sosem a régi dolgokhoz ragaszkodást. Fiatal vagyok hozzá.
-
Na, ki tud nagyobbat mondani a fentieknél, szakmaiságban és megalapozottságban?
Viccet félretéve, egy okból váltanám le a mavenes projektjeinket gradle-re, ha olyan jellegű performancia problémánk lenne, amin a gradle segítene, és a probléma elérne olyan szintet, hogy megérné kidobni kb. 1 hónapot az egyébként jól működő, maintenance és problémamentes projektjeink migrációjára.
-
-
Jonak nez ki.
Annyi megjegyzes, hogy ImageIO es a beepitett javas kepfeldolgozo megoldasok nagyon eroforraspazarloak mind memoria, mind cpu szempontjabol, es a vegeredmeny minosege sem feltetlenul a legjobb, szoval ha komoly megoldas kell, akkor erdemes ezeket kikerulni es valami nativ celeszkozt hasznalni (Pl convert (imagemagick) parancs linuxon), majd a vegeredmenyt direktben kiirni az outputstreamre. -
Nem látom át teljesen a problémádat, a streamektől nem egyértelmű, hogy mi történik. Egy működő példa talán segítene, hogy pontosan lehessen vizsgálni, mire gondoltál.
Nekem úgy tűnik, hogy a lambdák type inference limitációjába ütköztél.
Néhány link, ami indulásnak jó lehet, Brian Goetz kommentjeit érdemes olvasni:
[link]
[link]
[link]
Ha nagyon beleásod magad, javac-vel debug paraméterezéssel (utolsó link) ki lehet vsz. deríteni, hogy mi történik pontosan. -
Nem látom át teljesen a problémádat, a streamektől nem egyértelmű, hogy mi történik. Egy működő példa talán segítene, hogy pontosan lehessen vizsgálni, mire gondoltál.
Nekem úgy tűnik, hogy a lambdák type inference limitációjába ütköztél.
Néhány link, ami indulásnak jó lehet, Brian Goetz kommentjeit érdemes olvasni:
[link]
[link]
[link]
Ha nagyon beleásod magad, javac-vel debug paraméterezéssel (utolsó link) ki lehet vsz. deríteni, hogy mi történik pontosan. -
Kissé összemosódik a kép "nevének" (fájlnév / uri ? ) és magának a képnek a dinamikussága.
Nem világos az sem, hogy jön ide a header. Mindegy, kezdjük el és hátha kiderül, mire gondoltál./kepstream-re mappelsz egy servletet web.xml-ben vagy annotációval, request.getPathInfo-ból kiparse-olod a /kepstream utáni részt, megvan a path paramétered, amivel a képet azonosítod szerver oldalon.
Aztán a httpservletresponse outputstreamedre azt írsz dinamikusan, amit csak akarsz, akár on-the-fly generált képet, akár fájlból beolvasottat.
Plusz content-disposition, content-type headert nem árt kitölteni a céljaidnak megfelelően. -
Lehet force-olni egy windowsos ablak átméretezhetőségét (ResizeEnable util pl), de ettől önmagában még nem fog skálázódni a layout is, vagy igen, vagy nem, vagy jól vagy nem. Sokszor azért veszik fixre az ablak méretet, mert nem tudták rendesen megcsinálni a layout skálázódását.
De ez igazából nem javás kérdés. -
Lehet force-olni egy windowsos ablak átméretezhetőségét (ResizeEnable util pl), de ettől önmagában még nem fog skálázódni a layout is, vagy igen, vagy nem, vagy jól vagy nem. Sokszor azért veszik fixre az ablak méretet, mert nem tudták rendesen megcsinálni a layout skálázódását.
De ez igazából nem javás kérdés. -
Röviden: tényleg nincs.
Csinálhatsz generikus interface-t:
public interface IF1<T extends IF1> {
void add(IF1<T> other);
}
public class Imp1 implements IF1<Imp1> {
@Override
public void add(IF1<Imp1> Other) {
}
}
public class Imp2 implements IF1<Imp2> {
@Override
public void add(IF1<Imp2> other) {
}
}
{
IF1 impraw = new Imp2();
IF1<Imp1> impl1 = new Imp1();
IF1<Imp2> impl2 = new Imp2();
impraw.add(impraw);
impraw.add(impl1);
impraw.add(impl2);
impl1.add(impl1);
impl1.add(impraw);
impl2.add(impl2);
impl2.add(impraw);
pass(impraw, impl1);
pass(impl1, impraw);
pass2(impl2, impl1);
}
private static void pass(IF1<Imp1> one, IF1 other) {
one.add(other);
other.add(one);
}
private static void pass2(IF1 one, IF1 other) {
one.add(other);
other.add(one);
}De ez jobbára csak bohóckodás, mert ha használni akarod, úgyis meg kell adnod a típus paramétert fordítás időben, hogy garantáltan *csak saját magával tudd átadni neki, vagy típus paraméter nélkül hagyod és unchecked leszel. Valamint raw IF1 (impraw-t) IF1 példányt oda vissza tudod passzolgatni futási és fordítási hiba nélkül.
-
Röviden: tényleg nincs.
Csinálhatsz generikus interface-t:
public interface IF1<T extends IF1> {
void add(IF1<T> other);
}
public class Imp1 implements IF1<Imp1> {
@Override
public void add(IF1<Imp1> Other) {
}
}
public class Imp2 implements IF1<Imp2> {
@Override
public void add(IF1<Imp2> other) {
}
}
{
IF1 impraw = new Imp2();
IF1<Imp1> impl1 = new Imp1();
IF1<Imp2> impl2 = new Imp2();
impraw.add(impraw);
impraw.add(impl1);
impraw.add(impl2);
impl1.add(impl1);
impl1.add(impraw);
impl2.add(impl2);
impl2.add(impraw);
pass(impraw, impl1);
pass(impl1, impraw);
pass2(impl2, impl1);
}
private static void pass(IF1<Imp1> one, IF1 other) {
one.add(other);
other.add(one);
}
private static void pass2(IF1 one, IF1 other) {
one.add(other);
other.add(one);
}De ez jobbára csak bohóckodás, mert ha használni akarod, úgyis meg kell adnod a típus paramétert fordítás időben, hogy garantáltan *csak saját magával tudd átadni neki, vagy típus paraméter nélkül hagyod és unchecked leszel. Valamint raw IF1 (impraw-t) IF1 példányt oda vissza tudod passzolgatni futási és fordítási hiba nélkül.
-
Szerintem ha alapszinten programozni akarsz megtanulni akár java-ban, vagy akár másban, akkor először ne ui-ra, grafikára koncentrálj, mert nem ez a lényeg. Alkoss egy (állapottér) modellt fejben a játékodhoz, azonosítsd a különböző entitásokat, azok tulajdonságai, lehetséges állapotváltozásait, a játék logikáját. Vesd papírra, majd kezdj el gondolkodni rajta, hogyan lehet ezt Javába átültetni.
Ha kész a "motor", akkor érdemes a megjelenítésen elkezdeni dolgozni. -
Ha engem kérdezel, 1 óra alatt szerintem nem lehet, és nekem nem is célom. Reális cél számomra annak eldöntése, hogy együtt akarok-e dolgozni a jelölttel, ennek egy - fontos, de nem mindenek felett álló - összetevője a szakmai tudás.
Junioroknál szoktam javasolni inkább, hogy tesztsor vagy kódolós feladat legyen.
Senior esetén nálam szakmai beszélgetés jellegű az interjú, nem kérdezz felelek. Persze ehhez kell az, hogy a másik fél partner legyen ebben és jól tudjunk együtt gondolkodni, kommunikálni. -
Lehet ilyeneken szörnyülködni, de ezek tudása / nem tudása pont nem mond el semmit arról, hogy az illető milyen szoftverfejlesztő.
Sok-sok interjún túl számtalan példát tudnék hozni, hogy ki mit nem tudott interjún, olyanok is akiket később felvettünk és tök jó kollégák lettek. Valószínűleg tőled is lehetne java témában 5/5-öt kérdezni, amit nem tudnál, ~mindenkitől. -
Lehet ilyeneken szörnyülködni, de ezek tudása / nem tudása pont nem mond el semmit arról, hogy az illető milyen szoftverfejlesztő.
Sok-sok interjún túl számtalan példát tudnék hozni, hogy ki mit nem tudott interjún, olyanok is akiket később felvettünk és tök jó kollégák lettek. Valószínűleg tőled is lehetne java témában 5/5-öt kérdezni, amit nem tudnál, ~mindenkitől. -
Aethelstone
addikt
-
A FileOutputStream flush() metódusa, melyet az OutputStream osztályból örököl, így néz ki:
public void flush() throws IOException {
}Szóval ne pazaroljuk a vizet feleslegesen.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Hát elméletileg - a fedő lehajátásával - automatikusan üríteni kéne az edényt, de ezt csak a modern cuccok csinálják... Igazából fogalmam sincs, hogy itt konkrétan van-e értelme kézzel lehúzni, vagy a lezárás automatikusan ürít is.
-
Én. JDK-bol azert kerultek ki a Java EE interfeszek tobbek kozott, hogy egyszerubb legyen a JDK/JSE kiadas. Lasd motivation resz itt [link]. Eleve nem kellett volna belerakni Java EE reszeket.
Eddig sem volt resze a Java EE modulok tobbsege a JDK-nak, onmagaban a JDK nem volt elegendo (Java EE) fejlesztesre.
Ezeket csak azért tartottam fontosnak leírni, mert a hozzászólásodat továbbgondolva arra a következtetésre juthatnak a témában kevésbé járatosak, hogy most lényegesen nehezebb lesz Java EE-re fejleszteni vagy hogy halott a történet, pedig a szóbanforgó változások nem jelentenek ilyet. -
"Fizetős lesz a java az Oracle-től": igen.
Nem.
Még úgy sem állja meg a mondat a helyét, hogy a frissítések lesznek fizetősek.
Azzal a kitétellel állja meg a helyét, hogy bizonyos főverziók frissítései és támogatása és bizonyos idő után.
Mondhatná azt is, hogy lófütyit nektek, EOL után nem csinálok frissítést, helyette megpróbál pénzt csinálni belőle. Tetszik nem tetszik, nekem ugyan nem tetszik, de maradjunk a tényeknél egy szakmai topikban, a riogatást, félinformációk terjesztését, térítést meg hagyjuk.szerk: itthagyom, de áthúzom, mert félrevezető. Tévedtem, az állítás a 10-es verzióig bezárólag állja meg a helyét, az Oracle JDK használata a 11-es verziótól kezdve valóban nem ingyenes "üzleti célú" felhasználásra.
-
Aethelstone
addikt
Ez oké, amikor egyedül toljuk a saját garázs projektben, viszont csapatban illik a standardek, konvenciók, ajánlások szerint fejleszteni, mert jó esetben ez az, ahogyan a többi csapattag is fejleszt, egy új csapattagot így lehet legkönnyebben beilleszteni. Volt szerencsem mar sokfele tragya munkahoz sajnos, ahol a tragya megoldasok valtak konvenciokka, es igen kellemetlen tud lenni, mikor mindenki hulye a csapatban, csak en vagyok helikopter.
Nalam az & PR-nel azért menne a levesbe boolean operandusok eseten, mert a fejlesztok tobbsege szerintem csak a bitenkenti ES jelenteset, egeszeken ertelmezve ismeri es dobna egy exceptiont, ha ilyet lat, es ez netto kidobott ido, ha egy sima feltetelen gondolkodni kell. -
Aethelstone
addikt
Jól mondod, de én még tovább mennék: nem nem csak, hanem egyáltalán nem hatékonyság kérdése. Ha ugyanarra volna való a két operátor, csak az egyik hatékonyabb lenne, akkor nem is létezne a kevésbé hatékony.
Abban a nagyon ritka esetben, mikor &,|,^ valamelyikét írod boolean operandusok esetén és nem elírtad, akkor 99,99..%, hogy a rövidzár/nem rövidzár különbséget akarod valamiért kihasználni.Hát jah. Ennek ellenére pl. a Sonar a &-et simán kifügyöli, hogy Te biztos &&-t akartál használi
Egyébként én aránylag gyakran használom...ahogy írtam is, validálásra, amikor is azt akarom, hogy lefusson mindegyik, mert nem csak le kell futnia, hanem a lefutáskor mondjuk false esetén be is kell pirosozni vmit...nyilván ezt lehet &&-el is, de ez már ízlés dolga. -
-
Nullra kell vizsgálnod:
if (AskDeviceName == null) { ... }Egymásnak ellentmondóak, amiket írsz, vagy valami nagyon béna API-d van, ami egy sima get-re is mellékhatással jár és/vagy nem konzisztens, egyszer működik, egyszer nem.
Nem kérdezek vissza, hogy mi minden ellentmondó, de így nem tudok érvelni, se indokolni, hogy mi hogy...
A 2 kérdésemet akkor egyszerűsítve tenném fel:
Hogyan lehet vizsgálni, ha egy Objektum példánya létrejött (van, létezik)?
És ha létrejött a példány, akkor még lehet null tartalmű, amire hogyan kérdeznétek rá? (azon túl, hogy kiteszed egy lokális változóba, ahogy az előbb írtad (ha nincs más, marad ez a módszer, csak elég bénácskának néz ki a kezdő szememnek))Az összes választ itt szeretném előre (és hátra) megköszönni, nem szemetelném vele a fórmumot a későbbiekben!
(de úgy érzem a végére értünk a témának)
Köszönöm mindenkinek!
-
Aethelstone
addikt
(bocs, válaszra nyomtam, de nem csak neked írtam)
-Null-ra instanceof String false-t ad természetesen. Null az null típusú.
-Pointerezést hagyjuk már, nincs pointer javában, referencia van. Nem ugyanaz a kettő, úgyhogy nem csereszabatos a két fogalom.
-Az eredeti példában AskDeviceName null, és mivel isEmpty egy példány szintű metódusa a String oszálynak, ezért kapsz nullpointexceptiont, mert null referencián próbálod hívni a metódust. Objektum példányod viszont nincs.
-primitív típusoknak van default értékük, ha mezők. Lokális változokként inicializálatlanok by default, compile time error rájuk hivatkozni. -
(bocs, válaszra nyomtam, de nem csak neked írtam)
-Null-ra instanceof String false-t ad természetesen. Null az null típusú.
-Pointerezést hagyjuk már, nincs pointer javában, referencia van. Nem ugyanaz a kettő, úgyhogy nem csereszabatos a két fogalom.
-Az eredeti példában AskDeviceName null, és mivel isEmpty egy példány szintű metódusa a String oszálynak, ezért kapsz nullpointexceptiont, mert null referencián próbálod hívni a metódust. Objektum példányod viszont nincs.
-primitív típusoknak van default értékük, ha mezők. Lokális változokként inicializálatlanok by default, compile time error rájuk hivatkozni.lásd a hibaüzenetet:
Exception in thread "main" java.lang.NullPointerException at hid_joy.HID_joy.main(HID_joy.java:35)többieknek:
-
(bocs, válaszra nyomtam, de nem csak neked írtam)
-Null-ra instanceof String false-t ad természetesen. Null az null típusú.
-Pointerezést hagyjuk már, nincs pointer javában, referencia van. Nem ugyanaz a kettő, úgyhogy nem csereszabatos a két fogalom.
-Az eredeti példában AskDeviceName null, és mivel isEmpty egy példány szintű metódusa a String oszálynak, ezért kapsz nullpointexceptiont, mert null referencián próbálod hívni a metódust. Objektum példányod viszont nincs.
-primitív típusoknak van default értékük, ha mezők. Lokális változokként inicializálatlanok by default, compile time error rájuk hivatkozni. -
Java EE-ben JSF van, használható, de nincs benne túl sok perspektíva szerintem. Ahogy úgy általában a Java alapú frontend fejlesztésben.
Elhangzott már a GWT és Vaadin, előbbi alacsonyabb szintű, jól kiforrott megoldás, utóbbival gyorsan lehet használható frontendet készíteni.
Van még sok egyéb, pl. a Play fw, vagy az Apache webes frameworkök mint Struts/2, Wicket, Tapestry, Stripes.
Ott van a Spring (web) MVC pl. thymeleaffel.
Én már nem tervezek/fejlesztek új projekten java alapokon frontendet, a legtöbb esetben java az API-kat szolgáltatja, valamint a middleware-t, backendet, a frontend pedig böngészőben fut valamelyik javascript alapú frameworkön/libraryben megvalósítva, pl. React, Vue.js vagy Angular valamelyikében.Okés, köszi.
Lassan kezd letisztulni egy kicsit ez az egész Java "ökoszisztéma".
Egyelőre elkezdtem tanulni az alapoktól, aztán később majd kiderül, melyik részéből mit fogok használni. -
Új frontend fejlesztésre JSP-t nem javaslom, egyáltalán nem. Függetlenül az Oracle és Java EE viszonyától, mert ez itt irreleváns. JSP már nem fog fejlődni érdemben, ha Oracle diktál Java EE fronton, ha nem.
Érdemes lehet max pár órát rászánni, megnézni, hogy ilyen is volt, hozzátartozik az evolúcióhoz címszóval, kipróbálod, megérted, pipa, next. Servlet speccel azért érdemes lehet tisztában lenni.A "dobja az Oracle" lehet pozitív vagy negatív is, én inkább pozitívumként élem meg, hogy hátralép egyet és átengedi a communitynek az irányítást, a tényleges következményeket utólag lehet majd értékelni. A jelenlegi állapotában a Java EE egy használható platform. Amire nincs jelenleg Java EE spec, és reális igény, azt belegózhatod majd külső libraryként a stackbe, mint ahogy teheted most is. Én akkor se aggódnék néhány éves távlatban, ha nem volna egyáltalán Java EE fejlesztés. De erről nincs szó.
-
Amikor deklarálsz egy metódust, mindig meg kell adni a visszatérési értékének típusát vagy a voidot.
Vegyünk két metódust:
void m1() {
}String m2() {
return "visszatérési érték";
}m1 void, ami azt jelenti, hogy nincs visszatérési értéke, azaz a metódus hívás nem használható olyan kontextusban, ahol egy értéket várunk.
pl.
String x = m1(); //hibás, mert m1 nem tér vissza értékkel.
System.out.println(m1()); //hibás, mert m1 nem tér vissza értékkel.
x = m2(); // ok, x értéke "visszatérési érték" leszUgyanígy m1 metódus törzsében nem adhatsz meg pl. return "xyxy"; utasítást, mert nem térhetünk vissza értékkel, ellenben megadhatunk return; utasítást, amivel jelezzük, hogy adott ponton térjen vissza a metódus (visszatérési érték nélkül).
pl.void m1() {
return "xyxy"; //hiba
return; //ok, de nem kötelező, itt felesleges
}Többször nekifutottam annak, amit írtál, plusz még utánaolvastam pár helyen és végre értem. A példákat - amiket felhoztál - nagyon köszönöm, így már sokkal egyszerűbb volt megértenem!
Még1x nagyon köszi!(#9703) Aethelstone: Neked is köszönöm a segítséget! Én is így gondolom.
Apropó, hogyhogy nem készült még nyitó hsz? Pár gondolatot, könyvet, ajánlást bele lehetne tenni. Persze eddig a keresővel nagyjából mindent megtaláltam, de szerintem érdemes lenne.
-
Aethelstone
addikt
Amikor deklarálsz egy metódust, mindig meg kell adni a visszatérési értékének típusát vagy a voidot.
Vegyünk két metódust:
void m1() {
}String m2() {
return "visszatérési érték";
}m1 void, ami azt jelenti, hogy nincs visszatérési értéke, azaz a metódus hívás nem használható olyan kontextusban, ahol egy értéket várunk.
pl.
String x = m1(); //hibás, mert m1 nem tér vissza értékkel.
System.out.println(m1()); //hibás, mert m1 nem tér vissza értékkel.
x = m2(); // ok, x értéke "visszatérési érték" leszUgyanígy m1 metódus törzsében nem adhatsz meg pl. return "xyxy"; utasítást, mert nem térhetünk vissza értékkel, ellenben megadhatunk return; utasítást, amivel jelezzük, hogy adott ponton térjen vissza a metódus (visszatérési érték nélkül).
pl.void m1() {
return "xyxy"; //hiba
return; //ok, de nem kötelező, itt felesleges
} -
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]A linkelt oldalon ott van, hogy nem csak ott lehet(ett), de a másik oldalon meg az látszik, hogy wildflyon már nem úgy, de hogy hogy az sehol sincs.
standalone.xml-el meg nesze neked nagyban hangoztatott javas hordozhatóság mellesleg elég gagyi megoldás.
Akkor elengedem a JAAS-t, mert a nem JAAS megoldás pár perc alatt összejött, úgy ahogy kéne, csak az nem "szabványos". -
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. -
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.
-
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. -
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. -
-
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.
-
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. -
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
, 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;Köszi, közben rájöttem, hogy egyszerűen a createEntityManagerFactory paramétere rossz providerre mutatott, mert 8 éve jpaztam utoljára, és a kódrészlet amiből kicopyztam ugyan azt az azonosítót használta több dologra... így meg is lett a kavarodás.
Libeket majd utólag rendezem. Meg megpróbálok minél többet annotációba tenni, ha már egyre többet lehet. Én még a 454676 darab xml-be írogatós időszakba jpa jsf-eztem
De a jaas... az még mindig sötét, ugyan abból az adatbázisból kellene dolgoznia mint a JPA... de hogy? -
-
-
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.Nem a maven a bloatware, hanem a többi. A maven csak felesleges faxni. Igen, hibamentesebb, és profibb a kézi, de főleg gyorsabb
Soha sem bírtam a divatos dolgokat, úgy is néhány év múlva a "maven fúj"/"spring fúj"/"akármi fúj" mert jön egy újabb divatos tool, amit kovács géza mánáger aki a fősulin dreamweawerrel összekattintott egy html oldalt, megmondja(előírja) Hát a cégeknél még arra sincs fantázia hogy saját interjúkérdést kitaláljanak, a nemzetközi divatot követi mind (hashtable keresztkérdések). -
Aethelstone
addikt
Spring fanboykodáson felülemelkedve amúgy érdekes vita lehetne - bár nem valószínű
- , ha írnál valami releváns szakmait is azon kívül, hogy gyűlölöd a Java EE-t. Nem téríteni szeretnék, nekem se a Spring, se a Java EE nem a drágaszágom.
JSF ami zavar? Mást igazából nehéz elképzelnem, hogy mitől viseltetsz ekkora ellenszenvvel Java EE felé. Van megalapozott szakmai alapja vagy csak valami berögződés? Netán előző életedben EJB 1.1-et kellett használnod glassfish 1.0-n és azóta is rémálmokat okoz?
Elmúlt 4 évben többségében architektként 10+ Java EE projektem volt , de több Springes is, sőt most van egy OSGi leváltás is, volt zöldmezős, brownfield, meg totál legacy is. Sosem éreztem, hogy Spring az húde, Java EE meg blee.
Amikor tech stacket mérlegelünk architekt boardon, akkor általában sokadik szempont, hogy a Spring jellegéből fakadóan néhány lépéssel Java EE előtt jár.
GWT-t használsz meg Vaadint, közben írod, hogy IT-ban az évek az örökkévalóságot jelentik, holott ezek sem éppen jövőbe mutató technológiák finoman szólva és a trendek nem efelé mutatnak. Hogy van ez? -
Mitől lenne temető? Ennyi erővel az iparág 90%-ára rá lehet mondani, hogy temető. Pl a Javára is úgy általában.
Ha most azt mondta volna az Ora, hogy Java EE 8 volt az utolsó, és beszántja a francba, akkor is alaphangon egy évtized mire tényleg kikopik.Így van. Én tökre örülök, hogy végre megérkezett pl a hivatalos json binding így sok-sok év után
Talán ha elég sokáig áll az ember féllábon, akkor talán valami reaktív microservice specifikáció is készül a következő 10 évben. Illetve most már talán kicsit gyorsabban, hogy az ora legalább nem lábatlankodik az érdekeltek közt.Amúgy már rég nem az EE a mérvadó, csak kullog a trendek után.
-
-
Egyszer már kérdezted ezt. "Hagyományos értelemben" vett többszörös öröklődés nincs, ha pl. a C++-szal összevetésben vizsgáljuk a kérdést. Ha egy tesztben látod ezt a kérdést, akkor a tesztíró fejével kellene gondolkodni, mert nem biztos, hogy a hosszú válaszra kíváncsi. DE a nincstől bonyolultabb a téma.
Az interface, ahogy emvy anno rámutatott, gyakorlatilag egy abstract class csak publikus metódusok body nélkül (+final static mezők és static metódusok implementációval). Többszörös öröklődés van Javában a saját terminológiája szerint, viszont megkülönbözteti az állapot (ilyen nincs Javában, az interface esetleges statikus mezőit nem tekinti annak, hiszen osztály szintűek), implementáció (default interface Java 8-tól, +esetleg static interface method, szintén Java 8-tól) és típus (interface) szerinti többszörös öröklődést. -
Normális helyen nem szakbarbár fejlesztők vannak, hanem intelligens emberek, akik a fejlesztésen túl egyéb
kapcsolódó területeket is képesek megismerni, átlátni a szükséges mértékig.Business analyst semmiképp sem csinál technikai specifikációt az üzleti igényből. Üzleti igényből készíthet pl. funkcionális specifikációt, user storyt vagy bármit, ami már közelebb áll ahhoz, ami közös alapot képezhet a fejlesztőkkel. De egyáltalán nem szokatlan normálisan helyen sem, hogy egy fejlesztő csapat dolgozza fel az üzleti igényt és talál ki megoldást rájuk, hiszen a szoftverekhez sokkal jobban ért mint az üzlet. Pl. az üzlet nem fogja neked megmondani, hogy milyen egy modern ergonomikus, jól használható webes felület.
Persze az értelmes vitát úgy kéne kezdeni, hogy ki mit ért technikai specifikáció alatt, üzleti elemző alatt, üzleti igény alatt, mert ezek cégenként, területenként mást és mást jelenthetnek. -
A segítségkérésed itt offtopik. Nem csak a processing vs java miatt, hanem az "oldja már meg valaki helyettem a beadandómat" is.
Ez itt egy fórum, aminek az az értelme, hogy tudást, véleményt osszunk meg.
Te meg privátban kértél segítséged, konkrétumot nem írva, kvázi arra utalva hogy oldja meg helyetted valaki. Hülye lesz bárki minimum órákat beletenni és téged pátyolgatni, csak azért, hogy neked jó legyen.
Van álláshirdetés kategória. Ha azt akarod, hogy csinálja meg valaki helyetted, akkor tedd fel oda a hirdetésed.
Az meg, hogy neked áll feljebb, szánalmas. Magyar ugar? Tanulj, olvass el egy könyvet esetleg, ne másoktól várd a megoldást.
Amúgy meg levelező szakon alapvetés, hogy nem fogják neked szájbarágósan leadni az összes szükséges tudást, azért levelező. Azt feltételezi, hogy a hiányzó részt te rakod mellé. Lehet, hogy tájékozódni kéne mielőtt minden szar, csak a szegény diák nem, akinek dolgoznia kell a tudásért. -
Vegul ugy oldottam meg, hogy a Server UDP-vel broadcastolja a TCP ip cimet, aztan ha a kliens elkapja az UDP csomagot, akkor parosodik a Serverrel TCP-n
Mukodik tokeletesen es igy nem kell kezzel megadni a kliensnek a server ip cimét. -
Aethelstone
addikt
Az alapokat azért nem ártana elsajátítani mielőtt nekiállsz egy hello worldnél komolyabb feladatnak. Az értékadás pl. elég alap.
A kliensek.get(i) egy függvényhívás. Függvényhívás mint bal oldali kifejezés azt jelentené, hogy a hívás visszatérési értékének akarsz értéket adni. Ennek nincs értelme nyilván javában. Értéket adni változónak lehet. Egy lista adott elemét a set metódussal tudod lecserélni.
szerk: mindegy, már itt marad.Ráadásul a server.accept() nem is így használandó, hanem a ServerSocket példány streamjeit csesztetjük. Elte....istenem....a jövő katonái
-
A lista nem tömb, ha a listából törölsz egy elemet, akkor csökken a lista hossza.
Tehát az utolsó for ciklusodban, ha jól látom i=4-nél már csak 3 elemed lesz a listában, és nem tudsz megcímezni a get(4) hívással 4-es indexű elemet. Ha minden elemet törölni akarsz, akkor MyList.clear(); Ha egyesével akarod, akkor mindig az elsőt a MyList.remove(0) hívással, vagy inkább iterator.remove.köszönöm szépen, holnap reggel kipróbálom és jelentkezem amint megvagyok
-
Aethelstone
addikt
-
Chesterfield
őstag
Ha már 4 félév, akkor már miért nem 6 és van egy szakirányú diplomád. Nagy az átfedés a két képzés között, sok esetben ugyanazok az oktatók tanítanak, de az elvárások alacsonyabbak lehetnek - amik amúgy sem túlságosan magasak a példaként felhozott helyen.
Interjú másik oldaláról nézve én biztosan "nagyon megkérdezném" a jelöltet fejlesztői pozícióra, ha ilyen végzettséggel jelentkezik, de a végén úgyis a tudás döntene. Ha a képzés mellett egyénileg képzed magad és elhelyezkedsz gyakornokként közben, akkor van esély ledolgozni a kisebb értékű papírból eredő hátrányokat.Egyébként ha a tudás megvan, egy nem szakirányú műszaki diplomával is simán felvesznek. Pl. vannak/voltak villanyos, gépész, matematikus, fizikus, vegyész, közgazdász fejlesztő / tesztelő kollégáim. Az elején kompromisszumot kell kötni, és bárhogy bejutni valahova, ahol releváns tapasztalatot tudsz szerezni.
Köszönöm szépen a hozzászólást, jöhet még másoktól is
Ez a rengeteg matek tárgy, ami a Bsc-n van, elég ijesztő:
Diszkrét matematika, Matematikai logika, Kombinatorika és gráfelmélet, Lineáris algebra, Analízis, Numerikus analízis, Valószínűségszámítás és statisztikaMíg a FOKSZ-nál csak Diszkrét matematika van.
-
Kő!
Akkor kvázi json-rpc-szerűséget csinálsz?
Azért pl. cache-elhetőség és az api-d könnyű megismerhetősége, akár dokumentáció nélkül fontos szempont lehet. Főleg, ha nem nálad van a frontend, hanem másik csapatnak, beszállítónak kell kommunikálni resource-onként (vagy nálad inkább végpontonként), hogy mi hogy működik. A HTTP metódusok szemantikája lehet közös pont.Nézd, amikor én ezt web service-nek hívtam, mindenki lehurrogott, hogy REST. Én nem akadok fenn az elnevezéseken.
Ami a strukturálását illeti, az eddigi felhasználási területeken a legkevésbé sem volt szükség CRUD-szerű mechanizmusra. Specifikáció van, ha nem lenne, akkor egy ráerőltetett REST felépítés sem segítene nekik, mert nem pet store példaalkalmazásokról van szó
-
Valóban nem írtál. So last year ugye annyit tesz, hogy "lejárt lemez", emvy sejtésem szerint legalább részben viccnek (van ilyen szólás, mém). A +1-et már viszont nem tudtam máshogy értelmezni, minthogy tényleg elavultnak tekinted, és reméltem hátha van valami _új_ alternatíva, amiről lemaradtam.
RESTful egyébként jó téma, jönnek az arcok hozzám interjúzni, szinte már minden szenior javás CV-ben ott van a REST API tervezés és/vagy implementáció, de az alapelveit nem tudja szinte senki elmondani, arról pedig végképp fogalma nincs a többségnek, hogy az alapelvek mit jelentenek megvalósításban. A HTTP-t alig ismerik. RMM-ről senki nem hallott. Addig jutunk el, hogy spring mvc vagy jax-rs annotációk, és GET POST PUT DELETE meg json, azt' jó napot.
Természetesen mint vicc reagáltam rá!
Szerk.: azt hozzátenném a tisztán látás végett, hogy ha most egy webalkalmazást kéne csinálnom akkor természetesen Html5 + Bootstrap 3 + Angularjs és valami api megoldással (laravel, spring) állnék neki.
-
-1
Mit használsz az említett Angular mellé, ha nem REST API-t? Springet említettél, gondolom akkor Spring MVC.
Én most React + Redux kombóval prototipizálok és alapozok egy projektet, de még nincs kőbe vésve. Egyelőre Typescript mellett nem köteleződtem el, ahogy Angular 2 mellett sem. Ha valaki ráérez a JavaScriptre, és elfelejti a javaizmusokat, akkor statikus típusok nem sokat adnak hozzá a munkához, vannak hátrányai is, nálam elsősorban a tooling szempontjából lenne érdekes.
Előtte Angular 1-gyel töltöttem jelentősebb időt, azelőtt pedig klasszikus Java webes megoldásokkal mint JSF *faces, Struts/2, Wicket, de volt közben némi Backbone, GWT, Vaadin és még Extjs is.
-
Aethelstone
addikt
-
Ok, ha megfordítod, SVN mellett mi szól? Egyet tudok mondani, az egyszerűséget, ami abból fakad, hogy nem dvcs. Talán még a részleges checkout, ha valakinek ez szempont.
A git szerintem a legtöbb dolgot jobban tudja, flexibilisebb, rengeteg parancs van, végtelenségig paraméterezhető, gyors, hatékony, mindenre ráhúzható. Komplex problémákat lehet vele megoldani viszonylag egyszerűen. Egyszerűen git > svn.
A szakma SVN-nel szemben ezt preferálja egy ideje, legalább is az a rélsze, amivel én találkozom. Enterprise nyilván lassabban mozdul. Open source közösség egyre inkább ezt preferálja, github kb. megkerülhetetlen manapság, ha kimaradsz, lemaradsz - az eredeti kérdés szempontjából ezt tartom lényegesnek.
Konkrét előnyét is éreztem mostanság az elosztottságnak, normálisan tudtam dolgozni olyan ügyfélnek, akinek a repójához VPN kell (ez a VPN elég trükkös, és igencsak megnehezíti az életet, ha megy). Házon belül több fejlesztővel (folyamatos) VPN elérés nélkül tudtunk dolgozni, egymásnak reviewzni a saját workflownkban, saját eszköztámogatással az ügyfél dolgaitól teljesen függetlenítve magunkat, minden probléma nélkül, elegáns megoldással.
Egyébként most kéne presaleselnem egy svn > git átállást ügyfélnek, az anyagot lehet, hogy megcsinálom, de simán nem erőltetem (nem támogatom), mivel kis, központosított csapatuk van, erőforráshiánnyal, és mást tartok magasabb prioritásúnak. Szóval azért nem vagyok git hívő, csak használom, és látom, hogy jó.
Arról meg szó sem volt, hogy húzza le magát valaki, mert SVN-t használ, eredeti felvetés az volt, hogy érdemes-e git-et tudni.
Én Gradle mellett nem érveltem, mert nem érzem szükségét, ős Mavenes vagyok amúgy. Még a hello worldöm is multimodule maven projekt. -
Azért nem kell szándékosan félreérteni. Nálam simán előfordul, hogy egy adott branchre csak commitolok és remote-ba sosem jut el ( csak a commitok, de azok már másik branchen, vagy a commitok sem).
Sőt egyébként olyan dolgokra is használom a git-et, amiknél nincs is remote, csak az a lényeg, hogy verziókat vissza tudjam követni. Pl. saját doksik, lokális fejlesztői környezetek bizonyos részei, toolok, konfigok verziózása. Bár ez is megoldható svn-nel, csak nem áll már kézre. -
12 év és 8xxx hozzászólás után elhangozhatott-e a topikban már legalább hasonló kérdés?
Mit jelent a teljesen kezdő? Informatikai, matematikai, logikai, algoritmizálási, programozási alapjaid vannak és csak n+1. nyelvként akarod megtanulni, vagy semmi alapod nincs?
Ha előbbi, a Head First (Agyhullám) Java könyvet szokták javasolni, régi, de talán még manapság is jó alapnak.
Ha utóbbi, akkor nehezebb dolgod van, kezdő nyelvként nem a Javát szokták ajánlani, de igazából nem is a Java vagy nem Java lesz a legnagyobb problémád, hanem az, hogy azt a minimális alapot megszerezd, amire már érdemes építeni egy konkrét nyelvet. Ez kemény dió. Ha komolyan gondolod a dolgot, akkor talán valamelyik prog infó szak első évi kurzusainak jegyzeteivel kellene kezdeni. Csak baromi nehéz kiszűrni, hogy mi a tényleg releváns, hasznos rész. -
A concurrent-xy már nem a datasource-hoz tartozik, hanem az EE alrendszer JSR 236-hoz kapcsolódó beállításai.
Amibe pedig belefuttottál az az, hogy Java EE 7-ben meg kell adni default datasource-ot (wildflynál ee alrendszer default-bindings-nál), aminek validnak kell lennie, ez wildflynál az alap disztibúcióban az ExampleDS, ami egy dummy h2 db, amit wildfy alapból tartalmaz.harylmu: még nem látok ki a fejemből rendesen, de nem az van, hogy resource filteringet eresztesz rá a libre, ami ha tényleg elvégzi a resource filteringet, akkor jól elrontja azt? Kivételt kéne felvenni a binárisokra, vagy a resourceokat két részre osztani (include/exclude halmaz).
fingom sincs mi az a filtering, de most false-ra raktam és megjavult.
köszi. -
standalone_xy.xml-ben vagy domain.xml-ben (attól függ hogyan fut a wildflyod) nézd meg, hogy nincs-e ott feleslegesen hivatkozás egy nem létező datasource-ra.
A <subsystem xmlns="urn:jboss:domain:ee:4.0"> alrendszeren belül a <default-bindings \ datasource-t kell nézni, valamint
valamint a <subsystem xmlns="urn:jboss:domain:datasources:4.0"> alrendszeren belül a datasource definíciókat.na megvan a ludas:
<subsystem xmlns="urn:jboss:domain:datasources:4.0">mi ez az concurrent management pontosan? ez volt rosszul megadva, így volt benne valamiért java:jboss/mydatasource, a fönti módon átírtam és jó lett! Köszi a helpet!
<datasources>
<datasource jta="true" jndi-name="java:jboss/datasources/mydatasource" pool-name="Amusement_Park" enabled="true" use-ccm="true">
<connection-url>jdbc:mysql://localhost:3306/amusement_park</connection-url>
<driver-class>com.mysql.jdbc.Driver</driver-class>
<driver>mysql-connector-java-5.1.9.jar</driver>
<security>
<user-name>root</user-name>
<password>rolika19</password>
</security>
<validation>
<valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
<background-validation>true</background-validation>
<exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
</validation>
</datasource>
</datasources>
</subsystem>
<subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
<deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}"/>
</subsystem>
<subsystem xmlns="urn:jboss:domain:ee:4.0">
<spec-descriptor-property-replacement>false</spec-descriptor-property-replacement>
<concurrent>
<context-services>
<context-service name="default" jndi-name="java:jboss/ee/concurrency/context/default" use-transaction-setup-provider="true"/>
</context-services>
<managed-thread-factories>
<managed-thread-factory name="default" jndi-name="java:jboss/ee/concurrency/factory/default" context-service="default"/>
</managed-thread-factories>
<managed-executor-services>
<managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/>
</managed-executor-services>
<managed-scheduled-executor-services>
<managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/>
</managed-scheduled-executor-services>
</concurrent>
<default-bindings context-service="java:jboss/ee/concurrency/context/default" [B]datasource="java:jboss/datasources/mydatasource"[/B] managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
</subsystem> -
Persze, jadolod (pl. jd-gui), módosítod, és újrafordítod, a classt kicseréled a jar-ban.
(Feltéve, hogy a licence megengedi. )
Közben figyelj, hogy a class verzió (major/minor) egyezzen, azaz lehetőleg ugyanazzal a jdk-val fordítsd, amivel eredetileg fordítva lett. Ebben a MANIFEST.MF segíthet, ha rendesen ki van töltve, de javap-vel érdemes leellenőrizni.Azt már próbáltam, sikertelenül.
Egyébként már a jd-guival kimentett java fájlt sem tudom javac-vel lefordítani class-ra, pedig nem is módosítottam és ugyanazt a verziót használom...Egyébként a licenc engedi, ugyanis ezt még én írtam, azaz a 10 évvel ezelőtti énem.
-
Szerintem nem hogy ok az alsó, de számomra az a jobb. Nyilván nem azért, mert a kevesebb sor jobb. Számomra olvashatóbb, ez persze attól is függ, hogy az ember milyen kódhoz van szokva.
Szmeby javaslata is jobb, bár erre egy metódus hívás már határeset, és valóban kontextustól függ, de ha egy ismétlődő, üzletileg jelentéssel bíró logikai kifejezés vizsgálatáról van szó, akkor metódus is indokolt lehet.Köszi a megerősítést. Egyetértek. A metódushívást azért nem vettem most bele mert ez nem ismétlődő. De ha az lenne akkor egyértelműen kiszervezném. Ez nem is kérdés.
-
-Faceless-
őstag
Ha minden lényeges infó vagy a teljes kód megvolna a kérdésedben, tapasztalt szem fél perc alatt kiszúrná a problémát. Helyette van sok felesleges infó, amit azért nem biztos, hogy sokaknak van ideje kibogozni.
NPE ad neked sorszámot, az alapján elég egyértelmű szokott lenni szemmel veréssel is a probléma, ha mégsem, akkor bele kell állni debuggal, ha kell, visszanézni a stacken a frame-eket, a változóid állapotát. -
Ezt olyan embernek kellene csinálnia szerintem, aki azért tudja, hogy mit csinál, projekt alapozást eléggé be lehet nézni, és megnehezíteni az egész csapat számára a későbbi munkát. Az ehhez szükséges tudást egész biztosan nem egy fórum hozzászólás alapján fogod megszerezni.
Létrehozhatsz két különálló maven (gradle) projektet.
A-ból elkészül az artifact (pl. jar), azt instalállod a lokális és/vagy távoli repositoryba (Nexus (+nuget akár), vagy Artifactory).
B maven projektből meghivatkozod az A-t mint függőséget.
Az elkészült maven/gradle projektet behúzod a szimpatikus IDE-be, mint maven/gradle projekt.
Vagy használhatsz multi module-t: létrehozol egy parent projektet, A és B modult, és B modulban definiálod A-ra a függőséget.
Gyors kereséssel itt egy példa utóbbira: [link]
Itt A a weather, B a webapp module.Köszi a multi module-t, utána nézek. Erről a projekt alapozásról hol/hogyan tudnék többet "tanulni"?
Tényleg olyan ez a függőség, mint ha azt mondanám, hogy A projekt = Ruby on Rails, B projekt = Webshop Ruby on Rails alapon. Egy kód csak egy helyen legyen alapon.Tudom, hogy kellene egy senior, én nem tartom annak magam, de mediornak igen
. Az a baj, hogy a csapatban mindenki "kezdő" java-s (cégen belül sincs más). Van egy egyetemi oktató, aki jól vágja az algoritmusokat, de a scrum, unit tesztelés, és minden ami a szoftver fejlesztéshez tartozó toolok (clean code, code review) irtózik. A többiek is más nyelvben van munkatapasztalatuk, de ha én nem nyomom meg, hogy na menjünk sprintet tervezni, akkor elülnek a gép előtt. Meg ha valami új dolog van, hogy JavaFX-ben hozzunk létre a GUI-t akkor mindenki mondja, hogy ő még sosem csinált, és nem vállalná be, akkor mivel én "bátor gyerek" vagyok, ezért megcsinálom én, én sem csináltam sosem, de van dokumentáció. Mindenki kezdő Java-ban (meg senki sem senior) így egy kicsit nehéz. Én meg nem félek a kihívástól de én is jeleztem már a vezetőség felé, hogy kell a senior, mert én ehhez még kevés vagyok, de nyitott. Tudom jól, hogy a jó "alapok" fontosak, de ha "magamra vagyok utalva" akkor nem sokat tehetek, a fórumon meg tőlem tapasztaltabbak vannak .
Java-ban több választási lehetőséged van, mint a .NET-ben gondolok itt IDE-re, adatbázis, persze a .NET-ben is van, de ott elég egyértelmű, hogy mindenki ugyanazt az IDE-t és adatbázist használja.Találtam egy harmadik lehetőséget, szoktam github-ra tölteni php kódokat. Utána olvasva pedig műkődik maven és gradle-nál is. A kódokat egy gitlab-os repository-ba mennek. A maven és a gadle tud olyat, hogy a dependncy-t git-es repoból tölti be és használja fel. (Build során le is húzza) Ez mondjuk nekem azért tetszik,mert így ki tudom hagyni azt a lépést, hogy külön nexus / artifactory repository legyen, ráadásul ehhez csak a rendszergazda fér hozzá, hogy beállítsa ezt azt, telepítse a szerverre stb.
Max még egy-két esettanulmányt elolvasok ezügyben. Köszi a választ
-
Jó, akkor anonymous vagy local class se lehet? Pl. nem implementálhatsz egy Comparatort inline. Miért? Hogyan?
Persze, a nested class is class, ha de ha pl. egy beadandó automatikus kiértékelő rendszer valamilyen mesterséges korláta az, hogy "1 db osztályt" használhatsz, akkor lehet opció.
Egyébként nyilván ökörség bármi ilyen megkötés.A szabály az szabály. Sőt, lambdát is tilos írni, hátha véletlenül classra fordul.
Amúgy nem tudom, engem szerencsére nem érint. Csak sajnálom azt, akit igen. Remélem nem megy el tőle a kedve, amíg munkát nem talál. Akkor végre tanulhat is valami hasznosat.
Bocsánat a kirohanásomért, de nehezen viselem, ha oktatás címszó alatt rossz szokásokra nevelnek.Ha az automatikus kiértékelő rendszer (teszt?) az oka, akkor az a hibás és meg kell javítani. A teszt arra való, hogy a public APIn keresztül ellenőrizze a cuccot, se több, se kevesebb. Hogy én azt belül hogyan oldom meg, hány osztályt hozok létre mögötte és azok hogyan viselkednek, ahhoz senkinek semmi köze.
szcsaba1994: Ez a Tabla osztály konkrétan micsoda? Úgy érzem, hogy ez a Node... legalábbis ahogyan használni szeretnéd. A minimax elindul egy Node-on (Tablan?) és rekurzívan egyre mélyebbre haladva bejárja a gyerekeit, akik szintén Node-ok. Vagy a Tabla csak valami payload?
Amúgy igen, a gyerekek és az érték mindenképpen kell a számításhoz. Meg az az infó, ami alaján eldöntöd, hogy az aktuális Node min vagy max. A szülőt én feleslegesnek tartom, de nem ismerem a feladatot, szóval lehet, hogy kell.
Valami ilyesmi:
class Node {
private List<Node> children;
private int heuristicValue;
private boolean isMax; // például, de más módon is el lehetne dönteni hogy min vagy max
...
} -
szcsaba1994
tag
-
Atlantisz48
őstag
-
Nyilván nem keverendő össze, ha ugyanaz lenne a kettő, akkor nem lenne két alapvetően különböző megoldás a nyelvben (interface vs class, implements vs extends).
Az "öröklődés téma része", de nem állítottam, hogy implementációt örökölsz az interfésszel. Lásd pl. [Multiple Inheritance of State, Implementation, and Type] vége. Ez tovább bonyolódik a java 8 default interfész implementációkkal. Állapototot ezzel legyütt sem lehet örökölni.> két alapvetően különböző megoldás a nyelvben (interface vs class, implements vs extends).
Mondjuk a legtobb nyelvben nincs is ilyen megkulonboztetes, az interfesz az vegulis csak egy pure abstract class
-
Az, hogy "nincs".
Arra kell válaszolni, amit kérdeztek. Ha ezt így indoklás nélkül nem fogadják el, akkor hülyék. A túlokoskodás pedig nem biztos, hogy előnyös.
Egyébként vélhetőleg azért nem lett java-ban, mert egyszerű OOP nyelvet akartak. Az interface-ek adnak valamelyest megoldást a problémára.
Az ilyen típusú tesztektől egyébként falnak megyek, főleg mikor senior/lead dev pozícióra is ilyenekkel pre-screenelnek. -
Az, hogy "nincs".
Arra kell válaszolni, amit kérdeztek. Ha ezt így indoklás nélkül nem fogadják el, akkor hülyék. A túlokoskodás pedig nem biztos, hogy előnyös.
Egyébként vélhetőleg azért nem lett java-ban, mert egyszerű OOP nyelvet akartak. Az interface-ek adnak valamelyest megoldást a problémára.
Az ilyen típusú tesztektől egyébként falnak megyek, főleg mikor senior/lead dev pozícióra is ilyenekkel pre-screenelnek. -
Aethelstone
addikt
Ha windows service-re gondolsz, akkor ugye a java alkalmazásodhoz kell egy natív exe wrapper, ami scm-hez illeszkedik, erre vannak kész megoldások, vagy te is készíthetsz ilyen wrappert, ami vagy sima processz indítással vagy akár parancssoron keresztül indítja a java alkalmazást. A kész megoldások, amikkel én dolgoztam, lehetőséget adnak java path beállításra, hogy egy előre definiált helyen lévő jvm-mel indíthasd az alkalmazást. De írtam már olyan wrappert is, ami csak egy batchet indít (ami indítja a javát), ilyenkor természetesen annak a felhasználónak a környezeti változóival (including PATH) fog futni, aki a service indításhoz be van állítva. Ergo az amit írsz, bizonyos esetben igaz lehet - pl. ha a service-t futtató felhasználónak nincs a PATH környezeti változójában java elérési út (a \system-en kívül), vagy a natív wrapper a \system-ben lévő java.exe-hez ragaszkodik -, de nem szükségszerűen van így.
Jaja, nyilván a natív exe wrapper. Mivel a service egy speciális mód, ezért ott a normál PATH beállítások sajnos nem játszanak. Ebben az egész buliban igazából csak az a vicces, hogy pl. a Windows 2008 szerveren máshogy települ fel a 32 bites és a 64 bites Java...mind1..nem is annyira lényeges, de jó nagy szopók voltak ezzel. Egy standalone jetty-re épülő alkalmazást kellett windows service-ként futtatni
-
DeathAdder
veterán
-
NullPointerException-t alapvetően akkor kapsz, ha olyan objektum mezőjére / metódusára hivatkozol, amely null.
A konkrét esetben a lényeg:
...
Connection con = null;
...
stmt = con.createStatement();Nem állítod be a con változódat, null marad, de hívod a metódusát.
Köszi szépen a válaszokat, jól elnéztem. Most már működik. Még lekellett cserélnem ’ ezt erre ' hogy értelmezze az adatbázis
-
Aethelstone
addikt
-
Belepörgettem én is kíváncsiságból, mivel már sokszor előkerült itt is, de csak az első részbe.
Szerintem ez a "leegyszerűsített" magyar nyelvezet nem igazán segíti elő a későbbi továbbfejlődést. A magyar volta miatt is vannak benne olyan se füle, se farka meghatározások, kifejezések, amik szerintem csak félreviszik a dolgot a későbbiekben. Ha valaki komolyan java-t, programozást akar tanulni, megkerülhetetlen az angol nyelvű szakszöveg megértésének képessége, ezt el kell fogadni, és ne is legyen cél a megkerülése, mert később csak hátránya származik belőle.
Azt se mondanám rá, hogy biztos alapokat ezzel a könyvvel kell lerakni. Sok mindent próbál érinteni programozás témakörben, és még azon is túl, de éppen ezért sok mindent felületesen tárgyal csak, sem a JAVA rész nem erős benne, sem a bevezető részek. Nem helyettesít egy rendes bevinfót, egy rendes programozás alapozót, OOP alapozót.
Tele van olyan rövid, felsorolásszerű meghatározással, amik közül némelyik önmagában is meg tudna tölteni fejezeteket, és csak azért szerepel egy néhány soros meghatározás róla, hogy majd be lehessen vasalni.
Ez egy tankönyv, ez a legpozitívabb, amit el tudok mondani róla. -
Hm. Nem rémlik, hogy ezt próbáltam volna. Köszi a tippet, holnap teszek egy próbát.
Én a másik irányba mozdultam el, hozzáadtam a resteasy cuccait is system classként. Sajnos akkor máshol ütötte fel a fejét a ClassCastException. Végül sikerült elérnem, hogy már el sem indult a cucc.
Vagy azt a custom classloader okozta, már nem emélkszem.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Egyébként már a jd-guival kimentett java fájlt sem tudom javac-vel lefordítani class-ra, pedig nem is módosítottam és ugyanazt a verziót használom...
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Konkrét moderációval kapcsolatos kérdések
- Diablo II: Classic és Resurrected
- Genshin Impact (PC, PS4, Android, iOS)
- Poco F8 Ultra – forrónaci
- A fociról könnyedén, egy baráti társaságban
- Milyen légkondit a lakásba?
- Projektor topic
- Eredeti játékok OFF topik
- Motoros topic
- Amlogic S905, S912 processzoros készülékek
- További aktív témák...
- Lenovo Thinkbook 14 G4 Ryzen 7 5825U 8 mag 16 szál Radeon Vega GPU Boltból Garanciával Számlával
- Apple iPhone 16 Pro / 256GB / Kártyafüggetlen / 12Hó Garancia / Akku: 92%
- White STRIX Gaming PC! 7800X3D / RTX 4080 Super / 48GB DDR5 / 1TB NVMe / 1000W Gold! BeszámítOK!
- 27% - MSI MAG Coreliquid I240 AIO Vízhűtés!
- HIBÁTLAN iPhone 13 Pro Max 256GB Graphite -2 ÉV GARANCIA - Kártyafüggetlen, MS5464
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest