Broadcast triggered not inside request context

[Jarosław Lewandowski]

Hi,

I just wonder whether it is possible to get BroadcasterLookup outside  
HTTP request context. What I would like to have is in JEE application  
some suspended requests (long polling) to which I would like send  
messages generated base on some events not necessary been triggered  
from HTTP request. i.e. quartz events, some business logic etc.  I  
know that this object is retrievable from AtmosphereConfig but is  
there any simple way to get AtmosphereConfig from inside e..g. session  
beans (JNDI lookup ?) Or maybe there is some other way to have it done?

Regards
JL

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jeanfrancois Arcand]

Salut,

Jaros?aw Lewandowski wrote:

> Hi,
>
> I just wonder whether it is possible to get BroadcasterLookup outside
> HTTP request context. What I would like to have is in JEE application
> some suspended requests (long polling) to which I would like send
> messages generated base on some events not necessary been triggered from
> HTTP request. i.e. quartz events, some business logic etc.  I know that
> this object is retrievable from AtmosphereConfig but is there any simple
> way to get AtmosphereConfig from inside e..g. session beans (JNDI lookup
> ?) Or maybe there is some other way to have it done?

JNDI is not yet implemented, and my original idea was to allow

    BroadcasterLookup.lookup(...) // static call

but then postponed the implementation thinking I will have the cycle to
implement JNDI support. But the original idea was to be able to retrieve
this object from everywhere, like I previously did inside the Grizzly
Comet Framework (CometEngine). So I when ahead and commited the fix

  Committed revision 614.

But since you already have EJB + Jersey in place, could you inject the
BroadcasterLookup inside your EJB (I might be wrong here) by doing:

@Context BroadcasterLookup

when the EJB gets created. I admit I might say something really stupid...

A+

--Jeanfrancois



>
> Regards
> JL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jarosław Lewandowski]

On 2 Nov 2009, at 15:45, Jeanfrancois Arcand wrote:

> Salut,
>
> Jaros?aw Lewandowski wrote:
>> Hi,
>> I just wonder whether it is possible to get BroadcasterLookup  
>> outside HTTP request context. What I would like to have is in JEE  
>> application some suspended requests (long polling) to which I would  
>> like send messages generated base on some events not necessary been  
>> triggered from HTTP request. i.e. quartz events, some business  
>> logic etc.  I know that this object is retrievable from  
>> AtmosphereConfig but is there any simple way to get  
>> AtmosphereConfig from inside e..g. session beans (JNDI lookup ?) Or  
>> maybe there is some other way to have it done?
>
> JNDI is not yet implemented, and my original idea was to allow
>
>   BroadcasterLookup.lookup(...) // static call
>
> but then postponed the implementation thinking I will have the cycle  
> to implement JNDI support. But the original idea was to be able to  
> retrieve this object from everywhere, like I previously did inside  
> the Grizzly Comet Framework (CometEngine). So I when ahead and  
> commited the fix
>
> Committed revision 614.
>

Static call is enough if works :)

> But since you already have EJB + Jersey in place, could you inject  
> the BroadcasterLookup inside your EJB (I might be wrong here) by  
> doing:
>
> @Context BroadcasterLookup
>
> when the EJB gets created. I admit I might say something really  
> stupid...
>

I tried this, but it looks like that Jersey is not injecting this  
using your *InjectableProviderS and unfortunately it might work only  
if you have simply one tier with SessionBeans defined as resources...  
if session bean is not a JAX-RS Resource then @Context might not be  
processed as this EJBs probably are untouched by Jersey.


Thanks
JL

> A+
>
> --Jeanfrancois
>
>
>
>> Regards
>> JL
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jeanfrancois Arcand]

Jaros?aw Lewandowski wrote:

>
> On 2 Nov 2009, at 15:45, Jeanfrancois Arcand wrote:
>
>> Salut,
>>
>> Jaros?aw Lewandowski wrote:
>>> Hi,
>>> I just wonder whether it is possible to get BroadcasterLookup outside
>>> HTTP request context. What I would like to have is in JEE application
>>> some suspended requests (long polling) to which I would like send
>>> messages generated base on some events not necessary been triggered
>>> from HTTP request. i.e. quartz events, some business logic etc.  I
>>> know that this object is retrievable from AtmosphereConfig but is
>>> there any simple way to get AtmosphereConfig from inside e..g.
>>> session beans (JNDI lookup ?) Or maybe there is some other way to
>>> have it done?
>>
>> JNDI is not yet implemented, and my original idea was to allow
>>
>>   BroadcasterLookup.lookup(...) // static call
>>
>> but then postponed the implementation thinking I will have the cycle
>> to implement JNDI support. But the original idea was to be able to
>> retrieve this object from everywhere, like I previously did inside the
>> Grizzly Comet Framework (CometEngine). So I when ahead and commited
>> the fix
>>
>> Committed revision 614.
>>
> Static call is enough if works :)

