- Fórumok
- Szoftverfejlesztés
- Java programozás
- (kiemelt téma)
- Apple asztali gépek
- Melyik tápegységet vegyem?
- A Linux megnégyszerezte magát a Steamen — a Microsoft ismét ígérget
- Milyen széket vegyek?
- Nem indul és mi a baja a gépemnek topik
- Bluetooth hangszórók
- Házimozi belépő szinten
- Fokozatosan erősít majd a szerverpiacon az Intel
- E-book olvasók
- Gaming notebook topik
-
Fórumok
PROHARDVER! - hardver fórumok
Notebookok TV & Audió Digitális fényképezés Alaplapok, chipsetek, memóriák Processzorok, tuning Hűtés, házak, tápok, modding Videokártyák Monitorok Adattárolás Multimédia, életmód, 3D nyomtatás Nyomtatók, szkennerek Tabletek, E-bookok PC, mini PC, barebone, szerver Beviteli eszközök Egyéb hardverek PROHARDVER! BlogokMobilarena - mobil fórumok
Okostelefonok Mobiltelefonok Okosórák Autó+mobil Üzlet és Szolgáltatások Mobilalkalmazások Tartozékok, egyebek Mobilarena blogokIT café - infotech fórumok
Infotech Hálózat, szolgáltatók OS, alkalmazások SzoftverfejlesztésGAMEPOD - játék fórumok
PC játékok Konzol játékok MobiljátékokLOGOUT - lépj ki, lépj be!
LOGOUT reakciók Monologoszféra FototrendFÁRADT GŐZ - közösségi tér szinte bármiről
Tudomány, oktatás Sport, életmód, utazás, egészség Kultúra, művészet, média Gazdaság, jog Technika, hobbi, otthon Társadalom, közélet Egyéb Lokál PROHARDVER! interaktív
Új hozzászólás Aktív témák
-
Lortech
addikt
-
Lortech
addikt
-
Lortech
addikt
Az 1.8-as kód azt jelenti, hogy 1.8-ig értelmezett nyelvi elemeket fogad csak el a compiler. Az nem ugyanaz, hogy 1.8-as JDK/JRE-n is pöccre futni fog. Szerintem.
Ezért van külön source, target és release compiler beállítás. A source az, amit te írtál, a target és a release (9-es verziótól) pedig az, amire Ablakosnak van szüksége, ha 1.8-as runtime-mal kompatibilis (és azon is futni képes) kódot szeretne kapni úgy, hogy 23-as verzión buildel.
-
Lortech
addikt
Adott egy Counter és SubCounter, amely extendálja a Countert. Mindegyikben egy gc() methódus. A kérdésem, hogy a ciklusban (kérdőjeleknél), hogyan tudom az override-olt ősosztály gc()-t hívni?
ArrayList<Counter> cList = new ArrayList<>();cList.add(new SubCounter());cList.add(new Counter());for(Counter list:cList) {System.out.println(list.gc());??????????????}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)
-
Lortech
addikt
Ez egy console application vagy gui? Ha gui van akkor értelemszerűen ne system.out-ot használj logolásra vagy irányítsd át azt egy loggerrel fájlba, vagy console appot generált a jpackege-dzsel --win-console argumentummal.
-
Lortech
addikt
Azért klassz dolog a setter mert nemcsak védve van az adattag.
Hanem amikor keresed hogy hol lett módosítva/elrontva az adattag akkor könnyű megtalálni hol hívták a setter-ét.
Ha például életszerűen 100 helyen olvassák és 1 helyen írják. Mert egyébként setter nélkül nézhetné végig az ember mind a 101 helyet. És azt nem kívánom senkinek.Intellij megmondja neked, hogy írva vagy olvasva volt a field, setter meglététől függetlenül.
-
Lortech
addikt
Na igen, ez a kérdés. Mert spring security nélkül, egy sima szűz springboot alkalmazásban, a restcontroller getmapping metódusainak httpsession id-je minden kérésnél különbözik, 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...
Most tényleg valami principal azonosítót kérjek le, és azokat kulcsként használva töltögessek egy adattároló map-et, ahonnan a kulcs alapján lekérdezhető az adott userhez tartozó adat?
Azt hittem hogy erre van valami belső megoldás mert azért nem hiszem hogy annyira réteg igény lenne.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. -
Lortech
addikt
Mi a legegyszerűbb módja springbootos, jwt springsecuritys, frontenddel rest-en kommunikáló alkalmazásnál az adott sessionhoz, vagy userhez kötött, több requesten átívelő ideiglenes adattárolásra?
Igazából annyit kellene tárolni hogy adott user sessionben hány requestje volt az alkalmazás felé, floodot megelőzni.
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. -
Lortech
addikt
-
Lortech
addikt
helllo, adott egy java 8 (adoptopenjdk) maven springboot projekt.
Innen egy webservicet használnék (ekáer), úgy tűnik resttemplate-el. A programozás része eddig egyszerű volt, de a rendszergazda rész megint szívat, mivel köszönhetően a tetves google-nek ez is SSL...
Jön is az imádottsun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Ezen szeretnék túljutni a lehető leggyorsabban, és legegyszerűbben. Nem érdekel az úgynevezett "biztonság". Hordozhatóvá szeretném csinálni, ilyen cacertes minden gépen ahol fut létrehozós, mindent servicet amit használ letöltős dolgokat el szeretném kerülni.
Azt szeretném, hogy az intellij fejlesztőkörnyezetből, meg war-ba csomagolva és akárhol indítva is ugyanúgy működjön, mindenféle gépenként rendszergazdás tákolás nélkül.
úgy szeretném mint böngészőből, be az url azt jóvan, működik, nem cert marháskodik.Hogy érhetem el ezt? Googlen nem működő, vagy nem ide vonatkozó, vagy hiányos leírásokat találtam csak.
Á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 -
Lortech
addikt
Fordítsuk meg. Olyan use case van amit csak mavennal lehet xml nélkül?

