It seems there is a bug of some sort regarding the installation of a the mysql jconnector driver for wildfly domain mode. In wildfly standalone all is fine. Tried it in wildfly 9 as well - same results.
Anyway, managed to get it working, after so much digging around. Hopefully it will save someone's time.
1) Start server in domain mode
2) Download jconnector driver from: https://dev.mysql.com/downloads/connector/j/5.1.html
Use the development release 6.
3) Deploy in wildfly from the web interface:
a) http://localhost:9990 -> Deployments > Content Repository > Add . After that assign and activate
4) Configuration tab -> Profiles -> Full (or other as needed) -> Datasources -> Non-XA -> Add
a) From the list select the MySQL Datasource ... then Next
b) Naming. First field something arbitrary, up to you, second field in format java:/name-up-to-you ... then Next
c) JDBC Driver setup. Using the Specify Driver tab, leave everything as it, except for the first field: "Name*:" which should be the name of the deployed driver. For me, not changing anything this was mysql-connector-java-6.0.6-bin.jar ... then Next (*some notes below)
d) Connection URL*: jdbc:mysql://localhost:3306/my-db or whatever your db is located ... then Next and Finish
The detected driver tab never showed my driver after deployment for some reason. Using standalone, with deployment it was automatically populated.
You could manually include a driver as a module by placing it in the modules/system/... directory and setting it up through the wildfly-home/domain/configuration/domain.xml then in the tag find child element , then the child element , then add yours. But i couldn't make it work this way, so won't go into this.
Has anyone had such experiences?
Related
I have a .NET Core 3.0 app where am trying to connect to a Azure SQL database using EF Core and Active directory integrated authentication.
I have verified that I have access to this database from my machine as I can connect to it just fine using SQL server management studio and 'Azure Active Directory-Integrated' authentication.
However, when I try to read data in my app (using EF Core), I always get a System.Argument exception with the following statement:
Invalid value for key 'authentication'
Exception details point to the Db connection string.
So, here is my connection string from my dev appsettings.json file:
"ConnectionStrings": {
"MCDB": "Server=tcp:dev-media-center-sql.database.windows.net,1433;Initial
Catalog=MediaCenter;Persist Security Info=False;User
ID={my User ID};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Authentication=Active Directory Integrated;" },
I have tried hard coding the connection string directly in my code, thinking that there might be a problem with my JSON but I still get the same exception.
Is "Active Directory Integrated" not a valid value for the 'Authentication' keyword? If not, what is it then? I have already tried "ActiveDirectoryIntegrated" (with no spaces) and /"Active Directory Integrated"/ (escaping double quotes) but to no avail.
Thanks
Fike
Here's what did it for me:
If you're using EF Core with package Microsoft.EntityFrameworkCore.SqlServer...
Then be aware:
The Microsoft.Data.SqlClient package ships more frequently than the EF
Core provider. If you would like to take advantage of new features and
bug fixes, you can add a direct package reference to the latest
version of Microsoft.Data.SqlClient.
source: https://learn.microsoft.com/en-us/ef/core/providers/sql-server/?tabs=dotnet-core-cli
That being said 👆, the fix was EASY. Just add the package to your project 👇
upgraded to latest version of Microsoft.Data.SqlClient and the issue is resolved.
Hope this will help someone
This is essentially the same problem discussed in relation to a newer .NET Core version, which was answered as currently unsupported in that version, however I have added a comment where I note that it now works - see EF Core 3.1 using Authentication=Active Directory Integrated
If your only option for connecting to the Azure SQL Database is through Active Directory authentication, and your ADO.NET SqlConnection object is having problems trying to recognize the "Active Directory Integrated" value as the Authentication, you can still use the "Active Directory Password" value if you know the credentials of the user you're using to try to connect to the database. The connection string will be something like this:
"Server=tcp:yourservername.database.windows.net,1433;Initial Catalog=yourdatabasename;Persist Security Info=False;User ID={your_username};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Authentication="Active Directory Password";"
That worked for me.
You can use "Authentication=Active Directory Managed Identity" and be sure to set the User ID to the Object(principal)ID of the identity.
Example:
Data Source=dev-westeurope-001.database.windows.net;Initial Catalog=dev-westeurope-001;Authentication=Active Directory Managed Identity;User ID=[PrincipalId];TrustServerCertificate=True;
I'm working on a Perl6 project, but having difficulty connecting to MySQL. Even when using the DBIish (or perl6.org tutorial) example code, the connection fails. Any suggestions or advice is appreciated! User credentials have been confirmed accurate too.
I'm running this on Windows 10 with MySQL Server 8.0 and standard Perl6 with Rakudo Star. I have tried modifying the connection string in numerous ways like :$password :password<> :password() etc. but can't get a connection established. Also should note that I have the ODBC, C, C++, and.Net connectors installed.
#!/usr/bin/perl6
use v6.c;
use lib 'lib';
use DBIish;
use Register::User;
# Windows support
%*ENV<DBIISH_MYSQL_LIB> = "C:/Program Files/MySQL/MySQL Server 8.0/liblibmysql.dll"
if $*DISTRO.is-win;
my $dbh = DBIish.connect('mysql', :host<localhost>, :port(3306), :database<dbNameHere>, :user<usernameHere>, :password<pwdIsHere>) or die "couldn't connect to database";
my $sth = $dbh.prepare(q:to/STATEMENT/);
SELECT *
FROM users
STATEMENT
$sth.execute();
my #rows = $sth.allrows();
for #rows { .print }
say #rows.elems;
$sth.finish;
$dbh.dispose;
This should be connecting to the DB. Then the app runs a query, followed by printing out each resulting row. What actually happens is the application hits the 'die' message every time.
This is more of a work around, but being unable to use use a DB is crippling. So even when trying to use the NativeLibs I couldn't get a connection via DBIish. Instead I have opted to using DB::MySQL which is proving to be quite helpful. With a few lines of code this module has your DB needs covered:
use DB::MySQL;
my $mysql = DB::MySQL.new(:database<databaseName>, :user<userName>, :password<passwordHere>);
my #users = $mysql.query('select * from users').arrays;
for #users { say "user #$_[0]: $_[1] $_[2]"; }
#Results would be:
#user #1: FirstName LastName
#user #2: FirstName LastName
#etc...
This will print out a line for each user formatted as shown above. It's not as familiar as DBIish, but this module gets the job done as needed. There's plenty more you can do with it to, so I highly recommend reading the docs.
According to this github DBIish issue 127
The environmental variable DBIISH_MYSQL_LIB was removed. I don't know if anyone brought it back.
However if you add the library's path, and the file is named mysql.dll, it will work. Not a good result for the scientific method.
So more testing is needed - and perhaps
C:\Program Files\MySQL\MySQL Server 8.0\lib>mklink mysql.dll .\libmysql.dll
Oviously you can create your own lib directory and add that to your path and then add this symlink to that directory.
Hope this helps. I've spent hours..
EDIT: Still spending time - accounting later.
Something very transitory is going on. I reset the machine (perhaps always do this from now on), and still got the missing mysql.dll errors. Tried going into the MySQL lib directory to execute raku from there.. worked. changed directories.. didn't work.
Launched administrator cmd - from home directory, tried the raku command. Worked. Ok - not good, but perhaps consistent. Launched non admin cmd, tried it from the MySQL lib directory, worked. And just for giggles, tried it outside of that directory.. worked.
Now I can't get it not to work. Will explore NativeLibs::Searcher as Valle Lukas suggested!
Maybe the example in the dbiish repository is not valid anymore.
The DBIISH_MYSQL_LIB Env seems to be replaced by NativeLibs::Searcher with commit 9bc4191
Looking at NativeLibs::Searcher may help to find the root cause of the problem.
Does anyone know how to enable kerberos with Apache Drill? Is it possible. I can't seem to find any documentation on it, or any questions/answers floating around with the information on it. I am currently running a CDH cluster.
I am getting this error when trying to use HDFS with Drill:
Error: PERMISSION ERROR: SIMPLE authentication is not enabled.Â
Available:[TOKEN, KERBEROS]
HDFS + Kerberos integration isn't currently supported / tested / documented. Vote on this ticket to track when it becomes available:
https://issues.apache.org/jira/browse/DRILL-3584
There isn't any documentation that the Drill team provides about how to enable kerberos and they haven't tested kerberos with Drill. Drill Eng. does believe that it should work.
In order to gain access onto the cluster once Kerberized, you must configure certain files in order to gain access.
Make an HDFS Superuser account as indicated in this Cloudera doc. On the Main Node, run
•sudo kadmin.local
In addition, add an 'hdfs' principal with this command
•addprinc hdfs#LOCALDOMAIN -- Where localdomain is the principal name
In order to enable authentication with Kerberos, we also need to copy the file hadoop-yarn-api.jar into Drill's class path. Example given below
•cp /opt/cloudera/parcels/CDH-5.5.1-1.cdh5.5.1.p0.11/lib/hadoop/client/hadoop-yarn-api.jar ~/apache-drill/jars/
The above step and the three following must be performed on each node of the cluster that an Apache Drill is installed.
Next, Drill's conf/core-site.xml file should be edited to contain the following snippet of xml. You might have to copy this file from /etc/hadoop/conf.cloudera.yarn/core-site.xml, etc or a similar path.
<property>
<name>hadoop.security.authentication</name>
<value>kerberos</value>
</property>
After this step, you will also need to add the following xml snippet below to the drill core-site.xml file. In this instance, hdfs/_HOST#LOCALDOMAIN is my principal property. The property can be found on the hdfs-site.xml file
<property>
<name>dfs.namenode.kerberos.principal</name>
<value>hdfs/_HOST#LOCALDOMAIN</value>
</property>
All that is left to do is create an 'hdfs' Kerberos ticket for the user that we're logged into
•kinit hdfs -- hdfs is the super user
Then start up each of the drillbits
•/opt/apachedrillfolder/bin/Drillbit.sh start
So now, Drill has both the configuration and the authority to use our kerberized HDFS store. Give it a shot by opening up a Drill prompt (drill-conf) and trying a query
In moqui, I am trying to configure to use mysql, commented out derby and uncommented mysql in defaultconf, I copied the connector to framework lib, included the dependency in framework build.gradle, on running load, I get this error - java.lang.reflect.InvocationTargetExceptionjavax.management.InstanceAlreadyExistsException: bitronix.tm:type=JDBC,UniqueName=DEFAULT_transactional_DS,Id=0 -- thanks for any help
Can you post a snippet of code you have modified in MoquiDefaultConf.xml and build.graddle file.
A viable alternative to configure MySQL with Moqui is by doing related setting in configuration files (i.e. MoquiDevConf.xml for development instance, MoquiStagingConf.xml for staging instance and MoquiProductionConf.xml for production instance.). Follow the steps below to configure MySQL with Moqui.
Since, May be you are trying to do some development, you need to make changes in MoquiDevConf.xml file only.
Replace the <entity-facade> code in MoquiDevConf.xml with the following code.
<entity-facade crypt-pass="MoquiDefaultPassword:CHANGEME">
<datasource group-name="transactional" database-conf-name="mysql" schema-name="">
<inline-jdbc jdbc-uri="jdbc:mysql://127.0.0.1:3306/MoquiTransactional?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8"
jdbc-username="MYSQL_USER_NAME" jdbc-password="MYSQL_PASSWORD" pool-minsize="2" pool-maxsize="50"/>
</datasource>
</entity-facade>
In the code above 'MoquiDEFAULT' is the name of database. Replace the MYSQL_USER_NAME and MYSQL_PASSWORD with your MySQL username and password.
Create a database in MySQL (as per the code above, create the database with name MoquiTransactional).
Add the jdbc driver for MySQL in the runtime/lib directory.
In MoquiInit.properties file, set MoquiDevConf.xml file path to "moqui.conf" property i.e. moqui.conf=conf/MoquiDevConf.xml
Now just simply build, load and run.
To answer your question for loading seed data,
you can simply the run the gradle command gradle load -Ptypes=seed, this only loads the seed type data.
Without more details my best guess is that you have another instance of Bitronix running on the machine, by the UniqueName almost certainly another instance of Moqui running. Make sure no other instance is running, killing background processes if there are any, before starting your new instance.
I am facing some odd situation that when I select/deselect the features in the feature customization wizard, it sometimes crashes the window. It does not give any clue at all. It also not happens consistently.
Do you have any idea or faced such kind of issue? I am able to even trace the root cause using install log.
You may be able to get closer to isolating the problem if you turn on the Debug policy. Do this by setting HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer's Debug value to (dword) 7 in as described on the Windows Installer team blog. You will then need to use a tool like DebugView to view the extra output that Windows Installer will generate. Note you may have to restart the "msiserver" service for the policy to take effect. Best luck making sense of what it shows; often it's just a lot of SQL query dumps.
You can sometimes grab MSI exceptions from out of the event log, but they won't always tell you much.
Instead what you can do is turn on logging of the MSI, this can be done either via the registry, or via the command line. To find out about the registry option, visit this MS Support article. To do it from the command line you can use the same switches, but they obviously will only last for that one install. This is a snapshot as gathered from msiexec:
Logging Options
/l[i|w|e|a|r|u|c|m|o|p|v|x|+|!|*] <LogFile>
i - Status messages
w - Nonfatal warnings
e - All error messages
a - Start up of actions
r - Action-specific records
u - User requests
c - Initial UI parameters
m - Out-of-memory or fatal exit information
o - Out-of-disk-space messages
p - Terminal properties
v - Verbose output
x - Extra debugging information
+ - Append to existing log file
! - Flush each line to the log
* - Log all information, except for v and x options
/log <LogFile>
Equivalent of /l* <LogFile>
To take advantage of these options, use msiexec directly:
msiexec.exe [path to your msi] /l [your options]