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

[Design of POJO Server] - Re: Bean declarations only in jboss.xml

by bstansberry＠jboss.com

"wolfc" wrote : It should already be there. Because if it's an EJB3 descriptor merge will be called with mustOverride = false. (JBossMetaData#705@67155) I looked at what the "mustOverride" param does in JBossEnterpriseBeansMetaData and it doesn't control what happens when beans are missing in the spec metadata. It just gets passed in to JBossEnterpriseBeanMetaData.merge for each bean that exists in the spec metadata. JIRA for this is http://jira.jboss.com/jira/browse/JBAS-5018 . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108701#4108701 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108701

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: New persistence unit deployers

by wolfc

"scott.stark(a)jboss.org" wrote : Deployment scoping should be determined by the class loader import/export policy under the new class loader. What is this comment about? | // FIXME: if in EAR then unscoped else scoped | | An ear lib is not identified specially other than a deployment unit with an org.jboss.metadata.ear.spec.Ear5xMetaData attachment(type will be EarMetaData in terms of getting the attachment) with a libraryDirectory for which a VirtualFile exists. | This is about Persistence Unit scoping (JPA 6.2.2). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108700#4108700 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108700

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Client-side clustering classes in the aspects module

by bstansberry＠jboss.com

There are 3 classes in the aspects module org.jboss.aspects.remoting package that I'm thinking of moving over to the ha-client project for inclusion in the jboss-ha-client.jar. ClusterConstants, ClusterChooserInterceptor, FamilyWrapper. These are client-side clustering classes, and encapsulating client-side clustering classes is the purpose of jboss-ha-client.jar. Only downside I see is they add a dependency on Remoting to ha-client. Not IMHO a big problem if remoting is what we are using long term for client-server communications. An alternative is to create some sort of general "remoting-aspects" project for org.jboss.aspects.remoting classes. But then it would need to depend on jboss-ha-client.jar. I'd prefer to see these client-side clustering classes in ha-client. Thoughts? I'm asking now because I want to move jboss-ha-client.jar off a snapshot, so would prefer to deal with this before cutting a beta. Tangential topic: if we don't go the "remoting-aspects" route, there are a few classes in org.jboss.aspects.remoting that would go in the ha-server project when I get to that; for inclusion in a jboss-ha-server-api.jar. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108693#4108693 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108693

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Proper definition of embedded jboss

by max.andersen＠jboss.com

How to install JBoss Tools (nightly builds are best until we GA): http://wiki.jboss.org/wiki/Wiki.jsp?page=InstallingJBossToolsNightlyBuilds How to use TestNG setup in jboss tools (requires to install the testng plugin from testng.org): http://download.jboss.org/jbosstools/nightly-docs/seam/en/html_single/ind... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108674#4108674 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108674

16 years, 5 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

by bstansberry＠jboss.com

Yes. In the AS cluster module, as we can't leak the legacy Invocation class to the ha-client project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108671#4108671 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108671

16 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Translation update

by lucboudreau

It seems I can't build the release with the target 'release-full'. I go to the build project and launch 'ant release-full' but then I get an error : | BUILD FAILED | D:\MesDocuments\workspaces\jboss-portal\tools\etc\buildfragments\buildmagic.ent: | 259: The following error occurred while executing this line: | java.lang.NoClassDefFoundError: org/apache/commons/collections/Predicate | How can I fix this ? (BTW, the library is in the thirdparty dir. The 'release' target works fine, but not the 'release-full'). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108660#4108660 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108660

16 years, 5 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Service discovery; clustering; load-balancing; etc.

by david.lloyd＠jboss.com

I've come up with a basic client API for service discovery and utilization. Basically the idea is you create a ServiceLocator (which identifies what service you want to talk to), and you apply that to a Session (if you want to talk to a specific Endpoint) or to your local Endpoint (if you want your local Endpoint to decide what other Endpoint(s) you want to talk to). Either way you get back a ContextSource instance, which can be used to mass-produce Contexts that communicate with that service. Since the acquisition of Contexts is abstracted behind this simple interface, an implementation may choose to rotate between multiple remote Endpoints when acquiring Context instances, or apply a load-balancing policy, etc. In order to facilitate the various use cases for this, the ServiceLocator class has a series of properties that can be set to allow a ServiceLocator to match one or more candidates for a load-balancing arrangement. The properties are as follows: * serviceType - the actual kind of service you're looking for. All service instances with a given serviceType would have consistent request and reply object types, so that a piece of code that talks to that service type can be reused to talk to any other implementation of that same type. * serviceGroupName - the name of the group providing this service. A service might be available as two distinct groups - for example, a production group and a testing group. A "*" would mean match any service group. * serviceGroupMemberName - the name of the individual member within a group. A service might be deployed in more than once place for a group; this would allow you to select a specific node or member of the group. A "*" (which would be the default value) would mean match any service group member. This arrangement allows us to do a few things: * Deploy multiple instances of a service of the same type into a single Endpoint - an example application would be a system with multiple test environments. * Correlate services running on multiple Endpoints - for example, a cluster or load-balancing situation where there are two nodes that access a common database. Please give me your thoughts and comments. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108656#4108656 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108656

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Proper definition of embedded jboss

by scott.stark＠jboss.org

Point us to a page that describes how to set this up and run this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108647#4108647 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108647

16 years, 5 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: DeploymentInfo/Template MCF

by scott.stark＠jboss.org

There is no specific admin client, we just have a managment api which we support, similar to how jmx was the api in the past. The api is the ProfileService/ManagedObject apis. We will map the ManagedObjects onto jmx, but this will how show a portion of the management capability. You won't be able to create datasource deployments this way. The testcase is the org.jboss.test.profileservice.test.ProfileServiceUnitTestCase. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108645#4108645 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108645

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Docs/Wiki updates for beta3, JBAS-5016

by scott.stark＠jboss.org

http://jira.jboss.com/jira/browse/JBAS-5016 This thread is for identifying content that need updating for the changes in beta3: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5DeploymentFramework http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMCProfileServiceBootstrap http://wiki.jboss.org/wiki/Wiki.jsp?page=ProfileService http://wiki.jboss.org/wiki/Wiki.jsp?page=ManagedObjects http://labs.jboss.com/jbossas/architecture/ http://labs.jboss.com/projects/jbossas/source/ - currently a 404 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108644#4108644 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108644

16 years, 5 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 2007