Consultem também a FAQ de Sistemas Distribuídos.
wscompile -version e wsdeploy -version. Que pode estar mal?wscompile -version e wsdeploy -version. Que pode estar mal?Os scripts de execução do wscompile e wsdeploy dão-se muito mal com espaços. Verifique se a sua variável de ambiente PATH refere algum directório (mesmo de outros programas) com espaços. Se sim, remova ou substitua esses nomes com espaço pelos nomes curtos. Nesta notação, tipicamente Programas (ou Program Files) é abreviado para progra~1.
Adicionalmente, se mesmo assim não se resolver o problema, podem editar-se os
scripts directamente (estão localizados em %JWSDP_HOME%/jaxrpc/bin) e
eliminar as aspas à volta de %PATH%.
Na página de Downloads do MySQL, navega até Archives, selecciona
MySQL Database Server 5.0 e escolhe a versão 5.0.45 1.
1 um link directo, à altura de publicação desta resposta, é este.
Por norma desaconselhamos outras versões, pois pretendemos garantir que no final o vosso software vai correr sem problemas. Se usarem outras versões fazem-no por vossa conta.
As máquinas dos laboratórios são as máquinas de referência para avaliação, tendo sido configuradas de acordo com o guia de instalação de software. Na eventualidade de terem outra de versão do MySQL instalada nos vossos PCs podem sempre ir confirmando que o vosso trabalho funciona nos PCs dos laboratórios.
Para instalar o MySQL no Vista recomenda-se a leitura deste documento: http://port25.technet.com/videos/research/MySQL_Windows.pdf
A máquina virtual Java disponibilizada pela Apple não segue exactamente a
mesma estrutura de directórios que as versões fornecidas pela Sun. Em
particular, omite o directório %JAVA_HOME%/jre, colocando o seu conteúdo
directamente em %JAVA_HOME%. Por este motivo o Tomcat não está a
encontrar o provider de segurança da máquina virtual Java.
Para resolver este problema basta copiar o ficheiro
%JAVA_HOME%/lib/ext/sunjce_provider.jar para
%JWSDP_HOME%/jwsdp_shared/, garantindo assim que qualquer aplicação web
lançada no Tomcat terá acesso ao provider.
Não. Infelizmente o Tomcat esgotou a memória. A solução rápida é desligar e ligar novamente o servidor (catalina stop / catalina start).
A framework Stripes usada na aplicação web exemplo está a usar bibliotecas de cifra no processamento de campos escondidos. Ver entrada Utilizo MacOS X e....
Sim. No entanto, não devem colocar no CVS os ficheiros que forem gerados
automaticamente (nada dentro dos directórios dist e build).
Embora os domínios sejam independentes, na primeira entrega do projecto eles executam-se na mesma máquina virtual Java. Isto implica que só existe uma instância do hibernate, pelo que só é possível aceder a uma base de dados. Assim sendo, todas as tabelas têm de ser criadas na mesma BD. Vejam o ficheiro build.xml do componente mediator/web da aplicação exemplo trip-planner.
Têm 10 bases de dados, porque nas próximas entregas vão executar os vários domínios de forma distribuída. Nessa altura, vão precisar de separar as coisas. Na primeira entrega, só necessitam de uma BD.
ant dbunit-export-data para produzir o ficheiro xml de input para os testes. Todas as classes da herança estão mapeadas na mesma tabela. No entanto ao correr os testes noto que algumas colunas de algumas sub-classes ficam sempre a NULL na BD. Qual o problema?O DBUnit ao ler o ficheiro de xml para popular a BD em cada teste, apenas
considera as colunas que aparecem na primeira referência a uma dada tabela
ignorando as restantes. Por isso, é necessário garantir que todas as
colunas (mesmo que sejam irrelevantes para o objecto em causa) sejam
referidas na primeira linha de cada referência a uma tabela. Por exemplo:
considere-se as classes ClasseA, ClasseB e ClasseC. ClasseB e ClasseC
herdam de ClasseA. Cada uma das ClasseX tem um atributoX.
O ficheiro de xml pode ter o seguinte aspecto:
<ClasseA DTYPE="ClasseB" id="1" objVersion="0" atributoA="valor1" atributoB="valor2" atributoC="NULL"/> <ClasseA DTYPE="ClasseC" id="2" objVersion="0" atributoA="valor3" atributoC="valor4"/>
Ou seja, mesmo que o atributoC não seja relevante na primeira linha para
a instância de C, ele deve estar na primeira linha que diz respeito à
tabela para que seja considerado.
No editor da tarefa é necessário escolher o separador Planning (os separadores aparecem junto à base da janela do editor). Nesse separador é possível alterar a estimativa. Depois é necessário gravar e submeter as alterações. Atenção que gravar apenas grava localmente no workspace do eclipse; só o submit envia para a base de dados do projecto.
Depende o que querem dizer por "identificar". Não devem utilizar conceitos do modelo de domínio para representar identificadores do hibernate; estes são "internos". No entanto, o email pode ser o identificador do cliente que permite à loja referi-lo no sistema de autenticação.
O email não faz parte do perfil de cliente.
Os únicos serviços que podem fazer invocações a outros serviços são os serviços de workflow, ou seja, não podem ter um serviço que esteja no 'core' de um projecto a fazer invocações a outro serviço do 'core' de outro projecto. Nesses casos, o que devem é ter um serviço de workflow como o BookFlightService do trip-planner. São esses serviços que fazem a ligação entre domínios.
O Sistema de Autenticação não sabe o que são clientes nem administradores. O Sistema de Autenticação apenas tem utilizadores sem distinção entre si.
Não! Isso quebraria a independência dos domínios e impediria que mais tarde separassem o código em múltiplas aplicações cada uma a correr na sua máquina virtual.
A password não faz parte do perfil de cliente.
Quando uma classe de um componente depende de classes de outro componente,
além de fazer o import da classe que se pretende utilizar é necessário
garantir que durante o processo de construção da aplicação vão ser
encontradas as classes do outro componente.
Por exemplo, num sub-projecto, o componente 'core' depende do componente 'view' porque (a) as classes de domínio lançam excepções (b) os serviços retornam vistas e não tratam as excepções de domínio.
No exemplo Trip Planner, para que cada sub-projecto compile correctamente, foram tidos alguns cuidados no processo de construção da aplicação. Por exemplo:
build.xml constroi primeiro o componente
'view' e só depois o componente 'core' (alvo build);
build.xml cria o ficheiro flight-view.jar 1 no directório dist do
componente (por dependência do alvo build-library);
jar.external.path de forma a conter os arquivos JAR
que encontrar no directório dist do componente 'view' do componente
flight;
compile.classpath para incluir o jar.external.path
definido anteriormente. Este classpath é utilizado pelo ImportAnt
sempre que se invoca o alvo compile (do qual o alvo build
tipicamente depende).
Esta filosofia é seguida no resto da aplicação exemplo para gerir as dependências entre componentes e sub-projectos (o componente 'web' do sub-projecto mediator depende dos componentes 'core' e 'view' dos sub-projectos flight e mediator).
1 flight-view é o nome do componente, tal como definido na etiqueta
<project> do build.xml.
Podem chamar directamente o serviço do core, quando esse core pertence à mesma aplicação (neste caso a Loja). Os serviços de Workflow no componente web só necessitam de ser escritos quando se pretende compôr mais que um serviço e/ou aceder a outros cores.
Data: 2008/04/17 16:50:30