Gyorskeresés
Legfrissebb anyagok
- Bemutató Spyra: akkus, nagynyomású, automata vízipuska
- Bemutató Route 66 Chicagotól Los Angelesig 2. rész
- Helyszíni riport Alfa Giulia Q-val a Balaton Park Circiut-en
- Bemutató A használt VGA piac kincsei - Július I
- Bemutató Bakancslista: Route 66 Chicagotól Los Angelesig
Általános témák
LOGOUT.hu témák
- [Re:] [sziku69:] Szólánc.
- [Re:] [Luck Dragon:] Asszociációs játék. :)
- [Re:] [sziku69:] Fűzzük össze a szavakat :)
- [Re:] [gban:] Ingyen kellene, de tegnapra
- [Re:] [Szevam:] Érzelmi magabiztosság/biztonság - miért megyünk sokan külföldre valójában?
- [Re:] [bambano:] Bambanő háza tája
- [Re:] Elektromos rásegítésű kerékpárok
- [Re:] eBay-es kütyük kis pénzért
- [Re:] [Tüzi:] Geek-hatarozo
- [Re:] [D1Rect:] Nagy "hülyétkapokazapróktól" topik
Szakmai témák
PROHARDVER! témák
Mobilarena témák
IT café témák
Hozzászólások
Taoharcos
aktív tag
Aethelstone
addikt
Az a helyzet, hogy ha a vitákat letiltod, akkor továbbra is olyan témák lesznek, amiket 5 perc guglival el tud bárki intézni
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
sutszi
veterán
Nem az összes vitát tiltotta le, csak ezt. Ez meg teljesen jogos volt. Akinek ilyen extrém véleménye van az nem hajlik arra, hogy vevő legyen más felvetésekre...Ebből egy parttalan vita lenne csak. Érdemi eredmény nélkül a végén személyeskedésbe fordulna.
Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage
Az a baj, hogy ennek nem vita lett volna a vége. Az vita, hogy pl. Maven vs. Gradle de a kolléga teljesen ignorálta a dolgot.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
cucka
addikt
Az egyetlen érdekes kérdés szerintem is az, hogy miért pont java? Ilyen hozzáállással a java a legnagyobb önsz*patás, szinte bármelyik más platform jobb választás lenne
togvau
senior tag
<%@ 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?
[ Szerkesztve ]
hitler, sztálin, micro usb
A "jó öreg" 1.8 óta tök új.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
Retekegér
HARDVERAPRÓD
<< Heimdal >>
Lortech
addikt
Húzd be a wildfly jsf függőséget (wildfly 11.0.0 verziót feltételezve):
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-jsf</artifactId>
<version>11.0.0.Final</version>
</dependency>
Vagy telepíts jboss tools az eclipse-edbe, és add hozzá a runtime-ot.
[ Szerkesztve ]
Thank you to god for making me an atheist
floatr
veterán
Ne zavard össze, épp most mondta, hogy a Maven nem a barátja. Hadd töltse csak le a TLD-ket, meg jarokat kézzel.
togvau
senior tag
Már megoldottam (kézzel), volt 2 perc. Most a JAAS-al küzdök, a jsf oldalak authentikációját kéne megcsinálni vele, de ahány leírás róla, annyi egymásnak ellent mondó beállítás van. Úgy tűnik az nem megy hogy honnan szedje az adatokat (jelszó, role).
Na meg wildfly-on futtatott jsf egyszerű gombja aminek futtatnia kéne egy metódust, nem csinál semmit. Belöki az oldalt, klikk rá, és semmi. Konzolon sem, debug módban sem, semmit sem ír a szerver, meg más sem.
[ Szerkesztve ]
hitler, sztálin, micro usb
togvau
senior tag
Ok, rájöttem, hiányzott a form keret De most jött a "No Persistence provider for EntityManager named".
Mit írjak a persistence-be a provider helyre? Csak hibernate-s provider stringeket találok ha ráguglizok, de nem működik. Vagy milyen JPA implementációt használ ez a wildfly?
Eclipse data source-ként be van állítva, de gondolom az egy másik rendszer rendszerének a rendszere, és nincs átjárás
[ Szerkesztve ]
hitler, sztálin, micro usb
Lortech
addikt
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;
[ Szerkesztve ]
Thank you to god for making me an atheist
togvau
senior tag
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?
[ Szerkesztve ]
hitler, sztálin, micro usb
Lortech
addikt
Wildfly picketboxot használ jaasra, van olyan login module, hogy
DatabaseServerLoginModule.
Meg lehet adni neki datasource-ot paraméterként és jdbc-vel hozzáfog férni a db-dhez. Nem tudom, friss-e a leírás, de bele lehet nézni a login module forrásába.
[ Szerkesztve ]
Thank you to god for making me an atheist
togvau
senior tag
Majd megpróbálkozom vele, de ez az egész JAAS konfiguráció nagyon zavaros nekem, pl azt se tudom hol kell lennie ennek a login-config.xml-nek, meg a web.xml-ben lévő dolgok is elég zavarosak.
Nade <h:selectItems>-et kéne nekem egy enummal feltölteni. Rákeresve mindenhol azt írják, hogy a JSF 2.2 már támogatja az enumokat magától, de minden enumos példában egy sima class-t használnak enumként, enum nincs sehol... És ki is írja errorként ha enumot adok meg, hogy nincs konstruktora.
hitler, sztálin, micro usb
togvau
senior tag
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....?
[ Szerkesztve ]
hitler, sztálin, micro usb
Lortech
addikt
Na ez az az irány, amit nem kéne erőltetni.
Javaslom, szervezd EJB-be az üzleti logikádat és az adathozzáférést, és azt injektáld a JSF managed beanbe. Mert az nem arra való, hogy direktben JPA-zz és tranzakciót kezelj benne.
AZ EJB-be pedig injektáld az entitymanageredet pl. az általam fentebb írd módon. Így nem kell foglalkoznod az entitymanager létrehozásával, életciklusával (pl. hogy többször létrehozod a factory-t, mint ahogy tetted).
BalusC tutorialjait, megoldásait érdemes olvasni, ő jó forrása a JSF-fel kapcsolatos megoldásoknak: [link]
JAAS-hoz: a login-config.xml az jboss szerinti leíró, wildfly-on máshogy néz ki.
wildfly login module pl (standalone.xml vagy domain.xml megfelelő profiljában):
<security-domain name="xysecdomain">
<authentication>
<login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
<module-option name="dsJndiName" value="ds jdni név"/>
... többi opció ...
</login-module>
</authentication>
</security-domain>
De mindez megtehető webes admin konzolból is.
Aztán jboss-web.xml-ben kell egy <security-domain>xysecdomain</security-domain> hivatkozás, ami a webalkalmazásodat összekapcsolja a security domainnel wildfly-ban.
selectItem vs enum passz, szerencsére már rég JSF-eztem.
[ Szerkesztve ]
Thank you to god for making me an atheist
togvau
senior tag
a többször létrehozás miatt tettem static finallá. De úgy meg egyáltalán nem is működik...
hitler, sztálin, micro usb
togvau
senior tag
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.
hitler, sztálin, micro usb
Lortech
addikt
Valószínűleg rossz az entity-db mappinged, de ez abból amit írtál, nem látszik.
Logolás: org.hibernate (vagy specifikusabb) kategóriára fel kell venni egy loggert és hozzá egy handlert:
[link]
Jboss logging teljesen oké, nem kell log4j vagy egyéb implementáció.
[ Szerkesztve ]
Thank you to god for making me an atheist
Aethelstone
addikt
Véleményem szerint a jsp / jsf + ejb kombó fölött erősen eljárt már az idő.....nem vitaindító...
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
togvau
senior tag
É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...
hitler, sztálin, micro usb
Lortech
addikt
Azt értettem alatta, hogy az entitásban/db-ben a probléma mezőt/oszlopot nem jól definiáltad.
Pl. nem jó oszlopnevet adtál meg.
Detached entity passed to persistnek számos oka lehet. Kézzel állítasz be kulcs mezőket mentés előtt? Másodjára persisttel már nem fog menni, mert már létezik adott kulcsú mező, viszont az entity detached állapotban van, mivel még a persistence contextedbe nem töltődött be (pl. merge-dzsel tudod manageddé tenni). Látatlanban okosabbat nem tudok mondani.
[ Szerkesztve ]
Thank you to god for making me an atheist
floatr
veterán
Vagy foglalt szót használt a column elnevezéséhez, és nem escape-elte
Aethelstone
addikt
Mondjuk egyik fizikai tábládban sem látok 'user' mezőt.
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
togvau
senior tag
É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`))
[ Szerkesztve ]
hitler, sztálin, micro usb
Lortech
addikt
Nem definiáltál az entitásaidba relációkat, legalábbis nem látszik. Anélkül nem nagyon fog menni és FK be fog utagni, meg nyilván generátor se fog tudni jó db sémát generálni így. Ajánlott olvasmány: JPA relációk, de úgy általában JPA.
EntityManager em= getFactory().createEntityManager();
em.getTransaction().begin();
Event evt= new Event(new Date(),em.merge(getGod()),event, success);
em.persist(evt);
em.getTransaction().commit();
em.close();
Ezzel itt az (lehet) a baj, hogy amint lezárod az EntityManagert, az összes managed entitás példányod, amit a persistence contextben használtál, detached lesz. Ennek pedig az a következménye, hogy a még be nem töltött, lazy load relációk nem tudnak majd betöltődni, ill. az objektumok módosítása esetén nem lesznek automatikusan perzisztálva sem.
Thank you to god for making me an atheist
togvau
senior tag
Köszi, éééés működik az egyik összefüggős táblába adás már, egy @ManyToOne hozzáadásával. Ennyi kellett. De fura, mert a jpa tools entity-tábla generátor megtalálta enélkül is az összefüggéseket (mert FK-zot), és jól generálta a táblákat ehhez.
A factoryt pedig már static singletonosítottam, és az entity manager is entitykezelő (session scoped) osztályonként singleton.
Másik (szintén kapcsolatban lévő) táblánál, mivel nincs ID-nek való egyedi adat, ezért külön int id van definiálva, simán @GeneratedValue.
De először is, egy hibernate_sequence nevű táblát keresve száll el, de a jpa tools sima sequence nevűt generál. Átneveztem, így elindítva már azon száll el, hogy ebben nincs next_val nevű oszlop IDENTITY stratégiával.
Egyik módszer sem működik. Komolyan olyan buta a perzisztenciaréteg, hogy nem tud egy üres táblában mondjuk csak simán 0-val kezdeni, és mindenféle táblák kellenek neki?
[ Szerkesztve ]
hitler, sztálin, micro usb
togvau
senior tag
Meglett, <property name="hbm2ddl.auto" value="update"/> ennyi kellett a persistence.xml-be.
Nagy haladás van, bár a jaas túl bonyolult, szerintem marad a saját autentikáció.
[ Szerkesztve ]
hitler, sztálin, micro usb
togvau
senior tag
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...
hitler, sztálin, micro usb
Lortech
addikt
UsersRolesLoginModule az egy fapad login module, property fájl alapú, nem tud db-ből authentikálni.
Amit én linkeltem, az direktben a datasource-on keresztül jdbc-zik, de simán lehet írni JPA alapú login module-t, írtam is már wildflyra, weblogicra.. Nem triviális, de nem is ördöngősség.
Pl. csinálsz egy EJB szolgáltatást ami JPA-n keresztül elvégzi az authentikációhoz szükséges ellenőrzést. A loginmodule-ból pedig JNDI-n keresztül lookupolod az EJB-det. A loginmodule-t csomagolhatod az alkalmazásodhoz is, nem muszáj külön modulként telepíteni.
Belépés után httpservletrequestből (JSF-ben facescontexten keresztül) elérhető a felhasználó a getUserPrincipal metódussal (getName normálisan a felhasználó nevét adja vissza), ezzel bekérdezhetsz az adatbázisodba. Van még isUserInRole is ugyanitt.
[ Szerkesztve ]
Thank you to god for making me an atheist
togvau
senior tag
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.
hitler, sztálin, micro usb
Lortech
addikt
Pedig a standalone/domain.xml-ben kell beállítanod a security domainedet. A security domain / realm az nem 1:1 egy alkalmazáshoz kapcsolt, hanem alkalmazások fölött álló koncepció. JAAS infrastruktúra és Java EE pedig nem ad standard megoldást arra, hogy hogyan kell az alkalmazáshoz security domaint rendelni. Ezért van az, hogy jboss-web.xml-ben kell megadni. Vagy standalone/domain.xml-ben default security domainnek beállítani.
jboss-web konfiguráció itt van említve: [link]
security subsystem pedig itt van leírva: [link]
Ebből látszik, hogy a Database / DatabaseUsers modul a webes admin konzolon
a org.jboss.security.auth.spi.DatabaseServerLoginModul-t jelenti.
Tutorial: [link]
Fontos, hogy wildfly 11-től elytron alrendszer van és önmagában kevés a fenti legacy konfiguráció.
Migráció: [link]
[ Szerkesztve ]
Thank you to god for making me an atheist
togvau
senior tag
A linkelt oldalon ott van, hogy nem csak ott lehet(ett), de a másik oldalon meg az látszik, hogy wildflyon már nem úgy, de hogy hogy az sehol sincs.
standalone.xml-el meg nesze neked nagyban hangoztatott javas hordozhatóság mellesleg elég gagyi megoldás.
Akkor elengedem a JAAS-t, mert a nem JAAS megoldás pár perc alatt összejött, úgy ahogy kéne, csak az nem "szabványos".
[ Szerkesztve ]
hitler, sztálin, micro usb
togvau
senior tag
Kellene JSF-ben az <ui: taglib, de most az eclipse segítsége nélkül kell írtnom a jsf-et? Mert már amikor beállítom a JSF facetet, kiválasztom hogy a runtime libraryjait használja (mert írja is hogy az tud ilyet szolgáltatni), de aláhúzza a taglibeket "Can not find the tag library descriptor for "http://java.sun.com/jsf/core" és persze a kiegészítés sem megy. Csak akkor megy, ha userlibként behúzok 2 jsf jart.
Szerk: most működik a kiegészítés (bár ugyanúgy aláhúz), de ugyan azok jelennek meg benne mint a <h:-ban hiszen ugyan az a taglib uri is.
Mi az isten van ezzel a JSF-el hogy tele van ilyen összevissza, nem létező tageket használó egymásnak ellentmondó tutorialokkal a net?
Hogy a tudok egy nyomorék jsp/jsf fájlba egy másik jsp/jsf fájtl includeolni, javascript libek nélkül?
[ Szerkesztve ]
hitler, sztálin, micro usb
togvau
senior tag
Rájöttem, sehogy. (legalább is úgy, hogy egy includeolt form működjön).
Az mitől van, hogy egy hutputlink-re való kattintáskor org.apache.jasper.JasperException: java.lang.NullPointerException
-al száll el, ha előtte nem küldtem el legalább 1x formot, és működik a linkelés ha már küldtem formot?
hitler, sztálin, micro usb
togvau
senior tag
Egyszerűen, ha nem lett elküldve az adott jsf oldalon legalább 1x már form, akkor nem biggyeszti be az outputlink a servlet mapping /faces-ét az url-be, ha pedig már volt form küldve, akkor igen... szépen fejlődik visszafelé a dolog, 9 éve még ilyen probléma nem volt, bár akkor is sok jsf, és AS bug volt.
hitler, sztálin, micro usb
Aethelstone
addikt
Felejtsd el ezt a jsf témát....valami ajaxos frameworkkel sokkal többre mégy...
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
togvau
senior tag
igen, el kéne felejteni, mert elavult, nagyon régi dolog, és ahogy látom 9 év alatt minimális fejlődés jött össze, de maximális mennyiségű új bug. De sajnos sok helyen ragaszkodnak a régi dolgokhoz, mert a mánáger kitalálta.
hitler, sztálin, micro usb
G.Zs.
senior tag
Felejtsd el azt a ceget is ahol a manager talalja ki..
Ha a menyasszony apja az örömapa, a menyasszony anyja az örömanya akkor a menyasszony az örömlány?
floatr
veterán
Meg kell mondani a menágernek, hogy vagy most invesztál bele fejlesztésekbe X összeget, vagy később 10X-et kárelhárításra, javításokra, tarthatatlan supportra, és exponenciálisan növekedő költségigényű change requestekre.
[ Szerkesztve ]
Altalaban a team leadek talaljak ki (akik menedzserek). Miert, ki talalja ki?
while (!sleep) sheep++;
G.Zs.
senior tag
Szerintem a fejlesztocsapatnak kellene kozosen dontenie a technical stack-rol.
A team lead legyen aki a vegen elfogadja esetleg megvetozza a dontest, de ne egy szemelyben dontson.
Ha a menyasszony apja az örömapa, a menyasszony anyja az örömanya akkor a menyasszony az örömlány?
A demokracia nagyon nem mukodik jol technikai dontesek eseteben. Ha olyasmirol van szo, hogy tabs vagy spaces, akkor persze oke, de egy csapatban nagyon kulonbozo technikai tapasztalattal rendelkezo emberek vannak, miert kellene, hogy mindenkinek ugyanakkora beleszolasa legyen?
A masik, hogy ezekrol rengeteget lehet vitatkozni, es a valodi helyzet az, hogy a feladatok 99%-at 'barmiben' meg lehet csinalni, es a fejlesztok hajlamosak az alapjan valasztani, hogy 1) most mi erdekli oket 2) mi a divatos 3) ok szemely szerint mihez ertenek. Azert valasztanak valakit vezetove, hogy donteseket hozzon, amik elsosorban a ceg erdekeit veszik figyelembe.
while (!sleep) sheep++;
G.Zs.
senior tag
Adott egy feladat, amire keresem a megoldast. A feladat elemzesenel a csapat feltarja, hol lehetnek nagyobb problemak a megvalositasnal. A csapatbol minden egyes fejleszto keszit egy kutatast, esetleg egy technologiai demot, prezentalja a sajat megoldasat, es ervel, hogy szerinte az a technologia miert lenne jo valasztas a kulcsfontossagu problemak megoldasara. A csapat ezutan megvitatja a felmerult megoldasokat, es kivalasztja melyik a leghatekonyabb. Egyhangu dontes eseten ugye nincs mirol beszelni, az lesz amit mindenki akart. Ha nincs megegyezes, es sok megoldas johet szoba, akkor a legnagyobb tapasztalattal rendelkezo vezeto dont.
Ha a menyasszony apja az örömapa, a menyasszony anyja az örömanya akkor a menyasszony az örömlány?
Ez igy tok jo, ha nyilt vegu a kerdes, azaz ha tenyleg eldontendo, hogy melyik iranyba induljon a csapat. Feltetelezem, hogy lentebb nem ez a helyzet, es van egy jo adag JSP-alapu cucc keszen, es kell valami pluszt hozzarakni (gondolom, nem valami megaprojekt, ha itt a forumon probalja osszeszedni a hozzavalokat a kollega). Ilyen esetekben tok normalis, hogy azt hasznaljak, amibol mar eleve sok van.
while (!sleep) sheep++;
G.Zs.
senior tag
Amit irtam az termeszetesen greenfield projektre vonatkozik. Ha van legacy code a projekten, az mar megbolonditja a tortenetet. Ebben az esetben viszont nem csak azert ragaszkodunk a regi technologiahoz, mert a manager kitalalta.
[ Szerkesztve ]
Ha a menyasszony apja az örömapa, a menyasszony anyja az örömanya akkor a menyasszony az örömlány?
Persze. Gondolom lent nem GF projekt van
Greenfield projektek eseten sem igy megy, persze. A konkret technologiakat fel lehet dobni vitara, de az architekturat nem kozossegileg szokas megtervezni.
while (!sleep) sheep++;
Cathfaern
nagyúr
"A csapatbol minden egyes fejleszto keszit egy kutatast, esetleg egy technologiai demot, prezentalja a sajat megoldasat, es ervel, hogy szerinte az a technologia miert lenne jo valasztas a kulcsfontossagu problemak megoldasara. A csapat ezutan megvitatja a felmerult megoldasokat, es kivalasztja melyik a leghatekonyabb."
Ez tényleg van ahol így megy, vagy ez az elméleti ideális eljárás amit semmilyen nem amatőr / hobbi projectnél nem alkalmaznak?
Téma tudnivalók
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))