[java] Geronimo vs JBoss

Сорри ничем не могу помочь. Сижу на Glassfish v3 ибо Java EE 6

Geronimo под APL. JBoss под LGPL.

IBM Websphere Application Server Community Edition основан на коде Geronimo, поддерживает J2EE 5.0. Хорошая интеграция с Eclipse.

JBoss — это Java EE 6.0 и EJB 3.1.

Geronimo отстаёт от JBoss по части поддержки новых технологий, но это неудивительно, так как разрабатывается на бесплатной основе.

>JBoss — это Java EE 6.0 и EJB 3.1.

С каких это пор 5.1 (Последний релиз) поддерживает jee6? Вы с glassfish-v3 не путаете?

Прошу прощения, путаю.

На сайте http://www.jboss.org идут разговоры о поддержке Java EE 6.0 и EJB 3.1. У Geronimo пока всё глухо.

Короче, никто из высказавшихся и не пользовался Geronimo никогда.

Скажем так: недоисследовал.

Эх, а я уже не проверил и обрадовался, думал JBoss ставить. Кстати, почему нужно столько времени чтобы очередная версии Java EE обрела популярность. Нет никаких видимых причин использовать Java EE 5, когда есть 6. Кроме конечно единственного контейнера Glassfish v3. Что мешает хостерам его поставить, вроде хорошо работает, Sun позиционировала его как продакшн.

Каким ещё хостерам?

посмотри когда вышла Java EE5 и через сколько разродился Jboss, а GlassFish выходит одновременно с новой версией JavaEE и имеет человеческую админку, а не jmx-анальный интерфейс.

Что интересно - у меня дискуссии не видно вообще. Открыл - все как один заигноренные. Так что «никто из высказавшихся и не пользовался» совершенно не удивительно :)

Ну как каким? Обычным. Java EE - очень перспективная веб-технология. По своим возможностям она вплотную приближается к PHP 5.2.

> По своим возможностям она вплотную приближается к PHP 5.2.

O_o facepalm.png

По своим возможностям она вплотную приближается к PHP 5.2.

PHP вряд ли дотягивает до JSP, не говоря уж о JSF. До JEE — как до Китая через Альпы.

Все поняли - вы Дартаньян.

P.S. Не пользоваться Geronimo = не пропустить ничего в жизни

ну тут ничего и не писали, iZEN в очередной рас сообщил что FreeBSD RIP , да vertexua про какихта хостеров говорит

Glassfish гумно, ибо LoginModule они пейсали положив на своиже спецификации, какаши этакие.

Да, да, я согласен. Просто грустно что остальные технологии быстренько реализуются, а Java EE - спецификация, пока реализуют ее на продакшн серверах приложений пройдет огого времени. Я не знаю причин всем не переходить на Glassfish, просто не особо сталкивался с такими случаями. Ну раз сидят все на JBoss, WebLogic и т.д. значит причины есть. Кто знает причины? Я задаю вопрос, потому что точно помню маркетинг Sun, что Glassfish - полноценный и готовый к любым нагрузкам и задачам.

Обидно что на хостингах, которые я видел - максимум Tomcat... Чем обусловлено? Glassfish - слишком толстый?

> vertexua про какихта хостеров говорит

Могу позволить себе свою точку зрения? Извините если радикальная, но я за распространение Java EE среди обычных хостинг-провайдеров, за жесткий слив PHP

Интерестно. А что там не так?

Glassfish разве не использует Tomcat в качестве контейнера сервлетов? O_o

PHP сливается вчистую не Java EE, а одним лишь Tomcat.

Я говорил о только Tomcat.

Glassfish использует Grizzly - форк Tomcat-а. Только вопрос был о серверах приложений, а не о сервлет контейнерах.

