November 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Topics/Queues as MC Beans

by anil.saldhana＠jboss.com

I tried the following: | <bean name="QueueEJB3MDB" class="org.jboss.mq.server.jmx.Queue"> | <property name="destinationManager">jboss.messaging.destination:service=Queue,name=QueueEJB3MDB</property> | <property name="JNDIName">QueueEJB3MDB</property> | <property name="serverPeer">jboss.messaging:service=ServerPeer</property> | <depends>jboss.messaging:service=PostOffice</depends> | </bean> | reusing Scott's delegating bean http://anonsvn.jboss.org/repos/jbossas/trunk/messaging/src/main/org/jboss... All this does is delegation to the JBoss Messaging Destination MBean Service. The issue that I faced was that between the create() and start() calls on the Queue MC bean, there was no MBeanRegistration thereby no preRegister callback, such that the JBossMessaging mbean service could get hold of the mbean server. Because of this, the start() of the JBoss Messaging service fails with NPE because it has not got hold of the mbean server. If this is the same as the other thread, then forgive me. I did not want to digress the topic. http://www.jboss.com/index.html?module=bb&op=viewtopic&t=146039 Certainly we can create the destinations the mbean way. But I wanted to give the mc bean way a try. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191922#4191922 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191922

15 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Adding VFSMetaData for VFS deployment options

by alesj

WRT: - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191875#4191875 I guess we could add something like I suggested in wrt post. Although this looks a lot like jboss-structure.xml and its modification attribute, it is not. Since if we don't have noReaper option known before we actually create deployment root, there is no effect in disabling it later, as it will already run, hence probably stopping root file from being deleted from external client (e.g. plain File::delete from 2nd JVM), therefor not the effect user wanted with this flag. And since we already base most of our metadata on xml, I would use jboss-vfs.xml instead of before suggested vfs.properties. Or eventually it could be both, where jboss-vfs.xml would be easier to evolve, but vfs.properties easier to write. Although I don't see how I can read this file w/o VFS usage. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191921#4191921 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191921

15 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: No factoryClass does not use class attribute

by adrian＠jboss.org

"alesj" wrote : | Should I add this behavior? | Or at least throw an exception that something is missing, | either factory or factoryClass? You should do one or the other. i.e. either support it or give a reasonable error message. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191919#4191919 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191919

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Unrecognised deployments

by adrian＠jboss.org

One potential solution would be to rework this based on the TrackingMutableAttachments that I added for management purposes (so you could see which deployers were creating attachments). It would need extending to include who referenced the predetermined attachments and you've still got the issues of trying to workout the ClassLoadingMetaData is only a default rule and letting plain jar files through that just create classloaders. But its probably a lot less error prone than the isDeployed() handling with the deployed() invocations that is currently broken now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191918#4191918 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191918

15 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: comments on initial xsd jpdl 4

by estaub

"kukeltje" wrote : | you know, namespaces ;-)) You don't want Tom to get the hives - you know about his allergy to namespaces ;-) Seriously - as I see it, this is a clear case for using a namespace. I think there's a good chance another editor might come along, with a different persistent dataset to merge in. -Ed View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191916#4191916 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191916

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Unrecognised deployments

by adrian＠jboss.org

We need to come up with a fix for the problem that I mentioned on a different thread (I think in the user forums since I can't find it?) Basically what is happening is if I add a my.rubbish file to the deploy directory it is getting deployed and it is marked as being processed because the default classloading rules deployer is adding a ClassLoadingMetaData as an attachment which goes through this processing in AbstractDeploymentContext | public Object addAttachment(String name, Object attachment) | { | DeploymentContext deploymentContext = getDeploymentContext(); | deploymentContext.deployed(); // HERE THIS MARKS IT AS DEPLOYED | return deploymentContext.getTransientAttachments().addAttachment(name, attachment); | } | In principle the simplest fix would be to just remove that line (and some others related to transient attachment retrieval), except this change: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas?view=rev&revision=67299 modified the logic to include an invalid check for whether the deployment reached the DEPLOYED state. It will reach that state unless a deployer throws an error. But even then, I don't think it is as simple as it was before. e.g. you can now have a deployment that is correctly deployed without any TransientManagedObjects, e.g. if it is only scanned for annotations. There's also a few places now that invoke methods on the DeploymentUnit that would actually make it deployed anyway. e.g. AOP always asking for the classloader. If you add to that the hack (which I can't find anymore?) that used to let .jar files get through the isDeployed() check this whole area has become a lot more complicated. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191914#4191914 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191914

15 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Adding handy isInstance(Object) method to TypeInfo

by alesj

"alesj" wrote : | OK? Done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191903#4191903 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191903

15 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: No factoryClass does not use class attribute

by alesj

"adrian(a)jboss.org" wrote : | NOPE. You just imagined it. :-) | Could be, looking at old ConstructorHandler and BeanConstructorInterceptor. :-) But this feels like a natural way of introducing factory method, as I know I went that path a couple of times. Should I add this behavior? Or at least throw an exception that something is missing, either factory or factoryClass? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191897#4191897 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191897

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Hotdeployment is still broken

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | 2) Include the MetaDataAware handling in the SerializableDeploymentRepository | so we know when deployment descriptors (anything in the metadata-locations) | get modified. | We need this to know when admin edits are out of date anyway, so let's focus on that fix. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191889#4191889 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191889

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Hotdeployment is still broken

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | 1) the HDScanner which has some sane rules and a decent abstraction | but it is only used during the initial scan at bootstrap time | When you are not using the repository. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191887#4191887 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191887

15 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2008