I need to set up so that an object is created once-per-thread in a Karaf CXF container, since I assume that the container will itself set up multiple service threads. I can just use a ThreadLocal, but is there some support in the blueprint.xml for scoping to a thread?
no scope for that, only prototype (default) and singleton.
http://www-01.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.osgi.doc/ae/ca_blueprint_scopes.html
Viktor
Related
I've read the https://camel.apache.org/threading-model.html document. It is not clear to me however whether a given route in one camel context uses a separate threadpool from a totally separate route in another camel context. Basically what I need to establish is whether by default multiple camel contexts you create, will use the/a same threadpool. Did I miss soemthing in the documentation?
No each thread-pool is private to each camel context. Unless you explicit setup a shared thread-pool and refer to use that pool in those Camel's. But a general rule of thumb, its all isolated per camel context.
For a project I need to have a unique ID generator. So I thought about a Singleton with synchronized methods.
Since a Singleton following the traditional Singleton pattern (private static instance) is shared accross Sessions, I'm wondering if the #Singleton Annotation is working the same way?
The documentation says: Identifies a type that the injector only instantiates once.
Does it mean, that a #Singleton will be independent per User Session (which is bad for an id-generator)? Should I prefer an old school Singleton with Class.getInstance() over an Injection of an #Singleton-Bean?
Or should I use neither nor and provide the Service within an #ApplicationScoped bean?
it musst be guaranteed that only ONE thread, independent of the user session can access the method to generate the next id. (It's not solvable with auto-increment database ids)
Edit: JSF 2.2, CDI and javax.inject.* i'm talking about :)
All those kinds of singletons (static, #javax.inject.Singleton, #javax.ejb.Singleton and #javax.enterprise.context.ApplicationScoped) are created once per JVM.
An object that is created once per user session must be annotated with #javax.enterprise.context.SessionScoped so no, singletons will not be instantiated per user session.
Notice that there are two #Singleton annotations, one in javax.inject and the other in the javax.ejb package. I'm referring to them by their fully-qualified names to avoid confusion.
The differences between all those singletons are subtle and I'm not sure I know all the implications, but a few come to mind:
#javax.ejb.Singleton is managed by the EJB container and so it can handle transactions (#javax.ejb.TransactionAttribute), read/write locking and time-outs (#javax.ejb.Lock, #javax.ejb.AccessTimeout), application startup (#javax.ejb.Startup, #javax.ejb.DependsOn) and so on.
#javax.enterprise.context.ApplicationScoped is managed by the CDI container, so you won't have the transaction and locking features that EJB has (unless you use a post-1.0 CDI that has added transactions), but you still have lots of nice things such as #javax.enterprise.inject.Produces, #javax.annotation.PostConstruct, #javax.inject.Named, #javax.enterprise.inject.Disposes (but many of these features are available to EJBs too).
#javax.inject.Singleton is similar to #ApplicationScoped, except that there is no proxy object (clients will have a reference to the object directly). There will be less indirection to reach the real object, but this might cause some issues related to serialization (see this: http://docs.jboss.org/weld/reference/latest-2.2/en-US/html_single/#_the_singleton_pseudo_scope)
A plain static field is simple and just works, but it's controlled by the class loader so in order to understand how/when they are instantiated and garbage collected (if ever), you will need to understand how class loaders work and how your application server manages its class loaders (when restarting, redeploying, etc.). See this question for more details.
javax.inject.Singleton - When used on your bean, you have to implement writeResolve() and readReplace to avoid any serialization issues. Use it judiciously based on what your bean actually has in it.
javax.enterprise.context.ApplicationScoped - Allows the container to proxy the bean and take care of serialization process automatically. This is recommended to avoid unprecedented issues.
For More information refer this page number 45.
I am creating a stand alone camel application. I want to use only java (because the compiler tells whats wrong).
To make my code less coupled and reusable by tests i want to decouple the creation of context and registry to separate classes.
I just started to extend DefaultCamelContext - is this a good idea or should i extend/implement some other class?
Within this class i want to use my own registry (it binds some bean instances) class. I found method setRegistry(org.apache.camel.spi.Registry).
But how to implement such an registry? Is there also a "defaultRegistry"? (for tests there is an createRegistry(), is there something for outside the tests?)
At the end i want to use dependency injection (guice) to glue all stuff together: the registry will inject bean-instances, the registry is then injected in context and context is injected in my main-class than creates "main", sets context and "run()"s it.
Camel supports a pluggable registry strategy...so you should be able to implement the org.apache.camel.spi.Registry interface and call setRegistry(myImpl)...
there are several (Simple, Jndi, etc) registries that are supported that might meet your needs or serve as an example...
for example, here is the SimpleRegistry implementation class...
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=blob_plain;f=camel-core/src/main/java/org/apache/camel/impl/SimpleRegistry.java;h=d2a4a21c9f9fbc70f45fd485d1c46c8a20b9afea;hb=HEAD
Basically, we shouldn't use instance variables and methods in JSP declarations because it is not thread-safe. But GAE does not use threads. So should I use instance variables and methods in JSP declaration? I mean to ask whether it will cause any inaccurate data?
GAE does not use threads by default, but you can turn it on.
So, if you do not turn it on (by declaring your app thread-safe) you will not run into threading issues.
However, why would you want to use instance variables and methods in a JSP in the first place? A JSP should just produce page output and do nothing else. If it gets complex to the point where you want to throw in instance variables and methods, you probably want to move code out into a Java class (beans, servlets, filters).
I need to generate service proxies for multiple WCF services within the same namespace, which is not possible when using the Add Service Reference function of Visual Studio.
How can I do this in an automated way? I've considered using SLsvcUtil, but that would require that I make sure that I have my WCF services accessible, and, assuming I'm using the ASP.NET Development Server, I'd need to manually check the URL.
Ideally, I'd have some way of specifying an assembly, a service type, the configuration (web|app.config) and a target namespace, and then my code would be generated. Any Ideas?
Edit
To clarify, I'm trying to solve the same problem that is outlined in this connect issue:
http://connect.microsoft.com/VisualStudio/feedback/details/426791/adding-multiple-service-references-from-same-application-should-not-require-multiple-namespaces
I want a no-hassle, automated way to generate service proxies within a single namespace. It's unacceptable for me to have to specify a unique namespace for each service reference. Using SLsvcUtil is an option, but it requires that I have my service up-and-running so it can read the metadata - which is a problem because I don't always have the latest version of the service running at any given point in time.
The "Add Service Reference" functionality in VS handles this well - it automatically hosts the service just long enough to grab the metadata, and then generates the service contract interfaces and proxies. Once again, it requires that each service be code-gen'd in its own, unique namespace, which I don't want.
All I need is a way to generate the service proxies with a single, shared namespace, without having to go through the hassle of manually hosting and firing up an instance of my services. Ideally, I'd just double click a script file.
What I normally do is to inform a composite namespace. When the "Add Service Reference" dialog pops up, I put in the namespace something like Services.ServiceA or Services.ServiceB. Then all service namespaces share the common root Services.*.
If I'm understanding the question correctly, you're concerned because the way Add Service Reference functions, the ServiceContract interfaces are not exactly the same as the ones you define in your source assembly.
The only real difference is that the ServiceContract interface that Add Service Reference generates for SL has asynchronous operations defined (since SL doesn't support synchronous WCF calls). The rest of it (the XXXClient : ClientBase class) can be completely bypassed if you just use the ChannelFactory<TServiceContractInterface> directly.
I personally ended up sharing the synchronous ServiceContract interface, but creating a service contract with asynchronous operations using a System.Reflection.Emit.TypeBuilder. Then using a custom ChannelFactory, I created a wrapper around the dynamically generated asynchronous ServiceContract interface.
I hope that helps.