| [CDO] Negotiator with credential raises a NPE [message #429513] |
Fri, 24 April 2009 09:31  |
 Stephane fournier
Messages: 340
Registered: July 2009 |
Senior Member |
|
|
Hi,
I'm testing to connect a CDO Server with credentials.
I uncomment the "challenge" negiotator in the config.xml and this one
references a property file that contains :
user: dummy
From client side, I use this code to connect :
IConnector connector = (IConnector)
container.getElement("org.eclipse.net4j.connectors", "tcp",
"localhost:2036");
// Authentification
_credentialsProvider = new PasswordCredentialsProvider(CREDENTIALS);
LifecycleUtil.activate(_credentialsProvider);
_responseNegotiator = new ResponseNegotiator();
_responseNegotiator.setCredentialsProvider(_credentialsProvi der);
_responseNegotiator.activate();
((Connector) connector).getConfig().setNegotiator(_responseNegotiator);
// Create CDO session configuration
CDOSessionConfiguration config = CDONet4jUtil.createSessionConfiguration();
config.setConnector(connector);
config.setRepositoryName("repo1"); //$NON-NLS-1$
// Open the session.
_session = config.openSession();
....
I got a NPE in TCPConnector.registerChannelWithPeer(..), controlChannel is
null whereas the TCPConnector was activated. But in the meantime,
TCPConnector.handleRead is called that calls
ControlChannel.handleBufferFromMultiplexer(..).
In the switch case, we enter OPCODE_NEGOTIATION case, and the
assertNegotiating() deactivate the TCPConnector because it seems the
connection is not negociating... Afterwards, controlChannel is reset to
null, and the NPE is thrown in registerChannelWithPeer() when calling
controlChannel.registerChannel(..).
I should miss something but what ?
Stephane.
|
|
|
| Re: [CDO] Negotiator with credential raises a NPE [message #429529 is a reply to message #429513] |
Fri, 24 April 2009 10:27  |
|
Stéphane Fournier schrieb:
> Hi,
>
> I'm testing to connect a CDO Server with credentials.
>
> I uncomment the "challenge" negiotator in the config.xml and this one
> references a property file that contains :
> user: dummy
>
> From client side, I use this code to connect :
> IConnector connector = (IConnector)
> container.getElement("org.eclipse.net4j.connectors", "tcp",
> "localhost:2036");
That's just too early!
At this time the connector is already active (or at least activating,
depending on sync/async startup) and setting a negoiator later does not
change anything anymore. Can you file a Bugzilla so that we add a
lifecycle check in the setter?
You can do one of two things:
1) Don't let the managed container activate the connector (there's a
getElement method with an additional boolean activate parameter).
2) You can instantiate a ConnectorCredentialsInjector and add it to the
list of element post processors of the container.
Does this work?
Cheers
/Eike
----
http://thegordian.blogspot.com
>
> // Authentification
> _credentialsProvider = new PasswordCredentialsProvider(CREDENTIALS);
> LifecycleUtil.activate(_credentialsProvider);
> _responseNegotiator = new ResponseNegotiator();
> _responseNegotiator.setCredentialsProvider(_credentialsProvi der);
> _responseNegotiator.activate();
> ((Connector) connector).getConfig().setNegotiator(_responseNegotiator);
>
> // Create CDO session configuration
> CDOSessionConfiguration config =
> CDONet4jUtil.createSessionConfiguration();
> config.setConnector(connector);
> config.setRepositoryName("repo1"); //$NON-NLS-1$
> // Open the session.
> _session = config.openSession();
> ....
>
> I got a NPE in TCPConnector.registerChannelWithPeer(..),
> controlChannel is null whereas the TCPConnector was activated. But in
> the meantime, TCPConnector.handleRead is called that calls
> ControlChannel.handleBufferFromMultiplexer(..).
> In the switch case, we enter OPCODE_NEGOTIATION case, and the
> assertNegotiating() deactivate the TCPConnector because it seems the
> connection is not negociating... Afterwards, controlChannel is reset
> to null, and the NPE is thrown in registerChannelWithPeer() when
> calling controlChannel.registerChannel(..).
>
> I should miss something but what ?
>
> Stephane.
>
>
>
>
>
>
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Negotiator with credential raises a NPE [message #429539 is a reply to message #429529] |
Fri, 24 April 2009 11:16 |
Stephane fournier
Messages: 340
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
comments below.
Stéphane.
Eike Stepper wrote:
> Stéphane Fournier schrieb:
>> Hi,
>>
>> I'm testing to connect a CDO Server with credentials.
>>
>> I uncomment the "challenge" negiotator in the config.xml and this one
>> references a property file that contains :
>> user: dummy
>>
>> From client side, I use this code to connect :
>> IConnector connector = (IConnector)
>> container.getElement("org.eclipse.net4j.connectors", "tcp",
>> "localhost:2036");
> That's just too early!
> At this time the connector is already active (or at least activating,
> depending on sync/async startup) and setting a negoiator later does not
> change anything anymore. Can you file a Bugzilla so that we add a
> lifecycle check in the setter?
I'll see to it immediately after this answer :)
> You can do one of two things:
> 1) Don't let the managed container activate the connector (there's a
> getElement method with an additional boolean activate parameter).
It works, if add the false flag as you mentioned, but I have to call
explicitly connector.connect() before opening the session. Without that,
controlChannel is not instantiated.
> 2) You can instantiate a ConnectorCredentialsInjector and add it to the
> list of element post processors of the container.
Option 2) works too and I keep that way.
Thanks a lot for your help.
Stéphane.
> Does this work?
> Cheers
> /Eike
> ----
> http://thegordian.blogspot.com
>>
>> // Authentification
>> _credentialsProvider = new PasswordCredentialsProvider(CREDENTIALS);
>> LifecycleUtil.activate(_credentialsProvider);
>> _responseNegotiator = new ResponseNegotiator();
>> _responseNegotiator.setCredentialsProvider(_credentialsProvi der);
>> _responseNegotiator.activate();
>> ((Connector) connector).getConfig().setNegotiator(_responseNegotiator);
>>
>> // Create CDO session configuration
>> CDOSessionConfiguration config =
>> CDONet4jUtil.createSessionConfiguration();
>> config.setConnector(connector);
>> config.setRepositoryName("repo1"); //$NON-NLS-1$
>> // Open the session.
>> _session = config.openSession();
>> ....
>>
>> I got a NPE in TCPConnector.registerChannelWithPeer(..),
>> controlChannel is null whereas the TCPConnector was activated. But in
>> the meantime, TCPConnector.handleRead is called that calls
>> ControlChannel.handleBufferFromMultiplexer(..).
>> In the switch case, we enter OPCODE_NEGOTIATION case, and the
>> assertNegotiating() deactivate the TCPConnector because it seems the
>> connection is not negociating... Afterwards, controlChannel is reset
>> to null, and the NPE is thrown in registerChannelWithPeer() when
>> calling controlChannel.registerChannel(..).
>>
>> I should miss something but what ?
>>
>> Stephane.
>>
>>
>>
>>
>>
>>
>>
>>
>>
|
|
|
| Re: [CDO] Negotiator with credential raises a NPE [message #429544 is a reply to message #429539] |
Fri, 24 April 2009 11:28 |
|
>> 1) Don't let the managed container activate the connector (there's a
>> getElement method with an additional boolean activate parameter).
>
> It works, if add the false flag as you mentioned, but I have to call
> explicitly connector.connect() before opening the session.
Oh yes, I forgot to mention this!! LifecycleUtil.activate(connector)
does the same.
> Without that, controlChannel is not instantiated.
Possibly (hopefully) many other things would not work either.
>
>> 2) You can instantiate a ConnectorCredentialsInjector and add it to the
>> list of element post processors of the container.
>
> Option 2) works too and I keep that way.
>
> Thanks a lot for your help.
You're welcome ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.03362 seconds
] 
Search
Help
Register
Login
Home