.....
public class LoginModule implements javax.security.auth.spi.LoginModule{
.....
  @Override
  public boolean login() throws LoginException {
    String password = null;
    Set credentials = null;
    if(subject != null){
      credentials = subject.getPrivateCredentials();
    }
    if(credentials != null){
      /**
       * Дело в том что GlassFish использует метод аутентификации не
       * соответствующий спецификации, посему callBackHandler не может вернуть
       * пароль и имя пользователя, но они есть в subject в образе
       * "com.sun.enterprise.security.auth.login.common.PasswordCredential", но
       * Reflection спасет нас
       */
      for(Object cred : credentials){
        Class<?> clazz = cred.getClass();
        String className = clazz.getName();
        if("com.sun.enterprise.security.auth.login.common.PasswordCredential"
            .equals(className)){
          try{
            Method get = clazz.getMethod("getPassword");
            password = (String)get.invoke(cred);
            get = clazz.getMethod("getUser");
            name = (String)get.invoke(cred);
          } catch (Exception ex){
            throw new FailedLoginException(ex.getMessage());
          }
          break;
        }
      }
    } else {
      /**
       * А это уже аутентификация по спецификации 8)
       */
      NameCallback nameCall = new NameCallback("name");
      PasswordCallback passCall = new PasswordCallback("pass", false);
      Callback[] callbacks = new Callback[]{nameCall, passCall };
      try{
        callbackHandler.handle(callbacks);
      }catch (Exception ex) {
        log.log(Level.SEVERE,"In handler:", ex);
      }
      name = nameCall.getName();
      password = new String(passCall.getPassword());
    }
    Integer res = 0;
    Mdb mdb = null;
    try {
      passHash = Tools.getMD5(password);
      final HashMap<String, Object> params = new HashMap<String, Object>();
      params.put("login",name);
      params.put("pass",passHash);
      mdb = Mdb.getInstance();
      final DBBean dbBean = mdb.getBean(DBBean.class);
      res = runAs(new PrivilegedExceptionAction<Integer>() {
        @Override
        public Integer run() throws Exception {
          List<Integer> list = dbBean.selectList(NAMESAPCE + ".tryLogin",
            0, -1, params);
          return list.get(0);
        }
      });
      if(res == null){//это возможно только при ошибке
        throw new NullPointerException("res in null");
      }
    } catch (Exception ex) {
      throw  new FailedLoginException(ex.getMessage());
    } finally {
      if(mdb != null){
        mdb.free();
      }
    }
    if(res == 0){
      //пользователь с таким логином и паролем не найден!
      throw  new AccountNotFoundException();
    }
    return isLogined = true;
  }
...

смотри, код вместе с каментами взят из рабочего проекта, при чем это лишь маля часть косяков, там вагон «дыр» в спецификации сервлетов которые только кокетливо прикрыли в servlet 2.1 спецификации (если номером не ошибся) введя login, logout, не введя хе хе никакой возможности получить информацию о пользователи помещенную туда из LoginModule.

А еще иж каличный JMS...

Хотя JBoss намного хуже, да 8)

Какой сервер рекомендуете?

Ставь Geronimo с Jetty-контейнером внутрях.

glassfish если ты не чуйствуешь у себя задатки робота для совокупления с jboss

Зачем? Какой выигрыш по сравнению с Java EE 6 compatible Glassfish v3?

Я и пользуюсь Glassfish, просто думаю что же такого волшебного в JBoss и WebLogic, что они так широко распространены

пиар, пиар, пиар, куча рюшечек изкаробки, хотя например jbosscache мне проще было прикрутить чем тянуть jboss весь.

>смотри, быдлокод вместе с каментами взят из рабочего проекта, при чем это лишь маля часть косяков

fixed

Например у заказчика стоит J2EE 1.4, и он не собирается тратить ресурсы на апгрейд, который не принесёт ему явную выгоду (а принести проблемы может).

Grizzly - не форк томката, а http коннектор. Веб-контейнер в Glassfish - томкат.

Цитируем vertexua

Ну раз сидят все на JBoss, WebLogic и т.д. значит причины есть.

Причина проста - WebLogic работает, и очень даже хорошо работает, а JBoss - исторически первый бесплатный J2EE контейнер (сановский RI не в счет, т.к. медленный он был), ну и архитектура у него достаточно приличная всегда была. Что касается, почему на хостингах нет глассфиша - а зачем он там? Если нужны все возможности J2EE куда проще купить VDS или нормальную выделенную железку и ставить самому то, что больше нравится/то, на что деньги есть.