CDI: Prevent Classes from being remote subscribed (to Server)

[marius.gerwinn]

Hi,

we got some marshalling issues with CDI Events when running our app.

We figured out that for some reason every client class that is used with  @Observe or @Inject Event<SomeClass>

is subscribed to the server CDI-System. This also happens for some client only available classes (not annotated with @Portable and/or in a client only project).

So the marshalling exception is fine.

Anyhow we are actually not using CDI events for client<->server communication.

But we make a lot of use of the CDI Events on client side.

Is there a way to prevent the subscription of CDI Events to the server?

At best this would work for individual classes. So some black/whitelisting with an annotion would be nice (like @Portable)

Thanks for reading,

marius

[csa]

Hi Marius,

Non-portable event types should not be advertised to the server. We had a bug there that was fixed with this commit not so long ago: https://github.com/errai/errai/commit/a435a18513f255eec20808b26c5cb8b912ef548c

Which version of Errai are you on?

Cheers,

Christian

[marius.gerwinn]

Hi Christian,

updating to the latest snapchat did work. So the marshalling exceptions are gone.
Thanks for the fix!

The advertisement of events to the server seems to work as expected now (only for portable types).

Anyhow this is still means still a lot of useless calls to the server in our case since we are not intending ot use CDI for most of our portable-event-types.

The classes only have the portable annotation because we are using them in our RPC calls.

To get an understanding why this is importantant to us, here are some real numbers:

6 calls in the startup phase of our app, registering about 100 events.

As a possible fix we could replace CDI on the client side using the regular EventBus.

We currently don't need client-server CDI, but maybe later.

But Errais CDI is quite handy. So isn't there a better solution for that scenario?

[marius.gerwinn]

Hi again,

I know time is money. But any even short comment on my last post would be helpful!

Thanks,

Marius

[csa]

Hi Marius,

<6 calls in the startup phase of our app, registering about 100 events.>

I am assuming you refer to the RemoteSubscribe messages to the CDI event dispatcher? Why are these 6 calls?

We don't currently have another way to hide the events from the server other than not marking them @Portable. If I understand you correctly you want these types to be @Portable for RPC but local only for events (you don't send them across the wire as events).

The only "solution" right now would be to use different types for your local events and your RPC params. Ideally, how would you want this to work?

Cheers,

Christian

[marius.gerwinn]

Hi Christian,

thank you for your reply.

Regarding the calls in the startup phase of our app I created a file were I copied the relevant requests.

https://www.dropbox.com/s/kwaeowzebz4putp/StartupRequests.txt

As a solution for using CDI events only on the client side I had a look how the discovery strategie works for getting the relevant classes for remote subscribe.

From what I do understand there is a classpath scanner that looks for classes with the @Portable annotion.

All classes found by the scanner are then registered to the server. So the scanner just need to be modified not finding this classes.

Adding an other annotation like @ClientOnlyCDI to these classes would do so. Of course this isn't such pretty solution, but would work?

An other approach could be enabling "client only CDI" with a config variable in the ErraiApp.properties file. But I would prefer the additional annotation since it still leaves the possibility to use CDI for sending events across the wire were it's intended.

[csa]

Hi Marius,

OK thanks. So it's the RemoteSubscibe messages. I think we can introduce another annotation for this in (but prob. in Errai 3). Would you mind filing a JIRA for us?

Cheers,

Christian

[marius.gerwinn]

Cool.

Just created a jira issue: [ERRAI-649] Add client only CDI event support - JBoss Issue Tracker

Thanks,

Marius