Abev java .jnlp űrlapok

Linux-haladó

Hogyan lehet elérhetővé tenni az XYZ.jnlp letöltött adatlapokat az Abevjava főprogramba?
Állítólag van ezeknek .jar változata is, de 1. a nav.gov.hu oldalán a legtöbből csak .jnlp kiterjesztésű volt, 2. az az egyetlen amiből volt .jar változat ugyan elindult de a telepítése során hibával leállt?
Azt már meg sem kérdezem miért nem tudja letölteni maga az Abev java a hozzá tartozó adatlapokat, de hát állami szoftver, mit várok.

  • 11682 megtekintés

( uid_7086 | 2014. 05. 17., szo – 16:20 )

Ha nem tévedek, a .jnlp az valójában a webstartos alkalmazás.
Alatta van egy "további letöltések", amire kattintva megtalálod a .jar programot is.
Hogy maga a program miért nem tudja letölteni pl. a szükséges nyomtatványokat, ez egy jó kérdés. Párszor már én is anyáztam miatta.

Sikerült megoldani. Az icedtea-netx csomag kell neki: 

apt-get install icedtea-netx

majd utána 

javaws XYZ.jnlp

Ez még magát az Abevjava keretprogramot is letölti és telepíti ha korábban nem lett volna.
Még annyit, hogy default /usr/share -be akar mindent beszórni, nyilván nem hallottak még olyasmiről mint /usr/local/share/ illetve arról, hogy Linuxon nem alap az, hogy root jogokkal garázdálkodnak a userek. Ezt át kell írni /home/FELHASZNÁLÓ/abev/ vagy valami hasonlóra és akkor már jól működik.

Abevjava-ra van külön repó: http://hogyan.org/abevjava-deb-telepites

Netstart helyett van icedtea-netx, ami teljesen jó jnlp fájlokhoz.
De a fenti módszer még jobbnak tűnik nekem most. A user home-ban van minden, ha probléma lenne a frissítésekkel törölhetsz mindent és újra elindítod a kitölteni kívánt űrlap jnlp fájlt javaws-sel. Csak arra kell ügyelni, hogy a home könyvtáron belül adj meg egy külön könyvtárat neki, különben a home gyökeret hányja tele, és ne "abevjava" legyen az űrlap könyvtárának a neve, mert oda maga a főprogram kerül.

( uid_17626 | 2014. 05. 17., szo – 19:08 )

A legszebb, hogy van amelyik doksi installerje nem megy Linuxon. Ilyenkor marad a manuális kicsomagolás és a megfelelő helyre másolás.

Ez Java alapú szoftver esetében nem semmi teljesítmény.
Vajon az Abev-en dolgozó programozók hallottak olyanról, hogy tesztelés?
Pedig ha normálisan lenne megírva még tableten is működne amire lenne is igény. A Java egyébként jó választás egy ilyen szoftverhez, csak nem ártana ha normálisan meg lenne írva maga az alkalmazás is.

Pedig ha normálisan lenne megírva még tableten is működne amire lenne is igény

Szerintem meg nem működne. Jad-al belenéztem még régebben, swinget használnak. Nem értek az androidhoz, de az mintha xml-ben írná le a GUI-t, nem egy komponens könyvtár api-t kell használni, nem is tudom van-e komplett j2se port androidra? Ios-en meg nem működne sehogy egy j2se alkalmazás.

Úgy értettem, hogy aránylag kevés munkával lehetne készíteni Dalvik portot ha már egyszer javaban van írva. Swing heylett meg lehetne normál html5 ui, ami a pc-ken sem lenne hátrány. Az iOS bár nem kötődik olyan szorosan javahoz, de arra sem lenne hatalmas munka portolni. Javaban lehet iOS-re is fejleszteni csak natívra kell fordítani.
Html5 user felülettel az érintőképernyős támogatás sem igényelne sok munkát.

Ja, értem. Azt hittem, van valami fejlemény, amiről lemaradtam pl j2se port ios-re :)

még tavaly néztem meg egy ora konferencián promózott mobile adf nevű keretrendszert, de az bizony nagyon gyenge volt... igaz, simulatorban futott ios-en és androidon is amit csináltam, fordítani mindkettőre külön-külön kellett tehát a natív fejlesztői környezet nem kerülhető el, de ennél nagyobb probléma hogy 18MB volt egy egyszerű kis app, ami natívban kb. 400K (ios), meg kiderült az is hogy valami java me 1.4-es rt-t csomagolnak vele, webservice hívás lehetőségek nagyon alapszinten... az appstore állítólag befogadja az ilyen tákolmányokat is, de nem alapoznék rá. Főleg nem összetettebb programokat.

( Ritter | 2014. 05. 17., szo – 20:02 )

