May 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Deployment Framework] - Re: JSR 250 injection on VDF

by wolfc

https://jira.jboss.org/jira/browse/EJBTHREE-1828 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230436#4230436 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230436

16 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Alternative registry implementations

by bernd.koecke

Hi Kev, I'm working on such a small registry at the moment. I have the following reasons for doing this: The combination of scout/juddi is slow. This slows down the shutdown process of JBossAS. And this let our scripts kill the JBoss-Process. But then some of the services were not removed from the registry and at the next startup the ESB doesn't remove them, too. After some time you have a lot of dead EPRs in the registry, which again slows down the Insertion and Removement of EPRs. And it slows down calling a service, too. Newer versions of the ESB doesn't store any services in the registry. I think it is because only non gateway listeners were stored and the new default is an InVM-EPR which is not callable from outside the VM. But we used the registry to call a service from an external client. I learned that this was a bad idea, because we used ESB-Classes to send an ESB-Aware message to a non gateway EPR. But it is a nice feature to move a service from one cluster to another and the clients can call it without any changes, as long as the registry knows the new location. This is usefull for EJB- and WS-Calls, too. You must configure a lot when you want to call a service through the registry. You have to set a system property, put a lot of JARs on the classpath only to find the location of a service. During this process a lot of XML-Data is moved. But the only dynamic thing in calling an JMS-EPR is the JNDI-Lookup-URL of the cluster nodes. So i would like to have a very easy interface for finding an EPR. It should be very easy to call it from Java and non Java languages. We would like to use version numbers. For this we added the version to the service name to make the name unique. Lets say we use version x.y.z. We can't ask the ServiceInvoker for the newest version x.y of a service. To meet these issues I'm building the following system: The system is build out of some (minimum is 4) JMX-Managed-Beans. The data is stored into two SQL-Tables, but this is hidden by a persister bean (first MBean). For every deployable artifact a special MBean (one additional MBean, will be more in future) catches the JMX-Notification at deploy and undeploy time. These special MBeans will register itself to a Master (second MBean) and use the persister to store the information for calling a deployment. And there is an additonal MBean for handling version numbers. The first version will have a MBean to handle data for calling ESB-Servcies with a JMS-EPR. The internal data structure will have services, these are running on a cluster and this cluster is build out of several nodes. All of these items have properties and are combined by internal keys (Strings). When a node comes up he can check if the currently stored information about himself is valid. The minimal information is the service name. You can set the EPR-Type, e.g. JMS and the version or part of a version to narrow down the EPR you are interested in. To make the interface as easy as possible, I want to use RESTeasy. All this is packed into a SAR an can be deployed on any of our JBoss-Nodes. All these nodes use the same database. You only have to know one node to find services which may run on another cluster. With REST you can encode all information in the URL and get back only a line with hostname and port in a csv list. By setting HTTP-Headers you can switch easily to a JSON-, XML- or HTML-Response. This can be used by everybody without using SOAP-Stacks, JAXR etc. But it is very technical. This is no replacement for a repository. Sorry for the long posting. I don't know if this is what you expected, but I hope it helps. Bernd View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230425#4230425 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230425

16 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Proposal: Groovy integration in jBPM-4

by anders.norgaard

Have you considered integrating a groovy web-console like Guillaume Laforges: http://groovyconsole.appspot.com/ http://github.com/glaforge/groovywebconsole/tree/master or my attempt: http://code.google.com/p/ajaxgroovyshell/ ? Best Anders View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230418#4230418 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230418

16 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JmsConnectionPool: Allowing control over the number of S

by tfennelly

