I am trying to deploy my application (packed in .war file) that work properly on JBoss 4.2.3 to JBoss 5.1 (using java 5).
Currently during deployment time I see in the server.log the error:
... Caused by:
org.jboss.xb.binding.JBossXBRuntimeException:
Failed to create a new SAX parser
...
Caused by:
java.lang.ClassCastException:
org.apache.xerces.parsers.XML11Configuration
According to this thread in JBoss forums, I need to isolate my application.
My questions:
according to JBoss 5.1 Release Notes - The major differences with the existing configurations is that call-by-value and deployment isolation are enabled by default. Therefore do I really need implicitly set my application isolated?
I thought that isolation is mainly needed when the same application server runs several applications that collides with each other. In my case I am trying to run only one application. So again is the isolation required?
If the answer is positive to the above question and I need to enforce isolation - how can I configure it? suppose my war file is called 'foo'. do I have to insert to the jboss-web.xml the section:
<jboss-web>
<loader-repository>
tld.mydomain:loader=foo.war
</loader-repository>
</jboss-web>
OK Apperently the solution is to remove xerces.jar from my web-inf/lib
Isolation won't work due to some bug. See here
Failed to create a new sax parser error is due to the availability of unwanted JAR files in WAR and EAR if there. So by deleting those unwanted JARS this error is been cleared.
Related
we've an application, running in JBOSS EAP 6.4, generating a lot of logs. So we decided to give the application its own log, rotating each hour.
The application uses SFL4J, which is compatible with JBOSS Logging.
As we can't change parameters on JBOSS config we decided to use the logging per deployment feature and added, following the developers manual, a file logging.properties in the classpath, with the File Handler set up as below
handler.FILE=org.jboss.logmanager.handlers.PeriodicRotatingFileHandler
handler.FILE.level=ALL
handler.FILE.formatter=PATTERN
handler.FILE.properties=append,autoFlush,enabled,suffix,fileName
handler.FILE.constructorProperties=fileName,append
handler.FILE.append=true
handler.FILE.autoFlush=true
handler.FILE.enabled=true
handler.FILE.suffix=.yyyy-MM-dd-HH
handler.FILE.fileName=${jboss.server.log.dir}\\pfl.log
While in DEV station everything works as expected (JBOSS Developer Studio 7.1.1 with JBOSS EAP 6.1), in production and test JBOSS generates correctly the pfl.log file and the hourly backups, BUT the pfl.log is never made empty. So it's growing indefinitely (and so the hourly files). Also we noted that the same behavior happens using dayly rotating logs
handler.FILE.suffix=.yyyy-MM-dd
This is getting us crazy.. How can we solve this ? Where can be the problem ? Did we make any config mistakes ?
Environment
JDK 1.8
Tomcat 7.0.55
A spring web app
Chef scripts for deploying
What's the issue
The application is deployed via chef and most of the times everything is fine. Except for 1 in 10 times or so the web.xml (under appbase webapps/myapp/WEB-INF/web.xml) goes missing during redeployment which causes the application not to start up.
This symptom disappears in eventual chef-runs adding to the peculiarity of the issue.
My investigation till now
Ruled out any chef aspects from the problem . Was able to confirm that the scripts are doing what they are suppose to do - delete old war DIR -> unzip new war DIR in place(we use exploded war's) there by causing un-deploy of old and deployment of new.
Next point of investigation was to see if the tomcat is deploying the new web app even before its completely unzipped or extracted - this was not the case as confirmed by time lines on the logs.
We do not have jar's getting locked - so ruled out any issues caused by such scenarios.
All of the symptoms I see now points towards tomcats auto deployment policies - but was not able to see anything here which would cause such kind of inconsistency - Have gone through tomcat bug list sniffing for any compatibility issues but was not able to find any.
Am putting it out there to see if any one else is facing similar issues - any thoughts are welcome. Let me know if you need any more information
there I'm getting this during Spring Boot deployment to GF3,4
although it is know problem see
spring boot problem
another
there is nowhere solution to be found, except for the hack with try/catch in GF sources.
The whole problem is about #Conditional... Spring-Boot annotations, which holds classes references that are not on CP and this GF check disables the usage of Spring-Boot.
I don't want to abandon Spring-Boot, but switching off #EnableAutoconfiguration is not working, exclude auto-config classes in the annotation does not work either. Is there a way around(throw away all auto-configs) or I am doomed and need to fall back to vanilla Spring?????
Everybody is giving hands away as it seems to be GF problem. Any hack advice appreciated.
WARNING|glassfish3.1.2|global|_ThreadID=86;_ThreadName=Thread-2;|Error in annotation processing: java.lang.NoClassDefFoundError: org/springframework/batch/core/configuration/annotation/BatchConfigurer|#]
WARNING|glassfish3.1.2|global|_ThreadID=86;_ThreadName=Thread-2;|Error in annotation processing: java.lang.NoClassDefFoundError: org/springframework/batch/core/configuration/annotation/BatchConfigurer|#]
SEVERE|glassfish3.1.2|global|_ThreadID=86;_ThreadName=Thread-2;|Class [ org/apache/solr/client/solrj/SolrServer ] not found. Error while loading [ class org.springframework.boot.autoconfigure.solr.SolrAutoConfiguration ]|#]
SEVERE|glassfish3.1.2|global|_ThreadID=86;_ThreadName=Thread-2;|Class [ liquibase/integration/spring/SpringLiquibase ] not found. Error while loading [ class org.springframework.boot.autoconfigure.liquibase.LiquibaseAutoConfiguration$LiquibaseConfiguration ]|#]
SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=86;_ThreadName=Thread-2;|Exception while deploying the app [PaySafeCardConnector-1.0-SNAPSHOT]|#]
SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=86;_ThreadName=Thread-2;|sun.reflect.annotation.TypeNotPresentExceptionProxy
java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy
at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:715)
at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:522)
at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:348)
You can get around this by putting metadata-complete="true" in your web.xml, which tells glassfish to not process the annotations, as the app has already done so.
This fixes the java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy and will, for example, allow the example Spring Boot war application that Spring provide to deploy and run successfully.
The problem's due to a bug in GlassFish. The addition of the try-catch in GlassFish isn't a hack, in my opinion. It's making GlassFish's annotation handling more robust and bringing it into line with other Java EE servers such as WildFly and TomEE.
If you're happy to get your hands dirty you could try applying the patch in that issue or using the Payara download that's linked to in the issue. Failing that, to continue using Spring Boot you'll have to move away from GlassFish, either to another Java EE server or to an embedded container (Spring Boot supports Tomcat, Jetty, and Undertow).
I was using Jboss 6 . I am wondering to see jboss 7 which does not have many folders that jboss 6 had. It will be helpful if someone explains the difference between the jboss 7 stand alone server and the previous versions.
AS7 is different in a lot of respects to its predecessors AS6,5. So it wont be possible to list down all the differences here.
to list supported technology related differences, refer to below table.
Some Major Differences: (Thanks for #Jyore for additions)
Modular (on-demand) class-loading
Addition of domain managed nodes (multiple JVM management)
All configuration is done in Standalone.xml for standalone mode and domain.xml for domain mode.
About the new DIRECTORY Structure
configuration : Configuration files for the standalone server that runs off of this installation. All configuration information for the running server is located here and is the single place for configuration modifications for the standalone server.
data :Persistent information written by the server to survive a restart of the server
deployments: End user deployment content can be placed in this directory for automatic detection and deployment of that content into the server's runtime.
NOTE: The server's management API is recommended for installing deployment content. File system based deployment scanning capabilities remain for developer convenience.
lib/ext : Location for installed library jars referenced by applications using the Extension-List mechanism
log : standalone server log files
tmp : location for temporary files written by the server
Apart from that I really dont want to duplicate information on web
There is a migration guide from AS5,AS6 to AS7. This can help you understand what are the config changes that are generally required to switch to AS7. it also points out what has significantly changed, highly recommend going through it.
Also You can read Getting Started with AS7, to know AS7 better
I'm trying to combine Eclipse RCP with RMI. For that purpose I created six bundles:
(In parenthesis are dependencies)
Core: Interfaces for client and server
Server(Core): Server implementation and Registry start class
ServerApp(Server): GUI client which basically just instantiates the registry starter (and starts it on Activation)
Client(Core): Client implementation
ClientApp(Client): GUI client
Now I started the serverapp, but I got a
Caused by: java.lang.ClassNotFoundException: core.rmi.CallbackServerInterface (no security manager: RMI class loader disabled)
Now I started the server with
-consoleLog -Djava.security.policy=java.policy -Djava.rmi.server.codebase=file:${workspace_loc}/core/
(My java.policy file is in the core plugin).
I thought the problem was the classpath. So I made core and server buddies:
Eclipse-BuddyPolicy: registered
in the core bundle manifest file and
Eclipse-RegisterBuddy: core
In the server bundle manifest file.
Which didn't help, since I got the exact same error.
Does anyone know where I could have gone wrong on this one?
So apparently the problem was, that OSGI uses its own Classloader. So before we do the Naming bind we need:
Thread.currentThread().setContextClassLoader(
this.getClass().getClassLoader());
After this, the server works like a charm, and the client can connect.