Működik, kitölthető az űrlap. Csak annyi probléma van vele, hogy nem tudja beküldeni ügyfélkapun keresztül, végtelen várakozásba kezd.
Viszont .../abevjava/eKuldes/KR/kuldendo könyvtárba létrehozza a szükséges .kr fájlokat. Ezeket szerencsére manuálisan is be lehet küldeni ügyfélkapu weboldalán, ahol egyébként költői módon szintén egy webbe ágyazott java app fogadja a .kr fájlt.

Én debiant használok, és simán kitömörítettem a saját home könyvtáramban, onnan indítom és teljesen jól működik. Az űrlapokat is egyből letölti, telepíti, a webes felületen keresztül gond nélkül feltöltötte, és nyomban megjelent a tárhelyen az átvételi elismervény. Valószínűleg mázlim volt, de tényleg semmi problémába nem ütköztem.

( uid_952 | 2014. 05. 19., h – 08:53 )

Megnyomtam az ellenőrzés gombot, és annyit írt ki hogy "1353". Szoftverergonómia rules. A konzolra meg odahány valami logot, de vajon ezt minek, miért nem sikerült letiltani pár év alatt, mióta fejlesztik? Meg az egyházaknál a legördülőt nem sikerült olyan szélesre megcsinálni, hogy el is lehessen olvasni milyen egyházak vannak (érdekes hogy a legelső sora, az meg nem is egyház). A lehető legegyszerűbb dologra használtam, mert kivételesen jól számolták ki az adómat, mégis szívás volt vele. Mindegy, túl vagyok rajta..
Na jó. másrészről meg én is barom vagyok, hogy megint az utolsó pillanatra hagytam a bevallást. Bocs, hogy ideírtam ezt neked.

( Ritter | 2014. 05. 19., h – 23:15 )

Oracle Java telepítése utána semmilyen problémát nem tapasztaltam az Abev javaval. Ez az IcedTea/OpenJDK lecserélésével jár. Sajnos az Oracle Javaról semmi jót nem lehet elmondani azon túl, hogy az Abev ezzel működik a hibamentesen. Cserébe jól elcseszi a /usr/bin/java linket az eltávolítása után. Szerintem az Abeves űrlapok kitöltése és feltöltése után érdemes leszedni és visszatenni az IcedTea/OpenJDK-t. A már említett /usr/bin/java link hiányozni fog, ezt ln -s paranccsal pótolni kell. 


sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java8-installer

( tomsolo | 2014. 05. 20., k – 00:53 )

Az egész abev egy fostákolmány, persze mihez készült ugye. Az már nem annyira vicces hogy, még a NAV dolgozók sem látják át teljesen ezt az egész szájbakúrt förtelmet így kerülhet 2 mondatban elő a "ebből most baj lesz", "lehet kéne csinálni egy önellenőrzést", "jaj hát ez én se tudtam", "azért felhívok egy számot biztos-e".
No rainbow, no sugar

Ha már úgyis van ügyfélkapu, mehetne weben az egész és nem kellene bohóckodni űrlaponként külön telepítésekkel. Gondolom azért van így, hogy világvégi tanyákon is működjön ahol még internet sincs és pendriveon viszi a postás az Abev javat és az űrlap .jnlp-ket majd vissza a kinyomtatott lapokat. De ma már 2014-ben szerintem csak az nyomtat aki elfelejtette az ügyfélkapus jelszavát és határidő előtt már nem tud elmenni az okmányirodába új jelszóért. Szóval jó lenne szépen átterelni webre az egész Abev-et vagy legalább azt megoldani, hogy az Abev keretprogram maga is le tudja tölteni az űrlapjait. Talán az sem irreális elvárás, hogy OpenJDK-val is működjön.

A világért sem. Még mindig az volt a legkevesebb idő, hogy bementem és 5 perc alatt kitöltettem az ügyintézővel ahelyett hogy java, abev, űrlapok etc fasságok telepítésével, kibogarászásával csesztem volna el az időm.(cirka 10 perc a sorban állással.) Az más kérdés, hogy terelgetni kell őket mert Ők sem értik ezt az egész trágyalét ami adóbevallásnak hívnak.
No rainbow, no sugar

Megnézted, hogy hányféle úrlap van? És belegondoltál abba, hogy ezeknek az ellenőrzése mennyi erőforrást igényel? Ráadásul, mivel a bevallási időszakok dömpingszerűen hoznák a csúcsterhelést, így az eszközpark az ideje jelentős részében töredék terheléssel menne.
A nyomtatványkitöltő, minő meglepetés, képes azonosító alapján a nyomtatványok letöltésére, úgyhogy ez a kérésed máris teljesült. Az x, y meg z JDK-val való működés szép dolog - elméletben. Csak ez a gyakorlat, méghozzá olyan szinten, hogy jelentős anyagi vonzata van a hibás működésnek - akár az adózó, akár az állam részéről, úgyhogy célszerűen egy környezetre tesztelik ronggyá az alkalmazást és a nyomtatványokat.

