Newsgroup: it.comp.java
Titolo: Advanced Test e meditazioni (guru?) sul ng

Rinnovo l'invito a "risolvere" l'advanced test su Java che trovate sul
mio sito 
http://www.ugolandini.net
 che ora fra l'altro aggiornerò con
più costanza (più o meno una volta a settimana, con i contenuti che
avevo promesso - ieri ad esempioho aggiunto la parte sulle "Qualità del
software"). Nessuno ancora mi ha "risposto" correttamente. Possibile che
a nessuno freghi niente? A me sembrava interessante...almeno discuterne.
Se nessuno si fa vivo, apro un thread sul newsgroup, in modo anche da
evitare i soliti lamenti "si stava meglio prima", "il livello si è
abbassato", "non ci sono più i programmatori di una volta", "certo che
ai miei tempi quando debuggavo a mano 2000 righe di assembly"... che
ultimamente pervadono un po' il ng. Non che non sia daccordo almeno in
senso generale, ma mi sembra che tutti (io compreso) cerchino magari di
dare una mano dove possono (e quindi non su cose che non conoscono bene,
uno mica può sapere tutto) ma poi non è che anche loro lancino chissà
quali mirabolanti discussioni interessanti per migliorare insieme.
Perchè non diamo una sferzata di vita e usiamo il ng come gruppo di
"discussione" oltre che come "Faq", ci togliamo un po' la scorza da
saputelli e discutiamo anche (un po' come IDPSG un gruppo di studio sui
pattern che molti hanno ignorato -
http://www.egroups.com/group/idpsg/info.html
 -)?. Ad esempio il thread
su DB relazionali e Java potrebbe dar vita a discussioni interessanti ed
importanti (utili) e concentrare le energie ed il tempo (poco) su
qualcosa di diverso da "Chi ha incastrato Roger Rabbit?"
che ne dite?
Ugo

A parte l'uso di reflection per invocare un metodo, immagino che cio` a 
cui ti riferisci sia l'uso di Class[]{} invece che Class[0], che e` un
modo
per inizializzare immediatamente l'array e crearlo della dimensione pari
al
numero di elementi tra le {} (in questo caso 0).  Tuttavia cio` che a 
qualcuno sembra "particolare", per altri e` noto e non stupisce piu` di
tanto,
quindi se non fai una domanda chiara nel tuo test, non puoi essere
sicuro
che qualcuno ti risponda "centrando" quello che volevi tu.
L'unica altra cosa "strana" nel tuo codice e` che chiami "baseClass" una 
variabile che invece va a referenziare un istanza di Class che
rappresenta
Derived, e non Base.
Attendo chiarimenti sul test....
   Ciao,
           Roberto

BTW, il test intermedio 9 e` almeno "mal formulato", dato che un oggetto
di class String e` immutabile.

 wrote in message
37D0E1AB...@flashnet.it...

Mi sembra una valida idea. Penso che l'intero ng ne trarrebbe dei benefici
(intendo dire le persone che vi partecipano). Ci sono un sacco di cose che
magari si sanno ma non si ha tempo (o modo) di sperimentare. Comincio io.
Questo è un'idea che da un po' di tempo mi incuriosisce.
Un applet può aprire socket solo verso il server dal quale proviene. Se io
piazzo un'applicazione stand alone sullo stesso server che intercetta le
chiamate dell'applet, riuscirei a comandare l'applicazione dall'applet. Se
poi questa applicazione eseguisse istruzioni native, oppure I/O su file, di
fatto sarebbe possibile, tramite opportuni codici, eseguire tali operazioni
tramite un'applet. Sarebbe possibile generare pagine web dinamicamente, per
esempio, e visualizzarle. A me sembra che il ragionamento regga, a voi che
ve ne pare?
Ciao, Marco[:]|
\----------------------------------------------------\
/         Marco Carosio                              /
\      aka "Captain Harlock"                       \
/                                                             /
\  e-m@il : 
ort...@iol.it
                             \
/               
marcoc...@iol.it
                 /
\  home:    
http://utenti.tripod.it/~mcarosio
  \
/__________________________________/
=========================================
Yo man! Whaz di b3st way t0 hack 
www.nasa.gov
 ????
Ehy c'mon, explain me man!!!
=========================================

 ve ne pare?
Regge perfettamente. Incidentalmente, questo *e'* il modo con cui si
pilotano applicazioni da applet. :)

 pilotano applicazioni da applet. :)