Yes it should work :-)

>
>> But since you already have EJB + Jersey in place, could you inject the
>> BroadcasterLookup inside your EJB (I might be wrong here) by doing:
>>
>> @Context BroadcasterLookup
>>
>> when the EJB gets created. I admit I might say something really stupid...
>>
>
> I tried this, but it looks like that Jersey is not injecting this using
> your *InjectableProviderS and unfortunately it might work only if you
> have simply one tier with SessionBeans defined as resources... if
> session bean is not a JAX-RS Resource then @Context might not be
> processed as this EJBs probably are untouched by Jersey.

I see. Thanks for confirming. Let me know if rev 614 doesn't work.

A+

-- Jeanfrancois

>
>
> Thanks
> JL
>
>> A+
>>
>> --Jeanfrancois
>>
>>
>>
>>> Regards
>>> JL
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Paul Sandoz]

Some javascript/style in this post has been disabled (why?)

On Nov 2, 2009, at 4:54 PM, Jarosław Lewandowski wrote:

But since you already have EJB + Jersey in place, could you inject the BroadcasterLookup inside your EJB (I might be wrong here) by doing:

@Context BroadcasterLookup

when the EJB gets created. I admit I might say something really stupid...

I tried this, but it looks like that Jersey is not injecting this using your *InjectableProviderS and unfortunately it might work only if you have simply one tier with SessionBeans defined as resources... if session bean is not a JAX-RS Resource then @Context might not be processed as this EJBs probably are untouched by Jersey.

What app server are you using?

Injection of Jersey artifacts onto EJBs is supported in the latest promoted build of GF v3.

Paul.

[Paul Sandoz]

On Nov 2, 2009, at 4:45 PM, Jeanfrancois Arcand wrote:

> Salut,
>
> Jaros?aw Lewandowski wrote:
>> Hi,
>> I just wonder whether it is possible to get BroadcasterLookup  
>> outside HTTP request context. What I would like to have is in JEE  
>> application some suspended requests (long polling) to which I would  
>> like send messages generated base on some events not necessary been  
>> triggered from HTTP request. i.e. quartz events, some business  
>> logic etc.  I know that this object is retrievable from  
>> AtmosphereConfig but is there any simple way to get  
>> AtmosphereConfig from inside e..g. session beans (JNDI lookup ?) Or  
>> maybe there is some other way to have it done?
>
> JNDI is not yet implemented,

Note that the javax.naming APIs are blacklisted in GAE.

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jeanfrancois Arcand]

Paul Sandoz wrote:

>
> On Nov 2, 2009, at 4:45 PM, Jeanfrancois Arcand wrote:
>
>> Salut,
>>
>> Jaros?aw Lewandowski wrote:
>>> Hi,
>>> I just wonder whether it is possible to get BroadcasterLookup outside
>>> HTTP request context. What I would like to have is in JEE application
>>> some suspended requests (long polling) to which I would like send
>>> messages generated base on some events not necessary been triggered
>>> from HTTP request. i.e. quartz events, some business logic etc.  I
>>> know that this object is retrievable from AtmosphereConfig but is
>>> there any simple way to get AtmosphereConfig from inside e..g.
>>> session beans (JNDI lookup ?) Or maybe there is some other way to
>>> have it done?
>>
>> JNDI is not yet implemented,
>
> Note that the javax.naming APIs are blacklisted in GAE.

Right.

The good news is I think I have it working now with new GAE
Broadcaster/BroadcasterConfig ....Just need to test it.

A+

-- Jeanfrancois


>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jarosław Lewandowski]

Some javascript/style in this post has been disabled (why?)

HI,

On 2 Nov 2009, at 21:35, Paul Sandoz wrote:

On Nov 2, 2009, at 4:54 PM, Jarosław Lewandowski wrote:

But since you already have EJB + Jersey in place, could you inject the BroadcasterLookup inside your EJB (I might be wrong here) by doing:

@Context BroadcasterLookup

when the EJB gets created. I admit I might say something really stupid...