Talán számodra ez elképzelhetetlen, de az Abev javát leszámítva minden java alkalmazás amihez eddig szerencsém volt képes volt arra a bravúrra, hogy működjön SUN majd Oracle Java mellett OpenJava-n is. A kettőnek ugyanis van némi köze egymáshoz.

Belegondoltál már abba, hogy Youtube videoszolgáltatás, milliárdnyi egész világból feltöltött videó encodolása majd kiszolgálása mekkora erőforrásokat igényel? Ehhez képest űrlapok ellenőrzése egy tízmilliós Magyarországról... na ne vicceljünk már!
21. század második évtizedének a közepe felé már számtalan módszer van a csúcsterheléses időszakok "problémájának" a kezelésére.

Khm... ezen még gondolkodj egy picit! :D
(igen, komoly rendszerhez jár dokumentáció, abban leírva, hogy milyen követelményeket támaszt a futtató rendszerrel kapcsolatban. Ha abban azt írják, hogy Sun/Oracle java kell neki, akkor IBM/OpenJDK alatt örülj, ha fut, de nem elvárható - én sem tudom egyébként, hogy mi a különbség a különböző java változatok közt)

Nem egyedi megrendelésre készülő szoftverről van szó. Ott lehetnek ilyen megkötések, sőt olyan üzleti szoftverek is vannak amik csak Win XP-n működnek a későbbi Windows kiadásokra nincs garancia. Bár ez sem szerencsés de a gyakorlatban elnézik.
De itt nem erről van szó. Az OpenJDK egyébként nem IBM, és az Oracle kiadásoknak is alapja.

Khm... az openjdk ismereteim szerint az IBM által kiadott java utóda.
Másrészt egy Oracle RDBMS-t sem neveznék egyedi megrendelésre készült szoftvernek, mégis ott van az install guide-ban (na jó, volt, közel tíz éve nem láttam olyat), hogy pontosan milyen elvárásai vannak a szoftver környezettel kapcsolatban.
Bizonyos esetekben még az is, hogy milyen op.rendszer patch-ek kellenek hozzá.

Mondjuk a linkedről épp ez nem derül ki egyértelműen, de a wiki alapján úgy tűnik, vagy rosszul emlékeztem vagy a forrásom volt kissé hibás. Pedig határozottan úgy emlékeztem, hogy az ibm forkja volt... Na mindegy. A többi ettől még áll.

Lap alja:
© 2014 Oracle Corporation and/or its affiliates
Terms of Use · License: GPLv2 · Privacy · Trademarks

Én is tartom a korábban írott állításaimat. Egyedi megrendelésre, illetve kis példányban terjesztett szoftverek más követelményeknek kell, hogy megfeleljenek mint a tömeges használatra készített szoftverek.

> egyetlen baja az anyk-nak, hogy felrug minden az utobbi 40 evben kialakult GUI design koncepciot :-))

Na jó, azt mondjuk nem mondta senki, hogy az ÁNYK egy barátságos szoftver. Funkcionálisan nincs vele nagy baj, meg úgy nagyon fejlesztői szemszögből sem.

Csak hát UX szempontból katasztrófa, meg annyira fejleszteni sem kényelmes rá. :D

> Ha már úgyis van ügyfélkapu, mehetne weben az egész és nem kellene bohóckodni űrlaponként külön telepítésekkel.

Az hiányozna még csak. Dolgoztam fejlesztőként olyan alkalmazáson, aminek az outputja kitöltött, beküldésre kész ÁNYK fájl. Picit egyszerűbb volt így megoldani, mintha valami netes baromságra kellett volna fejleszteni. (Eleve úgy kezdődik, hogy így elég a javás ÁNYK-t karbantartain, amúgy meg kéne egy böngészős felület és egy webservice-réteg is.)

> De ma már 2014-ben szerintem csak az nyomtat aki elfelejtette az ügyfélkapus jelszavát és határidő előtt már nem tud elmenni az okmányirodába új jelszóért.

Leszámítva az emberek nem elhanyagolható többségét, akiknek nincs ügyfélkapujuk. Beleértve de nem kizárólag kb. minden ismerősömet, aki nem informatikus, de elmúlt 25.

> az Abev keretprogram maga is le tudja tölteni az űrlapjait

Le tudja.

> Talán az sem irreális elvárás, hogy OpenJDK-val is működjön.

Talán tényleg nem, de ha nem közszféráról beszélnénk, már valaki felhördült volna, hogy az pénzügyileg mennyire nem éri meg.