Supporting SocketAddress as a config property?

[pmm]

I know this isn't part of the spec but supporting SocketAddress as a config property would be a really nice enhancement. Resource adapters often need to bind or connect to sockets. So you'll have to reimplement this every time and also which interfaces need to be bound. There is ususally support for this in the application server, but since it's not a "native" configuration property type you can't hook into it.

In the same vain supporting List properties would be nice, so that you can have a list of addresses to bind.

[jesper.pedersen]

Complex objects like SocketAddress and List won't be supported any time soon.

The config-property's are initialized before the resource adapter is started, connection factories bound in JNDI, ... so it would require a very explicit lifecycle model. Not to mention the marshal/unmarshal of their values.

[pmm]

Jesper Pedersen wrote:

Complex objects like SocketAddress and List won't be supported any time soon.

The config-property's are initialized before the resource adapter is started, connection factories bound in JNDI, ... so it would require a very explicit lifecycle model. Not to mention the marshal/unmarshal of their values.

Yeah. It's just something common that adaptors need to do and it would be cool if the application server could do the heavy lifting. There doesn't seem to be a JCA 1.7 planned for EE 7 so I thought I'd mention it. I guess I can still hope for a JCA 1.8 in EE 8

[jesper.pedersen]

I'm working on JCA 1.7 right now, but it is just a spec update to align with EE 7.

But yeah, we will return to JCA in EE 8 for sure if I have anything to say about it

[pmm]

Jesper Pedersen wrote:

I'm working on JCA 1.7 right now, but it is just a spec update to align with EE 7.

But yeah, we will return to JCA in EE 8 for sure if I have anything to say about it

Cool, while we're at it it would be cool if MessageEndpoint could implement AutoCloseable so that it can be used in a try-with-resources block.

[jesper.pedersen]

And what is stopping you from doing that ?

I'm not seeing the use-case, as the release method provides a hint that the resources should be released. That is very different than a close.

[pmm]

Jesper Pedersen wrote:

And what is stopping you from doing that ?

I'm not seeing the use-case, as the release method provides a hint that the resources should be released. That is very different than a close.

It's just something that I always have in a finally clause. But you're right, using close for that is probably misuse.

One more thing Could javax.resource.spi.ManagedConnectionFactory.matchManagedConnections(Set, Subject, ConnectionRequestInfo) be given a Set<?> instead of a raw typed Set? It prevents raw type compiler warnings and also more clearly communicates that you shouldn't add to it.