Походы определенно будут. Без них уже трудно представить себе лето. А для желающих поучаствовать остаются в силе все те же предложения (нереализованные в прошлом проекты): http://trip.altailand.ru/Index.jsp?id=30 Сроки по согласованию с участниками (если таковые будут). Также можно предлагать здесь что-то свое.

Хотелось бы иметь адрес не вида ip_servera:8080/application_name/faces/index.xhtml , а такой:ip_servera/index.xhtml
Подскажите пожалуйста,как можно это реализовать?

1. Порт (8080) настраивается у сервера tomcat 7 (файл conf/server.xml, Connector port="8080" protocol="HTTP/1.1" ...). Если поставить 80 то порт в url не обязателен.
2. application_name можно убрать в контексте приложения (файл META-INF/context.xml, Context antiJARLocking="true" path="" ). path="" - значит приложение будет у сервера в корне: "/".
3. faces выводится потому, что шаблон faces/* установлен в web.xml. Поставьте там, например, *.jsf и к странице index.xhtml нужно будет обращаться как к index.jsf, но faces при этом из url исчезнет.

Надеюсь вы сможете исправить данную ошибку в скором времени

Спасибо за замечание. Ошибка исправлена.

Версия 2.00 проекта aomai опубликована: http://soft.altailand.ru/Index.jsp?id=11 Исходный код доступен для скачивания: http://soft.altailand.ru/download/aomai_200.zip В результате значительной переработки кода удалось полностью избавиться от ограничивающих свободу Java веб-фреймворков. В последней версии используются только классические Java веб-технологии: JSP, Servlet 3.0, а также JavaScript (JQuery) на клиенте.

В стандарте протокола HTTP при ответе (response) на запрос (request) предусмотрена заголовочная часть header и в ней может быть поле location, отвечающее за переадресацию. Обновить страницу можно заполнив это поле ее адресом в response. Например, можно сделать это уже на клиенте в JavaScript:

 window.location = '/homepage.html'; 

Веб-приложение на java обычно является сервлетом (wicket не исключение). В методы doGet и doPost класса сервлета (HttpServlet) передаются объекты HttpServletRequest request и HttpServletResponse response. У response можно переписать поле location:

response.setHeader("Location", "homepage.html");

У response также есть метод sendRedirect:

response.sendRedirect("homepage.html");

Вероятно, в нем просто вызовется setHeader("Location", "homepage.html") как и в сервлете wicket, когда Вы пишете setResponsePage(HomePage.class ...). Изнутри wicket Вы можете, конечно, попробовать добраться до response и вызвать один из этих методов, но это имеет смысл делать только для методов, к которым wicket не дает прямого доступа.

Ну если нужно именно полностью всю страницу перегружать в запросе, то как-бы неважно каким способом Вы это сделаете - все будет пересоздаваться вновь. Можно какие-то объекты сохранять в сессии (например, значение индекса или даже весь комбобокс ), тогда при перезагрузке страницы можно восстанавливать сохраненные данные из сессии. То есть, из того что Вы написали не видно проблемы, поскольку неясно, что Вы собираетесь далее с этим делать.

Serj wrote:
Как лучше реализовать синхронизацию локальной БД (SQLite) с базой в интернете?

Вопрос может иметь несколько смыслов, не совсем понятно, что именно Вас интересует. Например:

1. Алгоритм синхронизации. Обычно работает принцип "Главный" - "Подчиненный", то есть вторая структура приводится в соответствии с первой. При этом может применяться полная синхронизация либо только добавление отсутствующего (пример - утилита rsync). Более сложные алгоритмы возможны, но это зависит уже от смысла и логики самого приложения.

2. Организация синхронизации (когда вызывать метод синхронизации). По таймеру внутри программы, по таймеру вне программы (например, cron), в момент соединения с интернет, по указанию пользователя, и так далее.

3. Техническая реализация. Добавляем в подчиненную БД все отсутствующие в ней записи, имеющиеся в главной. Если нужно удаляем из подчиненной БД все записи отсутствующие в главной. Средство - SQL запрос. Механизм идентификации записей - хэш всех или некоторых наиболее важных полей.

Попробуйте аннотацию @ViewScoped вместо @RequestScoped. RequestScoped это, видимо, чистый stateless, то есть запрос-ответ и вообще не используется состояние, а у Вас IndexBean сериализуемый, то есть его состояние сохраняется.

Дневник похода 2010 года по плато Укок, хребту Сайлюгем и Кара-Алахе опубликован полностью:

http://trip.altailand.ru/Index.jsp?id=29

В качестве иллюстраций выложено много новых фотографий.

Начал выкладывать дневник похода на Укок: http://trip.altailand.ru/Index.jsp?id=29
Страницы добавляются по мере их готовности.

Ну если уж использовать PrimeFaces, то, видимо, и ajax лучше тоже его (по умолчанию у commandButton ajax включен):

<p:commandButton action="#{indexBean.btAction}" value="p_ajax" update="table1" />

Но просто так это работать не станет, если остальное оставить все как есть:

<p:dataTable id="table1" rendered="#{indexBean.isTableVisible}">  
    <p:column headerText="Колонка1"/>  
    <p:column headerText="Колонка2"/>  
</p:dataTable>  

При использовании компонентов JSF2 часто приходится угадывать в какие контейнеры и как их поместить, чтобы они правильно работали.
Например, при помещении таблицы в контейнеры как это приведено ниже, все заработает:

<h:panelGrid id="table1">
    <h:panelGrid rendered="#{indexBean.isTableVisible}" >
        <p:dataTable>
            <p:column headerText="Колонка1"/>
            <p:column headerText="Колонка2"/>
        </p:dataTable>
    </h:panelGrid>
</h:panelGrid>

В прилагаемом файле - проект, в котором показана работа с управлением показа таблицы как при помощи <f:ajax...>, так и при помощи PrimeFaces commandButton.
При этом, при <f:ajax..>. странным образом один из текстов отображается с точностью до наоборот.

Может быть нужно <p:dataTable /> поместить в контейнер

<h:panelGroup>
     <p:dataTable ...>
          ...
     </p:dataTable>
</h:panelGroup>

Чтобы помочь с решением этой проблемы желательно бы иметь весь тестовый проект, где она присутствует.

На самом деле, судя по документации, http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html
драйвер можно зарегистрировать в самом томкате и обращаться к нему по JNDI - имени. Тогда в проект не нужно было бы добавлять этот драйвер.

Отличие томката от glassfish в другом: tomcat - простой контейнер сервлетов, а glassfish - это сервер приложений, содержащий tomcat внутри себя. Он дополнительно является

контейнером для бизнес компонентов - EJB контейнером

контейнером для адаптеров ресурсов - JCA контейнером

ну и еще содержит набор стандартных служб: JNDI, JTS, JACC, JMS, mail...
Если не нужны функции сервера приложений, то tomcat быстрее, проще и удобнее в использовании.

Для томката нужно регистрировать драйвер.

DriverManager.registerDriver(new com.mysql.jdbc.Driver());

Вот как выглядит у меня теперь конструктор обновленного класса SqlAction.

public SqlAction(){
    connInfo = new Properties();
    connInfo.put("user",user);
    connInfo.put("password",password);
    setError("");
    try{
        DriverManager.registerDriver(new com.mysql.jdbc.Driver());
    } catch(SQLException ex) {setError("Ошибка регистрации драйвера: "+ex.getMessage());}
}

Можно добавить этот jar (драйвер) к проекту в NetBeans (свойства проекта). Затем проверить появляется ли он в build/web/WEB-INF/lib после компиляции (build).