I tried this, but it looks like that Jersey is not injecting this using your *InjectableProviderS and unfortunately it might work only if you have simply one tier with SessionBeans defined as resources... if session bean is not a JAX-RS Resource then @Context might not be processed as this EJBs probably are untouched by Jersey.

What app server are you using?

Glassfish v3-b70.

Injection of Jersey artifacts onto EJBs is supported in the latest promoted build of GF v3.

It looks like @Context Broadcaster is injected when used as a method argument, but not injected into EJB's fields... (EJB has business interface).

Paul.

[Paul Sandoz]

Some javascript/style in this post has been disabled (why?)

On Nov 3, 2009, at 10:38 AM, Jarosław Lewandowski wrote:

HI,

On 2 Nov 2009, at 21:35, Paul Sandoz wrote:

On Nov 2, 2009, at 4:54 PM, Jarosław Lewandowski wrote:

But since you already have EJB + Jersey in place, could you inject the BroadcasterLookup inside your EJB (I might be wrong here) by doing:

@Context BroadcasterLookup

when the EJB gets created. I admit I might say something really stupid...

I tried this, but it looks like that Jersey is not injecting this using your *InjectableProviderS and unfortunately it might work only if you have simply one tier with SessionBeans defined as resources... if session bean is not a JAX-RS Resource then @Context might not be processed as this EJBs probably are untouched by Jersey.

What app server are you using?

Glassfish v3-b70.

That one should work.

Injection of Jersey artifacts onto EJBs is supported in the latest promoted build of GF v3.

It looks like @Context Broadcaster is injected when used as a method argument, but not injected into EJB's fields... (EJB has business interface).

There is a simple Jersey EJB sample:

  http://download.java.net/maven/2/com/sun/jersey/samples/jersey-ejb/1.1.4-ea-SNAPSHOT/jersey-ejb-1.1.4-ea-SNAPSHOT-project.zip

that works fine with a recent build of GF (we also continuously test this sample against nightly builds of GF). Could you try that?

Note that you need to make sure that the version of the web.xml is 2.5:

<web-app version="2.5" 

xmlns="http://java.sun.com/xml/ns/javaee" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

The sample consists of a root resource no-interface view EJB:

@Stateless

@Path("/")

public class MessageBoardRootResource {

    @EJB MessageBoardResourceBean r;

    @Path("messages")

    public MessageBoardResourceBean getMessageBoardResourceBean() {

        return r;

    }

}

Which has injected an instance of the following no-interface view EJB:

@Stateless

public class MessageBoardResourceBean {

    @Context private UriInfo ui;

    @EJB MessageHolderSingletonBean singleton;

    @GET

    public List<Message> getMessages() {

        return singleton.getMessages();

    }

    @POST

    public Response addMessage(String msg) throws URISyntaxException {

        Message m = singleton.addMessage(msg);

        URI msgURI = ui.getRequestUriBuilder().path(Integer.toString(m.getUniqueId())).build();

        return Response.created(msgURI).build();

    }

   ...

}

Paul.

[Jarosław Lewandowski]

Some javascript/style in this post has been disabled (why?)

Hi,

On 3 Nov 2009, at 10:06, Paul Sandoz wrote:

On Nov 3, 2009, at 10:38 AM, Jarosław Lewandowski wrote:

HI,

On 2 Nov 2009, at 21:35, Paul Sandoz wrote:

On Nov 2, 2009, at 4:54 PM, Jarosław Lewandowski wrote:

But since you already have EJB + Jersey in place, could you inject the BroadcasterLookup inside your EJB (I might be wrong here) by doing:

@Context BroadcasterLookup

when the EJB gets created. I admit I might say something really stupid...

I tried this, but it looks like that Jersey is not injecting this using your *InjectableProviderS and unfortunately it might work only if you have simply one tier with SessionBeans defined as resources... if session bean is not a JAX-RS Resource then @Context might not be processed as this EJBs probably are untouched by Jersey.

What app server are you using?

Glassfish v3-b70.

That one should work.

Injection of Jersey artifacts onto EJBs is supported in the latest promoted build of GF v3.

It looks like @Context Broadcaster is injected when used as a method argument, but not injected into EJB's fields... (EJB has business interface).

There is a simple Jersey EJB sample:

  http://download.java.net/maven/2/com/sun/jersey/samples/jersey-ejb/1.1.4-ea-SNAPSHOT/jersey-ejb-1.1.4-ea-SNAPSHOT-project.zip

that works fine with a recent build of GF (we also continuously test this sample against nightly builds of GF). Could you try that?

