[Design of POJO Server] - Re: JBAS-5259, JMS Destination Names is showing as QueueServ
by mark.spritzler
Using build #1202 I see the following about 6 times. This is at AS startup, when we are discovering what is deployed. Which would be before the Queues and Topics are even deployed. Also, these exceptions are now stopping us from seeing the Datasources too, but I think that is an after-affect.
Thanks
Mark
09:35:46,984 INFO [ProfileJBossServerDiscoveryComponent] Discovering resources of Server Type: ResourceType[id=0, categ
ory=Server, name=Application Server, plugin=ProfileService]
09:35:47,281 INFO [ManagementViewImpl] Creating hsqldb-ds.xml ManagedDeployment
09:35:47,343 INFO [ManagementViewImpl] DefaultDS ManagementComponent
09:35:50,359 WARN [QueueService] Queue is stopped
09:35:50,359 WARN [AbstractManagedObjectFactory] Cannot create String name from non-Simple property: ManagedProperty{JN
DIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
09:35:50,359 WARN [QueueService] Queue is stopped
09:35:50,359 WARN [QueueService] Queue is stopped
09:35:50,375 WARN [QueueService] Queue is stopped
09:35:50,375 WARN [AbstractManagedObjectFactory] Cannot create String name from non-Simple property: ManagedProperty{JN
DIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
09:35:50,375 WARN [QueueService] Queue is stopped
09:35:50,375 WARN [QueueService] Queue is stopped
09:35:50,421 WARN [TopicService] Topic is stopped.
09:35:50,421 ERROR [ExceptionUtil] Topic[(destination.getName() == NULL)] listMessagesNonDurableSub
java.lang.NullPointerException
at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
at org.jboss.jms.server.destination.TopicService.getMessageCounters(TopicService.java:549)
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.mx.interceptor.AttributeDispatcher.invoke(AttributeDispatcher.java:99)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.invoke(ModelMBeanAttributeInterceptor.java:197)
at org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceInterceptor.java:76)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:362)
at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
at org.jboss.system.deployers.managed.ServiceMetaDataICF.getValue(ServiceMetaDataICF.java:150)
at org.jboss.system.deployers.managed.ServiceMetaDataICF.getValue(ServiceMetaDataICF.java:55)
at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateValues(AbstractManagedObjectFactory.ja
va:603)
at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateManagedObject(AbstractManagedObjectFac
tory.java:552)
at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.initManagedObject(AbstractManagedObjectFactory
.java:186)
at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.getValue(AbstractManagedObjectFactory.java:763
)
at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateValues(AbstractManagedObjectFactory.ja
va:603)
at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateManagedObject(AbstractManagedObjectFac
tory.java:552)
at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.initManagedObject(AbstractManagedObjectFactory
.java:186)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.build(AbstractParsingDeployerWithO
utput.java:290)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.build(DeployerWrapper.java:202)
at org.jboss.deployers.plugins.deployers.DeployersImpl.getManagedObjects(DeployersImpl.java:341)
at org.jboss.deployers.plugins.main.MainDeployerImpl.getManagedObjects(MainDeployerImpl.java:674)
at org.jboss.deployers.plugins.main.MainDeployerImpl.processManagedDeployment(MainDeployerImpl.java:723)
at org.jboss.deployers.plugins.main.MainDeployerImpl.getManagedDeployment(MainDeployerImpl.java:655)
at org.jboss.profileservice.management.ManagementViewImpl.loadProfile(ManagementViewImpl.java:186)
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:847)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
at org.jboss.remoting.Client.invoke(Client.java:1685)
at org.jboss.remoting.Client.invoke(Client.java:589)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at AOPProxy$1.loadProfile(AOPProxy$1.java)
at org.rhq.plugins.jbossas5.factory.ProfileServiceFactory.refreshCurrentProfileView(ProfileServiceFactory.java:1
02)
at org.rhq.plugins.jbossas5.factory.ProfileServiceFactory.getCurrentProfileView(ProfileServiceFactory.java:86)
at org.rhq.plugins.jbossas5.factory.ProfileServiceFactory.refreshCurrentProfileView(ProfileServiceFactory.java:1
02)
at org.rhq.plugins.jbossas5.ProfileJBossServerDiscoveryComponent.discoverResources(ProfileJBossServerDiscoveryCo
mponent.java:54)
at org.rhq.core.pc.inventory.AutoDiscoveryExecutor.pluginDiscovery(AutoDiscoveryExecutor.java:189)
at org.rhq.core.pc.inventory.AutoDiscoveryExecutor.call(AutoDiscoveryExecutor.java:98)
at org.rhq.core.pc.inventory.AutoDiscoveryExecutor.call(AutoDiscoveryExecutor.java:65)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.j
ava:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:168
)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136767#4136767
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136767
18 years
[Design of JBoss Build System] - Re: Moving jbossas to a maven repo for thirdparty (2nd try)
by adrian＠jboss.org
"pgier" wrote : I believe moving off the thirdparty repository is something that we still want to do,
|
Yes
anonymous wrote :
| even though my first try was a failure.
|
It wasnt properly validated/tested before it was committed.
anonymous wrote :
| At least I think it helped to flush out some issues that might have otherwise taken more time to figure out. So the plan going forward is to fix the out of sync dependencies, and add exclusions to the dependencies where we don't want certain transitive deps included.
|
| Then of course do additional testing to make sure that the testsuite runs. I'll plan to post daily updates here, and then send a notification to the dev-list when I'm ready for the 2nd try at this.
|
Don't get my critisms on the dev-list wrong. The old thirdparty mechanism
has similar issues to Maven. In fact, in some instances it is worse
(e.g. not detecting changes to snapshots or stale artifacts in thirdparty)
It's just that we are used it (so we know how to make it work)
and its configuration has the advantage of having the correct dependencies. ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136762#4136762
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136762
18 years
[Design the new POJO MicroContainer] - Re: Field injection
by alesj
"adrian(a)jboss.org" wrote :
| I know you're probably scared of me telling you did it wrong after the fact,
| but now I'll tell you that you are asking a stupid question before the fact. :-)
|
Could be, but I think it's again the case of 'me explaining what I want badly'. :-)
See below for more details.
"adrian(a)jboss.org" wrote :
| Isn't it obvious that PropertyInfo is the contract and AbstractPropertyInfo
| is an implementation detail?
|
Really?
I thought I was missing some conclusion after 2 years of work on MC? :-)
"adrian(a)jboss.org" wrote :
| There should be some refactoring like;
|
| | public abstract class AbstractPropertyInfo implements PropertyInfo { String name }
| | public class StandardPropertyInfo extends AbstractPropertyInfo { MethodInfo getter, MethodInfo setter }
| | public class FieldPropertyInfo extends AbstractPropertyInfo { FieldInfo field }
| |
|
Already got exactly all this in place. ;-)
OK, let me try once more to explain what I see as an issue.
...
Eh, during thinking what I wanted to ask/write, I understood what I really needed to do.
So, yes, we can call my previous post again a bad explanation. Since I see I couldn't explain it even to myself at that time. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136752#4136752
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136752
18 years
[Design the new POJO MicroContainer] - Re: Field injection
by adrian＠jboss.org
"adrian(a)jboss.org" wrote : "alesj" wrote :
| | "adrian(a)jboss.org" wrote :
| | | This should have a BeanInfo with one property which is a FieldPropertyInfo
| | |
| | What about if the bean is in ALL or FIELDS mode and the property has just setter or just getter?
| | OK, there should be some kind of CombinedPropertyInfo.
| |
|
| I don't know, I'm not deep in the implementation details and don't want to be.
| I have my own work to do. :-)
|
| If you think there is a policy choice to be made then let
| the user decide with a addtional enum value.
|
Or post examples where you think there is a problem we don't have
to do full analysis ourselves.
Then we can decide whether use case makes sense.
To me the only ones that I'd personally use are the three I gave above,
but I could be wrong.
The more permutations and external policy you add, the more you've got to test and
the more chance of error due to complexity.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136744#4136744
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136744
18 years
[Design the new POJO MicroContainer] - Re: Field injection
by alesj
"adrian(a)jboss.org" wrote : "alesj" wrote : "adrian(a)jboss.org" wrote :
| | | This should have a BeanInfo with one property which is a FieldPropertyInfo
| | |
| | What about if the bean is in ALL or FIELDS mode and the property has just setter or just getter?
| | OK, there should be some kind of CombinedPropertyInfo.
| |
|
| I don't know, I'm not deep in the implementation details and don't want to be.
| I have my own work to do. :-)
|
| If you think there is a policy choice to be made then let
| the user decide with a addtional enum value.
|
| Don't mix policy and implementation! :-)
|
| anonymous wrote :
| | The real question is, should I also replace the existing AbstractPropertyInfo in AbstractBeanInfo.properties or just in AbstractBeanInfo.propertiesByName?
|
I know you're probably scared of me telling you did it wrong after the fact,
but now I'll tell you that you are asking a stupid question before the fact. :-)
Isn't it obvious that PropertyInfo is the contract and AbstractPropertyInfo
is an implementation detail?
There should be some refactoring like;
| public abstract class AbstractPropertyInfo implements PropertyInfo { String name }
| public class StandardPropertyInfo extends AbstractPropertyInfo { MethodInfo getter, MethodInfo setter }
| public class FieldPropertyInfo extends AbstractPropertyInfo { FieldInfo field }
|
I'll let you decide some better names :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136739#4136739
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136739
18 years