[Design of POJO Server] - Re: AbstractDeploymentTest still using DeploymentContext
by alesj
OK, this DS check can be changed to this simple true/false:
| boolean deployed = isDeployed(info.getName());
| assertTrue("Should be fully deployed: " + shortName, deployed);
|
Where 'isDeployed' is this:
| protected boolean isDeployed(String deployment) throws Exception
| {
| URL deployURL = getDeployURL(deployment);
| String[] sig = { URL.class.getName() };
| Object[] args = {deployURL};
| return invokeMainDeployer("isDeployed", args, sig, Boolean.class);
| }
|
| protected <T> T invokeMainDeployer(String methodName, Object[] args, String[] sig, Class<T> clazz) throws Exception
| {
| if (clazz == null)
| throw new IllegalArgumentException("Null class.");
|
| MBeanServerConnection server = getServer();
| Object result = server.invoke(MainDeployerMBean.OBJECT_NAME, methodName, args, sig);
| return clazz.cast(result);
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103272#4103272
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103272
18 years, 5 months
[Design of AOP on JBoss (Aspects/JBoss)] - Re: re: Feedback requested on throttling ejb calls
by ScottMarlowNovell
I'm tempted to have a standalone module manage the named semaphores (perhaps called SemaphoreManager). The SemaphoreManager api methods could be used for reconfiguration (JMX aspect could expose them in the JMX console.)
The api should allow:
* List all named semaphores (show name, total permit count + current available permits)
* Increase number of permits for a named semaphore
* Decrease number of permits for a named semaphore
I'm still trying to understand how all of this AOP stuff works together. I see that the SemaphoreAspect is loosely coupled with the underlying semaphore instance via the SemaphoredObject class. Should we have a SemaphoreFactory class that can return a SemaphoredObject implementation that is based on a named semaphore? I suppose that the SemaphoreFactory could also return a SemaphoredObject based on an anonymous semaphore as well.
The SemaphoreFactory factory would depend on the SemaphoreManager for resolving the semaphore instances.
Make any sense?
On a different node, I can build trunk with "mvn install" command. I would like to run the testsuite but "mvn test" doesn't seem to do much. How can I run the unit tests?
Scott
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103271#4103271
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103271
18 years, 5 months
[Design of JBoss Web Services] - Re: Deployment.types not propagated
by adrian＠jboss.org
"thomas.diesler(a)jboss.com" wrote : With the current API it seems the attachments that I get from
|
| org.jboss.deployers.client.spi.Deployment.getPredeterminedManagedObjects()
|
| are read only.
|
| Please show me the correct usage of a client using attachments
|
They're not read-only in the implementations.
It's just that the Deployment interface assumes that they might be read only,
i.e. you could implement Deployment yourself in a way that the attachments
are immutable.
You can in fact downcast the Attachments to a MutableAttachments
in the provided implementations.
| MutableAttachments attachments = (MutableAttachments) deployment.getPredeterminedManagedObjects();
|
Or if you don't like the cast, you can create an
MutableAttachments yourself and set it on the deployment
| VFSDeploymentFactory factory = new VFSDeploymentFactory();
| VFSDeployment deployment = factory.createDeployment(virtualFile);
| MutableAttachments attachments = new AttachmentsImpl();
| attachments.addAttachment("blah", serializable);
| deployment.setPredeterminedMangedObjects(myAttachments).
|
The latter is also method where you could replace AttachmentsImpl
with some form of immutable attachments implementation that loads
them using some other method.
e.g. the profile service might load them a database.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103256#4103256
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103256
18 years, 5 months
[Design of POJO Server] - AbstractDeploymentTest still using DeploymentContext
by alesj
Currently AbstractDeploymentTest class is still using DeploymentContext (DC), which as I remember should just be an implementation detail.
I was able to easily refactor DC usage to DeploymentUnit (DU).
Except for the DeploymentState (DS) code snippet:
| public void visit(DeploymentUnit info)
| {
| String shortName = shortNameFromDeploymentName(info.getName());
| log.info("Found deployment " + shortName);
| boolean found = expected.remove(shortName);
| if (found == false)
| fail(shortName + " not expected, or duplicate?");
| else
| {
| DeploymentState state = DeploymentState.DEPLOYED; // FIXME!!
| assertEquals("Should be fully deployed: " + shortName + " state=" + state, DeploymentState.DEPLOYED, state);
| }
| }
|
If I want to get to DS, I need to expose this in MainDeployerMBean or again use DC.
And this needs changing as well:
| protected void assertNotDeployed(String deployment) throws Exception
| {
| DeploymentUnit result = getDeploymentUnit(deployment);
| assertNull("Should not be deployed " + result, result);
| }
|
Since this previously never returned null.
Perhaps it will now with the new DU change ... need to test this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103255#4103255
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103255
18 years, 5 months
[Design of JBoss Web Services] - Re: [Productivity] Level 1 - Start from scratch
by max.andersen＠jboss.com
I finally got around to read through these various threads about WS and productivity efforts.
I don't disagree with much in these threads so let me just state some points that you might or might not be aware of ;)
0) I am not a big WS guy - I've found WS to be to clunky to be bothered with; mainly because even with tooling WS is an XML hell and waaay to compliated (I know the annotated way make this more managable but annotation solutions didn't exist when I had to bother with web services ;) - Just know that when I in the future ask some stupid WS beginner question or assume too much or too litle about WS.
1) The only WS tooling we have right now in RHDS is what comes with Eclipse WTP (and that is mainly axis biased)
2) We *want* to get SoapUI back into the JBossTools build again - once when we get over the release hurdle of JBossTools/RHDS GA this will be a priority
3) Be aware that just because something is in JBoss Tools does not mean it will show up in RHDS
4) Looking into how you can integrate your docs/samples with Eclipse Cheatsheets would be very interesting
5) Providing Ant or Maven kind of samples is good - neither of these exclude good JBoss Tools support as long as they are done correctly
6) We/you shouldn't just go out and create an isolated WS-way of creating sample/projects - look into how the eclipse best support it...just using Eclipse as an glorified text editor to calling ant isn't really adding value ;)
7) We need someone who knows about WS to build proper WS support into tooling....preferably someone who likes to do both WS and write plugins ;)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103236#4103236
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103236
18 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ManagedObject support in next messaging release
by dimitris＠jboss.org
Running tests-profileservice there is a debug message in the server log about not been able to read the serverPeer attribute.
After the management class for a service is defined by ServiceMetaDataICF.getManagedObjectClass() so that management metadata can be established, is that class participating at all when reading/writing attribute values?
| 2007-11-09 13:11:42,640 DEBUG [org.jboss.system.deployers.managed.ServiceMetaDataICF] Using alternate class 'class org.jboss.jms.server.destination.QueueServiceMO' for class class org.jboss.jms.server.destination.QueueService
| 2007-11-09 13:11:42,640 DEBUG [org.jboss.system.deployers.managed.ServiceMetaDataICF] Failed to get property value for bean: org.jboss.jms.server.destination.QueueServiceMO, property: serverPeer
| java.lang.IllegalArgumentException: Property is not readable: MBeanServer for javax.management.ObjectName
| at org.jboss.beans.info.plugins.AbstractPropertyInfo.get(AbstractPropertyInfo.java:170)
| at org.jboss.beans.info.plugins.AbstractBeanInfo.getProperty(AbstractBeanInfo.java:238)
| at org.jboss.metatype.plugins.values.DefaultMetaValueFactory.createCompositeValue(DefaultMetaValueFactory.java:361)
| at org.jboss.metatype.plugins.values.DefaultMetaValueFactory.internalCreate(DefaultMetaValueFactory.java:773)
| at org.jboss.metatype.plugins.values.DefaultMetaValueFactory.create(DefaultMetaValueFactory.java:432)
| at org.jboss.system.deployers.managed.ServiceMetaDataICF.getValue(ServiceMetaDataICF.java:141)
| at org.jboss.system.deployers.managed.ServiceMetaDataICF.getValue(ServiceMetaDataICF.java:52)
| at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateValues(AbstractManagedObjectFactory.java:585)
| at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateManagedObject(AbstractManagedObjectFactory.java:534)
| at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.initManagedObject(AbstractManagedObjectFactory.java:171)
| at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.getValue(AbstractManagedObjectFactory.java:727)
| at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateValues(AbstractManagedObjectFactory.java:585)
| at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateManagedObject(AbstractManagedObjectFactory.java:534)
| at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.initManagedObject(AbstractManagedObjectFactory.java:171)
| at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.build(AbstractParsingDeployerWithOutput.java:290)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.build(DeployerWrapper.java:202)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.getManagedObjects(DeployersImpl.java:339)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.getManagedObjects(MainDeployerImpl.java:459)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.processManagedDeployment(MainDeployerImpl.java:508)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.getManagedDeployment(MainDeployerImpl.java:437)
| at org.jboss.profileservice.management.ManagementViewImpl.loadProfile(ManagementViewImpl.java:164)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
| at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
| at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:56)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:771)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:373)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103210#4103210
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103210
18 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ManagedObject support in next messaging release
by dimitris＠jboss.org
I added the org.jboss.system.deployers.managed.ManagementObjectClass annotation and modified the code do deal with it in org.jboss.system.deployers.managed.ServiceMetaDataICF .
The 2 queues in deploy/messaging/destination-service.xml are now annotated by default:
| <mbean code="org.jboss.jms.server.destination.QueueService"
| name="jboss.messaging.destination:service=Queue,name=DLQ"
| xmbean-dd="xmdesc/Queue-xmbean.xml">
| <annotation>@org.jboss.system.deployers.managed.ManagementObjectClass(code=org.jboss.jms.server.destination.QueueServiceMO)</annotation>
| <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
| <depends>jboss.messaging:service=PostOffice</depends>
| </mbean>
|
Based on the xmbean metadata for JBM QueueService and TopicService I created 2 new classes to hold the management information in the messaging integration module:
org.jboss.jms.server.destination.QueueServiceMO
org.jboss.jms.server.destination.TopicServiceMO
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103206#4103206
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103206
18 years, 5 months