Is it possible to manage ldap contexts in jboss? - jboss

In the same way that JBoss can manage jdbc data sources can it manage LDAP contexts using JNDI?

Yes, this is just a Tomcat custom <Resource>, see the Tomcat documentation.
In brief, just define a and provide your own implementation of an LdapContextFactory. JBoss will call your getObjectInstance() method with a first parameter that you can cast to a Reference, traverse all its RefAddrs, and get your option names via RefAddr.getType(), and their values via RefAddr.getContent(). Then you use whatever you have passed there to create your LdapContext and return it.

Related

Thorntail: dynamic values on project_defaults.yml

Working with Thorntail/Kubernetes, is it possible to use dynamic values on project_defaults.yml? For example:
thorntail:
ejb3:
thread-pools:
default:
max-threads: ${my.variable}
Where my.variable will be configured on the dashboard of a specific module.
The idea is to replace standalone.xml values without performing a new deploy every time I need to change the value.
That is in theory possible, because Thorntail is based on WildFly, which allows changing some configuration values without restart. Your example refers to a WildFly configuration value, so it might be possible. Those configuration values in Thorntail that don't come from WildFly don't allow for this at all.
You can use the management fraction to let Thorntail expose the WildFly management interface. Then, you can use the WildFly management client (ModelControllerClient) to issue management operations. However, I'd discourage you from doing this, as Thorntail isn't really designed for it.
(Also, Thorntail has reached its end of life. See here for more: https://thorntail.io/posts/the-end-of-an-era/)
We can do that by configuring the variable as an environment variable. Using the previous example:
thorntail:
ejb3:
thread-pools:
default:
max-threads: ${env.my_variable:default_value}
And then we configure my_variable on the dashboard of the desired module.
It is important to notice that we should define a default value, because if that thorntail property is numeric and the environment variable is not defined on the module, we will face a parsing problem since the parser will interpret the variable name as a number. This is a real example:
Kubernets module:
RCNT_MAX_THREADS is defined with 12
project_defaults.yml:
thorntail:
ejb3:
thread-pools:
default:
max-threads: ${env.RCNT_MAX_THREADS:10}
This will cause the application to use max-threads with the value 12. If we don't define RCNT_MAX_THREADS on the module, the value 10 will be used instead.
There is also a very useful option to track what values are really being used: https://docs.thorntail.io/2.5.0.Final/#the-usage-txt-file_thorntail

Use ResourceSet within another Plugin

I use a xtext generated DSL in my project. I now want to generate some files with a wizard. I can currently create these files just by adding some strings to the file. But initially i wanted to create a Model Object of the DSL and add the new generated file to the resource set. I can't find a way accessing this without the StandaloneSetup of the DSL.
I'm now unsure if the use of the StandaloneSetup inside the Editor is the correct way, since it seems there should be a better way to access the already build up resource set used by the xtext framework to manage the already known files/sources. If i use the StandaloneSetup shouldn't there be 2 Injectors which could get really bad?
you can use the resource service provider registry to obtain the injector
http://koehnlein.blogspot.de/2012/11/xtext-tip-how-do-i-get-guice-injector.html
URI fakeOrRealUri = ...;
IResourceServiceProvider.Registry.INSTANCE.getResourceServiceProvider(fakeOrRealUri).get()

Parameter for BPEL process

I use OpenESB + BPEL. I would like to use some parameter to set system specific settings (path, string constants, etc.). I tried to use a properties file that a simple java class should read up and use with this method (http://wiki.open-esb.java.net/Wiki.jsp?page=BPELSEHowToCallJavaMethods).
The problem is that I can't create properties file in BPEL project (not supported). So I created a file by hand. But this file is not included in the deployed app.
Is there any working solution for including property file or is there any other method to set parameters on BPEL process?
Thanks,
Hubidubi
UPDATE:
I found that using application variables is the solution. I defined some variable, but I can't figure out how can I use them in BPEL.
IIRC you reference them via a ${VariableName} directive. I used to use them in OpenESB-Netbeans so I know they work...
Check out http://wiki.open-esb.java.net/Wiki.jsp?page=ApplicationConfiguration
Afaik there is also some kind of preferences for a bpel process that you can set in the bpel file. To reference them in your bpel process, there is function getPreference(key). I successfully use this with the Oracle BPEL stuff.

How to preload EJB instances on JBOss

Is there a way to pre-load EJB instances (stateless) in JBoss 4.2.0? I know there isn't any configuration option for this, but could I write my own MBean or something to do this?
-Dave
It's probably not neccessary according to this article
in $JBOSS_HOME/server/default/conf/standardjboss.xml
you find
<container-pool-conf>
<MaximumSize>100</MaximumSize>
</container-pool-conf>
for both container-confgiurations Clustered Stateless SessionBean and
Standard Stateless SessionBean
Looking in the DTD shows MinimumSize as an optional element in container configuration for experimenting you could set the MinimumSize and check whether some server code cars about.
<!--
The container-pool-conf element holds configuration data for the
instance pool.
jboss does not read directly the subtree for this element: instead,
it is passed to the instance pool instance (if it implements
org.jboss.metadata.XmlLoadable) for it to load its parameters.
The default instance pools, EntityInstancePool and
StatelessSessionInstancePool, both accept the following configuration.
Used in: container-configuration
-->
<!ELEMENT container-pool-conf ((MinimumSize?, MaximumSize?,
strictMaximumSize?, strictTimeout?) | Synchronized)>

Accessing Datasource from Outside A Web Container (through JNDI)

I'm trying to access a data source that is defined within a web container (JBoss) from a fat client outside the container.
I've decided to look up the data source through JNDI. Actually, my persistence framework (Ibatis) does this.
When performing queries I always end up getting this error:
java.lang.IllegalAccessException: Method=public abstract java.sql.Connection java.sql.Statement.getConnection() throws java.sql.SQLException does not return Serializable
Stacktrace:
org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService.doStatementMethod(WrapperDataSourceS
ervice.java:411),
org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService.invoke(WrapperDataSourceService.java
:223),
sun.reflect.GeneratedMethodAccessor106.invoke(Unknown Source),
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25),
java.lang.reflect.Method.invoke(Method.java:585),
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155),
org.jboss.mx.server.Invocation.dispatch(Invocation.java:94),
org.jboss.mx.server.Invocation.invoke(Invocation.java:86),
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264),
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659),
My Datasource:
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
<jndi-name>jdbc/xxxxxDS</jndi-name>
<connection-url>jdbc:oracle:thin:#xxxxxxxxx:1521:xxxxxxx</connection-url>
<use-java-context>false</use-java-context>
<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
<user-name>xxxxxxxx</user-name>
<password>xxxxxx</password>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
<min-pool-size>5</min-pool-size>
<max-pool-size>20</max-pool-size>
</local-tx-datasource>
</datasources>
Does anyone have a clue where this could come from?
Maybe someone even knows a better way how to achieve this.
Any hints are much appreciated!
Cheers,
Michael
Not sure if this is the same issue?
JBoss DataSource config
DataSource wrappers are not usable outside of the server VM
#Michael Well, java.sql.Connection is an Interface - it might technically be possible for the concrete implementation you're getting from JBoss to be Serializable - but I don't think you're really going to have any options you can use. If it was possible, it would probably be easy :)
I think #toolkit might have said the right words with useable outside the VM - the JDBC drivers will be talking to native driver code running in the underlying OS I guess, so that might explain why you can't just pass a connection over the network elsewhere.
My advice, (if you don't get any better advice!) would be to find a different approach - if you have access to locate the resource on the JBoss directory, maybe implement a proxy object that you can locate and obtain from the directory that allows you to use the connection remotely from your fat client. That's a design pattern called data transfer object I think Wikipedia entry
#toolkit:
Well, not exactly. Since I can access the data source over JNDI, it is actually visible and thus usable.
Or am I getting something totally wrong?
#Brabster:
I think you're on the right track. Isn't there a way to make the connection serializable? Maybe it's just a configuration issue...
I've read up on Ibatis now - maybe you can make your implementations of Dao etc. Serializable, post them into your directory and so retrieve them and use them in your fat client? You'd get reuse benefits out of that too.
Here's an example of something looks similar for Wicket
JBoss wraps up all DataSources with it's own ones.
That lets it play tricks with autocommit to get the specified J2EE behaviour out of a JDBC connection. They are mostly serailizable. But you needn't trust them.
I'd look carefully at it's wrappers. I've written a surrogate for JBoss's J2EE wrappers wrapper for JDBC that works with OOCJNDI to get my DAO code unit test-able standalone.
You just wrap java.sql.Driver, point OOCJNDI at your class, and run in JUnit.
The Driver wrapper can just directly create a SQL Driver and delegate to it.
Return a java.sql.Connection wrapper of your own devising on Connect.
A ConnectionWrapper can just wrap the Connection your Oracle driver gives you,
and all it does special is set Autocommit true.
Don't forget Eclipse can wrt delgates for you. Add a member you need to delegate to , then select it and right click, source -=>add delgage methods.
This is great when you get paid by the line ;-)
Bada-bing, Bada-boom, JUnit out of the box J2EE testing.
Your problem is probably amenable to the same thing, with JUnit crossed out and FatCLient written in an crayon.
My FatClient uses RMI generated with xdoclet to talk to the J2EE server, so I don't have your problem.
I think the exception indicates that the SQLConnection object you're trying to retrieve doesn't implement the Serializable interface, so it can't be passed to you the way you asked for it.
From the limited work I've done with JDNI, if you're asking for an object via JNDI it must be serializable. As far as I know, there's no way round that - if I think of a better way I'll post it up...
OK, one obvious option is to provide a serializable object local to the datasource that uses it but doesn't have the datasource as part of its serializable object graph. The fat client could then look up that object and query it instead.
Or create a (web?) service through which to access the datasource is governed - again your fat client would hit the service - this would probably be better encapsulated and more reuseable approach if those are concerns for you.