There are couple of datasource configuration files for XA and NON-XA datasource in JBOSS v4.2.3 for the various need of the deployed applications in the jboss environment. Also the DB passwords are encrypted using the JBOSS provided techniques (some datasources are created using JaasSecurityDomain and some use SecureIdentityLoginModule) .
How these datasource configurations and these encryption methodologies are going to behave in jboss v5 and jbossv7 ?
Is there any JBOSS tool/utility to convert the datasource to the corresponding new JBOSS version and also take care of the encryption password part ?
What is the best way to migrate these datasources created with the password encrypted.
Any help in this topic is highly appreciated .
Regards,
Jiten
Take a look at Windup project http://windup.jboss.org/
that is aiming to provide as automated upgrade as possible.
Related
Can some one help in providing steps for creating a datasource for mongodb in websphere
A recommended approach for using the MongoDB java driver in WebSphere Application Server Liberty is documented here:
https://openliberty.io/blog/2019/02/19/mongodb-with-open-liberty.html
If you are using traditional WebSphere Application Server rather than Liberty, the CDI aspect of the approach is all standard and will work there as well, however, the MicroProfile Config part would not be available.
I'm looking to configure some settings present in the version of Infinispan shipped with Keycloak's Wildfly from the following Infinispan provided xsd:
infinispan-config-8.2.xsd
The settings I'm looking for ('global-state' element) aren't present in the jboss-as-infinispan_4_0.xsd schema, though.
How do I leverage configuration features the version shipped with Wildfly supports?
I apologize if this is obvious (I'm new to Wildfly). I've spent a fair amount of time researching and am starting to think it cannot be done without write a custom submodule. Any pointers would be appreciated.
I want to create a Spring Boot REST Web Service and deploy and publish it in Traditional Websphere 9 Application Server. Is it possible ?
What all challenges I might encounter? Can someone please provide me few pointers for reference?
Yes this can be done. It is not a good design, but yes it can be done. Back in the day when I was working for a big bank, they deployed java spring-boot microservices in IBM websphere(Not liberty).
How to do it?
1) Package your deployable as war. You can do this by editing your pom to package as WAR.
2) You can either add connection string config in your springboot starter class or get a JNDI created in the websphere instance. We observed that performance of the API's improved when the app used websphere JNDI as opposed to app created connection bean.
3) If you use IBM MQ, the best course of action is get a non-ssl and ssl based channel created at MQ and a JNDI for the MQ connection as well.
4) If you plan to create MQ connection beans within the app, like we did, ensure the JKS file has all the valid set of signers of your org.
Problems we faced
1) Our app used a lot of third party rule engine like drools, so ensure the websphere server.xml is configured to servlet version 3.1 or higher
2) Webshpere admin console is helpful, but don't just blindly believe if it says green to your container, always check your app logs for errors.
3) Common pain points are establishing a successful connection with IBM MQ host. Get a MQ server admin to troubleshoot all MQRC errors.
4) If you plan to use Oracle as backend, ensure the DBA has created a wallet for you to enable both SSL and Non SSL connections. Some organisations are picky with non-sssl db connections. It is easier to handle all this if you leverage webspehere JNDI for DB connections.
Let me know if this helped.
Both WebSphere Traditional and WebSphere Liberty support Spring boot.
Are you looking for something like this?
http://www.adeveloperdiary.com/java/spring-boot/deploy-spring-boot-application-ibm-liberty-8-5/
I am having a project where we want to migrate from WebLogic Server to JBoss.
The project is WebPortal Build using Beehive and NetUI, NetUIX xml portal/portlets.
Is it possible to migrate those directly to Jboss with very limited changes to view like the entire structure can be reused in view which is defined in .portal files.
I also doubt that we can use tiles instead of using portals in JBoss, as Tiles when getting loaded in browser are not going to call to individual controller's begin methods and load default content from there.
I request you to please help me find solution for this migration problem.
Thanks,
Amit
From my experience, the migration from weblogic portal to jboss required a rewrite of the entire application.
If you are using weblogic portal (perhaps a 9.x version since you mentioned netui), i.e. the portal framework on top of weblogic server, there are far too many libraries specific to the portal framework p13n and netui alike that requires migration with no guarantee that these will be supported in Jboss.
Likely to face trouble retrieving entitlements from the p13n jars for users.
Regarding netui beehive, I think that is retired now (not sure), but I didn't got much support for it besides there are more lightweight frameworks out there that can help.
As mentioned in the article https://community.jboss.org/wiki/DataSourceConfigurationInAS7 JBoss 7 provides 2 main ways to configure a data source.
What is the BEST practice of configuring a data source in JBoss 7 AS ? Is it
As a module?
As a deployment?
(The same question has been asked in the thread https://community.jboss.org/thread/198023, but no one has provided an acceptable answer yet.)
The guide JBoss AS7 DS configuration says the recommended way is to configure the datasource by deployment
But according to discussion on the link Jboss 7 DS configuration JBoss Community Discussion on page 54 of the guide it mentions that the recommended way to deploy JDBC driver is to use modular approach
But I personally say that the better(not the best) approach to configure JDBC driver would be to use modules because of 3 reasons
JDBC driver will generally not change.
Re-usability : You can use the same module across various applications and not deploy the jar along with each application, this prevents duplicacy
Space Effective : Using the module approach lets you reduce the size of your EAR/WAR as you do not need to supply the jar with the package
Hence I would argue that the better of the two approaches is via modules
#Mukul Goel
It's not necessary to include it the EAR of your application it's sufficient to put the .jar inside the deployments folder so:
no need to embed in ear
no need to create a module
Jist deploy in deployments folder or via admin console