Note that you need to make sure that the version of the web.xml is 2.5:

<web-app version="2.5" 

xmlns="http://java.sun.com/xml/ns/javaee" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

The sample consists of a root resource no-interface view EJB:

@Stateless

@Path("/")

public class MessageBoardRootResource {

    @EJB MessageBoardResourceBean r;

    @Path("messages")

    public MessageBoardResourceBean getMessageBoardResourceBean() {

        return r;

    }

}

Which has injected an instance of the following no-interface view EJB:

@Stateless

public class MessageBoardResourceBean {

    @Context private UriInfo ui;

    @EJB MessageHolderSingletonBean singleton;

    @GET

    public List<Message> getMessages() {

        return singleton.getMessages();

    }

    @POST

    public Response addMessage(String msg) throws URISyntaxException {

        Message m = singleton.addMessage(msg);

        URI msgURI = ui.getRequestUriBuilder().path(Integer.toString(m.getUniqueId())).build();

        return Response.created(msgURI).build();

    }

   ...

}

Oh, I have no problem with JAX-RS context objects... UriInfo, Providers etc. are injected properly.. the only problems are with Atmosphere specific objects...

Jaro

Paul.

[Paul Sandoz]

Some javascript/style in this post has been disabled (why?)

On Nov 3, 2009, at 1:16 PM, Jarosław Lewandowski wrote:

Oh, I have no problem with JAX-RS context objects... UriInfo, Providers etc. are injected properly.. the only problems are with Atmosphere specific objects...

Ah!

The Atmosphere instances are provided in the scope of the request. Try:

  @Context Injectable<BroadcasterLookup> ibl;

Because the EJB is a singleton (one instance per app) Jersey injects thread local proxies for the standard JAX-RS artifacts like UriInfo that are in the scope of the request [*]. However, Jersey does not have generic support to proxy any registered per-request injectable.

AFAICT there is nothing currently specific about the Atmosphere injectable providers that they should be in the scope of the request since they all defer to a thread local proxy of HttpServletRequest. So we could change the scope to Singleton.

Paul.

[*] IMHO it was a mistake to support such thread local proxies (too much magic) and instead we should have required a wrapper like Injectable or Provider. If JSR 330 had been around when JAX-RS was being specified things would have been different :-) 

[Jeanfrancois Arcand]

Paul Sandoz wrote:

> On Nov 3, 2009, at 1:16 PM, Jarosław Lewandowski wrote:
>>
>> Oh, I have no problem with JAX-RS context objects... UriInfo,
>> Providers etc. are injected properly.. the only problems are with
>> Atmosphere specific objects...
>>
>
> Ah!
>
> The Atmosphere instances are provided in the scope of the request. Try:
>
>   @Context Injectable<BroadcasterLookup> ibl;
>
> Because the EJB is a singleton (one instance per app) Jersey injects
> thread local proxies for the standard JAX-RS
> artifacts like UriInfo that are in the scope of the request [*].
> However, Jersey does not have generic support to proxy any registered
> per-request injectable.
>
> AFAICT there is nothing currently specific about the Atmosphere
> injectable providers that they should be in the scope of the request
> since they all defer to a thread local proxy of HttpServletRequest. So
> we could change the scope to Singleton.

You means annotating the class with @Singleton?

Thanks

-- Jeanfrancois



>
> Paul.
>
> [*] IMHO it was a mistake to support such thread local proxies (too much
> magic) and instead we should have required a wrapper like Injectable or
> Provider. If JSR 330 had been around when JAX-RS was being specified
> things would have been different :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Paul Sandoz]

On Nov 3, 2009, at 4:05 PM, Jeanfrancois Arcand wrote:

>
>
> Paul Sandoz wrote:
>> On Nov 3, 2009, at 1:16 PM, Jarosław Lewandowski wrote:
>>>
>>> Oh, I have no problem with JAX-RS context objects... UriInfo,  
>>> Providers etc. are injected properly.. the only problems are with  
>>> Atmosphere specific objects...
>>>
>> Ah!
>> The Atmosphere instances are provided in the scope of the request.  
>> Try:
>>  @Context Injectable<BroadcasterLookup> ibl;
>> Because the EJB is a singleton (one instance per app) Jersey  
>> injects thread local proxies for the standard JAX-RS artifacts like  
>> UriInfo that are in the scope of the request [*]. However, Jersey  
>> does not have generic support to proxy any registered per-request  
>> injectable.
>> AFAICT there is nothing currently specific about the Atmosphere  
>> injectable providers that they should be in the scope of the  
>> request since they all defer to a thread local proxy of  
>> HttpServletRequest. So we could change the scope to Singleton.
>
> You means annotating the class with @Singleton?
>