OK... I'm going with option #1 for now. I'm happy enough with that too. So the current JmsConnectionPool maintains a relationship between a single connection and multiple sessions. So (termed loosely), what I think we need is a pool of JmsConnectionPools (as it's currently badly called :) ). OK... we can't do it exactly like that, so what I was thinking was to push the connection:sessions management code down into a new class called "JmsSessionPool". Each JmsSessionPool will be responsible for maintaining the relationship between a single connection and its set of sessions (just like JmsConnectionPool is doing today). It would not be responsible for creating the connection (unlike todays JmsConnectionPool), but would be responsible for creating the sessions off a connection, cleaning them up the sessions etc. Then, the roll of the JmsConnectionPool would change slightly in that it's now responsible for the management of a pool of JmsSessionPools. It would be responsible for creating the Connection instances and the JmsSessionPool associated with each instance. When asked for a session, JmsConnectionPool would need to locate a JmsSessionPool that has a free session. If non are available, it will need to have the logic that decides whether or not a new JmsSessionPool needs to be created, or otherwise go into that "pool empty" loop. Am I making sense? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230407#4230407 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230407

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 default configuration, what should it be

by ataylor

anonymous wrote : Not sure about that: I think AS must not have default resources (CF, destinations). We changed the javaee examples so that they also create the resources they need. Either way we should be consistent between both stand alone and AS. 1.4 does have default resources, a cf, dlq and expiry queue. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230403#4230403 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230403

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: DESCRIBE phase - Dependency builders for MC Beans

by jaikiran

"alesj" wrote : | As you can see, this needs an explicit flag in order to check the MD, | hence it should be rarely true --> checked. I missed that :) I'll give these changes a try today and let you know how it goes. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230398#4230398 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230398

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: DESCRIBE phase - Dependency builders for MC Beans

by alesj

"jaikiran" wrote : if (factory.checkMetaDataForBuilderInstance()) | | { | | // still allow for more configurable DependencyBuilder | | dependencyBuilder = md.getMetaData(DependencyBuilder.class); | | } | | | | Do we still need to check the metadata? Just thinking whether its worth it, since it still leads to two checks. | This allows us for more configurable DB, not only no-arg constructor, but perhaps a fully configurable, singleton, ... DB. As you can see, this needs an explicit flag in order to check the MD, hence it should be rarely true --> checked. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230397#4230397 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230397

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: DESCRIBE phase - Dependency builders for MC Beans

by jaikiran

if (factory.checkMetaDataForBuilderInstance()) | { | // still allow for more configurable DependencyBuilder | dependencyBuilder = md.getMetaData(DependencyBuilder.class); | } | Do we still need to check the metadata? Just thinking whether its worth it, since it still leads to two checks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230395#4230395 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230395

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: DESCRIBE phase - Dependency builders for MC Beans

by alesj

"jaikiran" wrote : | I guess, instead of checking two things in the metadata (a DependencyBuilder and a IgnoreAOP annotation), its better to just look for a single annotation | Yes, I was just thinking about this duplicate lookup. This is what we have now: | protected DependencyBuilder getDependencyBuilder(MetaData md, Kernel kernel) throws Throwable | { | DependencyBuilder dependencyBuilder = null; | DependencyBuilderFactory factory = md.getAnnotation(DependencyBuilderFactory.class); | if (factory != null) | { | if (factory.checkMetaDataForBuilderInstance()) | { | // still allow for more configurable DependencyBuilder | dependencyBuilder = md.getMetaData(DependencyBuilder.class); | } | else | { | Class<? extends DependencyBuilder> value = factory.value(); | if (basicDependencyBuilder.getClass().equals(value)) | { | dependencyBuilder = basicDependencyBuilder; | } | else | { | dependencyBuilder = value.newInstance(); | } | } | } | | if (dependencyBuilder == null) | { | KernelConfig config = kernel.getConfig(); | dependencyBuilder = config.getDependencyBuilder(); | } | | return dependencyBuilder; | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230393#4230393 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230393

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: DESCRIBE phase - Dependency builders for MC Beans

by jaikiran

anonymous wrote : value=DescribeAction.BASIC These constants probably need to come from some place else assuming DescribeAction is an internal impl detail of the MC. But i believe, you get what i was trying to convey through that example :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230391#4230391 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230391

16 years, 11 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 May 2009