Ma ci potrebbe però essere qualche problema se c'è un firewall di mezzo
(dovunque nel percorso), dunque è applicabile solo in un contesto Intranet in
cui sai cosa c'è nel cammino fra il client e il server. Si potrebbe però usare
una servlet ed aggiungere così anche la possibilità Internet
--
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Enterprise Java Consulting
@mail: Ugo.L...@Flashnet.it
Home URL: 
http://www.ugolandini.net
Sample Work: 
http://www.sirena.lomb.cgil.it
Work Phone: 02/26254326
Cell Phone: 0347/6310749 - 0347/4783580
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

 Derived, e non Base.
b è un handle di tipo Base che punta ad un oggetto Derived, ed è una prassi
comune per il polimorfismo. Comunque è un particolare abbastanza importante.
Ugo


 di class String e` immutabile.
Che è poi la soluzione del test, ma forse si poteva formulare un po' meglio
(senza dare indicazioni però sulla risposta giusta)


Internet 
LOL e' evidente che ci sono maree di dettagli per ogni configurazione di
rete particolare. Con un fw, le scelta sono aprire una porta nel fw,
usare un protocollo di tunnelling,  usare SOCKS, eccetera e combinazioni 
varie. Descriverli/discuterli tutti richiederebbe un trattato. ;-) 
-- 
God is Real, unless declared Integer.


La maggior parte delle volte usando un opportuno middleware (ad esempio
RMI) questo problema e' superabile senza scomodare i servlet (che di
fatto in buona parte costringono poi in fase di design a replicare in
peggio le funzionalita' offerte dal middleware).
Sent via Deja.com 
http://www.deja.com/
Share what you know. Learn what you don't.

 peggio le funzionalita' offerte dal middleware).
Infatti abbiamo dovuto replicare con le servlet tutto il meccanismo di
invocazione remota di metodi per avere finalmente un meccanismo univoco che
funzioni con tutti i browser e sia con internet che con intranet senza
avere applet da 500Kb (esempio ORBlet, le applet CORBA). Il framework
costruito è interessante, tanto che a Novembre (o Dicembre) dovrebbe uscire
un articolo su Computer Programming a questo proposito. Se sia in peggio o
in meglio dipende dai punti di vista, tenendo conto di tanti fattori
diversi. Conta che possiamo costruire applet Java AWT da sole 20/30Kb che
invocano metodi su oggetti remoti in maniera trasparente (con l'uso di un
proxy) alla stessa maniera di CORBA/RMI, ed il tutto è basato sulle
servlet, sulla serializzazione e sulla reflection API. Unapplet da 30Kb che
chiama metodi remoti su un oggetto server (che a sua volta può essere un
client CORBA, dunque con possibilità illimitate) e dunque realmente
utilizzabile su internet non è cosa da poco! Dunque non sottovalutiamo le
possibilità delle servlet, altro che scomodare...!!!!


 scomodare...!!!!
Non e' che sottovaluto le servlet. Solo che mi sembra inutile
riscrivere roba gia' scritta: preferisco prendere quella attuale e
farla evolvere.
Ciao,
      Bruno.


farla evolvere.
Io penso la stessa cosa, infatti. Abbiamo preso le Servlet API e le abbiamo 
fatte evolvere per risolvere dei problemi abbastanza sentiti. Il discorso 
chiave sta tutto nell'importanza che dai al fatto di poter fornire 
"servizi" in maniera OO anche su internet su browser qualsiasi (l'unico 
requisito è il supporto alla serializzazione, dunque Java 1.1). Non mi 
parlare del plugin che è uno schifo (ancora adesso, magari per poco, 
chissà). Intanto vale lo stesso discorso di sopra dei browser "potenziati", 
poi ci sono tutta una serie di bug (per esempio il doPost() non "vede" i 
cookies, ma ti parlo solo di quello che ho testato personalmente e 
verificato, chissà cosa cova sotto la cenere...) che lo portano al limite 
dell'inagibile
ciao, e approfondiamo magari un po' il discorso che sembra molto 
promettente. Mi sembra che abbiate sviluppato un framework "parallelo" a 
quello sviluppato da me (noi, il mio gruppo, è lo stesso) ma con un'enfasi 
su altre caratteristiche. A me è servito poter fare applet piccole ed OO 
(intendo che invochino metodi remoti e non cgi o servlet o quant'altro) su 
browser qualsiasi in internet, tu(voi) hai dato più importanza alla 
compatibilità con midlleware preesistenti e forse anche alle prestazioni 
(ti dico comunque che con Apache + Jserv non va affatto male,anzi! E il 
recente accordo - il progetto jakarta - di Sun con il gruppo apache fa ben 
sperare per il supporto futuro alle servlet API, tutto aggratise 
ovviamente...vero Billy?). 
P.S. E' impossibile che abbiate applet più piccole di 20-30Kb (non in senso 
assoluto ma in senso relativo): il 95% delle dimensioni delle applet è dato 
dal codice dell'interfaccia grafica, quello che ci portiamo appresso 
(essenzialmente lo stub) è veramente poco, una classe con le signature dei 
metodi remoti più un'altra paio di piccole classi (una ha un solo metodo, e 
piccolo!)
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Enterprise Java Consulting
@mail: Ugo.L...@Flashnet.it
Home URL: 
http://www.ugolandini.net
Sample URL: 
http://www.sirena.lomb.cgil.it

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°


Mah, noi ci portiamo tre micro-classi per oggetto remoto + lo stub RMI
o il proxy CORBA... Evidentemente ho misurato male. Resta da vedere
qual'e' il footprint del vostro middleware, anche in relazione ai
servizi forniti (vedi sopra): nel nostro caso sia che si usi CORBA che
RMI mi pare si tratti di un 10-20k extra (ma devo verificare, non
prendermi alla lettera)



A dire il vero si tocca un campo nel quale mi sento un po' profano, però
sono argomenti che mi interessano tantissimo; io ho sempre immaginato che un
linguaggio come Java non permettesse un uso malizioso di programmi (almeno
per quanto riguarda le applet).
Sarebbe possibile creare in java un meccanismo per bypassare queste misure
di sicurezza? (Non ho intenzioni maligne, la mia è solo curiosità).


 prendermi alla lettera)
OK, mi arrendo: sul 1° livello avete più servizi voi! Comunque appena c'è
tempo ne implementeremo parecchi - le transazioni già ci sono - (senza
contare che sul lato server-server usiamo VisiBroker e c'è già tutto fatto)
Ugo
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Enterprise Java Consulting
@mail: Ugo.L...@Flashnet.it
Home URL: 
http://www.ugolandini.net
Sample Work: 
http://www.sirena.lomb.cgil.it


 di sicurezza? (Non ho intenzioni maligne, la mia è solo curiosità).
Non è che proprio si superino delle misure di sicurezza, anche se in un certo
senso ... si. Un applet Java può alla fine invocare un metodo di un oggetto
remoto su un computer qualsiasi... ma deve fare un bel giro per riuscirci, tra
cui tramutare il tutto in richiesta HTTP (Tunnelling) , avere degli oggetti
intermedi che "palleggiano" la richiesta (Middleware), ecc., tutto comunque
all'interno della sandbox.



Scusa, non volevo spostare la discussione su un lato competitivo, mi
devo essere lasciato trascinare. A me interessarebbe sapere secondo te
(secondo voi! Hey, del newsgroup, c'e' qualcuno?) quali servizi sono
veramente importanti (e qualificanti) per un middleware del nostro /
vostro tipo.


 vostro tipo.
Dipende anche dal contesto d'uso del middleware, cioè per quali
applicazioni cerchi di facilitarti la vita. Io personalmente aggiungerei
(anche se si parla di un livello di astrazione un po' diverso, ed è un
servizio che di solito offre un Application Server) il Connection Pooling,
visto che un DB ci sarà per forza, da qualche parte.
Ugo
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Enterprise Java Consulting
@mail: Ugo.L...@Flashnet.it
Home URL: 
http://www.ugolandini.net
Sample Work: 
http://www.sirena.lomb.cgil.it


 parte.
Non lo avevo neanche citato ma lo abbiamo ;-D. Un po' datato (e'
del '96, estrapolato da quel primo progetto), con una archiettura un
po' vecchia ma funziona egregiamente. Sempre parlando di DB, abbiamo
anche degli oggetti che ci incapsulano delle selezioni basate su query
realizzate sul server.
Ci sono anche classi per ricevere/spedire mail via POP3/SMTP,
probabilmente ormai obsolete vista l'uscita di JavaMail.
Poi... non so, pensi che potrebbe servire spostarsi sul
livello "business objects" e costituire alcuni oggetti applicativi di
alto livello? (tipo San Francisco, per intenderci?) E' una cosa di cui
ogni tanto si parla, ma che secondo me richiede troppo lavoro e troppa
esperienza.
