Re: [Jug-Torino] COVID-19 and Business

[Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]]

Il link sembra rotto


On Thu, Mar 12, 2020 at 1:03 PM Simone Bordet simone.bor...@gmail.com
[it-torino-java-jug]  wrote:

>
>
> Ciao a tutti,
>
> vi raccomando di seguire oggi, alle 16:00, Heinz Kabutz che intervista
> Peter Carruthers:
> https://twitter.com/heinzkabutz/status/1238061919262527489
>
> Diffondete la voce!
>
> --
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless. Victoria Livschitz
> 
>


-- 
Massimo Ugues

Re: [Jug-Torino] Problema con spring-boot e metodo annotato con ehcache

[Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]]

Ciao Bruno, riesci a rilasciare un test case negativo? Lo stack purtroppo
lascia il tempo che trova.

Grazie saluti

Il giorno sab 21 dic 2019 alle 03:04 bruno bossola bboss...@gmail.com
[it-torino-java-jug]  ha scritto:

>
>
> Ciao a tutti,
>
> Ho un problema molto strano sui metodi annotati con ehcache usati in un
> servizio con spring-boot. Succede in poche parole che se il metodo lancia
> un'eccezione allora il lock usato da ehcache su quell'elemento della cache
> non viene rilasciato e a quel punto ogni successivo tentativo di accedere
> all'elemento vede il thread ancorarsi su tale lock. Accedendo ad un altro
> elemento tutto funziona.
>
> Ci sto lavorando da stamattina e non so proprio cosa fare... possibile che
> nel 2020 si siano dimenticati di un finally per rilasciare il lock in caso
> di eccezione? Se trappo l'eccezione e ritorno un sonoro "null", tutto va
> perfettamente
>
> Se avete suggerimenti concreti li accetto volentieri, suggerimenti vaghi o
> altre cose tipo "ma perche' non usi XY?" potete girarli su /dev/null.
> Allego uno stack trace bonificato a titolo illustrativo.
>
> Ciao e grazie in anticipo,
>
> Bruno
> --
> Bruno Bossola
> CTO - meterian.io
> Scan your project now! 
>
> 
>
-- 
Massimo Ugues

Re: [Jug-Torino] [JOB] Software engineer e altro a Zurigo

[Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]]

Io alla PR applicherei anche una bella code review per non accettare le
“offerte” di lavoro palesemente imbarazzanti per aspetto economico .



Il giorno ven 11 ott 2019 alle 17:22 bruno bossola bboss...@gmail.com
[it-torino-java-jug]  ha scritto:

>
>
> Paolo,
>
> Questa mail e' contraria alle regole del JUG. Non ci sono valutazioni da
> fare, le regole sono chiare.
>
> Per aggiungere un’offerta di lavoro, effettuare una pull request
>  o editare
> online questa pagina
> 
>  (richiede
> un account GitHub).
>
> Ciao,
>
> Bruno
>
> --
> Bruno Bossola
> CTO - meterian.io
> Scan your project now! 
>
>
> On Fri, 11 Oct 2019 at 13:41, Paolo Mossino paolo.moss...@gmail.com
> [it-torino-java-jug]  wrote:
>
>>
>>
>> Ciao,
>>
>> Piccolo spam per offerte di lavoro.
>>
>> Nella mia azienda (EPAM System) stanno cercando parecchie persone per
>> vari progetti, su Zurigo.
>> Tra le very hot position al momento ci sono queste, fortemente incentrate
>> su Java (nell'unica in cui non compare nel titolo, lo trovate nella job
>> description):
>>
>>- Senior Java Developer
>>
>>- Senior Java Developer with DevOps
>>
>>- 3rd Level Support / Java Developer
>>
>>- Java Developer 
>>- Senior Java/J2EE Developer
>>
>>- Senior Java Developer with Data Modeling
>>
>>- Full Stack Developer
>>
>>
>> (e oltre a questo ci sono svariate altre posizioni aperte
>> ,
>> di cui queste
>> 
>> che matchano la keyword "java").
>>
>> Qualcuno interessato a lavorare a Zurigo?
>>
>> Credo che tutte richiedano di essere eleggibili per lavorare in Svizzera,
>> quindi sicuramente OK per tutti i cittadini Italiani... se avete altre
>> nazionalità, bisogna verificare caso per caso.
>>
>> Se si, please contattatemi dandomi CV e posizione per cui vorreste
>> applicare, così faccio un referral ;-)
>>
>> Disclaimer: nessuna di queste è sul mio progetto, quindi non correrete il
>> rischi di trovare me come RM/TL... ma di contro non so dirvi molto del
>> progetto in se o quando pagano, se non informazioni generiche.
>>
>>
>> Paolo
>>
>>
>> P.S. Stavo valutando se postare anche su http://jugtorino.it/jobs/, ma
>> non mi sembra si sposi bene con questo use case dove ho N offerte, di cui
>> io ho poche info dirette... alla fine sarebbe diventato un "da me cercano
>> sempre, guardate qui" quindi mi sono limitato a questo post.
>>
>> --
>> Paolo Mossino  
>>
>> 
>
-- 
Massimo Ugues

