How can you use Liquibase with an Azure SQL database and Azure Active Directory Authentication? Specifically, I want to connect using ActiveDirectoryPassword authentication mode as documented here:
https://learn.microsoft.com/en-us/sql/connect/jdbc/connecting-using-azure-active-directory-authentication?view=sql-server-ver15#connecting-using-activedirectorypassword-authentication-mode
I cannot figure out how to call the Liquibase CLI to make this happen.
Is this possible?
I was able to get this to work. I am not very familiar with Java (we use Liquibase with a C# project), so I think some of the Java pieces tripped me up.
There were a few things I had to do to make this work:
I needed to add some properties to the URL I sent to Liquibase:
--url="jdbc:sqlserver://REDACTED.database.windows.net;databaseName=REDACTED;authentication=ActiveDirectoryPassword;encrypt=true;trustServerCertificate=true"
ActiveDirectoryPassword is what tells the driver to use the authentication mechanism I wanted. I also had to add encrypt=true and trustServerCertificate=true to avoid some SSL errors I was getting (from: https://learn.microsoft.com/en-us/sql/connect/jdbc/connecting-with-ssl-encryption?view=sql-server-ver15).
I needed the MSAL4J (Azure Active Directory) libraries in my classpath. I added them to the liquibase/lib directory so that the default Liquibase launcher scripts would add them for me. I got caught on this, too, because I needed to use Maven which we do not use. After downloading Maven, I used the copy-dependencies plugin to download the dependencies I needed.
mvn dependency:copy-dependencies
Here was the simple pom.xml I used:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1</version>
<dependencies>
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>adal4j</artifactId>
<version>1.6.3</version>
</dependency>
</dependencies>
</project>
I also put these dependencies in the liquibase/lib directory so they were automatically included in the classpath. The instructions from Microsoft were helpful in leading me to the correct places:
https://learn.microsoft.com/en-us/sql/connect/jdbc/connecting-using-azure-active-directory-authentication?view=sql-server-ver15#connecting-using-activedirectorypassword-authentication-mode
Also, not sure it was required to meet my goal, but I upgraded to the latest Liquibase (3.8.7) and latest SQL Server drivers (8.2):
https://learn.microsoft.com/en-us/sql/connect/jdbc/download-microsoft-jdbc-driver-for-sql-server?view=sql-server-ver15
I'm wondering whether anyone had an exprecience in deploying the DocuSign Java Client on WildFly 10?
DocuSign jvaa SDK depends on Jersey 1.19, while the wildfly 10 supports RESTEasy out of the box > is it possible to disable RESTEasy ?
Or will it be safe to use the RESTEasy as an JAX-RS implementation (instead of the Jersey 1.19)?
Thank you.
Will answer by myself: excluding the wildfky subsystem "jax-rs" in jboss-deployment-structure.xml works fine:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclude-subsystems>
<subsystem name="jaxrs" />
</exclude-subsystems>
</deployment>
....
</jboss-deployment-structure>
I'm follow this docs this docs
and add maven depency:
<dependency>
<groupId>org.springframework.integration</groupId>
<artifactId>spring-integration-sftp</artifactId>
<version>5.0.0.M6</version>
</dependency>
<dependency>
<groupId>org.springframework.integration</groupId>
<artifactId>spring-integration-java-dsl</artifactId>
<version>1.2.3.RELEASE</version>
</dependency>
But it cannot resolve these method:
does I miss anything?
Starting with Spring Integration 5.0, whole Java DSL project is merged to the core project. So, you don't need that extra spring-integration-java-dsl dependency anymore. More over it isn't compatible with Spring Integration 5.0.
There is no any more such a handleWithAdapter() since there is no single entry point because all the namespace factories are distributed between appropriate modules.
So, right now you have to do this:
.handle(Sftp.outboundGateway(...))
See Migration Guide for more info.
And also follow back to the past from release blog post.
I need to bundle JSF implementation in my WAR file due to known bug in the original mojarra implementation.
I am not allowed to replace the JSF implementation in the modules, so i am using the useBundledJsf property.
Running Payara Version: Payara Server 4.1.1.164 #badassfish (build 28)
This versions should support useBundledJsf properly.
I have added this to my glassfish-web.xml:
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
and added the javax.faces dependecy to my pom:
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.2.13</version>
</dependency>
I am getting the following error and all injections are failing.
SEVERE: JSF1051: Service entry 'org.glassfish.faces.integration.GlassFishInjectionProvider' does not extend DiscoverableInjectionProvider. Entry will be ignored.
I have tried to add the weld-integration.jar to my project but it still produces the JSF1051 error following by:
Unable to create a new instance of 'org.jboss.weld.jsf.ConversationAwareViewHandler'
The dependency for the weld-integration i have used:
<dependency>
<groupId>org.glassfish.main.web</groupId>
<artifactId>weld-integration</artifactId>
<version>4.1.2</version>
<exclusions>
<exclusion>
<artifactId>*</artifactId>
<groupId>*</groupId>
</exclusion>
</exclusions>
There is an extra feature to make this easier in Payara Server 171 which was added specifically to make these scenarios work properly.
From the documentation:
It’s possible to configure an extreme isolation level on the class loading delegation for deployed applications. With this extreme isolation behavior, a deployed application can force the server to load only classes from libraries included on Payara Server that belong to whitelisted packages defined on its deployment descriptors.
To configure whitelist packaging you can use the <whitelist-package> element on the glassfish-web.xml (WAR artifacts) or the glassfish-application.xml (EAR artifacts). This element can be included multiple times to whitelist multiple packages. Here is an example of whitelisting both the Google Guava and Jackson packages for a WAR application:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app error-url="">
...
<whitelist-package>com.google.guava</whitelist-package>
<whitelist-package>com.fasterxml.jackson</whitelist-package>
</glassfish-web-app>
The whitelist syntax is simple: Define the name of the package which contains the classes in question. For example writing com.google would whitelist all Google libraries included on the server, while writing com.google.guava would only whitelist the Google Guava library instead.
Extreme Classloading Isolation
I am searching the web for information regarding the usage of Oracle ADF as a component suite (and not as a development framework), alongside vanilla JSF (2.0).
I am working with a client that insists the solution uses the Oracle ADF UI components. The rest of the Fusion Middleware, however, can be completely skipped for all he cares. Therefore, I'd like to stay as close to the Java EE-JSF2 blueprints as possible, and only resort to ADF as a UI component library, as one would with PrimeFaces, for example.
So, the question - is it possible? Does ADF imposes limitations/dependencies that would prevent this scenario? Can we use it solely as a component library, or must we depend on its heavyweight framework to make them work?
It does not work; at least, not as one would expect. In short: ADF does indeed support JSF2 and Facelets, and they coexist nicely in a single application. As long as you don't mix them together.
I intended to use ADF as a component library, in a way similar to how one uses PrimeFaces or RichFaces: you add the correct dependencies, config what needs to be configured, and you're good to go. When Oracle says that ADF supports JSF2 and Facelets, this is the scenario that one would assume.
To start, you cannot use ADF components outside of a <af:document /> tag (or trinidad's counterpart); which means that content outside this tag is ignored, reducing the ability to use Facelets to a minimum. So, you'll hardly have any Facelets code on the same page where ADF components reside.
JSF + CDI integration is only available through the Mojarra implementation. Using MyFaces (the base for the current ADF version), one might make it work through updating the MyFaces jars and adding CODI, but it does not work out-of-the-box and I did not take the time to investigate it further.
To add to that, for layout management, you're stuck with the ADF way (through pageTemplateDef and pageTemplate tags), since mixing in Facelets is difficult due to the dependency on the document tag. So you see, Facelets support is there, "standard" JSF2 pages can exist in a ADF application - but to use ADF's components, you need to be in an ADF page.
To anyone that might be interested, once you populate your local maven repository using JDeveloper (as per the techniques suggested on the comments in the original question), the minimal dependencies to have ADF UI components in a web application (war) that can be run on WebLogic 12c or Glassfish with ADF essentials, are the following:
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.oracle.adf</groupId>
<artifactId>trinidad-api</artifactId>
<version>12.1.2-0-0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.oracle.adf</groupId>
<artifactId>trinidad-impl</artifactId>
<version>12.1.2-0-0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.oracle.adf</groupId>
<artifactId>adf-richclient-api-11</artifactId>
<version>12.1.2.0.40.66.34</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.oracle.adf</groupId>
<artifactId>adf-richclient-impl-11</artifactId>
<version>12.1.2.0.40.66.34</version>
<scope>provided</scope>
</dependency>
You'll also need to add several other configuration files:
WEB-INF/adfc-config.xml
META-INF/adf-config.xml
META-INF/connections.xml
META-INF/wsm-assembly.xml
Along with further ADF boilerplate configuration on faces-config.xml and web.xml files.
So, the answer so far is:
Is it possible (to use ADF as a component library)? Yes.
Are there any limitations? There's no CDI (out of the box), and limited Facelets support. JSF2 ajax capabilities cannot be used within a ADF document - you must resort to the ADF partial page rendering, but JSF2 custom components and any ClientBehavior you may code work fine.
Is it worth the hassle? No.
Couple of months ago, Oracle ADF was supporting only JSF 1.2.
But with the release of JDeveloper 12c there are lots of new features and improvements over the IDE and over the Oracle ADF, for which there is JSF 2.0 Support now.
So, to answer your question - yes, you can use Oracle ADF with JSF2/Facelets.
If you just want a WAR through Maven do this (In JDeveloper 12c):
New Application -> Custom Application
Add the ADF Faces technology (shuttle to the right).
In the last step of the wizard choose "Use Maven".