No, the following:

@Provider
public class BroadcasterLookupInjector implements  
InjectableProvider<Context, Type> {

     // The current {@link HttpServletrequest{
     @Context
     HttpServletRequest req;

     public ComponentScope getScope() {
         return ComponentScope.PerRequest;  // change to "return  
ComponentScope.Singleton"
     }

I think you should be able to change all your injectable providers to  
inject in the scope of singleton.

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jeanfrancois Arcand]

Paul Sandoz wrote:

>
> On Nov 3, 2009, at 4:05 PM, Jeanfrancois Arcand wrote:
>
>>
>>
>> Paul Sandoz wrote:
>>> On Nov 3, 2009, at 1:16 PM, Jarosław Lewandowski wrote:
>>>>
>>>> Oh, I have no problem with JAX-RS context objects... UriInfo,
>>>> Providers etc. are injected properly.. the only problems are with
>>>> Atmosphere specific objects...
>>>>
>>> Ah!
>>> The Atmosphere instances are provided in the scope of the request. Try:
>>>  @Context Injectable<BroadcasterLookup> ibl;
>>> Because the EJB is a singleton (one instance per app) Jersey injects
>>> thread local proxies for the standard JAX-RS artifacts like UriInfo
>>> that are in the scope of the request [*]. However, Jersey does not
>>> have generic support to proxy any registered per-request injectable.
>>> AFAICT there is nothing currently specific about the Atmosphere
>>> injectable providers that they should be in the scope of the request
>>> since they all defer to a thread local proxy of HttpServletRequest.
>>> So we could change the scope to Singleton.
>>
>> You means annotating the class with @Singleton?
>>
>
> No, the following:

I should look at the code before asking stupid question :-)

>
> @Provider
> public class BroadcasterLookupInjector implements
> InjectableProvider<Context, Type> {
>
>     // The current {@link HttpServletrequest{
>     @Context
>     HttpServletRequest req;
>
>     public ComponentScope getScope() {
>         return ComponentScope.PerRequest;  // change to "return
> ComponentScope.Singleton"
>     }
>
> I think you should be able to change all your injectable providers to
> inject in the scope of singleton.

OK I will work on that.

A+

--jeanfrancois



>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jeanfrancois Arcand]

Jeanfrancois Arcand wrote:

>
>
> Paul Sandoz wrote:
>>
>> On Nov 3, 2009, at 4:05 PM, Jeanfrancois Arcand wrote:
>>
>>>
>>>
>>> Paul Sandoz wrote:
>>>> On Nov 3, 2009, at 1:16 PM, Jarosław Lewandowski wrote:
>>>>>
>>>>> Oh, I have no problem with JAX-RS context objects... UriInfo,
>>>>> Providers etc. are injected properly.. the only problems are with
>>>>> Atmosphere specific objects...
>>>>>
>>>> Ah!
>>>> The Atmosphere instances are provided in the scope of the request. Try:
>>>>  @Context Injectable<BroadcasterLookup> ibl;
>>>> Because the EJB is a singleton (one instance per app) Jersey injects
>>>> thread local proxies for the standard JAX-RS artifacts like UriInfo
>>>> that are in the scope of the request [*]. However, Jersey does not
>>>> have generic support to proxy any registered per-request injectable.
>>>> AFAICT there is nothing currently specific about the Atmosphere
>>>> injectable providers that they should be in the scope of the request
>>>> since they all defer to a thread local proxy of HttpServletRequest.
>>>> So we could change the scope to Singleton.
>>>
>>> You means annotating the class with @Singleton?
>>>
>>
>> No, the following:
>
> I should look at the code before asking stupid question :-)
>
>>
>> @Provider
>> public class BroadcasterLookupInjector implements
>> InjectableProvider<Context, Type> {
>>
>>     // The current {@link HttpServletrequest{
>>     @Context
>>     HttpServletRequest req;
>>
>>     public ComponentScope getScope() {
>>         return ComponentScope.PerRequest;  // change to "return
>> ComponentScope.Singleton"
>>     }
>>
>> I think you should be able to change all your injectable providers to
>> inject in the scope of singleton.
>
> OK I will work on that.

Done.

A+

-- Jeanfrancois

>
> A+
>
> --jeanfrancois
>
>
>
>>
>> Paul.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]