Which jar correspond to this org.eclipse.jetty.server.context.ManagedAttributes?
I am trying to expose bayeux mbeans as documented here. But just out of curiosity I was trying to look for source of above mentioned file and am unable to find it.
All search results are ending in annotation jar which is a different class.
P.S. Jetty 9.2.2
The string org.eclipse.jetty.server.context.ManagedAttributes is a constant field of class ContextHandler.
ContextHandler will look up the beans and update the beans belonging to this context.
The jetty-jmx module registers itself as a listener for bean updates, and when an update event is fired, it wraps the correspondent bean in a MBean, and export it to the MBeanServer.
Related
I am setting up a multi tenant Symfony 4 application where each tenant has it's own database.
I've set up two database connections in the doctrine.yaml config. One of the connections is static based on an env variable. The other one should have a dynamic URL based on a credential provider service.
doctrine:
dbal:
connections:
default:
url: "#=service('provider.db.credentials').getUrl()"
The above expression "#=service('provider.db.credentials').getUrl()" is not being parsed though.
When injecting "#=service('provider.db.credentials').getUrl()" as argument into another service the result of getUrl() on the provider.db.credentials service is injected. But when using it in the connection configuration for doctrine the expression is not being parsed.
Does anyone have an idea how to solve this?
You're trying to rely on ability of Symfony services definition to use expressions for defining certain aspects of services. However you need to remember that this functionality is part of Dependency Injection component which is able (but not limited to) to use configuration files for services. To be more precise - this functionality is provided by configuration loaders, you can take a look here for example of how it is handled by Yaml configuration loader.
On the other hand configuration for Doctrine bundle, you're trying to use is provided by Config component. A fact that Dependency Injection component uses same file formats as Config component do may cause an impression that these cases are handled in the same way, but actually they're completely different.
To sum it up: expression inside Doctrine configuration does not work as you expecting because Doctrine bundle configuration processor doesn't expect to get an Expression Language expression and doesn't have support for handling them.
While explanations given above are, hopefully, answers your question - you're probably expecting to get some information about how to actually solve your problem.
There is at least 2 possible ways to do it, but choosing correct way may require some additional information which is out of scope of this question.
In a case if you know which connection to choose at a time of container building (your code assumes that it is a case, but you may not be aware about it) - then you should use compiler pass mechanism yo update Doctrine DBAL services definitions (which may be quite tricky). Reason for this non-trivial process is that configurations are loaded at the early stages of container building process and provides no extension points. You can take a look into sources if necessary. Anyway, while possible, I would not recommend you to go in this way and most likely you will not need it because (I suppose) you need to select connection in runtime rather then in container building time.
Probably more correct approach is to create own wrapper of DBAL Connection class that will maintain list of actual connections and will provide required connection depending on your application's logic. You can refer to implementation details of DBAL sharding feature as example. Wrapper class can be defined directly through Doctrine bundle configuration by using wrapper_class key for dbal configuration
I am using Apache Jetty 9.2.10 which uses weld weld-servlet-2.2.5.Final.jar.
Is it possible to update weld version to the last release? I did not find a procedure to update jetty modules in its documentation.
Firstly you need to decide whether you bundle these implementations in your application or whether you want to use the module system in Jetty.
From your question I would guess it is the module way.
Then it should be very straightforward.
get weld-servler.jar and weld-servlet-core.jar in your desired version
in ${jetty_dir}/lib create a folder weld and put the above jars into it
in ${jetty_dir}/modules create weld.mod file:
and type in the following:
[depend]
jndi
annotations
plus
[lib]
lib/weld/*.jar
as a last step, edit ${jetty_dir}/start.ini and add a sinle line containing --module=weld
Now you should be able to start server and deploy an app using CDI/Weld.
Here is a link to external information about this.
I am evaluating wso2 and came across the following issue: imagine that my company already has a well defined Common Data Model for their business. Those schemas (and even service definitions - wsdls) live on a repository and references between files are done using relative paths between them. Now, what I want is to import all of these XSD's and WSDL's into wso2 Gorvernance Registry (wso2greg) to make it manage them. More (and this is where I start to lose the grip on wso2) I want to reference wso2greg's resources on wso2bps's BPEL Workflows. I want to say: "Hey, workflow! Forget all about your auto-generated interface. Your interface will be this one {wsdl_from_wso2greg}."
I am trying to accomplish this by creating an Registry Resources Project inside my "main" Carbon Application Project (along-side with my BPEL Workflow) and then creating PartnerLinks on the workflow but, after I configured everything, I get the following error: "The import location of ../TestGreg/TestServiceWsdl.wsdl is not supported by this implementation. Import artifacts must be contained within the folder hierarchy that has the deployment descriptor at the root".
Now, am I doing something really stupid or wso2 really does not support what I am trying to do? If so, how do you guys usually deal with these issues?
Thks,
Leandro Nunes
When you are referring to WSDLs/XSDs from BPEL, you need to package them with BPEL. You cannot refer the ones stored in the registry.
Referring from the external registry can be done only for security policies and endpoint references. Any other resources need to be packaged with the BPEL.
So here's what I'm trying to do and stuck at:
I have a shared Eclipse Java project with #Entity (EJB 3.1) classes that is used by a couple of other Eclipse WebApp projects. This project itself has no persistence.xml! The other WebApp projects that use this project declare their own persistence.xml under WebContent/META-INF and refer to the JAR of this project in their persistence.xml using the jar-file tag. Of course the shared project's JAR is added as a deployment dependency in these WebApp projects and is placed under WEB-INF/lib.
Now I am creating JUnit4 Testcases to test Stateless session beans in these WebApp projects. I'm using Apache TomEE 1.5.0 Plus and in the testcase I use a #Before method to start the OpenEJB container in Embedded mode using EJBContainer.createEJBContainer() method. For this to work properly, I have created an alternate test.persistence.xml (that uses a different datasource to an HSQL memory db and creates the tables using forward mapping). I have placed this in META-INF of the src folder and in the #Before method, I set the "openejb.altdd.prefix" to "test" so that the alternate test.persistence.xml is read. All this setup is working.
The trouble is that as soon as OpenJPA 2.2.0 starts, it complains that there are no persistent classes from the shared project! This is because, the jar-file tag in test.persistence.xml refers to a jar that doesn't exist! When Eclipse deploys the other WebApp projects, it creates the JAR under WEB-INF/lib and the actual persistence.xml refers to the jar under that path! However, I do not find any such JAR when running a JUnit testcase.
So how do I refer to this JAR or the classes in the shared project in the test.persistence.xml without making the testcase itself overly dependent on deployment structure or any specific hard-coded path! This testcase will eventually be committed to the repository and hence must be such that any dev checking it out can simply run it.
Any pointers in the right direction would be greatly appreciated!
IMO the easiest and better way to do that is to use Arquillian.
It's far more easier to control the packaging, the life cycle of the container, etc
TomEE also provides a great integration (adapter) with Arquillian you can use.
Check the documentation page http://tomee.apache.org/documentation.html
There is an arquillian section.
You can also check TomEE examples page where you can find a huge amount of small samples including arquillian.
Hope it helps
Jean-Louis
I would like to use a WorkManager to schedule some parallel jobs on a WebLogic 10.3 app server.
http://java.sun.com/javaee/5/docs/api/javax/resource/spi/work/WorkManager.html
I'm finding the Oracle/BEA documentation a bit fragmented and hard to follow and it does not have good examples for using WorkManagers from EJB 3.0.
Specifically, I'd like to know:
1) What exactly, if anything, do I need to put in my deployment descriptors (ejb-jar.xml and friends)?
2) I'd like to use the #Resource annotation to inject the WorkManager into my EJB 3 session bean. What "name" do I use for the resource?
3) How do I configure the number of threads and other parameters for the WorkManager.
My understanding is that the underlying implementation on WebLogic is CommonJ, but I'd prefer to use a non-proprietary approach if possible.
First, you'll find the documentation of CommonJ, an implementation of the Timer and Work Manager API developed by BEA Oracle and IBM, in Timer and Work Manager API (CommonJ) Programmer’s Guide. They provide a Work Manager Example but it's not injected in this document.
1) What exactly, if anything, do I need to put in my deployment descriptors (ejb-jar.xml and friends)?
According to the Work Manager Deployment section:
Work Managers are defined at the
server level via a resource-ref in the
appropriate deployment descriptor.
This can be web.xml or ejb-jar.xml
among others.
The following deployment descriptor
fragment demonstrates how to configure
a WorkManager:
...
<resource-ref>
<res-ref-name>wm/MyWorkManager</res-ref-name>
<res-type>commonj.work.WorkManager</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
...
Note: The recommended prefix for the JNDI namespace for WorkManager
objects is java:comp/env/wm.
Check the WorkManager javadocs for more details (e.g. "The res-auth and res-sharing scopes are ignored in this version of the specification. The EJB or servlet can then use the WorkManager as it needs to.").
2) I'd like to use the #Resource annotation to inject the WorkManager into my EJB 3 session bean. What "name" do I use for the resource?
I'd say something like this (not tested):
#ResourceRef(jndiName="java:comp/env/wm/MyWorkManager",
auth=ResourceRef.Auth.CONTAINER,
type="commonj.work.WorkManager",
name="MyWorkManager")
3) How do I configure the number of threads and other parameters for the WorkManager.
See the description of the <work-manager> element and Using Work Managers to Optimize Scheduled Work for detailed information on Work Managers
My understanding is that the underlying implementation on WebLogic is CommonJ, but I'd prefer to use a non-proprietary approach if possible.
I don't have any other suggestion (and, as long as this implementation follows the standards, I wouldn't mind using it).
The Weblogic documentation will answer your questions.
Using Work Managers to Optimize Scheduled Work