[Javalist] Spring kerdesek

[Szabolcs Póta]

Nem is a Spring lenne ha egy problémára nem egy tucat megoldást kínálna ;-)
A java config valóban előnyös ha valakinek fontos az OO koncepció még a
konfig szinten is. Ami nekem nem szimpatikus, hogy a "configokat" le kell
fordítani, ami sokszor a deploymentet  nehezíti. Hogy az XML ne legyen
katyvasz tényleg már az elejétől oda kell figyelni, hogy miként szervezzük
a fájlokat. Erre további segítség a profilok használata 3.1-ben:

http://blog.springsource.com/2011/02/11/spring-framework-3-1-m1-released/

Üdv,

Szabolcs
 On Jun 4, 2012 10:45 PM, "Zsombor" <gzsombor at gmail.com> wrote:

>
> Hi,
>
>  Azért ha már a Phased interfészig eljut az ember, akkor az már kicsit
> gyanús, hogy valami nagyon el van rontva, ha ilyen rejtett összefüggések
> vannak a komponensek között, ami miatt szükség van mágikus egész
> konstansokra az ütemezett indításhoz.
> Tapasztalatom szerint az xml-ekkel is hatalmas, kezelhetetlen katyvasz
> lesz egy idő után, miután vegyül az összehuzalozás kérdése, a tényleges
> konfigurációs adatokkal. Valamint bár lehet xml-eket importálni, és így
> magasabb szintű modulokat készíteni, és azokat egyben beemelni, azért ezek
> nem szeparálódnak - azaz ha beimportálsz egy xml-t, akkor mindegyik bean
> látszódni fog belőle, még ha azt az eredeti alkotó, belső implementációs
> kérdésnek is gondolta. Az xml gép feldolgozása valóban csábító, de így
> egyes elvetemült embereket még arra is csábíthatja, hogy írjanak egy meta
> konfigurációs nyelvet, amivel generálhatják a különféle környezetekhez való
> xml konfigurációkat ... :)
>  Ha már Spring, akkor szerintem inkább ezzel praktikus összehuzalozni az
> objektumokat:
>
> http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java
> Ezekből képződnek a "modulok", amik egymásra is tudnak hivatkozni, egymást
> tudják kiterjeszteni, priváttá lehet tenni részeket, stb,
> S a pár, valódi konfigurációs értéket meg egy property fileból húzza be az
> ember ...
>
> üdv
> Zs
>
> 2012/6/4 Szabolcs Póta <szabolcs.pota at gmail.com>
>
>> Hello,
>>
>> Háttérben futó szálak indításához és leállításához én még ezt javaslom:
>>
>>
>> http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-factory-lifecycle-processor
>>
>>
>> Egyszerűen definiálni kell egy singleton bean-t az XML-ben, ami a
>> Lifecycle interface-t implementálja. A konténer indulásakor (miután minden
>> bean elkészült)  meghívja a start-ot, majd leálláskor a stop-ot. A dolgot
>> tovább lehet finomítani a Phased interfésszel, amivel a sorrendiséget is
>> meg lehet határozni. Mi ezt használjuk például szerver transzportok
>> indítására, leállítására.
>>
>> Én személy szerint nem szeretem az annotációkat. Egy bizonyos kódméret
>> fölött kezelhetetlen 'magic' lesz belőle. Jobban szeretem ha az alkalmazás
>> teljes struktúrája ott van az XML-ben. Lehet cserélgetni (dev, qa, prod),
>> áttekinthető, a függőségi gráf vizualizálható, míg ugyanez annotációkkal
>> bajos. De természetesen ez már nem tartozik szorosan a tárgyhoz.
>>
>> Üdv,
>>
>> Szabolcs
>>
>>
>> 2012/6/4 Böszörményi Péter <zmblevlist at gmail.com>
>>
>>> Spring nem hasznal poolt. Alapbol singleton az objektum, ha keszites
>>> hozza sajat scopeot, akkor ott tudsz poolt megvalositani.
>>>
>>>
>>> On Mon, 04 Jun 2012 21:41:56 +0200, zamek <zamek at vili.pmmf.hu> wrote:
>>>
>>>  06/04/2012 09:20 PM keltezéssel, cx.chico írta:
>>>>
>>>>> Az Spring AOP alapban interfészeken keresztül működik. A @Autowired
>>>>> használatához létre kell hozni egy interfészt. A program így
>>>>> módosulna:
>>>>>
>>>>
>>>> Szerintem a leírt feladat szempontjából nincs szükség arra, hogy a
>>>> "PollingService"-t a Spring kezelje (mivel azt írtad, hogy csak egynek
>>>> szabad lennie belőle), a DeviceServiceImpl  nyugodtan lehet akár ilyen
>>>> is:
>>>>
>>>> @Service("getDeviceData")
>>>> public class DeviceServiceImpl extends RemoteServiceServlet implements
>>>>        DeviceService {
>>>>
>>>>    private final PollingServiceImpl pollingService = new
>>>> PollingServiceImpl();
>>>>
>>>>    @Override
>>>>    public Response<Map<String, Pojo>>  getDeviceData() {
>>>>
>>>>           Response<Map<String, Pojo>>  result = pollingService.start();
>>>>            pollingService.reset();
>>>>
>>>>    }
>>>>
>>>>
>>>> Hmmm, ez nem fog minden DeviceServiceImpl peldanybol egy
>>>> pollingService-t letrehozni?
>>>>
>>>> A spring nem ugy csinalja, mint az ejb, hogy egy pool-ban vannak a
>>>> bean-ek es szukseg eseten a pool-bol vesz elo egyet, vagy ha nincs, akkor
>>>> uj peldany?
>>>>
>>>> Esetleg, ha static lenne, de az mar nagyon nem szep.
>>>>
>>>>
>>>
>>> --
>>> Üdvözlettel,
>>> Böszörményi Péter
>>>
>>> ______________________________**_________________
>>> Javalist mailing list
>>> Javalist at lists.javaforum.hu
>>> http://lists.javaforum.hu/**mailman/listinfo/javalist<http://lists.javaforum.hu/mailman/listinfo/javalist>
>>>
>>
>>
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>
>>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20120604/8ad0dcd8/attachment.html>