Configuration for (remote) EJB inside the server non-cluster vs. cluster (of the destination)
by Wolf-Dieter Fink
As I configure a server to use a different server as destination for a
remote call
there is a outbound-connection.
But if the server behind is a member of a cluster the connection will
throw a Exception:
[Server:app-main] 12:29:31,732 INFO
[org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-4-thread-4) Could not
create a connection for cluster node ClusterNode{clusterName='ejb',
nodeName='master:app-oneB',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=5147}], resolvedDestination=[Destination
address=127.0.0.1, destination port=5147]} in cluster ejb:
java.lang.RuntimeException: javax.net.ssl.SSLException: Unrecognized SSL
message, plaintext connection?
If I add the clusters.cluster.name=ejb element to the main application
jboss-ejb-client.xml it will work
BUT
for me it make no sense to have the configuration for non-cluster in the
server and for cluster in the application because it is in
responsibility of the server to find the connection.
Also such config sounds very confusing to me.
Is there a way to configure the cluster properties also in the profile?
- Wolf
12 years, 3 months
Switch to standard Java debug options -Xrunjdwp --> -agentlib?
by Cheng Fang
AS7 currently has the Java debug options
-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
This uses non-standard options, which may be removed in future JDK, and
may not work with other vendors' JDK.
How about switching to use the standard options, to make it easier to
maintain and port?
-agentlib:jdwp=transport=dt_socket,address=localhost:8787,server=y,suspend=n
Cheng
12 years, 3 months
Delegating web auth to a security domain
by Bill Burke
I've written a very small library that allows you to fully delegate
authentication to a security domain/login module. I implemented this to
support integration with a RESTful token service (Openstack Keystone).
https://github.com/resteasy/Resteasy/tree/master/jaxrs/security/skeleton-...
AFAICT, you pretty much have to go through the Realm/Security domain
execution path if you want principals and roles set up correctly to work
with EE security. So doing all protocol work in the Valve just wasn't
gonna cut it. This small library tunnels the catalina Request object (so
you can access info not in HTtpServletRequest) as well as a
HttpServletRespones via a ThreadLocal. Thats about it.
What I'd also like to do is write a web metadata processor that allowed
you to set the auth-method in web.xml to something like:
<login-config>
<auth-method>Securty Domain</auth-method>
<realm-name>java://jaas/myDomain</realm-name>
</login-config>
And it would automatically set up the correct valve and security domain
so you wouldn't have to create a jboss-web.xml. If there is interest
I'll add this and submit a pull request to AS7. Otherwise, I'll just
keep doing what I'm doing.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 3 months
Karaf <-> AS integration
by David M. Lloyd
Attention all - until further notice, any pull requests with the express
or implied purpose of integrating Karaf into AS will be rejected or
reverted by me.
This integration is off the table until all concerned parties have an
opportunity to discuss, in detail, the requirements, implications, and
design of how we could possibly make this work.
Thank you, carry on
--
- DML
12 years, 3 months
Re: [jboss-as7-dev] AS7 Web console architecture, future directions
by Heiko Braun
Thanks Oved,
I'll have a look.
Regards, Heiko
On Sep 16, 2012, at 8:46 AM, Oved Ourfalli <ovedo(a)redhat.com> wrote:
> Hey,
>
> I read your post.
> Have no deep knowledge of the current console architecture and implementation, but I just wanted to note that we (at the oVirt project) currently work on a UI-Plugin infrastructure to our management engine.
>
> Maybe the ideas and research done there can help.
> You can see more details in http://wiki.ovirt.org/wiki/Features/UIPlugins
>
> Oved
>
> ----- Original Message -----
>> From: "Heiko Braun" <hbraun(a)redhat.com>
>> To: "jboss-as7-dev(a)lists.jboss.org Development" <jboss-as7-dev(a)lists.jboss.org>
>> Cc: "Charles Crouch" <ccrouch(a)redhat.com>, "Ramesh Reddy" <rareddy(a)redhat.com>, "alan santos"
>> <alan.santos(a)redhat.com>, gwt-users(a)redhat.com
>> Sent: Friday, September 14, 2012 10:17:05 AM
>> Subject: AS7 Web console architecture, future directions
>>
>>
>>
>>
>>
>>
>> I've put together some entry-points for the discussions around
>> layered products and console extensions in general:
>>
>>
>> http://hbraun.info/2012/09/web-console-architecture-future-directions/
>>
>>
>> Your feedback is very much appreciated.
>>
>>
>> Regards, Heiko
>>
>>
12 years, 3 months
Re: [jboss-as7-dev] weld-osgi status update
by Ales Justin
> Now the next question is how to get this into AS7?
> As it's sort of a chicken-n-egg problem. :-)
>
> We need to upgrade Weld API in AS7 + switch its impl,
> but to release the impl we need to test this against latest AS7.
For the AS7-dev ml ...
We have Weld-OSGi impl, which needs API change,
plus small impl change on top of this API in AS7 integration code.
But in order to confirm everything works, we need to test this against upgraded AS7.
I did this manually, and it seems to work -- all tests pass.
But of course, when releasing, there should be no SNAPSHOT.
I could trick Weld Core into using AS7.1.1 jars, where the AS7 running would be this modified instance,
as we only need it for Arquillian API, *but* unfortunately 7.1.1 is not "Arquillian" compatible with latest AS7 upstream.
Any suggestion on how to actually pull off this Weld 1.2 (with OSGi) release?
-Ales
12 years, 3 months
