sob as rotinas de tratamento instaladas pela JVM. Mais tarde, quando qualquer um desses sinais surgir e for verificado que eles nao se destinam a JVM, as rotinas de tratamento pre-instaladas serao chamadas. Para utilizar libjsig.so: Efetue o link com o aplicativo que cria ou incorpora uma JVM: gcc -L$JAVA_HOME/bin -ljsig -L$JAVA_HOME/bin/j9vm -ljvm java_application.couUtilize a variavel de ambiente LD_PRELOAD: export LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (bash and ksh)setenv LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (csh)(Assumindo que JAVA_HOME esteja configurado; caso contrario, utilize /opt/ibm/java2-i386-50/jre.) Se voce instalar rotinas de tratamento de sinais que utilizam sigaction(), alguns sa_flags nao serao observados quando a JVM utilizar o sinal. Sao elas: SA_NOCLDSTOP - Isso nunca e definido. SA_NOCLDWAIT - Isso nunca e definido. SA_RESTART - Isso sempre e definido.A biblioteca libjsig.so tambem oculta do aplicativo rotinas de tratamento de sinais da JVM. Por essa razao, chamadas como signal(), sigset() e sigaction() que sao feitas apos o inicio da JVM nao retornam mais uma referencia a rotina de tratamento de sinais da JVM; em vez disso, retornam qualquer rotina de tratamento que foi instalada antes da inicializacao da JVM. Trabalhando com Pilhas Flutuantes Distribuicoes especificas do Linux - Red Hat, por exemplo - possuem um recurso GLIBC ativado chamado 'pilhas flutuantes'. Por causa das limitacoes do kernel Linux, a JVM nao sera executada em hardware SMP com pilhas flutuantes ativadas caso o nivel do kernel seja inferior a 2.4.10. Nesse ambiente, pilhas flutuantes devem ser desativadas antes que a JVM ou qualquer aplicativo que inicie a JVM seja iniciado. No Red Hat, utilize este comando para desativar pilhas flutuantes, exportando uma variavel de ambiente: export LD_ASSUME_KERNEL=2.2.5 Em um sistema Linux de pilha nao-flutuante, independentemente do valor que for definido para -Xss, sera fornecido um tamanho minimo de pilha nativa de 256 KB para cada encadeamento. Em um sistema Linux de pilha flutuante, os valores -Xss sao aceitos. Por isso, se voce estiver migrando de um sistema Linux de pilha nao-flutuante, sera necessario assegurar-se de que todos os valores de -Xss sejam grandes o suficiente e que nao dependam de um minimo de 256 KB. Transformando Documentos XML O IBM SDK contem o processador XSLT4J e o analisador XML4J que estao em conformidade com a especificacao do JAXP 1.3. Essas ferramentas permitem que voce analise e transforme documentos XML, independentemente de qualquer implementacao de processamento XML especifico. Ao utilizar "Factory Finders" para localizar as implementacoes SAXParserFactory, DocumentBuilderFactory e TransformerFactory, seu aplicativo podera alternar entre diferentes implementacoes sem precisar alterar qualquer codigo. |A tecnologia XML incluida com o IBM SDK e semelhante ao |Apache Xerces Java e Apache Xalan Java. Consulte | http://xml.apache.org/xerces2-j/ e |http://xml.apache.org/xalan-j/ para obter |mais informacoes. O processador XSLT4J permite que voce escolha entre o processador Interpretativo XSLT original ou o novo processador de Compilacao XSLT. O processador Interpretativo foi projetado para aprimorar e depurar ambientes. Ele suporta as funcoes de extensao XSLT nao suportadas pelo processador de Compilacao XSLT. O processador de Compilacao XSLT foi projetado para ambientes de tempo de execucao de alto desempenho; ele gera um mecanismo de transformacao ou translet, de uma folha de estilo XSL. Essa abordagem separa