Re: [Jug-Torino] Miglioramenti alle NullPointerException

[Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]]

Meglio tardi che mai :D


On Fri, Sep 27, 2019 at 9:27 AM Federico Fissore feder...@fsfe.org
[it-torino-java-jug]  wrote:

>
>
> Da
>
> Exception in thread "main" java.lang.NullPointerException
> at Prog.main(Prog.java:5)
>
> a
>
> Exception in thread "main" java.lang.NullPointerException:
> Cannot read field 'c' because 'a.b' is null.
> at Prog.main(Prog.java:5)
>
> La target release è java 14
>
> https://openjdk.java.net/jeps/358
>
> federico
> 
>


-- 
Massimo Ugues

[Jug-Torino] Sconti jug per fullstackconf

[Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]]

Ciao, volevo sapere se per caso come jug abbiamo degli sconti per la
fullstackconf di ottobre
https://fullstackconf.it

Grazie in anticipo, saluti
Max
-- 
Massimo Ugues

Re: [Jug-Torino] Re: Trovare memory leak ?

[Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]]

Ciao, nel passato quando ne ho avuto bisogno mi sono sempre appoggiato a
Jprofiler: all'epoca mi pareva che ti desse un trial che mi ha sempre
permesso di stanare il balordo :D
JMC è un valido prodotto, ma secondo me Jprofiler è superiore.



On Wed, Jun 5, 2019 at 9:59 AM ilmur...@yahoo.com [it-torino-java-jug] <
it-torino-java-jug@yahoogroups.com> wrote:

>
>
> Ciao Salvatore,
> se non hai un crash della jvm per java.lang.OutOfMemoryError ma è il
> demone docker che ti killa il container controlla prima i parametri di
> memoria che hai impostato. Limitando il solo Heap non si limita tutta la
> memoria utilizzata da Java perchè ci sono anche lo stack, la memoria
> "native", etc... Considera anche il minimo overhead di docker stesso, e se
> hai anche altri processi il totale della memoria di tutti i processi che
> girano nei container non deve superare questo limite. Prova prima se con un
> valore più più stretto sul max size heap cominci a vedere degli
> OutOfMemoryError, oppure la tua applicazione funziona correttamente.
>
> Andrea.
>
> 
>


-- 
Massimo Ugues

Re: [Jug-Torino] [ANN] Secondo meeting di Aprile, il 15, su GraalVM

[Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]]

Ciao, grazie dell'informazione.

Purtroppo per motivi di lavoro non ci potro' essere; spero vivamente che
questo talk venga registrato e condiviso sui soliti canali ;)

Grazie in anticipo

On Mon, Apr 15, 2019 at 11:31 AM Federico Fissore feder...@fsfe.org
[it-torino-java-jug]  wrote:

