Best unofficial Apache Server developers community
Username
Forgot password?
Sign in with Twitter account
Sign in with Facebook account
List archives

what does EJBContainer.PROVIDER property mean?

trunk: Failed for Revision: 983779
(34 lines)
trunk: Failed for Revision: 983848
(10 lines)
Aug 9, 2010
David Jencks
David Jencks
The ejb 3.1 spec says

22.2.2.1 javax.ejb.embeddable.provider
This property holds a String value that specifies the fully-qualified name
of an embeddable container provider class corresponding to the embeddable
container implementation that should be used for this application.
The property name is defined as EJBContainer.PROVIDER.

I think this clearly and unambiguously means the property value should be
the class name of the implementation of javax.ejb.spi.EJBContainerProvider.

Can anyone explain how to understand this sentence to mean that the
property value is the class name of the implementation of
javax.ejb.embeddable.EJBContainer?

thanks
david jencks



Reply
Tags: containerembeddableimplementationcorresponding
Similar Threads
Setting property 'minSpareThreads' to '300' did not find a matching property
Hi, now,we use  JBoss Web/2.1.0.GA,when startup,I find warn log:

How can I set concurrent policy for a provider?
I setup a provider service in activeMQ and want to offer 1000 requests at
the
same time. How can I set the thread policy for this provider?




Problem invoking a provider
Hi all,
I have implemented a Provider for my web service but the request doesn't
pass into my provider. To declare my provider I only have added there 2
lines before my class:
@javax.xml.ws.WebServiceProvider(portName="HelloWorldSoapBinding",
serviceName="HelloWorld")
@javax.xml.ws.ServiceMode(value = javax.xml.ws.Service.Mode.MESSAGE)

Is there no other thing to do?

thanks a lot,
Fabian.




question about package provider on Solaris
Hello,

Here is how I am trying to make sure sudo is installed on my solaris
boxes:

            package {'sudo':
              ensure => 'installed',
              provider => 'blastwave',
              adminfile => '/usr/local/etc/adminfile',
            }

The package is installed, but every time puppetd executes, I get this:

	notice: //base_server/Package[sudo]/ensure: created

It seems like the package provider is not seeing that sudo is already
installed….
How can I fix that?

Both my puppetmaster and puppetd are 0.25.5

Thanks,

Don





x-net] Creating a provider based on OpenSSL
  Hi all,

I'm currently investigating the possibility of implementing a JSSE 
provider wrapping OpenSSL. This has a couple of obvious advantages:
  - The onus of code maintenance and bug fixing in a security sensitive 
area is moved outside of Harmony.
  - New protocols can be integrated into the Harmony provider with 
minimal effort (updating dependencies rather than implementing them 
ourselves).

Really I'm sending this mail as a heads up, but would be interested to 
know if anyone has any experience/opinions in this area. In particular, 
I'd be interested in ideas on:
  - the best way to setup OpenSSL as a dependency - precompile the 
libraries and make them available for download or compile them at build 
time on the user's machine.
  - how to tie in the Java x-net APIs to the OpenSSL APIs.

Any comments/suggestions welcome.

Regards,
Oliver





Do we need to keep the encoder/decoder Provider stuff ?
  Hi,

once upon a time, ie, 8 years ago, Alex codec the network frontend by 
assuming that there will be some other codec used later. It made perfect 
sense back then, as he first used an ASN.1 based codec named Snacc, 
which was not ASL.2 compatible. Then he had to change and define its own 
version of an ASN.1 codec, but as he wanted to check that the new codec 
was valid, he designed the system to be able to switch the codec just to 
know if the new codec was responsible for the failures he met, or 
something else.

The rational was :
- if the server behaves the same way whether Snacc or Snickers (the new 
codec) is used, then if the server has an issue, it means the codec is 
not responsible
- OTOH, if the server behaves differently, then it's likey the new codec 
the cause of the problem.

That was a smart move, and it was leveraged again when I wrote Twix, the 
third codec. I was able to do the same thing : compare the results 
obtained with twix with what was obtained with Snickers.

