Új hozzászólás Aktív témák

• F1rstK1nq aktív tag

  #9176

  #9175 mobal

  2017-02-14 15:50:25

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #9175 mobal

  Megértem. Tényleg embere válogatja.
  Egyébként Spring Boot olyan szépen autoconfigolja, hogy öröm belekezdeni.

  Ránéztem, nem rossz dolog ez a Mustache sem.
  Viszont, most ez az AngularJS 2 + Spring keltette fel az érdeklődésem, hogy megemlítettétek, biztos kipróbálom valami hobbiprojektben a közeljövőben.

  (#9158) Aethelstone: Nekem sincs jó véleményem Vaadin-ról, sőt nagyon megutáltam a projekt végére, pedig még a Vaadin Spring integrációt is használtuk. CustomLayout-tal még hagyján, de amit kigenerál magából néha enélkül, az vicc. Mindegy, egy Vaadin Certification-re jó volt a tudás, projekt után, de nem igazán tervezek rá visszatérni, ha nem muszáj.

• F1rstK1nq aktív tag

  #9174 2017-02-14 15:06:29

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  Én kedvencem Spring + Thymeleaf kombó, Bootstrap-vel fűszerezve.
  Valaki próbálta? Ajánlom.

• F1rstK1nq aktív tag

  #9126

  #9125 Taoharcos

  2017-01-23 10:12:01

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #9125 Taoharcos

  Lehet én vagyok a maradi, de nem egyszerűbb/hatékonyabb így? mvnrepository, majd megkeresed és bemásolod a megfelelő dependency-t a pom-odba?

  

• F1rstK1nq aktív tag

  #8786

  #8784 floatr

  2016-11-16 12:10:11

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #8784 floatr

  Érdekes amit írsz, bizonyos szinten érhető is, de szerintem ez abszolút szubjektív. (még ha te nem is annak érzed)
  SLF4J oldaláról: "We used to recommend that loggers members be declared as instance variables instead of static. After further analysis, we no longer recommend one approach over the other."
  Ott van egy jó kis táblázat a pro/kontra érvekre, de ő sem akar kimondott állást foglalni, hogy osztály vagy példány változó legyen a logger.
  Régebben erről már olvastam egy kisebb vélemény ütközést stackoverflow-n is.
  Akkor engem meggyőzött a példányváltozós logger használat és úgy kötöttem ki végül itt, hogy kényelmes nekem a logger példány inject-álás prototype-ként.

• F1rstK1nq aktív tag

  #8783 2016-11-16 11:07:02

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  Nem tudom kinek mennyire új dolog ez, de leírom, mivel doksiban nem nagyon tűnt fel.
  Spring 4.3-mal bejött az InjectionPoint class. CDI-ben már régebb óta van ilyen. Nekem ez abból az szempontból volt érdekes, hogy ennek a segítségével használtam CDI környezetben eddig a Loggereket. (inject-áltam, nekem ez így kényelmesebb volt, mint a standard megoldás)

  Íme spring oldalon a megvalósítás:

  @Bean
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public Logger logger(InjectionPoint injectionPoint){
return LoggerFactory.getLogger(injectionPoint.getMember().getDeclaringClass());
}

  (SL4FJ a facade)

  Ezt ugye csak be kell szúrni a megfelelő osztályokba és kész:

  @Autowired
private Logger logger;

  Mit gondoltok? Tetszik/nem tetszik?
  Jobban szeretitek a hagyományos megoldást?

  private final Logger logger = LoggerFactory.getLogger(getClass().getName());

• F1rstK1nq aktív tag

  #8584

  #8582 DarkByte

  2016-09-27 15:01:43

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #8582 DarkByte

  Szintén. IDEA után ránézni nem tudok Eclipse/Netbeans párosra.

  Nyilván ez eléggé szubjektív dolog.

• F1rstK1nq aktív tag

  #8376

  #8373 Karma

  2016-06-27 10:19:25

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #8373 Karma

  Én is ezt hittem sokáig, hogy elég a Hikari függőséget betenni a pom-ban, aztán kidebugoltam a közelmúltban és láttam, hogy így az alap tomcat-jdbc datasource-t szúrja be.

  Szóval kell a spring.datasource.type=com.zaxxer.hikari.HikariDataSource. Majd checkold azért te is légyszí, ha lesz rá időd.

• F1rstK1nq aktív tag

  #8372

  #8371 CJ19

  2016-06-24 16:42:29

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #8371 CJ19

  Nem tudom Karma, hogy csinálja, mert lehet máshogy is, de nekem ez tűnik a legegyszerűbbnek, én így szoktam.

  A pom-ba berakod a dependency-t, verzió nem kell ugye, mert Spring Boot a parent, azt ő intézi.

  <dependency>
<groupId>com.zaxxer</groupId>
<artifactId>HikariCP</artifactId>
</dependency>

  Majd az application.properties-be ezt a sort:
  spring.datasource.type=com.zaxxer.hikari.HikariDataSource
  Mivel a default, a tomcat-jdbc datasource.

  Majd a megfelelő értékekből létrehozza a datasource-ot a Spring Boot.
  pl.: spring.datasource.driver-class-name=org.hsqldb.jdbc.JDBCDriver
spring.datasource.url=jdbc:hsqldb:mem:test
spring.datasource.username=sa
spring.datasource.password=

• F1rstK1nq aktív tag

  #8301

  #8299 Orionk

  2016-05-11 11:26:59

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #8299 Orionk

  Ez nem rossz.

  A Head First Design Patterns könyvhöz még nem volt ugyan szerencsém, de nagyon dicsérik.

• F1rstK1nq aktív tag

  #8211

  #8209 func93

  2016-03-31 16:13:07

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #8209 func93

  Ha nem probléma az angol, akkor a legjobb könyv a témában, ami ad egy részletes leírást a nyelvről: Thinking in Java
  Abszolút kezdőknek is ajánlott és mérföldekkel jobb, mint a magyar "társaik".

• F1rstK1nq aktív tag

  #8194

  #8193 Dave-11

  2016-03-18 16:11:29

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #8193 Dave-11

  Gondolom a static main() metódusban használod.
  Igen amit mondasz, ebben az esetben teljesen jó. AktualisOsztaly.class a getClass() helyett.

  Kevés az esélye, hogy ezt egy static metódusban fogod használni real life projectben, bár ki tudja.

• F1rstK1nq aktív tag

  #8192

  #8191 Dave-11

  2016-03-18 15:45:10

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #8191 Dave-11

  Ez a klasszikus megoldás:

  String fileName = "res01.res";
  ClassLoader classLoader = getClass().getClassLoader();
  URL resource = classLoader.getResource(fileName);
  if (resource != null) {
  File file = new File(resource.getFile());
  try (BufferedReader br = new BufferedReader(new FileReader(file))) {
  
  String line;
  while ((line = br.readLine()) != null) {
  System.out.println(line);
  }
  } catch (IOException e) {
  e.printStackTrace();
  }
  }

  Viszont, ha érdekel más módszer is, itt még tudsz csemegézni Java8-as megoldások közül is. Viszont amit ezekben a megoldásokban nem látsz, hogy hogyan éred el a resources alatti fájlokat. Így:
  ClassLoader classLoader = getClass().getClassLoader();
  URL resource = classLoader.getResource(fileName);

• F1rstK1nq aktív tag

  #8157

  #8151 tboy93

  2016-02-22 10:05:20

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #8151 tboy93

  Spring-re Spring in Action.

  Nagyon jó könyv, szájbarágós, angolja sem vészes, ha attól félnél.

• F1rstK1nq aktív tag

  #8033

  #8032 Aethelstone

  2015-12-11 11:46:43

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #8032 Aethelstone

  Így van, én is erre szántam a "még legmagasabb értelmes interfészt megadni" részemet, de lehet a tiéd jobb megfogalmazás.

• F1rstK1nq aktív tag

  #8030

  #8029 pvt.peter

  2015-12-11 11:27:15

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #8029 pvt.peter

  Így megmarad az az előnyöd, hogy csak a Lista implementációját változtatod meg példányosításkor, a kód többi része változatlan marad. (Például ha úgy döntesz, ArrayList helyett LinkedList-et használsz később)

  Clean Code szerint egyébként érdemes szinte minden esetben a referencia értéknek a még legmagasabb értelmes interfészt megadni.

• F1rstK1nq aktív tag

  #7657

  #7656 Aethelstone

  2015-07-30 13:46:10

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #7656 Aethelstone

  Természetesen meglehet és teljesen jó az a megoldás is, csak az hivatalosan nem típusbiztos és nem refactor barát. (én idea zom az is megtudja amúgy )

  @ ComponentScan(basePackages={"package1", "package2"})

  Kinek mi? Én egyszerűbbnek tartom a marker interfacet.
  Egy elméleti példával be is bizonyítom, hogy miért:
  -van egy top level package-ed (hu.somebody.main)
  -ez alatt lesz 3 package-ed ahol a component-ek leszek definialva:
  (hu.somebody.main.package1, hu.somebody.main.package2, hu.somebody.main.package3)
  -a marker interface-t beteszed a top level pakage-edbe:

  package hu.somebody.main;
  public interface Application {}

  Ez az alap felállás. Akkor a 2 opció scannelésre:

  @Configuration
  @ComponentScan(basePackageClasses = Application.class)
  class ApplicationConfig {}

  vagy

  @Configuration
  @ComponentScan(basePackages={"hu.somebody.main.package1", "hu.somebody.main.package2", "hu.somebody.main.package3"})
  class ApplicationConfig {}

  Melyik tűnik egyszerűbbnek?

• F1rstK1nq aktív tag

  #7655

  #7654 emvy

  2015-07-30 13:04:02

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #7654 emvy

  Ez nem szar, így van kitalálva Springben. Amit megjelölsz @Component annotációval (vagy valamelyik stereotype-jával) az az osztályod lesz Component és működnek rajta a spring specifikus dolgok (pl: Autowired). Ez természetesen a Spring álltal ajánlott implicit mód (Implicit bean discovery and automatic wiring). Lehet expliciten is @Bean annotációval Javaconfig-ból, meg xml config-ból is, de most kicsit elkalandoztam.

  Amit te keresel, erre van egy jó kis "best practice" Springben: Csinálj egy üres marker interface-t abba a csomagodba ahol scannelni szeretnél és akkor arra az interfacere hivatkozz a ComponentScan-nél.
  pl.: @Configuration
  @ComponentScan(basePackageClasses = Application.class)
  class ApplicationConfig {}

  marker interface:
  public interface Application {}

• F1rstK1nq aktív tag

  #7632

  #7629 #39560925

  2015-07-16 10:43:01

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  F1rstK1nq

  aktív tag

  #7629 #39560925

  Jól tetted. Egyébként apró észrevétel, de én úgy tudom Spring Boot-nál ExceptionalBackend/src/main/java/spring-config.xml fájl teljesen fölösleges, nyugodtan törölheted.

Új hozzászólás Aktív témák