>
>
> Ciao a tutti
>
> Sanne, lo speaker del meeting di questa sera, ci informa che, anche se
> l'annuncio non lo specifica, l'argomento principale è Quarkus [0].
>
> Hibernate viene usato come esempio di libreria non banale integrata in
> Quarkus e adattata per sfruttare al meglio GraalVM
>
> A stasera! [1]
>
> federico
>
> [0] https://quarkus.io/
> [1] https://www.meetup.com/it-IT/JUGTorino/events/260366202/
>
> Federico Fissore feder...@fsfe.org [it-torino-java-jug] ha scritto il
> 05/04/19 alle 13:06:
> > Ciao a tutti
> >
> > Questo mese avremo ben 2 meeting, quello del 10 aprile e un altro il 15
> >
> > Sanne Grinovero, di Red Hat, leader di Hibernate e coautore di Quarkus,
> > ci parlerà di GraalVM nel talk "GraalVM senza limiti: avviare Hibernate
> > ORM in 5ms e con solo 15MB di memoria"
> >
> > Maggiori dettagli su
> http://jugtorino.it/2019/04/15/meeting-aprile-2019.html
> >
> > Iscrivetevi tramite meetup
> > https://www.meetup.com/it-IT/JUGTorino/events/260366202/
> > Questa volta più di altre è importante iscriversi perchè, a seconda di
> > quanti saremo, Toolbox ci darà la sala più adeguata
> >
> > Ciao
> >
> > federico
> >
> >
> > 
> > Posted by: Federico Fissore 
> > 
> >
> > 
> > Se desideri essere rimosso dalla mailing list manda una mail a questo
> indirizzo:
> > it-torino-java-jug-unsubscr...@yahoogroups.com
> > 
> >
> > 
> >
> > Yahoo Groups Links
> >
> >
> >
> >
>
> 
>


-- 
Massimo Ugues

Re: [Jug-Torino] Cloudconf 2019

[Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]]

In realta' con  jug-to applicando il codice si passa da 89 a 69 ;)
yeah

Max

On Fri, Mar 22, 2019 at 9:22 AM Simone Bordet simone.bor...@gmail.com
[it-torino-java-jug]  wrote:

>
>
> Ciao,
>
> On Fri, Mar 22, 2019 at 9:08 AM Massimo Ugues m.ug...@gmail.com
> [it-torino-java-jug]  wrote:
> > Ciao, per caso abbiamo ancora sconti sulla cloudconf?
>
> No, per quanto ne so sono terminati e la conferenza è vicina al
> sold-out, quindi affrettati.
>
> --
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless. Victoria Livschitz
> 
>


-- 
Massimo Ugues

Re: [Jug-Torino] Java: come scegliere il miglior IDE?

[Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]]

IntelliJ Ultimate edition da 4 anni dopo 10 anni con Eclipse e i vari
derivati (STS, Jboss Developer).
Dal mio punto di vista assolutamente superiore agli altri, non tornerei
indietro.

Max

On Mon, Oct 22, 2018 at 2:14 PM Giovanni pino_o...@yahoo.com
[it-torino-java-jug]  wrote:

>
>
> IntelliJ lo uso in ufficio. Lo trovo ottimo!
>
> Ciao
> jo
>
> On Monday, October 22, 2018, 6:33:56 PM GMT+8, Ivan Martoccia
> m.iv...@gmail.com [it-torino-java-jug] 
> wrote:
>
>
>
>
> Io sono passato ad intelliJ da circa un anno e da 9 mesi alla versione a
> pagamento, non tornerei indietro ad eclipse o netbean neanche se mi
> pagassero. Lo trovo formidabile!
>
> Il giorno lun 22 ott 2018 alle ore 12:15 beppeconig...@yahoo.it
> [it-torino-java-jug]  ha scritto:
>
>
>
> Ciao a tutti,
>
> so che molti storceranno il naso , ma da "vecchio" informatico ho ancora
> la newsletter da siti storici eheh (che magari ora non sono piu' tanto
> affidabili secondo molti guru...) , ma mi ha incuriosito una tra le notizie
> di cui  oggi si parla di :
> https://www.html.it/articoli/java-come-scegliere-il-miglior-ide
>
>
> In termini % nel JUG quale viene usato maggiormente?
>
>
> Buona giornata jugger
>
>
>
> --
> Response to : m.iv...@gmail.com
> 
>


-- 
Massimo Ugues

Re: [Jug-Torino] JDK 10 !

[Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]]