Eventually, we decided to ditch Snickers and to keep Twix, which was 
renamed.

So as of today, we use the so-called twix internally.

Now, we still have a lot of remaining plumbery in place : all the 
classes needed to declare which codec to use. Mainly, we have :
- Provider, an abstract class in charge of class loading the LdapProvider
- LdapProvider, a class used to create the LdapEncoder and LdapDecoder

Those two classes are created when we create the FilterChain as soon as 
a new session is initialized. More specifically, the ProtocolCodecFilter 
is added into the chain, and before we can process any incoming messages 
from the client, we initialize the codec, using the 
LdapProtocolCodecFactory class to create the encoder/decoder instances.

What are the essential elements ?
- the factory
- the encoder
- the decoder

We should be able to get rid of the provider, assuming we won't even 
switch the codec in the near or distant future. That would simplify the 
code which is, to say the least, cryptic...

so, wdyt ? Should we keep the machinery that allow us to change the 
codec by using an environment variable ?





Changing operation in ServiceMix CXF consumer --> provider
Hi,

    When routing from ServiceMix CXF-BC consumer to ServiceMix CXF-BC
provider, need to call a different operation of CXF provider web service.
The application uses ServiceMix and Camel JBI component. Camel is used for
routing purpose only. The route is

CXF BC consumer ----> Camel ----> CXF BC provider

For example 