Egy use case ahol ugyan jó a maven, de:
- Spring Boot alkalmazás
- Groovy / Kotlin dsl gradle file
- Yaml konfigurációs fileok
- Java konfigokNekem ebben a körneyezetben egy XML nagyon elütne / nem illene bele. De mint fentebb is beszéltük egyéni preferencia kérdése és semmi több.
Nagyon beakadt ez az XML. Így pár száz maven projekt és modul (és jópár plugin megírása) után azt tudom mondani, hogy az XML-t éreztem a legkevésbé problémásnak a mavenben. Csak a felszínt karcolgatod.
Én sem szeretem az XML-t különösebben, de nem érzem problémának, mert ha mavent is használ a projekt, ez nem jelenti azt, hogy egész nap ezt kell hegeszteni az egész fejlesztő cspatnak, nem olyan fajsúlyú kérdés, mint mondjuk egy frontend template, amiben egész nap hegeszt a fél társaság. A kezdeti project setup után kb. heti rendszerességű, hogy a buildünk változik, leginkább új dependency vagy verzió update miatt, ami teljesen automatikus és fájdalommentes változtatás, bármi érdemi változás ennél ritkább.
Most megnéztem egy kisebb-közepes projektet, van kb. 20 pom.xml össz. 150KB, aminek a 90+%-a copy paste-elt <dependency>, nincs mind module submodule viszonyban, tehát nem mindenhol van öröklődés, ezért a viszonylag nagy méret.Nem XML alapján döntünk, hogy maven vagy gradle.
Saját döntési szempontok:
-mi a probléma, amit meg akarunk oldani, mit kell tudnia a buildnek és mit akarunk azon kívül kezelni.
-van-e bármi nem szokványos körülmény, amiért testre kell szabni a buildet, kell-e egyedi plugint írni hozzá, ez a néhány fajsúlyosabb probléma viszi el az idő 90%-át általában.
-hol fog futni, hova és hogyan kell illeszkednie, mivel kell integrálódnia, gondolok itt meglévő projektekre, IDE-re, teszt keretrendszerre, futtatókörnyezetre, CI/CD-re, konténerekre stb.
-karbantarthatóság, mennyire egyszerű bővíteni, vagy teljesen átalakítani
-olvashatóság, átláthatóság: pl. a konvenciók, ha ismered őket, sokat segíthetnek egy projekt megismerésében egy új résztvevő számára, míg a flexibilitás, hogy kódot tudsz írni a buildben, nem mindig előny, ha a fejlesztő csapat tényleg elkezd nagy mennyiségű kódot beleütni a buildbe.
-várható fejlesztői élmény, pl. mennyire egyszerű vele belőni a fejlesztői környezetet, milyen a tooling támogatás
-megoldás erőforrás igénye (esetleges traininggel együtt)
egyszerű használni, mennyire gyors, kiszámítható és problémamentes
-csapat meglévő kompetenciája, tanulási görbe, community, dokumentáció
-megoldás várható performanciája, ha nagyobb a projekt és számít bármit
...
...
és valahol itt egy kilométerrel lentebb van az, hogy XML-e -
Lortech
addikt
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.
-
Lortech
addikt
-
Lortech
addikt
Szeretném megoldani, hogy az alkalmazásom autentikációjához ne kelljen felhasználónév / jelszó párost használni, hanem automatikusan az Active Directory-ba bejelentkezett windows felhasználó accountját használja az alkalmazás. Ebben szeretnék tanácsokat (esetleg példa vagy tutorial linkeket) kérni. Keresgéltem, de nem találtam használható információt.
Nem mindegy, hogy helyben futó alkalmazás vagy webalkalmazás, de kerberos, SPNEGO, GSSAPI kulcsszavak környékén keresgélj.
-
Lortech
addikt
Ja. Ne keverjük már a kommentet egy javadoc (API) leírással. API leírás kell, ha például 3rd party használja az API-dat, aki nem tudja/akarja elolvasni a forrásodat, hogy megismerje a belső működését.
Olyan komment nem kell, ami a kódot szemeteli tele. Normális esetben a clean code egyúttal jól strukturált és jól olvasható kód is, tehát könnyű megérteni, így nem kell lépten nyomon teletűzdelni olyan kommentekkel, hogy "ez azért van, mert..", vagy "ezt ne változtasd meg mégha nagyon fura is, mert behány tőle a rendszer stb". Ugyanakkor ilyen kód nem létezik, és sokszor jól jön egy-egy magyarázó sor. -
Lortech
addikt
Ez mennyire BestPactice? Én még úgy tanultam, hogy próbáljuk kerülni a lambda-t, mert a forráskód nehezebben olvasható majd. Nem "nyúlfarknyi" példákra, gondolok, hanem nagyobb osztályokra például. Persze most nem azt mondom, hogy 1-1 forEach vagy hasonló nem kerülhet bele csak például nálam egy-egy komplexebb sor átláthatósága debug esetén nehezebb/lassabb.
Persze tény, hogy elegánsabb
Vagy ez teljesen rendben van és marhaságot tanultam?
A best practice az olvasható kód.
Ez persze bizonyos mértékig szubjektív.
Az olvashatóság lambda esetében még inkább az, erősen függ attól, hogy ki az olvasó. Ki mihez van szokva, kinek már állt rá jobban az agya. Már csak azért is, mert a lambda nem volt mindig alap nyelvi elem, és máig rengeteg kódbázis van, ami nem ilyen szemléletben íródott. Ha a csapat, aki a kódot írja és karbantartja, lambdát preferálja, akkor menjen a lambda, de azért ne ész nélkül.
Az adott problémától függ, hogy lambdával olvashatóbb lesz-e a kód, esetleg hatékonyabb vagy elegánsabb. -
Lortech
addikt
Van egy szamomra nem ismert oku jelenseg, bocs kicsit hosszu.
A feladat: volt egy 2 adott tipusu objektumot kombinalo osztaly, most ugyanez kene altalanosan, tobb elemre.
Az objectumok tipusabol ami lenyeges:public interface SpecInterface<K extends Serializable & Comparable<? super K>>
extends DoublePanel<K, String>
ahol:public interface DoublePanel<R extends Serializable,C extends Serializable>
Ezen kivul kene hasznalni a kombinalashoz mindket iranybol egy-egy fuggvenyt:
A SpecInterface-bol:Optional<SubType> getMyList()
A DoublePanel oldalrol meg egy Utils osztalyon keresztul:public static <R extends Serializable, C extends Serializable>
DoublePanel<R, C> mergeColumns(DoublePanel<R, C> left,
DoublePanel<R, C> right)
Ami az eddig kodban volt:SpecInterface<K> f1=...SpecInterface<K> f2=...
es ezutan siman ment a ketfajta meghivas:...=f1.getMyList()...=DoublePanelUtils.mergeColumns(f1, f2)
Most viszont az elemeket praktikus okokbol Stream-bol vennem es hasznalnam ezeket a kombinalashoz szukseges lepeseket. Az elso nyilvanvaloan csak akkor megy vegig, ha a tipusaStream<SpecInterface<K>> fobjs, viszont ekkor a...=fobjs.reduce((f1, f2) -> DoublePanelUtils.mergeColumns(f1, f2)).get();
sornal azt mondja, hogy nem tudja R,C, es K erteket meghatarozni.
Ellenben ha beszurom hogyStream<DoublePanel<K, String>> fobjs2 = fobjs.map(f -> f);
akkor siman lefordul az...=fobjs2.reduce((f1, f2) -> DoublePanelUtils.mergeColumns(f1, f2)).get();
Mukodik, de randa, es jogosan nem szeretnek code review-n, de azt se tudom hogyan kene rakeresni az okra es megoldasra. El tudna valaki legalabb iranyitani hogy merre keressek?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. -
Lortech
addikt
Odáig megvagyok, hogy megvan a dinamikusan összerakott kép egy BufferedImage-ben.
Ezt eddig fájlba tároltam csak le ImageIO.write()-al.
Viszont, ahogy említettem a browsernek ezt most stream-ként adnám át. Ha jól értem akkor monjuk egy response.setContentType("image/jpeg") és a ServletOutputStream megoldja a dolgot?Valami ilyesmi ugrik be nagy vonalakban a leírtak alapján:
BufferedImage generatedImage = imageGenerator(...);response.setContentType("image/jpeg");ServletOutputStream streamOut = response.getOutputStream();ImageIO.write(generatedImage, "jpg", streamOut);out.close();Ez így valamennyire jó irány?
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. -
Lortech
addikt
Milyen megoldással lehetne egy servlet-ben megoldani azt, hogy amikor képet jelenítek meg egy weboldalon, akkor ne a kép nevét használjam az url-ben, hanem egy servlet url-t és az egy kép stream-et adjon vissza header-el?
Tehát ne ez legyen:
<div><img src="valami.hu/valami_kep_neve.jpg"></div>Hanem ez:
<div><img src="valami.hu/kepstream/123456"></div>Azaz dinamikusan generálódna le egy adott kép minden request-re és nem akarom szerver oldalon tárolni.
Anno PHP-ban az elv az volt, hogy elküldtem egy header-t és azután raw-ként az image adatait.
Itt valami hasonló dolog lenne? Header+stream?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. -
Lortech
addikt
Mint fogalom az "Executor Service". Egy támpontot szerettem volna adni a kollágának, hogy szerintem az egyik legegyszerűbb módon oldja meg a problémát.
Az általad említett single threaded executor meg szerintem is egy jó megoldás.
Az emlitett reszletek (single thread pool) nelkul nem oldja meg a problemat, a felteves az volt, hogy van ket async task, tehat a szal inditas megvolt, a kolcsonos kizaras volt a kerdes, amit az executorservice onmagaban nem old meg.
Legegyszerubb fapad megoldas elhangzott, 2-3 threadnel teljesen ok egy kozos eroforrasra lockolni. Ha nem nagyon gyors lefutasuak a szalak, ebben az esetben jobb sorbarendezni a futtatasukat. -
Lortech
addikt
StackOverflowError, ahogy a neve is mutatja, nem exception, hanem Error -> Throwable.
A catchben StackOverflowErrort, Throwable-t vagy Errort próbálj elkapni. -
Lortech
addikt
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. -
Lortech
addikt
Üdv!
JavaFX projektet kellett elkészítenem egyetemi beadandó feladatnak.
Egy telefonkönyv alkalmazást csináltam, ami kontaktokat tárol.
A kontaktok tárolásáról Apache Derby adatbázis gondoskodik, amivel az a gond hogy JDBC-t használ.
Mint utólag kiderült csak JPA-t lehet használni vagy JSON/XML-ben tárolni az adatokat.
Vasárnapig kaptam haladékot, de nagyjából képtelen vagyok addig megoldani.
Szóval ha valaki sos tudna segíteni nekem, természetesen nem ingyen, akkor jelentkezzen kérem és privátban megbeszéljük a dolgot.
Nem hinném, hogy túl nagy feladat lenne annak aki ért hozzá.
Mert összvissz van egy TableView 3 oszloppal és ezeket kellene eltárolni mondjuk JSON-ben, mert az tűnik az opciók közül a legegyszerűbbnek. Csak én még sohasem találkoztam vele és az idő szűke miatt nincs lehetőség a sikertelen próbálkozásokra.Már mindegy elvileg, de azért tegyük tisztába, hogy nem a Derby használ JDBC-t, hanem a Java programod JDBC-t használva kapcsolódik a Derby adatbázishoz, már ha úgy írtad meg. A JPA (hibernate, eclipselink stb) leggyakoribb esetben egy relációs adatbázishoz való csatlakozáshoz a motorháztető alatt szintén JDBC-t használ, csak ezt magasabb absztrakció lévén elfedi előled.
Derby és JPA minden további nélkül összebarátkoztatható, egy ilyen egytáblás projekt összerakása egy tutorial alapján 10 percekben mérhető ([link]), legyen az akár standalone, vagy webes, konténeres megoldás.
Ha már telefonkönyv adatot tárolunk - nem konfigról volt szó, akkor nem látom értelmét (fájl alapon) JSON-nel vagy XML-lel szüttyögni, egy derby vagy akármilyen embedded sql/nosql megfelel a célra JPA-val kombinálva.szerk: Szvsz nincs baj az XML-lel sem, csak a megfelelő feladatra kell használni, ugyanúgy ahogy a JSON-t, Yaml, protobufot stb. Ilyen leegyszerűsítésnek, hogy XML-t úgy általában felejtsük el, szerintem nem sok értelme van, mint ahogy a 2000-es évek XML fetisizmusának se volt sok.
Ismerjük az eszközeinket és használjuk mindig a megfelelőt a megfelelő célra. [law of the instrument] -
Lortech
addikt
Nem írtam, hogy lenne baj a magyar könyvekkel, de általában minden témában vannak jobbak, nemzetközileg elismert szerzőktől. De főleg azért nem javaslom őket, mert ha valaki professzionálisan akar Javát tanulni, akkor jó, ha az angol terminológiát szokja meg. Legtöbb érdemi anyag, cikkek, szakmai fórumok, tananyagok angolul elérhetőek.
-
Lortech
addikt
Nem tudom, hogy érdemes-e egyáltalán magyar könyvet olvasni a témában, szerintem nem, de Java 7-es verzióját, amit ez a könyv tárgyal a 2014-es kiadásban, biztosan nem kéne erőltetni.
-
Lortech
addikt
Illetve ez így gép specifikus lesz?
Ez így java runtime specifikus lesz, a cacerts ahhoz tartozik, ez egy sima fájl a lib/security mappában.
Nálam letölti a fájlt a FileUtils.copyURLToFile. openjdk-8/11 cacertsben benne van a netlock ca certje. Nincs előttem windows éppen, oracle jre ezek szerint nem tartalmazza. Tuti ugyanazzal a java runtime-mal futtatod a programodat, mint aminek a cacertsébe beimportáltad a certet? -
Lortech
addikt
Miért nem simán T a paraméter az első add függvényedben, az interface-ben? Ha azt csinálod, akkor azzal meg tudod akadályozni, hogy a "impl1.add(impraw);" illetve a "impl2.add(impraw);" leforduljon. Persze az impraw.add fogad mindenféle típusú interface-et. Aztán ha type mismatch van, akkor futási időben száll el a
paramEnforcerMatrix.add(paramEnforcerVector); sor.public interface ParamEnforcer<T extends ParamEnforcer<T>> {
void add(T other);
}
class MatrixType implements ParamEnforcer<MatrixType> {
@Override
public void add(MatrixType other) {
}
}
class VectorType implements ParamEnforcer<VectorType> {
@Override
public void add(VectorType other) {
}
}
class Tester {
void test() {
MatrixType matrixType = new MatrixType();
ParamEnforcer paramEnforcerMatrix = matrixType;
VectorType vectorType = new VectorType();
ParamEnforcer paramEnforcerVector = vectorType;
matrixType.add(matrixType);
vectorType.add(vectorType);
paramEnforcerMatrix.add(paramEnforcerVector);
}
}Ha azt csinálod, akkor azzal meg tudod akadályozni, hogy a "impl1.add(impraw);" illetve a "impl2.add(impraw);" leforduljon.
De azt is megakadályozza, hogy az
impl1.add(impl1);
impl2.add(impl2);
forduljon. De ja, igazából nem vagyunk sokkal beljebb az IF1<T> fordítási idejű típussal sem az Imp1 / Imp2 helyett. IF1<T> -vel mind a két imp típuskompatibilis - nem úgy a Matrixtype és Vectortype egymással -, ezért nem kapsz classcastexceptiont, ahogy a példádban viszont igen. Fordítás időben kéne tudni kiküszöbölni ezt az esetet, de a generikusok erre nem jók javában. -
Lortech
addikt
Vagy nagyon pentek van, vagy mindenki masnak trivialis hogy ilyen nincs... es meg hetfon is jo lesz csak felre akarom tenni a problemat es a tobbi reszt csinalni.
Tehat ha van ket osztalyom, Imp1Class es Imp2Class, akik azonos interface-t akarnak megvalositani, amiben van hogy "onmaguk" tipusa kell legyen a parameter, mondjuk van benne egy addMtx(... other) fuggveny. Ilyenkor van-e arra megoldas, hogy az other tipusa az az osztaly legyen amelyik eppen megvalosit? Mert ha az interface-t magat irom tipusnak, akkor nem lehetek biztos benne, hogy ugyanazt kapom (holott az a terv, hogy mindenkit csak sajat tipusaval szabadna osszeereszteni).
Igen, lehet ellenorizni instanceof-fal es akkor meghivni csak a sajatot amugy exception. De ez igy onmagaban nem egy megoldhato dolog? Vegulis nem szukseges, foleg hogy egyutt vszinu csak bemutatozni kene, de most mar idegesit, hogy ennyire hianyos a tudasom vagy megint tul sokat gondolok termeszetesnek.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.
-
Lortech
addikt
Urak. Hogyan tudom megcsinálni, hogy a maven által elkészített jar fájlban az App class (ez az egy main() van benne) hívódjon meg automatikusan, amikor a java -jar usermanager.jar parancssort beírja valaki?
Ez a jelenlegi pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.etcetc.usermanager</groupId>
<artifactId>user-manager</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>user-manager</name>
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
<finalName>usermanager</finalName>
</build>
</project>[link]
szerk: 2.2-t szoktam egyszerű esetben preferálni. -
Lortech
addikt
Sziasztok! Tanulási/fejlődési célból szeretnék leprogramozni egy játékot Javaban, egy Monopoly szerűt. Tudnátok segíteni, hogy merre induljak el, esetleg van valakinek egy alapszintű kódsora ilyesmire? Annyi lenne csak a kikötésem, hogy normális grafikája legyen, ne ilyen windows 95 szerű.
Van valamennyi alap szintű tudásom, kisebb félprogramokat írtam a munkahelyemen, Pythonban már jól alakulnak a dolgok, de most a Java-t szeretném megtanulni, valahogy elakadtam az autodidakta fejlődésben, és úgy gondolom, hogy ez továbblökne egy kicsit. Én szeretném megírni, vagy fejlesztgetni, csak az alapok kellenének, elég lenne egy tábla, meg hogy lépegetnek rajta a játékosok.
Megköszönök előre is minden segítséget!
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. -
Lortech
addikt
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. -
Lortech
addikt
En lattam 5+ eves tapasztalattal rendelkezo java programozot, aki nem volt tisztaban a szamok (sot: sima, 1-2-4 byte-os elojeltelen egeszek) memoriaban valo tarolasanak mikentjevel. Nezett nagyott mikor egy byte-stream-ben kellett volna adott modon a periferiara kuldenie...
(Arra mar nem emlekszem, hogy a kettes szamrendszer mennyire volt neki ujdonsag, de amikor a kettes komplemens elokerult, az tuti nullarol kellett neki elmondani.)
Ja es diplomaja volt mernoki szakrol, nem ilyen himi-humi tanfolyamos, meg ugy kb. 5 evvel ezelotti sztori, nem is azert vettek fel mert barkit.
A kedvencem a temaban akkor is az a 4. eves prog.terv.mat-os, aki a koleszban jott nekem, hogy "torol a space!" - nem ismerte az insert billentyut...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. -
Lortech
addikt
Tudnátok segíteni, hogy a .classpath fájlt miért nem zárja ki a .gitignore?
Az alábbi jelenleg a .gitignore tartalma# Java
*.class
*.jar
*.war
*.ear
# Eclipse
.project
.classpath
.settings
# Idea
.idea
*.iml
*.iws
*.ipr
# OS
Thumbs.db
.DS_Store
# Gradle
.gradle
!gradle-wrapper.jar
# Maven
target
# Build
out
build
bin
# Other
*.log
*.swp
*.bakAz szokott lenni az oka, hogy mar trackelve van a fajl, ilyenkor a gitignore hatastalan.
-
Lortech
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)
-
Lortech
addikt
Ez elég nyilvánvaló. De eddig is lassan mozgott a Java EE. Aminek nem csak hátránya van azért.
Meglátjuk a következő 1-2 évben, hogy mi lesz a Jakarta EE-vel.Szerintem nem nehezebb EE-ben dolgozni, napi szinten használom mindkettőt évek óta és még mindig a specifikus igényektől függene, hogy melyikhez nyúlnék, ha valami zöldmezőset kellene csinálni.
Springben talán egyszerűbb kezdőként eredményeket elérni, de ha megvan a tudás Springben és Java EE-ben is, valamint egy jól összerakott, bejáratott architektúra, akkor elég jól lehet haladni mindkettővel. -
Lortech
addikt
É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. -
Lortech
addikt
-
Lortech
addikt
-
Lortech
addikt
"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.
-
Lortech
addikt
Nem olvastam a cikket, de vagy hülyeséget írtak, vagy félrevezetően írták, vagy féltreértelmezted (valószínűleg utóbbi). A "java" használata továbbra is teljesen ingyenes. A 8-as verzió támogatása szűnik meg 2019-ben, a támogatásért kell fizetni onnantól kezdve, ha igénybe szeretnéd venni. Tehát továbbra sem akadályoz meg semmi abban, hogy 8-as verzió legutolsó kiadását használd az ingyenes támogatás lejárta után is. De ajánlott gyorsabban átállni újabb verziókra.
-
Lortech
addikt
Pontosan, ahogy a kolléga írta. Jackson, Json, Gson témakörben nézelődj.
Szerk, hogy webservice. Hmm. Rest vagy webservice? Nem jó keverni. A rest alapvetően json (ez a szokás), a webservice xml.
Ha restcontroller, akkor feltetelezhetjuk, hogy spring @RestController, default jackson, es @RequestBody automatikusan deszerializalodik (sajat típus is), ha lehetseges. Tehat nem feltetlenul kell egyedi (de-) szerializaciot faragni hozza.
REST(-ful webservice) pedig ugyancsak webszerviz ebben a kontextusban, ahogy a SOAP, en nem szeretem ezt a megkulonboztetest. -
Lortech
addikt
Ezért írtam, hogy ízlés dolga
A könyvekben található dolgokat meg nem véletlenül hívják ajánlásnak 
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. -
Lortech
addikt
A && és & közötti különbség nem csak hatékonyság kérdése. Egyszerűen másra való. & akkor kell, ha mindenképpen végig akarod tolni a láncot, pl. több érték validálása. Logical vs. Conditional
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. -
Lortech
addikt
Ezt úgy értem, hogy a szoksásos CRUD mellet van még pár darab sima hívás ami pl. egy előre, fixen beállított értékkel megcsinálja az updatet, vagy fix értékekkel beilleszt egy újat.
Pl.:
/api/v1/valamiGET/api/v1/valamiPOST, store/api/valami/{id}GET, show/api/valami/{id}PUT, update/api/valami/függvényAmiUpdateliADátumot/{1}POST (jelen esetbe adat postázása nem történik)Kérdés, mi az oka.
Ha valami spéci consumerhez kellett igazítani és megkötés volt, hogy így nézzen ki az api, akkor nincs mit tenni, vsz nem ez a helyzet. Egyéb esetekben irtanám az ilyet tűzzal-vassal. -
Lortech
addikt
Megint itt kérdeznék nem Javá-s kérdést. Nekem erről van véleményem, de a tiétekre is kíváncsi vagyok. Van egy REST API amibe bekerült néhány RPC. Mennyire jó ezeket keverni, továbbá ha ott a REST van-e értelme az RPC-t használni - keverni?
(RPC csak bizonyos értéket settel, kvázi paraméter nélküli update lenne.)
mobal,
Szerintem azért nem jött még válasz, mert nem túl definitív a kérdés. Milyen RPC-ről van szó és pontosan hogyan értendő, hogy "bekerült" a REST API-ba?
-
Lortech
addikt
8-asnak nem szűnt meg a támogatása. 9-es egy köztes release, azért pörgetik ki. Végfelhasználóként használhatsz 8-ast vagy 10.0.1-est. Dev vagy üzemeltetőként meg úgyis azt használod, amelyiket épp kell.
-
Lortech
addikt
Jaj istenkém, hát így hívják az exceptiont, béna, inkonzisztens elnevezés. És akkor mivan?
Historikusan (pl. C és társai esetén) mutató típushoz olyan többletjelentést (pointer aritmetika) társítunk, ami Java referenciáknak nincs, ezért szoktuk különválasztani a kettőt. -
Lortech
addikt
Ez lesz az akkor!
"Objektum példányod viszont nincs"
Hogyan tudom ellenőrizni, hogy van-e példány már, vagy sincs?
(nem az instanceof String-el)
Van erre valami uri huncut megoldás? (hivatalos, bevált, szakmai, tuti)(#9832) bambano:
Kipróbáltam, de mindig true-t ír, a te verziódra is: (tehát van benne valami?)System.out.println(info.getProductString()!=null);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.
-
Lortech
addikt
Nem igaz. A primitív típusoknak van konkrét default értékük.
byte 0
short 0
int 0
long 0L
float 0.0f
double 0.0d
char '\u0000'
boolean false(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. -
Lortech
addikt
Az álláshirdetésekben általában össze vissza van ez. Akkor is beleírják sokszor, ha full spring stacken dolgoznak. Akik kiírják a pozíciókat, sokszor azt se tudják, mi a különbség. Mai napig J2EE-nek nevezik Java EE helyett stb.
-
Lortech
addikt
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. -
Lortech
addikt
Hmmm. Lehet, hogy rosszul fogalmaztam.
Nem a JSP-t akarom megtanulni elmélyedés címszó alatt, hanem majd a későbbiekben szeretnék pár weboldalt összedobni JSP alatt.
Előtte természetesen végigrágom magam kb. a HelloWorld-től a Spring-ig.
Csak az érdekelne, hogy szerintetek mennyire lehet alapozni az EE + JSP-re most, hogy dobja az Oracle.Ú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ó.
-
Lortech
addikt
Sajnos 8 év után újra web servicekkel, és soappel ver a sors. Van egy webservice kliensem, aminek a requestjére érkező response, kb 10 darabb " unmarshalling exception: ? "-t okoz.
Hogy lehet a ?-et debugolni? Sajnos a ? cause nekem túl bőbeszédű, nem tudom melyik részét nézzem. Akkor rég úgy ment, hogy 654x újra és újra átnéztem mindent, majd újra... tényleg nem történt ezekben a borzalmakban fejlődés? Vagy van valami trükk?Most tényleg kérdőjel van az exceptionben, vagy csak nem akartad leírni a konkrét hibát?
Én először megnézném, hogy az adott requestre adott válasz érvényes-e a wsdl-re.
Pl. Soapui megmondja a response-on jobb klikkre.
Aztán leellenőrizném, hogy a wsdl nem változott-e időközben, ugyanazt a wsdl-t implementálja-e a végpont, mint amiből a kliens lett generálva (?).
Ha már muszáj debuggolni, akkor IDE-ben be tudsz állítani exception breakpointot az exception típusra. -
Lortech
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
} -
Lortech
addikt
Ne kövezzetek meg, de nem értek a java-hoz. Viszont módosítani szeretnék egy meglévő programot.
Van benne egy adatszerkezet, aminek az elemeire nem tudom, hogyan kell hivatkozni.A util.inspect(msg.data, false, null)) -el stringként kiíratva így néz ki a tömb(?) :
innen szeretném az Index 150 -hez tartozó 2205 adatot kivenni.
Ilyesmivel próbálkozom, de ez nyilván nem jó :
pl = msg.data['index: 150']
Mi lenne itt a helyes hivatkozási syntax?
Esetleg még háttér info erről a structuráról : link
Ez javascript, nem java.
Alábbi példából talán ki tudod hámozni, ami neked kell, a screenshot alapján készült a struktúra, nem tudtam pontosan azonosítani.
var sampleObj = { cid: 'genBasic',
data: {
xiaomiStruct:
[
{ index : 100, data: 0 },
{ index : 150, data: 2205 }
]
}
}
var indexToLookFor = 150;
var dataObj = sampleObj.data.xiaomiStruct.find(function(e) {
return e.index == indexToLookFor
});
console.log(dataObj.data); -
Lortech
addikt
Tudom milyen a userroles, azért írtam át org...akármi...database-re... csak lehet nem abban a fájlban ahol kéne. De éppen, hogy a standalone.xml-es gányolást akarom elkerülni, és valami projectben lévő xml-es megoldást használni, ami jbosshoz le van írva, de wildflyon úgy látszik már máshogy van, csak nincs leírva hogy, mert a normális dokumentáció az luxus...
Bárcsak ejb meg jpa logint írhatnék... de jó dolog is programozni, és nem konfigurálgatni, és azt kutatni, hogy az ami volt konfiguráció az most nem az, de nincs sehol leírva hogy mi... De hát 20% programozás, 80% xml matatás(konfiguráció), és hogy hol kell elhelyezni, és hogy kéne kinéznie az xml-nek.
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] -
Lortech
addikt
Találtam egy ilyet [link]
Így tetszene, talán így nem lenne olyan szívás JAAS-t beállítani. De ez még jbossra van írva de itt nem írja hogy lenne ilyen "[domain_name]-jboss-beans.xml" a wildfly-ban.Na meg nekem adatbázisból dolgozó login modul kéne, de ha rákeresek wildflynál mindenhol azt írják, hogy code="Database" a jboss doc-ban meg egy ronda org.jboss.security.auth.spi.UsersRolesLoginModule-van, akkor gondolom wildflyban is hasonló kéne legyen nem?
Az kéne, hogy a jsf oldalakhoz JAAS belépés után lehessen hozzáférni, valamelyikhez adminként, valamelyikhez nem adminként, és a belépés után a belépett userről tudjak valamit (legjobb egy user entity lenne, de ha van egy username már az alapján is lekérdezhető az entity).
A JPA háttér a user entityket használja más táblákhoz kapcsolódva is, és a user entityből azonosítani is lehet mindent, de úgy látom jpa-s JAAS azonosítás nincs, csak sima jdbc, de az is jó lenne, csak hogy?Mert mindenféle összefüggéstelen egymásnak ellentmondó, ősrégi "tutorial" van erről...
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. -
Lortech
addikt
És ezt a merget-t hova kell tenni?
Mert így ugyan az a hiba. (getgod() konkrétan az adatbázisból kérdezi leg a god entity-t, ami egy user.
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();#9626 az még lehet más más állapotból volt, most username van, és amiatt sír, hogy "Unknown column 'username' in 'field list'"
De érdekes, mert az events-ben nincs username, hanem username_username-t generál oda a jpa tools, ahogy az applicant osztályban is applicant van, és applicant_username-t generál az adatbázisba. A username az events-ben és az applicant entity-ben is igazából egy hivatkozás az XUser entity-re
@Entity
public class XUser implements Serializable {
private String name;
@Id
private String username;
private String password;
private UsrType type;
@Entity
@Table(name="Events")
public class Event implements Serializable {
@Id
private Date date;
private XUser username;
private String event;
private boolean success;
@Entity
@Table(name="Applications")
public class Application implements Serializable {
@Id
@GeneratedValue
private int id;
private XUser applicant;
private float amount;
private boolean approved;Lehet bugos a JPA Tools table from entities generátora?
Szerk:
kipróbáltam azt hogy stimmeljen pontosan a név, tehát@Entity
@Table(name="Events")
public class Event implements Serializable {
@Id
private Date date;
@Column(name="USERNAME_USERNAME")
private XUser username;
private String event;
private boolean success;De ez sem nyert:
"Cannot add or update a child row: a foreign key constraint fails (`ulytestdb`.`events`, CONSTRAINT `FK_Events_USERNAME_USERNAME` FOREIGN KEY (`USERNAME_USERNAME`) REFERENCES `xuser` (`USERNAME`))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.
-
Lortech
addikt
És ez mit jelent hogy rossz az entity db mappingem? Az entitykből lettek generálva a táblák.
Egyébként most megcsináltam fordítva, a meglévő táblákból generáltam az entityket, így kiegészült pár mappedby-al, meg onetomany, meg manytone annotációval, 2 user hozzáadás ment, bár event akkor is "detached entity passed to persist", de aztán már a user hozzáadás is ugyan ez. Most már generálni sem tudok az entitykből táblát, mert az meg más exceptionnel száll el.
Szóval állítom vissza az ezelőtt mentett workspacet...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. -
Lortech
addikt
Vannak így létrehozott adatbázis táblák, JPA entitykből:
CREATE TABLE Applications (ID INTEGER NOT NULL, AMOUNT FLOAT, APPROVED TINYINT(1) default 0, APPLICANT_USERNAME VARCHAR(255), PRIMARY KEY (ID))
CREATE TABLE Events (DATE DATETIME NOT NULL, EVENT VARCHAR(255), SUCCESS TINYINT(1) default 0, USER_USERNAME VARCHAR(255), PRIMARY KEY (DATE))
CREATE TABLE XUSER (USERNAME VARCHAR(255) NOT NULL, NAME VARCHAR(255), PASSWORD VARCHAR(255), TYPE INTEGER, PRIMARY KEY (USERNAME))
ALTER TABLE Applications ADD CONSTRAINT FK_Applications_APPLICANT_USERNAME FOREIGN KEY (APPLICANT_USERNAME) REFERENCES XUSER (USERNAME)
ALTER TABLE Events ADD CONSTRAINT FK_Events_USER_USERNAME FOREIGN KEY (USER_USERNAME) REFERENCES XUSER (USERNAME)
CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT DECIMAL(38), PRIMARY KEY (SEQ_NAME))
INSERT INTO SEQUENCE(SEQ_NAME, SEQ_COUNT) values ('SEQ_GEN', 0)Xuser létrehozása megy, de eventet már nem lehet, mert:
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column 'user' in 'field list'Akkor is ezt dobja, ha az eventben lévő user példányt létrehozom, és az megy az event entity-be, de akkor is ugyan az, ha konkrétan a JPA-s lekérdezésből jött user példány van az eventbe irányítva.
Ez mitől van? Hogy lehet a wildfly hibernate-jének a végső SQL parancsait kiirattatni mondjuk a konzolra? Az lehet segítene a hiba keresésben.
Valószínűleg rossz az entity-db mappinged, de ez abból amit írtál, nem látszik.
Logolás: org.hibernate (vagy specifikusabb) kategóriára fel kell venni egy loggert és hozzá egy handlert:
[link]
Jboss logging teljesen oké, nem kell log4j vagy egyéb implementáció. -
Lortech
addikt
WARN [org.hibernate.jpa.internal.EntityManagerFactoryRegistry] (default task-3) HHH000436: Entity manager factory name (provajder) is already registered. If entity manager will be clustered or passivated, specify a unique value for property 'hibernate.ejb.entitymanager_factory_name'
Ha
@ManagedBean(name="AnnoTestAdd")
@RequestScoped
public class TestAdd {
private EntityManagerFactory factory= Persistence.createEntityManagerFactory("Ulyprov");
private String username;
private String name;
....Semmi sem történik a JSF-ből való metódushívásra (semmi üzenet), ha:
@ManagedBean(name="AnnoTestAdd")
@RequestScoped
public class TestAdd {
private static final EntityManagerFactory factory= Persistence.createEntityManagerFactory("Ulyprov");
private String username;
private String name;
És akkor sem történik semmi ha applicationscoped-re változtatom.(most már jól emlékszem hogy régen is 10% volt a programozás, 90% a keretrendszerek lelki világának, és bugjainak a kitesztelése
)És mindez azért történik, mert
<h:selectOneMenu value="#{AnnoTestAdd.type}">
<f:selectItems value="#{AnnoTestAdd.type}"/>
</h:selectOneMenu>
Ha ez nincs, működik.
ez még is mi a....?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.
-
Lortech
addikt
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?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. -
Lortech
addikt
Ok, rájöttem, hiányzott a form keret
De most jött a "No Persistence provider for EntityManager named".Mit írjak a persistence-be a provider helyre? Csak hibernate-s provider stringeket találok ha ráguglizok, de nem működik. Vagy milyen JPA implementációt használ ez a wildfly?
Eclipse data source-ként be van állítva, de gondolom az egy másik rendszer rendszerének a rendszere, és nincs átjárás

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; -
Lortech
addikt
<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%@ taglib prefix="h" uri="http://java.sun.com/jsf/html"%>Eclipse: Can not find the tag library descriptor for "http://java.sun.com/jsf/core"
Mi baja? Wildfly-ra van bekonfigolva, runtime provided library-ra.
Egyébként manapság mi a célszerűen használandó dátum-idő osztály? Adatbázisban lesz eltárolva. Jó az öreg java.util.Date?
Húzd be a wildfly jsf függőséget (wildfly 11.0.0 verziót feltételezve):
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-jsf</artifactId>
<version>11.0.0.Final</version>
</dependency>Vagy telepíts jboss tools az eclipse-edbe, és add hozzá a runtime-ot.
-
Lortech
addikt
De azért, büszke vagyok rá, hogy lightweight, kompakt cuccokat tudok összehozni, amit egy másolás után lehet is indítani anélkül hogy egy 6 terabyte-os vinyót megtöltenénk keretrendszerrel, meg a keretrendszer keretrendszerével, és a keretrendszer keretrendszerének a keretrendszerének a függőségkezelő keretrendszerével, amivel lehet a végső keretrendszert keretrendszerelni
De sajnos a divat nem erre visz
hanem hogy "vegyééé új gépet azon menni fog így is"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. -
Lortech
addikt
Vagy TomEE, ha már...
mobal: egyszerűnek egyszerű, de csak egy servlet konténer, így nem alternatívája egy Java EE alkalmazásszervernek.
Amúgy a wildfly is tök egyszerű, alapból is, de elég jól testre is szabható, moduláris.
Productionben pedig leginkább ugyanazon kell futni, mint fejleszteni (persze lehet egy lightosabb profilon), különben tökönlövöd magad, Java EE kompatibilitás ide vagy oda. -
Lortech
addikt
Nem mennék bele egy vitába, de pár dolgot azért megjegyeznék.
Spring Data, Spring Boot, Spring Rest...EE?
Alkalmazás-szerver vs Servlet Container. Szerintem erről ne nyissunk vitát.
JSF vs gwt/vaadin. Ugyan már....
4 év, 10+ projekt architektként. Tehát nem kódoltál és valszeg tök részletesen bele tudtál merülni a technológiákba a boardon...nem hiszem.
Satöbbi. Igen, rühellem az EE-t. Pont. Befejeztem.
Bár nem rólam van szó, de ha már ... Igen, abszolút kódolok és reviewzok. Nem ilyen enterprise architect vagyok aki meetingekre jár és ott okoskodik. De, elég részletesen bele tudok merülni a technológiákba igen, hiszen ez a munkám, hogy meghatározzam az irányokat. Azért felelek, hogy jó döntéseket hozzak és jó irányba tereljem a projektet és csapatot, sőt a cég stratégiáját.
Dev környezetet, infrát,, db-t, CI-t, fejlesztői teszt alap struktúráit, integrációt, az alap framewörk megoldások elsőprő többségét, a fejlesztési folyamatot, a branchelési stratégiát meg még ki tudja mit én rakom össze. Csapattagok többnyire feature-t fejlesztenek.Írtál pár dolgot, mi az, ami miatt Spring, de semmit arról, hogy mi az, ami miatt nem Java EE.
JSF-hez hozzá sem nyúltam pár éve, előtte sem saját elhatározásból.

Java EE nem azt jelenti, hogy akkor JSF-et kötelező használni webre. Eleve nem csak webalkalmazás létezik, másrészt meg hülye lennék JSF-et választani, sőt bármilyen Java alapú webes frameworköt.
Nem volt "JSF vs gwt/vaadin", csak a te fejedben, Már csak azért sem, mert Java EE és gwt / vaadin semennyire sem zárja ki egymást. A JSF-fel csak tippeltem, hogy az biztos nem szíved csücske. Nekem se, de a Vaadint is hasonló baromkodásnak tartom.Alkalmazás-szerver vs Servlet Container. Szerintem erről ne nyissunk vitát.
Hát a semmivel nem tudok vitatkozni.Spring Data - Deltaspike, két saját projekten eddig bevált.
Spring Boot - ezzel mit szeretnél? Ezért használjon valaki Springet? Enélkül nem élet az élet? Csak így lehet?
Spring Rest - egy REST API az valami olyasmi, amire csak a Spring lenne képes 2017-ben? Lehet, hogy csak álmodtam, hogy ma is vagy 5db REST API-t implementáltam A-Z-ig (wildfly / resteasy).Satöbbi. Igen, rühellem az EE-t. Pont. Befejeztem.
El se kezdted, de oké, nem is számítottam többre. -
Lortech
addikt
"identitás-válság"
Amúgy hogy a nyelv maga mit tud, annak a megítélése erősen szubjektív, mert annotation processinggel széthekkelheted a javat, mint ahogy az is, hogy kinek milyen haszna van abból, ha egy bizonyos dolgot egy v többféleképpen lehet megoldani, vagy hogy 1-2 sorral kevésbé terjengős a kód.
Szerintem -- ha kíváncsi vagy a véleményemre -- már rég nem az számít, hogy egy megoldásban az implementáció milyen nyelvi bravúrokat képes felvonultatni; ez csak az elméleti része az egésznek. Sokkal fontosabb, hogy milyen ökoszisztéma az, amit fel tudsz köré építeni, vagy eleve adott hozzá, és ebben a java verhetetlen. Mert amikor jön a PM/PO megkérdezni, hogy "ez meg lehet csinálni?", felsorolsz neki 6 megoldási lehetőséget költségbecsléssel, akkor senkit sem fog érdekelni, még Bill szüleit sem, hogy 3 vagy 4 sorban írtad le, ponttal, nyíllal, vagy kínai írásjelekkel tarkítva, van-e vessző a sor végén, meg egyebek. Csak az az ember lesz tőle lelki beteg, akivel megcsináltatják végül.
Én is egyetértek. Én egyébként .NET-ről váltottam pályakezdőként és nagyon örülök neki, hogy így alakult. A nyelv amúgy tök oké, de az ökoszisztéma, zártság, kötöttség, windows, iis, dll stb mindig is idegesített.
-
Lortech
addikt
Gwt és Vaadin inkább mostanában

Szerintem meg ha át kellene állnom EE-re, felmondanék a g..cibe és keresnék egy Springes állást

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? -
Lortech
addikt
A EE a temető...tökmindegy, kihez kerül

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. -
Lortech
addikt
Sziasztok!
Lehet, hogy hülye problémával fordulok hozzátok de elég idegesítő tud lenni.
Eclipse-ben próbálnék írni bal oldali nyitó kapcsos zárójelet " { " de nem engedi mert a hülye billentyű kombináció pont hozzá van rendelve egy funkcióhoz a "Skip all breakpoiints"-hoz. Nem lehet ezt valahol átírni, vagy csak én nem tudok nyitó kapcsos zárójelet írni ?
Köszi előre is.
window / preferencesben ird be keresobe hogy shortcut, ott a listan megkeresed azt, ami bezavar es unbind.
-
Lortech
addikt
Sziasztok!
Többszörös öröklődés tudtommal nincs Java-ban.
De többszörös interface implementálás?Ha lehet egyszerre több interface-ből implementálni, akkor az implements kulcsszó után vesszővel kell elválasztani az interface-eket?
Ha igen, akkor hányat lehet egyszerre implementálni?köszönöm
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. -
Lortech
addikt
mennyire tudja összekötni az üzleti igényt az adott eszközzel, programnyelvvel. Mennyire képes egy üzleti specifikációból valós és jól működő kódot alkotni.
Ez egy nagyobb cégben azért két szerepkör:
- egy technology designer vagy business analyst - aki az üzleti igényből technikai specifikációt csinál
- egy fejlesztő - aki a technikai specifikációból kódot csinálEgy normális helyen egy fejlessztő sosem ül le (egyedül) az üzlettel megbeszélni, hogy mi az igény. Az ilyenekből lesznek azok a fejlesztések, amitől a tech kontrol vagy az infosec osztályon mindenki évekig a haját tépi (már ha van ilyen).
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. -
Lortech
addikt
Már linkelték a nem pollozós, eseményalapú megoldást. Ez ha lehetséges, akkor az OS funkcióját veszi igénybe, amely értesíti a változásról, amikor az történik.
A pollozás általában kerülendő, ha van más megoldás, és itt van. Nem is biztos, hogy bármennyire is megoldás a pollozás, az eredeti igényben szerepelt az azonnaliság. Továbbá nem biztos, hogy értesülsz egyáltalán egy változásról, pl. létrehozás és rögtön utána törlés esetén, ha az két poll közé esik. Ez vagy releváns az adott probléma szempontjából, vagy nem. De egy nagyobbacska (több ezer elemet tartalmazó) mappa is meg tudja nehezíteni az ilyen naiv megoldások működését, ha folyamatosan pollozni kell. -
Lortech
addikt
Hi!
Lenne két darab, általam kreált class:
QueueArray<E>;
QueueLinked<E>;
Tesztben szeretnek hozza írni egy olyan (generikus?) metódust ami elfogadja mindkettőt bemenő paraméterként. Lehet ilyen csinálni? Ha igen mi a paraméter típusa?
Eddig ezzel próbálkoztam:
public static <E> long counter(Collection<E> c, int r)
Koszi
Kell nekik egy közös ős, interface vagy base class, pl.
public interface Queue<E> {...}
aztán
public class QueueArray<E> implements Queue<E> {}
végül
public static <E> long counter(Queue<E> c, int r) {Persze nem írtad, hogy néz ki az általad kreált két class és hol lenne ez a metódus, illetve nem tudni pontosan mit akarsz ezzel, de gyanús, hogy érdemesebb lenne eleve az interface-be vagy base-be tenni ezt a countert, példány szinten.
-
Lortech
addikt
Mindegy hogy mit gondolsz, mert nem érdekel.
Aki segít az segít, ha meg nem tudsz segíteni, akkor minek szólsz bele és mit érdekel?
Gondolom Te mindig mindent segítség nélkül csináltál meg.
Amúgy meg elég érdekes ez a fórum, hogy szakmai hozzászólás egy sincs csak kötözködés. Tipikus magyar ugar....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. -
Lortech
addikt
Üdv!
Nem tudom megoldható-e, de valami olyasmire lenne szükségem, hogy egy byte/integer váltózó értéke mindig 0 és 9 között maradjon műveletek után. Pl.: value %= 10 megakadályozza, hogy 9 fölé menjen az értéke, value++ esetén 0-ra ugrik az értéke.
Na nekem ennek az ellenkezőjére is szükségem lenne, (ha létezik ilyen) hogy (ha value = 0) value-- után 9 értéket vegyen fel.(Egy olyan programról van szó ami képeket mutat végig 0-tól 9-ig sorszámozva, egy előre és egy vissza gombbal lehet léptetni őket, az előre működik)
Kezdő vagyok, nem tudom hogy lehet a legegyszerűbben megoldani ilyen feladatot.

x = (x + n) % n ?
itt n = 10, x-et lépteted, és x értékét a fenti képlettel számolod ki. -
Lortech
addikt
Na srácok újabb hiba:
van egy kliensek nevű Listám ami socketeket tartalmat és ezeket akarom accept-elni.
get-el lekérek a socketet a listából,for(int i=0;i<n;++i) {
kliensek.get(i) = server.accept();
}és sajna ezt a hibaüzenetet kapom:
\DominoServer.java:61: error: unexpected type
kliensek.get(i) = server.accept();
^
required: variable
found: value
1 error
1 warningmi lehet a baj?
kösziAz 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. -
Lortech
addikt
Sziasztok
van egy listám amiben vannak számpárok(dominók), miután elküldöm őket a kliensnek, azokat amiket elküldtem ki szeretném törölni, itt mindig hibát dob. valamit elcsesztem de nem látom. szerintetek mi a baj?
List<Domino> MyList = new ArrayList<Domino>();
MyList.add(new Domino(0,1));
MyList.add(new Domino(1,2));
MyList.add(new Domino(2,3));
MyList.add(new Domino(3,4));
MyList.add(new Domino(4,5));
MyList.add(new Domino(5,6));
MyList.add(new Domino(6,7));
for (int i = 0; i < 7; i++) {
pw.println(MyList.get(i).getX());
pw.println(MyList.get(i).getY());
System.out.println("elküldve");
}
for (int i = 0; i < 7; i++) {
MyList.remove( MyList.get(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. -
Lortech
addikt
Újabb kérdéssel fordulnék hozzátok. Adott egy Server és egy Kliens android app. TCP protokollal kommunikálnak. A servernek ugye van egy ip címe, amit ha manuálisan beállítok a kliensen akkor egymásra találnak és mehet az infó küldés. A kérdés az, hogy hogyan tudnám megoldani, hogy ne kelljen a kliensen manuálisan megadni az ip címet, szóval hogyan találja meg az azonos wifi hálózaton lévő servert magától? Mik erre a bevett megoldások?

-
Lortech
addikt
Jasperreports.
Jasperreports is Apache POI-t használ xlsx generálásra (JRXlsxExporter).
Ill. használhat még jexcelt, de az csak xls-re jó (JExcelApiExporter).
Szerintem Apache POI-nál jobb ingyenes alternatíva nincs jelenleg. -
Lortech
addikt
Ez az oracle hivatalos hitvallása. Nem olvastad? Most jöttek rá, hogy lehet h erre kéne koncentrálni, nem a SOAP-ot nyomni még ezerrel.

Amúgy kövezzetek meg, de én a REST-ből implementációból csak a service method regisztrációt, és a message convertert használom. Ez a GET/PUT/POST/DELETE annyira felesleges nekem
Kő!
![;]](//cdn.rios.hu/dl/s/v1.gif)
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. -
Lortech
addikt
Másik topicban nem ír senki, nekem meg ma esetig le kéne adnom a jelentkezést:
Szakirányú végzettség híján nézegetem a felsőoktatási lehetőségeket, és látom, hogy néhány suliban van 4 féléves programtervező informatikus felsőoktatási szakképzés.
Az oklevélben szereplő megnevezése elég gagyi: Felsőfokú programtervező informatikus-asszisztens.
A névválasztás egyébként nem véletlen, a képzés 120 kreditjéből 90-et el lehet fogadtatni a Bsc képzésben, ha valaki utána meg szeretné csinálni.
Például Egerben:[link]
Ilyesmi képzésről van valakinek valami tapasztalata?
Aki esetleg felvételiztetni szokott, mit szólna, ha valaki ilyen végzettséggel jelentkezne a cégéhez?
Már van egy műszaki diplomám, de váltani szeretnék programozásra, nem tudom, hogy van-e kedvem egy Bsc-t elvégezni.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.
-
Lortech
addikt
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.
-
Lortech
addikt
Nem tőlem kérdezted, és csak részben válaszolok.
Számomra a Vaadin (és hasonló megoldások) legnagyobb hátránya az egész megoldás alapfilozófiája, ami egyébként legnagyobb előnye is volna egyben. Az, hogy megpróbálja a webet elfedni a Java programozó elől a webalkalmazásokkal kapcsolatos általános problémákat és technológiákat, html-t, css-t, javascriptet. Kapsz egy keretet és előre meghatározott eszközkészletet (pl. komponenseket), amiből össze tudsz legózni egy webalkalmazást anélkül, hogy igazán értenél a webhez, nem sűrűn kilépve a Java adta komfortzónádból. Ezt kínálja elméletben. A gyakorlat természetesen nem ilyen egyszerű, mert vannak a fránya ügyfelek, felhasználók, akik nem uniformizált szoftvereket akarnak, hanem egyedit, a nekik legmegfelelőbbet, testreszabottat, pont olyat, amilyet elképzeltek.A gond ott kezdődik, amikor ki kell lépned a készen kapott megoldások keretei közül és bővítened kell az eszközkészletet egy saját megoldással, vagy hibába futsz bele, vagy a kapott keretek szűkösnek bizonyulnak egy adott probléma megoldásához. Ez pedig fájdalmas lehet, elviheti azt a produktivitásbeli előnyt, amit korábban megnyertünk.
Az én munkám - sajnos vagy szerencsére - olyan, hogy sokféle, teljesen különböző projektünk van, és teljesen egyedi igényeknek kell megfelelni, ritkán tudjuk egy komponens halmaz által szabott lehetőségekhez igazítani az igényeket, ezért nincs csak egyféle megoldás, amit mindig használunk, pl. egy extjs, ami egyébként tök oké a licencelését és a releaselésüket leszámítva.
Egyébként azt gondolom, hogy 2017-ben gyors, modern, igényes, reszponzív webalkalmazásokat aligha lehet erős webes frontend tudás és némi designer véna nélkül fejleszteni, ehhez képest pedig igencsak kompromisszumos megoldásokat nyújtanak az ilyen előre definiált komponensekkel operáló frameworkok, mégha a megjelenítésük jól testre szabható is. Én azt mondom, hogy aki nem frontend fejlesztő, és nem érdekli a frontend annyira, hogy a szükséges dolgokat megtanulja hozzá, annál felesleges a frontend fejlesztést erőltetni. /Persze nyilván teljesen mások lehetnek az igények egy enterprise intranetes webalkalmazásnál, mint egy csillivilli, milliós végfelhasználói bázist különböző eszközökre optimalizáltan kiszolgáló alkalmazásnál./ -
Lortech
addikt
-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.
-
Lortech
addikt
köszönöm a válaszokat.
Igen, ez egy gyakorlófeladat lenne, a leírásban szerepel, hogy írjam meg a tesztosztályokat is.
Ahogy elhangzott, előbb eldöntendő, hogy unit tesztet vagy integrációs tesztet akarsz írni.
Mivel nem írtál konkrét kódot, nem tudható, hogy van-e olyan metódus az osztályában, ami tartalmaz olyan logikát, amit érdemes unit teszttel lefedni. Ha van, a 9114 jó irány. Ha integrációs tesztet szeretnél írni, az a 9110-es irány.
Ha csak gyakorolni szeretnél, érdemes mindkettőt kipróbálni. -
Lortech
addikt
Pl. github?

Sok értelmét nem látom amúgy. -
Lortech
addikt
-
Lortech
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. -
Lortech
addikt
Jaja.....élő ember nem ismerek, aki használt volna SVN lokál repót. Olyat sem, aki a GIT-nél nem a commit/push-t használta, hanem csak a commit-ot

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. -
Lortech
addikt
Első körben tisztázzuk, hogy céges környezetben, céges fejlesztési policy-val nézem ezt az egészet. Nálam a GIT rögtön ott bukik meg, hogy localhost-on van (lehet) olyan munkád a céges projekten, aminek nincsen nyoma a céges/központi repóban. A branch létrehozása egy mozdulat, ha a céges projekteken bíbelődsz valamit, az nem saját kis mitymuty, tessék létrehozni egy branchet akár kísérleti jelleggel a központi repóban, egy hosting/rendszergazda/devops kollégának meg legyen az a dolga, hogy ennek a feltételeit megteremti.
Minden branch minőségbiztosítási okok miatt meg kell hogy legyen központilag, lefedve egy task management rendszerrel úgy, hogy bármikor bárki tudja folytatni, review-olni, vagy épp merge-ölni DEV/UAT/PROD környezetbe.
#8933) WonderCSabo a másolás egy logikai művelet. Ellentétben néhány más rendszerrel, SVN alatt nincsen olyan speciális művelet, hogy branch, mivel nincsen erős kötöttség arra vonatkozóan, hogy a repoban mit hova teszel. Branch-et úgy csinál, hogy egy másik branch (URL) adott állapotáról egy referenciát készít az új URL-en. Meg kell határoznod a saját workflow-dat, hogy milyen elnevezéseket és kötöttségeket használsz. Ez nyilván lehet az eredeti ajánlás szerinti is, bár az csak egy viszonylag egyszerű munkafolyamatra jó.
(#8937) Aethelstone rebase
SVN-nel ugyanúgy lehet olyan munkád, aminek nincs nyoma a központi repóban (egyszerűen nem tolod fel, ha nem akarod), a GIT viszont segít abban, hogy ha ezt akarod, kényelmesen meg tudd oldani, akár központi repóhoz fordulás nélkül, de úgy, hogy commitok (vagy stashben a változások) meglegyenek.
Nálam van, hogy 5+ feature branch között váltogatok napon belül, ha segítek vagy reviewzok kollégáknak. Eközben a saját munkám 1-2..n branchen van, amiket vagy feltoltam a remote-ba vagy nem, nincs jelentőségük, lényeg, hogy az infó megvan, és könnyen tudok váltani köztük. Van egy csomó olyan köztes állapota az elvégzendő munkának, aminek vcs historyban nincs különösebb keresnivalója, mert a végeredmény szempontjából nem hordoz értéket, mégis a köztes állapotnak is meg kell lennie, hogy később vissza tudjak rá váltani, ha folytatom a munkát rajta. Ugyanakkor más számára nem mindig hordoz értéket és így teljesen felesleges a feltöltésével időt vesztenem. A kész feature / javítás / akármi pedig úgy fog visszakerülni a masterbe / egyéb protected branchbe, hogy az csak azokat a commitokat és olyan üzenetekkel tartalmazza, ami a módosítás egésze szempontjából lényeges, és a historyban megőrzendő információ.
Ez nem azt jelenti, hogy nálunk a kollégák 2 hétig a saját kis játszóterükben szórakozhatnak, és ha elüti őket az autó, akkor annyi a munkának. Már csak a CI miatt is sokkal rövidebb életciklusú (vagy folyamatos integráció) branchek szükségesek. Erről git-nél és SVN-nél is le lehet szoktatni őket, ebből a szempontból én nem látok nagy különbséget. Pl. ha látom, hogy kolléga egyik remote branchre sem commitolt egy hete (van róla stat), akkor azért megkérdem, hogy mi a hasfájása. -
Lortech
addikt
Re maven/gradle: a gradle megítélésem szerint még elég kiforratlan dolog, és elég gyerekcipőben jár a támogatása az egyes IDE-kben. Sajnos én addig nem tudom eléggé komolyan venni a dolgot. Mondom ezt úgy, hogy egy nagyobb projektcsomagot migrálunk most gradle-re. Akinek egy maven-féle XML szerkesztése gondot jelent, az válasszon más pályát

Re SVN/GIT: nagyon menő egy ideje a GIT, és mindenki migrál veszettül, ész nélkül sajnos. A legtöbb projekt ugyanis nem igényli a GIT modelljét, ellenben komplikáltabb a használata. Tapasztalatom szerint még az SVN használata is kihívás sokaknak, nemhogy a GIT. Biztos van helye a GIT-nek is (pl nagy projekt kis, 1-2 személyes, javarészt független alprojektekkel), bár én eddig még sehol nem láttam indokoltnak, leszámítva azt az esetet, amikor egy ügyfél előtt pozicionálunk arculatot.

Gradle Android/studio-nál megkerülhetetlen.
Git akkor komplikáltabb, ha komplikáltabb dolgokra használod. Sokaknál azt veszem észre, hogy git előtt csak egyszerű dolgokra használta a vcs-t, git után ráérez és elkezdi jobban érdekelni a dolog.
Nagyon egyszerű felhúzni új repót, gyors, hatékony, jól skálázódik, jól testreszabható, tök jó támogató eszközök épültek köré, jól üzemeltethető.
Az SVN a jelenlegi workflowt, amit használunk, nehezen tudná jól támogatni, legalábbis az én munkámat dev leadként. Mondhatnám én is, hogy akinek gondot jelent pár nap alatt belerázódni a GIT-be, az válasszon más pályát. Sima alkalmazásfejlesztőknek kb. három mondatban le tudom írni adott projekten az össz teendőjét gittel. Kb. 6 éve az összes projektemen git mellett döntök, SVN-ről váltottam, azóta soha eszembe nem jutott SVN-t használni, ha nem adottság. Ha SVN-t, neadjisten CVS-t, vagy CC-t látok (ügyfélnél), hamar idegrángásom lesz tőle és általában felrakok fölé egy GIT-et.
#8908 eredetire: igen, mind a 4-re szükséged van, de ha nem senior pozíció, akkor alap szinten ismerni elég ezeket. Komolyabban úgyis munka közben tudod megtanulni.
-
Lortech
addikt
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. -
Lortech
addikt
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>
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).
-
Lortech
addikt
"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.\"sql-2-homework-ear-1.0-SNAPSHOT\".\"sql-2-homework-web-1.0-SNAPSHOT\".DefaultDataSource is missing [jboss.naming.context.java.whatever]"]}van egy java ee applicationöm három modullal(ejb,web,ear és az utóbbi megy deployra),és van egy datasource a wildflyban ami szépen bele van rakva a persistance xmlbe, létre is jönnek a táblák viszont a deploy megakad a fenti hibakóddal és az istenért se tudok rájönni, hogy mi okozza.. ugyanaz az a név az entity managerben mint a unitnak stb..
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1" 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">
<persistence-unit name="***">
<jta-data-source>java:jboss/datasources/vidampark</jta-data-source>
<class>com.company.rolanddarvas.entity.*****</class>
<class>com.company.rolanddarvas.entity.****</class>
<class>com.company.rolanddarvas.entity.*****</class>
<class>com.company.rolanddarvas.entity.********</class>
<class>com.company.rolanddarvas.entity.*******</class>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<properties>
<property name="javax.persistence.schema-generation.database.action" value="create"/>
</properties>
</persistence-unit>
</persistence>ötletek?
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. -
Lortech
addikt
A hibák nagy részét kijavítottam, három maradt amivel nem tudok mit kezdeni:
SajatPanel.java:379: error: cannot find symbol
/* 305 */ Logger.getLogger(SajatFrame.class.getName()).log(Level.SEVERE, null, ex);
^
symbol: class SajatFrame
location: class SajatPanel
SajatPanel.java:386: error: cannot find symbol
/* 312 */ SajatDialog mdialog = new SajatDialog(null, true);
^
symbol: class SajatDialog
location: class SajatPanel
MentesPanel.java:386: error: cannot find symbol
/* 312 */ SajatDialog mdialog = new SajatDialog(null, true);
^
symbol: class SajatDialog
location: class SajatPanel
3 errorsA SajatFrame és a SajatDialog külön classok.
Nyilván minden függőséget oda kell tenni mellé, hogy forduljon. Kiexportálod a teljes jar forrását, behúzod IDE alá egy projekt forrásaként. Ekkor a jaron belüli függőségekkel megvagy, ha egyéb libtől is függ a lefordítandó osztály, akkor azt is build pathhoz adod. A cannot find symbol hibák hiányzó típusokat jelentenek, ha nem tudod, hol a hiányzó függőség, rá kell keresni az alkalmazás/konténer egyéb csomagjaiban (jar,war,ear), ha vannak.
-
Lortech
addikt
Sziasztok!
Van egy ezer éves jar file-om, amihez sajnos már nincs meg a forrás. Át kellene írnom egyetlen metódusban két értéket, van erre valami módszer?
if ((this.egyes.exists()) || (this.kettes.exists()))
{
if (this.egyes.exists()) {
this.egyes = "EGYES";
}
if (this.kettes.exists()) {
this.kettes = "KETTES";
}
}
}na már most még csak a változók neveit sem akarom átírni, csak az értékük legyen HÁRMAS vagy NÉGYES. Megoldható ez?
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.
Új hozzászólás Aktív témák
-
Fórumok
PROHARDVER! - hardver fórumok
Notebookok TV & Audió Digitális fényképezés Alaplapok, chipsetek, memóriák Processzorok, tuning Hűtés, házak, tápok, modding Videokártyák Monitorok Adattárolás Multimédia, életmód, 3D nyomtatás Nyomtatók, szkennerek Tabletek, E-bookok PC, mini PC, barebone, szerver Beviteli eszközök Egyéb hardverek PROHARDVER! BlogokMobilarena - mobil fórumok
Okostelefonok Mobiltelefonok Okosórák Autó+mobil Üzlet és Szolgáltatások Mobilalkalmazások Tartozékok, egyebek Mobilarena blogokIT café - infotech fórumok
Infotech Hálózat, szolgáltatók OS, alkalmazások SzoftverfejlesztésGAMEPOD - játék fórumok
PC játékok Konzol játékok MobiljátékokLOGOUT - lépj ki, lépj be!
LOGOUT reakciók Monologoszféra FototrendFÁRADT GŐZ - közösségi tér szinte bármiről
Tudomány, oktatás Sport, életmód, utazás, egészség Kultúra, művészet, média Gazdaság, jog Technika, hobbi, otthon Társadalom, közélet Egyéb Lokál PROHARDVER! interaktív
- Fórumok
- Szoftverfejlesztés
- Java programozás
- (kiemelt téma)
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Mesterséges intelligencia topik
- Okos otthon - Home Assistant, openHAB és más nyílt rendszerek
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Háztartási gépek
- Apple asztali gépek
- E-roller topik
- Samsung Galaxy Felhasználók OFF topicja
- Battlefield 6
- Melyik tápegységet vegyem?
- További aktív témák...
- iKing.Hu - Apple MacBook Pro 14 M3 Pro (2023) 18GB/500GB SSD karcmentes 100% akku 23 ciklus
- Bontatlan Moleskine Smart Writing Set Ellipse digitális e papír füzet / 12 hó jótállás
- HIBÁTLAN iPhone 13 Pro Max 128GB Alpine Green -2 ÉV GARANCIA - Kártyafüggetlen, MS4946, 100% Akksi
- Acer Chromebase All-in-One PC 23.8" Touchscreen
- Azonnali készpénzes GAMER / üzleti notebook felvásárlás személyesen / csomagküldéssel korrekt áron
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest




![;]](http://cdn.rios.hu/dl/s/v1.gif)

hanem hogy "vegyééé új gépet azon menni fog így is"



)