Con un cambio di ritmo del genere (6 mesi a major release) sara' veramente
difficile mantenere il passo: finira' che alcune release non verranno mai o
quasi adottate in produzione, come probabilmente sara' successo per la
versione 9.

Sarebbe bello vedere l'attuale penetration market percentage delle varie
versioni a oggi; purtroppo ho trovato solo la "foto" fino a marzo 2017
https://goo.gl/WrKgKs.


2018-03-21 11:09 GMT+01:00 Roberto Franchini ro.franch...@gmail.com
[it-torino-java-jug] :

>
>
> Ma si può mettere in un docker?
>
> On 21 Mar 2018 10:58, "bruno bossola bboss...@gmail.com
> [it-torino-java-jug]"  wrote:
>
>>
>>
>> Beh, la mia preferita e' sempre 1.02 con jdbc-odbc bridge in early access
>> :)
>>
>> 2018-03-21 14:38 GMT+05:30 Roberto Franchini ro.franch...@gmail.com
>> [it-torino-java-jug] :
>>
>>>
>>>
>>>
>>>
>>> 2018-03-21 9:30 GMT+01:00 bruno bossola bboss...@gmail.com
>>> [it-torino-java-jug] :
>>>


 Si, ma penso che la grande migrazione avverra' con la 11 che e' LTS. La
 9 e la 10 sono una buona idea, e spero che molti le adottino in modo da
 prevenire casini passando diretti da 8 a 11, ma diciamo che molte aziende
 aspettano la 11 per avere un supporrto a lungo termine. Poi ci sono sempre
 "sacche di resistenza..." :)



>>> Il vintage va di moda, Java 1.3.1 ha sempre il suo fascino..
>>> FRANK
>>>
>>> --
>>> Roberto Franchini
>>> "The impossible is inevitable"
>>> https://github.com/robfrank/
>>> https://twitter.com/robfrankie 
>>> https://www.linkedin.com/in/robfrank
>>>
>>>
>> 
>



-- 
Massimo Ugues

Re: [Jug-Torino] Dubbio Spring MVC

[Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]]

Certo che va bene.
Perché no?

Il giorno ven 16 feb 2018 alle 16:17 Danilo Boi danilobo...@yahoo.com
[it-torino-java-jug] <it-torino-java-jug@yahoogroups.com> ha scritto:

>
>
> Ok scusami , ma allora non va bene fare l'autowired di un oggetto
> repository in un service .
>
>
>
> Il Venerdì 16 Febbraio 2018 16:08, "Andrea Ligios andrealig...@gmail..com
> [it-torino-java-jug]" <it-torino-java-jug@yahoogroups.com> ha scritto:
>
>
> Ciao,
>
> Stateless nel senso che essendo singleton non devono mantenere uno stato,
> non devono avere variabili.
> @Stateless è la notazione Java EE per definire un EJB stateless
> non-singleton, non è quello che stai cercando.
>
>
> 2018-02-16 14:41 GMT+01:00 Danilo Boi danilobo...@yahoo.com
> [it-torino-java-jug] <it-torino-java-jug@yahoogroups.com>:
>
> Ciao Massimo .
> Grazie della risposta .
> Mi preocupa perchè mi domando : Quando ho piu chiamate  in contemporanea
> essendo oggetti Singhelton non rischio di restituire o eseguire operazioni
> su db Sbagliate ? una sorta di sovraposizione degli accessi a db.
> Per stateless intendi definire le mie cleassi services con @Stateless o
> anche i repository?
> Grazie mille ciao.
>
>
> Il Venerdì 16 Febbraio 2018 13:27, "Massimo Ugues m.ug...@gmail.com
> [it-torino-java-jug]" <it-torino-java-jug@ yahoogroups.com
> <it-torino-java-jug@yahoogroups.com>> ha scritto:
>
>
> Ciao.
> Direi che l'approccio e' da manuale, in spring per default tutti i bean
> hanno scopo singleton: la premessa importante da capire è che essendo
> singleton devono essere stateless.
> Perchè hai dei dubbi sul Repository? Direi che visto che possono essere
> visti come dei DAO anche loro dovrebbero essere stateless.
>
> Lo stereotipo @Repository mi pare che aggiunga degli aspetti per fare il
> translate delle sottostanti sql exceptions e ti permetta di iniettare un
> PersistenceContext o un EntityManager se dovessi averne bisogno (ripeto mi
> pare e su questo sto andando a braccio).
>
> Secondo me quindi tutto corretto ;)
>
> P.S. I servizi Rest li stai annotando con @Controller? lo stereotipo
> dedicato è @RestController.
>
> 2018-02-16 11:12 GMT+01:00 Danilo Boi danilobo...@yahoo.com
> <danilobo...@yahoo..com> [it-torino-java-jug] <it-torino-java-jug@
> yahoogroups.com <it-torino-java-jug@yahoogroups.com>>:
>
> Ciao A tutti .
> Grazie per aver accettato la richiesta.
> Mi sto occupando di programmazione java specificatamente , al momento , su
> Spring MVC.
>
> Sto sviluppando dei servizi Rest ..
>
> In particolare la Parte ORM la sto gestendo con spring-mybatis
> Lasciando fare a spring la factory dei mapper
>
> Mentre per il layer di controllo sto seguendo l’approccio di alcuni esempi
> che ho trovato in rete e cioè
>
> Un oggetto controller annotato con @Controller
> Vari oggetti di servizio (Business logic) annotati come @Service
> Oggetti di manager dei mapper MyBatis annotati come @Repository
>
> All’interno di questo oggetto eseguo del
> @Controller eseguo  @Autowired degli oggetti @Service
> Negli oggetti @Service eseguo @Autowired degli oggetti @Repository
> Che a loro volta iniettano i mapper MyBatis.
>
> Il dubbio che mi attanaglia da qualche giorno è che Spring
> All’avvio istanzia il @Controller con un riferimento a n @Service
> Questi a loro volta saranno “Singleton” che  a loro volta iniettano
> Gli oggetti   @Repository che a loro volta iniettano i mapper MyBatis.
>
> Da quello che ho capito mi trovo in una situazione in cui tutti gli
> oggetti
> sono “Singleton” e questo può andarmi bene per il @controller e forse
> anche
> per il @Service ma mi intimorisce per il layer @Repository.
>
> Ho sbagliato l’approccio ?
> Scusate e grazie .
> Ciao.
>
>
>
>
> --
> Massimo Ugues
>
>
>
>
>
>
> 
>
-- 
Massimo Ugues

Re: [Jug-Torino] Dubbio Spring MVC

[Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]]

Scusa, stateless come paradigma non come keyword (EJB?!! Oh NO!!)

I componenti di spring li devi disegnare come "oggetti" senza stato, senza
instance variable e cosi via  in quel senso stateless.

*Mi preocupa perchè mi domando : Quando ho piu chiamate  in contemporanea
essendo oggetti Singhelton non rischio di restituire o eseguire operazioni
*

Ehm, come dire, vediamo se trovo le parole giuste.. NO!!! :D

Max



On Fri, Feb 16, 2018 at 2:41 PM, Danilo Boi danilobo...@yahoo.com
[it-torino-java-jug] <it-torino-java-jug@yahoogroups.com> wrote:

>
>
> Ciao Massimo .
> Grazie della risposta .
> Mi preocupa perchè mi domando : Quando ho piu chiamate  in contemporanea
> essendo oggetti Singhelton non rischio di restituire o eseguire operazioni
> su db Sbagliate ? una sorta di sovraposizione degli accessi a db.
> Per stateless intendi definire le mie cleassi services con @Stateless o
> anche i repository?
> Grazie mille ciao.
>
>
> Il Venerdì 16 Febbraio 2018 13:27, "Massimo Ugues m.ug...@gmail.com
> [it-torino-java-jug]" <it-torino-java-jug@yahoogroups.com> ha scritto:
>
>
>
> Ciao.
> Direi che l'approccio e' da manuale, in spring per default tutti i bean
> hanno scopo singleton: la premessa importante da capire è che essendo
> singleton devono essere stateless.
> Perchè hai dei dubbi sul Repository? Direi che visto che possono essere
> visti come dei DAO anche loro dovrebbero essere stateless.
>
> Lo stereotipo @Repository mi pare che aggiunga degli aspetti per fare il
> translate delle sottostanti sql exceptions e ti permetta di iniettare un
> PersistenceContext o un EntityManager se dovessi averne bisogno (ripeto mi
> pare e su questo sto andando a braccio).
>
> Secondo me quindi tutto corretto ;)
>
> P.S. I servizi Rest li stai annotando con @Controller? lo stereotipo
> dedicato è @RestController.
>
>
> 2018-02-16 11:12 GMT+01:00 Danilo Boi danilobo...@yahoo.com
> <danilobo...@yahoo..com> [it-torino-java-jug] <
> it-torino-java-jug@yahoogroups.com>:
>
>
> Ciao A tutti .
> Grazie per aver accettato la richiesta.
> Mi sto occupando di programmazione java specificatamente , al momento , su
> Spring MVC.
> Sto sviluppando dei servizi Rest 
> In particolare la Parte ORM la sto gestendo con spring-mybatis
> Lasciando fare a spring la factory dei mapper
>
> Mentre per il layer di controllo sto seguendo l’approccio di alcuni esempi
> che ho trovato in rete e cioè
>
> Un oggetto controller annotato con @Controller
> Vari oggetti di servizio (Business logic) annotati come @Service
> Oggetti di manager dei mapper MyBatis annotati come @Repository
>
> All’interno di questo oggetto eseguo del
> @Controller eseguo  @Autowired degli oggetti @Service
> Negli oggetti @Service eseguo @Autowired degli oggetti @Repository
> Che a loro volta iniettano i mapper MyBatis.
>
> Il dubbio che mi attanaglia da qualche giorno è che Spring
> All’avvio istanzia il @Controller con un riferimento a n @Service
> Questi a loro volta saranno “Singleton” che  a loro volta iniettano
> Gli oggetti   @Repository che a loro volta iniettano i mapper MyBatis.
>
> Da quello che ho capito mi trovo in una situazione in cui tutti gli
> oggetti
> sono “Singleton” e questo può andarmi bene per il @controller e forse
> anche
> per il @Service ma mi intimorisce per il layer @Repository.
>
> Ho sbagliato l’approccio ?
> Scusate e grazie .
> Ciao.
>
>
>
>
> --
> Massimo Ugues
>
>
>
> 
>



-- 
Massimo Ugues

Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

[Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]]

*L'uso dei builder per costruire oggetti nei test è stato reso popolare
dal GOOS *

Sinceramente non riesco a vedere una differenza sostanziale tra un builder
e una fluent interface dei setter del POJO in oggetto.
Come PRO la fluent interface ti evita di avere una classe che fa appunto da
builder, e come spesso LESS IS MORE.

Il fatto che tu sostenga che i builder siano stati resi popolari dal TDD mi
sembra a dir poco opinabile (https://tinyurl.com/y9qxgzhh).
E' un po' come dire che il Singleton sia stato reso impopolare dallo stesso
movimento..



2018-01-15 21:30 GMT+01:00 Matteo Vaccari matteo.vacc...@gmail.com
[it-torino-java-jug] :

>
>
>
> L'uso dei builder per costruire oggetti nei test è stato reso popolare dal
> GOOS 
>
> 2018-01-12 18:35 GMT+01:00 Federico Fissore feder...@fsfe.org
> [it-torino-java-jug] :
>
>>
>>
>> Ciao
>>
>> domandina del venerdì sera
>>
>> Da qualche tempo vedo con crescente frequenza questo tipo di codice
>>
>> return ExpenseBuilder.anExpense()
>> .withId(id)
>> .withAmount(new BigDecimal(66.6).setScale(2, RoundingMode.CEILING))
>> .withDate(new Date())
>> .withReason("Something pretty")
>> .build();
>>
>> Viene da un test, quindi i dati sono hardcodati. Altrimenti vengono
>> presi da un altro bean via getter, oppure quest altro bean offre lui un
>> metodo che restituisce un builder pre-popolato
>>
>> Anche voi siete abituati a fare così quando dovete passare dati da una
>> DTO a un altro? Se no, come fate?
>>
>> ciao
>>
>> federico
>>
>
> 
>



-- 
Massimo Ugues