operation: {http://example.org}hello

changed to

operation: {http://example.org}greet

I tried to set operation as a header in camel route but is not working.

<route>
    <from uri="jbi:service:http://example.org/helloRouteBuilder"/>
    <setHeader headerName="operationName">
        <constant>greet</constant>
    </setHeader>
    <to uri="jbi:service:http://example.org/greetingService"/>
</route>

I know that this syntax is for Camel CXF endpoints. Will it work for
ServiceMix CXF components?

Anto



Overriding the default Jettison JSON Provider
I've defined a jaxrs server like:

<jaxrs:server id="myService" address="http://localhost:19300/ai/" >

    <jaxrs:serviceBeans>
        <ref bean="resourceService" />
    </jaxrs:serviceBeans>
    <jaxrs:providers>
           <bean
class="org.codehaus.jackson.jaxrs.JacksonJsonProvider">
            <property name="mapper">
             <bean
                class="com.rest.json.ObjectMapperFactoryBean">
            </bean>
            </property>
           </bean>
        <ref bean="jaxbElementProvider" />
    </jaxrs:providers>
    <jaxrs:extensionMappings>
        <entry key="json" value="application/json" />
           <entry key="xml" value="application/xml" />
        </jaxrs:extensionMappings>
 </jaxrs:server>

- For some reason, when I request Json from the service the
org.apache.cxf.jaxrs.provider.JSONProvider#readFrom method is used instead
of the jackson provider. How can I remove/override the built-provider and
replace it with Jackson?

Thanks,


java.util.concurrent.ExecutionException: Provider Exception
Can any one tell me what might be the reason for this exception

on pendingResponse.get()
        at
org.jredis.ri.alphazero.connection.SynchPipelineConnection.serviceRequest(SynchPipelineConnection.java:92)
        at
org.jredis.ri.alphazero.JRedisPipelineService.serviceRequest(JRedisPipelineService.java:96)
        at
org.jredis.ri.alphazero.JRedisSupport.mget(JRedisSupport.java:983)
        at
com.kaboodle.core.cache.impl.JredisCacheServiceImpl.mget(JredisCacheServiceImpl.java:133)
Caused by: java.util.concurrent.ExecutionException: Provider Exception
        at
org.jredis.ri.alphazero.connection.PendingRequest.checkStatus(PendingRequest.java:112)
        at
org.jredis.ri.alphazero.connection.PendingRequest.get(PendingRequest.java:134)
        at
org.jredis.ri.alphazero.connection.PendingRequest.get(PendingRequest.java:26)
        at
org.jredis.ri.alphazero.connection.SynchPipelineConnection.serviceRequest(SynchPipelineConnection.java:80)
        ... 67 more
Caused by: org.jredis.ProviderException: Bug?  Expecting status code for
size/count
        at
org.jredis.ri.alphazero.protocol.SynchProtocol$SynchMultiLineResponseBase.readControlLine(SynchProtocol.java:410)
        at
org.jredis.ri.alphazero.protocol.SynchProtocol$SynchMultiBulkResponse.read(SynchProtocol.java:544)
        at
org.jredis.ri.alphazero.connection.PipelineConnectionBase$ResponseHandler.run(PipelineConnectionBase.java:230)
        ... 1 more



Thanks.





Created: (CAMEL-2906) ValueBuilder should provider the DSL for Predicate
ValueBuilder should provider the DSL for Predicate

Created: (FELIX-2490) OBR repository provider should use lastModified value in xml and/or URL Connec
OBR repository provider should use lastModified value in xml and/or URL
Connection lastModified to check whether to update cached index file

Created: (CAMEL-2989) provider an API to query available endpoints on a component
provider an API to query available endpoints on a component

Re: SPI-Fly and provider-configuration file names that are different than the abstract service clas
David,

Have you had chance to take a look at the changes mentioned in ARIES-353?

I can rename the main SPI-Fly project to something else than
spi-fly-core/org.apache.aries.spifly.core and send updated pom.xml
files if you like :).

Thanks,
  Bartek

2010/7/8 Bartosz Kowalewski <kowalewski### @gmail.com>:
 Hi David,

 I've just created ARIES-353. It covers initial changes to be applied
 to to the SPI-Fly project structure. These changes transform SPI-Fly
 into a multi-module project. Once these changes are in SVN, I'll
start
 contributing itests and other improvements.

 Thanks,
  Bartek

 2010/6/29 David Bosschaert <david.bo### @gmail.com>:
> Hi Bartek,
>
> On 25 June 2010 22:32, Bartosz Kowalewski
<kowalewsk### @gmail.com> wrote:
>> Hi David,
>>
>> I managed to make Eclipse Aspects/Weaving work inside a Pax
Exam test.
>> I can contribute this simple project with integration tests
(of course
>> after applying some clean-up) if you find it useful. I think
that
>> SPI-Fly requires a change in project structure anyway - it
needs a
>> parent project and a second subproject - spifly-itests.
>
> That would be greatly appreciated!
>
>> Some more comments on the SPI-Fly + AOP topic:
>> 1. My understanding is that there's no single uniform
mechanism for
>> supporting AspectJ load-time weaving that would work in all
OSGi
>> containers. Due to the specifics of the OSGi world,
container-specific
>> mechanism are required. Am I right? For Equinox it's Equinox
>> Aspects/Weaving and there's no such mechanism for Felix. This
seems to
>> be a really important disadvantage of using LTW in SPI-Fly.
>
> Yes - there is currently no general mechanism to support
load-time
> weaving in OSGi but this is something being worked on in the OSGi
> Alliance so I expect that it will be possible in a standardized
way in
> the future.
>
>> 2. The problem with adding aspects to bundles is still
unresolved. I'm
>> not sure if there's a clean solution for adding aspects to
consumer
>> bundles (or bundles that provide the API). Of course some
ugly
>> solutions can be applied (like my original headache causing
fragment
>> based one), but these are more intrusive that we might wish.
>
> Yes, this is still an open question. Maybe something for the
AspectJ
> mailing list. I will post there.
>
>> 3. I started implementing support for SPI-Consumer and
SPI-Provider
>> headers that contain some data helpful whne running the
aspect, i.e.
>> api name and provider name/version for the Provider header,
and some
>> mechanism to define consumer constraints/hints in the
SPI-Consumer
>> header that would help the aspect that will tweak the thread
context
>> classloader to make decisions about providers. These
mechanisms are
>> similar to the ones that you described in one of your
e-mails.
>> However, I feel that we should first solve #1 and #2 above
and only
>> then it makes sense to continue with the implementation.
>
> cool stuff - looking forward to your contributions :)
>
> Best regards,
>
> David
>



Created: (DERBY-4745) Custom Authentication Provider : ClassNotFoundException
Custom Authentication Provider : ClassNotFoundException