January 2007 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: bean/mbean integration issue

by alesj

"adrian(a)jboss.org" wrote : | To what? Again this should probably be a seperate interface that can be | optionally implemented. | | That a context has an associated classloader is true for JMX | and sort of true for POJO (there is no first class support like the MBeanServer methods) | But is this really true of all contexts of a state machine? | So we should split DispatchContext into simple get/set interface and 'advanced' interface with invoke, target, classloader. Since how else would you get the parameters and signatures? | protected Object invoke(KernelConfigurator configurator, DispatchContext context, String name, List<ParameterMetaData> params) throws Throwable | { | String[] signature; | Object[] parameters; | if (params == null || params.isEmpty()) | { | signature = new String[0]; | parameters = new Object[0]; | } | else | { | int size = params.size(); | signature = Configurator.getParameterTypes(log.isTraceEnabled(), params); | Object target = context.getTarget(); | // TODO - is this ok for non-POJO targets? | if (target != null) | { | MethodInfo methodInfo = Configurator.findMethodInfo(configurator.getClassInfo(target.getClass()), name, signature); | parameters = Configurator.getParameters(log.isTraceEnabled(), context.getClassLoader(), methodInfo.getParameterTypes(), params); | // add some more info, if not yet set | for(int j = 0; j < size; j++) | { | if (signature[j] == null) | { | signature[j] = methodInfo.getParameterTypes()[j].getName(); | } | } | } | else | { | parameters = new Object[size]; | ClassLoader classLoader = context.getClassLoader(); | for (int i = 0; i < size; i++) | { | ParameterMetaData pmd = params.get(i); | TypeInfo typeInfo = null; | if (signature[j] != null) | { | typeInfo = configurator.getClassInfo(signature[j], classLoader); | } | // typeInfo might be null, but we can still get value in some cases | parameters[j] = pmd.getValue().getValue(typeInfo, classLoader); | } | | } | } | return context.invoke(name, parameters, signature); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002911#4002911 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002911

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Why SingletonSchemaResolverFactory?

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : Yes, obviously it can't read minds. | | Also without the MC (Spring) xsd in the bootstrap/singleton, you couldn't use | MC (Spring) xml to define this POJO either. :-) Well actually you could if you know the system location of the xsd. But that isn't very nice. Which is better, having to know the schema that is going to be used and its location | <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | xsi:schemaLocation="urn:jboss:bean-deployer bean-deployer_1_0.xsd" | xmlns="urn:jboss:bean-deployer"> | or just specifying the namespace? | <deployment xmlns="urn:jboss:bean-deployer"> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002908#4002908 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002908

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Running with the full featured profile service

by charles.crouch＠jboss.com

"scott.stark(a)jboss.org" wrote : | Ok, I was lying. A previous simple deployment creation was working, but applying changes to the template properties as is currently done in the test is not. This should be working by tonight's checkin. | I'm watching the rss feeds from fisheye for checkin's and haven't seen anything. However these are definitely behind real time so I was wondering if this checkin happened? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002907#4002907 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002907

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Why SingletonSchemaResolverFactory?

by adrian＠jboss.org

Yes, obviously it can't read minds. Also without the MC (Spring) xsd in the bootstrap/singleton, you couldn't use MC (Spring) xml to define this POJO either. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002904#4002904 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002904

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: bean/mbean integration issue

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | But, that doesn't mean that the dependency project can't define optional | interfaces to allow contexts to provide add-on behaviour that | cross cuts the different implementations. I would also put these optional interfaces in different packages to signify that they are not a part of the main api. e.g. rather than org.jboss.dependency.spi.DispatchContext something like org.jboss.depedendcy.spi.dispatch.DispatchContext As you can probably tell, I'm a big fan of keeping packges small and to the point! ;-) This sort of thing might look impression, but it makes it difficult to see the wood for the trees. :-) http://java.sun.com/javase/6/docs/api/javax/swing/package-summary.html I'd have split the frames, widgets, layouts, etc. into different packages View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002903#4002903 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002903

19 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: JMS Example in 3.2 Beta

by jeffdelong

Actually this looks more like a usage example - i.e., start a process vis tha command listener. I think it would be good to have such an example. This one could probably be fixed up to work. By the way, in looking at CommandListenerBean, it looks for a jobId, which it does not appear to use except to log. What should a client starting a process via the command listener set the jobId to be (since it not really a Job)? Set it to zero? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002900#4002900 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002900

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: bean/mbean integration issue

by adrian＠jboss.org

More concretely, for the case in hand - invoking a method on another context during the install phase... The code should be something like: | if (context instanceof DispatchContext) | { | DispatchContext dc = (DispatchContext) context; | dc.dispatch(...); | } | else | { | throw new IllegalArgumentException("Cannot install, context " + context + " does not implement DispatchContext"); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002896#4002896 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002896

19 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: JMS Example in 3.2 Beta

by tom.baeyens＠jboss.com

i think that originated from an initial attempt to implement the jms based message service that someoen contributed. because i didn't want to throw it away, i moved it to the examples. i don't think we need it any more can be removed, i think. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002893#4002893 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002893

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: bean/mbean integration issue

by adrian＠jboss.org

"alesj" wrote : | I did make it to extend ControllerContext. I need the target and I thought I needed name. Should I make it plain 'standalone'? | It should be a seperate optional interface that a context can implement. Not all contexts will have/need a notion of "dispatch". anonymous wrote : | I also added getClassLoader() method - to help me with getting the param TypeInfos. To what? Again this should probably be a seperate interface that can be optionally implemented. That a context has an associated classloader is true for JMX and sort of true for POJO (there is no first class support like the MBeanServer methods) but is this really true of all contexts of a state machine? Remember the dependency project is intended to be just a model of state transitions governed by their dependencies. The other part, i.e. what those transitions means and additional state/methods is a property of the implementation projects. But, that doesn't mean that the dependency project can't define optional interfaces to allow contexts to provide add-on behaviour that cross cuts the different implementations. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002891#4002891 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002891

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Why SingletonSchemaResolverFactory?

by alesj

"adrian(a)jboss.org" wrote : There is an MBean/POJO that can be deployed to add schemas at runtime. | | | <bean name="Schemas" class="org.jboss.xb.binding.sunday.unmarshalling.SchemaResolverConfig"> | | ... | | And this beans should be installed before any other with new schema usage. Meaning that the order matters - since those beans cannot depend on this one. Right? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002889#4002889 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002889

19 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2007