December 2006 - jboss-dev-forums - Jboss List Archives

[Design of the JBoss EJB Container] - Re: Services in JBoss AS 5

by scott.stark＠jboss.org

You have always been able to do this by simply adding another deploy url to the scanner. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993501#3993501 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993501

19 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: jbossws deployer on JBoss AS 5

by jason.greene＠jboss.com

As of last week its split into two parts a sar and a deployer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993495#3993495 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993495

19 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Universal Business Language v2.0 Approved As An OASIS Standa

by scott.stark＠jboss.org

UBL 2.0 has been approved as an OASIS Standard. UBL defines a common XML library of business documents (purchase orders, invoices, etc.). OASIS congratulates the TC, and the community of implementers, developers and users who have brought the work successfully to culmination. http://www.oasis-open.org/archives/tc-announce/200612/msg00003.html View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993493#3993493 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993493

19 years, 3 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Configuration - normalization

by tfennelly

Hi there. Kurt Dave and I have been discusing a number of issues re the config normalisation. The only bit that we still haven't decided fully on is the question of how far do we take the normalisation of the config? One argument is to take normalisation as far as it can possible go and thereby remove all duplication of any type. This of course removes that family of error caused by duplication. It was also mentioned that it should make tooling easier. An example of this is outlined at the start of this thread where the configuration has 4 main sections - hosts, servers, buses/channels and services. The other argument is for an approach somewhere in th middle i.e. normalising away most of the duplication we have in the current config, but living with a little and not going the whole way i.e by dropping the need to have the hosts and servers blocks (see sample config below). The thinking here is that the 100% normalised config is just a bit too difficult for a human to comprehend, because you're continually referencing across sections of the config. There's no clear cut right/wrong answer to this question. Basically, we need to strick a balance between the benefits of normalisation and the need for the config to be understandable by a human. Of course, once we have tool support in this area it won't be an issue. There might also be the question of slightly different definitions of "host", "server", "bus" and "listener". | <?xml version = "1.0" encoding = "UTF-8"?> | <jbossesb xmlns="http://www.jboss.org/soa/esb/listeners/config"> | | <buses> | <jms-bus busid="server1-jms" | connection-factory="ConnectionFactory" | jndi-context-factory="org.jnp.interfaces.NamingContextFactory" | jndi-URL="localhost" /> | </buses> | <services> | <service category="Bank" name="Reconciliation" description="Bank Reconciliation Service"> | | <listeners> | <jms-listener name="Bank-JMS-Gateway" | is-gateway="true" | busidref="server1-jms" | destination-type="QUEUE" | destination-name="queue/A" | message-selector="service='Reconciliation'" | maxThreads="1" | /> | <jms-listener name="Bank-Listener" | is-gateway="false" | busidref="server1-jms" | destination-type="TOPIC" | destination-name="queue/B" | message-selector="service='Reconciliation'" | maxThreads="2" | /> | </listeners> | | <actions> | <action name="TestDefaultRouteAction" process="route" class="org.jboss.soa.esb.actions.CbrProxyAction"> | <property name="propName" value="propValue" /> | </action> | </actions> | | </service> | </services> | | </jbossesb> | The current XSD can be found here. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993492#3993492 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993492

19 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - WS-SecurityPolicy 1.2

by scott.stark＠jboss.org

anonymous wrote : | To OASIS members, Public Announce Lists: | | The OASIS Web Services Secure Exchange TC has recently approved the following | specification as a Committee Draft and approved the package for public review: | | WS-SecurityPolicy 1.2 | | The public review starts today, 12 December 2006, and ends 10 February 2007. | This is an open invitation to comment. We strongly encourage feedback from | potential users, developers and others, whether OASIS members or not, for the | sake of improving the interoperability and quality of OASIS work. Please feel | free to distribute this announcement within your organization and to other | appropriate mail lists. | | More non-normative information about the specification and the technical | committee may be found at the public home page of the TC at | http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx. Comments may | be submitted to the TC by any person through the use of the OASIS TC Comment | Facility which can be located via the button marked "Send A Comment" at the top | of that page, or directly at | http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ws-sx. | | Submitted comments (for this work as well as other works of that TC) are | publicly archived and can be viewed at | http://lists.oasis-open.org/archives/ws-sx-comment/. All comments submitted to | OASIS are subject to the OASIS Feedback License, which ensures that the feedback | you provide carries the same obligations at least as the obligations of the TC | members. | | The specification document and related files are available here: | | Editable Source: | http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/ws-securitypoli... | | PDF: | http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/ws-securitypoli... | | HTML: | http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/ws-securitypoli... | | The schema files, that are included normatively in the specification document, | are available as separate files at: | | Schema: | http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/ws-securitypoli... | | OASIS and the WS-SX TC welcome your comments. | | | --------------------------------------------------- | Mary P McRae | Manager of TC Administration, OASIS | email: mary.mcrae(a)oasis-open.org | web: www.oasis-open.org | --------------------------------------------------------------------- | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993489#3993489 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993489

19 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: jbossws deployer on JBoss AS 5

by scott.stark＠jboss.org

No reason why it should not be other than dependencies on other deployers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993486#3993486 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993486

19 years, 3 months

1
0
0 / 0

[Design of JBoss Transaction Services] - JBossTS jar names

by dimitris＠jboss.org

I'm switching JBossAS 4.2 to JBossTS JTA. The jar names would look a lot better/uniform with an extra '-'. jboss-jta.jar jboss-jta-integration.jar jboss-ts-common.jar Maybe that could be fixed in repository.jboss.com if JBossAS is the only consumer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993478#3993478 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993478

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Serialization Compatibility Tests

by manik.surtani＠jboss.com

anonymous wrote : | Let's go with 1. We really should move the org.jboss.tools classes to the test module, and have jbosscache depend on the test module. But for now, let's just get the test in place. | +1. Also, +1 to Brian's comment about a "varia" directory - I'd rather see this under tests/compat as well. Cheers, Manik View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993371#3993371 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993371

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: ClientContainer enc handling

by wolfc

Yup, except that the server environment should start at java:comp and not java:comp/env like now in the EJB3 client container. Then we can use java:comp/jboss for our own stuff. I've committed a prototype of injection in https://svn.jboss.org/repos/jbossas/projects/ejb3/trunk/injection. It is a standalone project which should be usable in the 1.4 client launcher. The client launcher will then work more or less like org.jboss.injection.test.annotated.unit.AnnotatedTestCase. With the injector setup coming from JNDI. Note/ToDo: check getHandle in Java URL factory. I think there might be a conflict there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993341#3993341 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993341

19 years, 3 months

1
0
0 / 0

[Design of JBoss Portal] - PortletInvoker interception refactoring

by julien＠jboss.com

I am willing to make a refactor of the portlet invoker interception. Today we only intercept render/action. We need to intercept all other business methods. The goal is to provide interception of all methods, for example : - security (all operations needs to be protected) - it will make the implementation of the ProducerPortletInvoker turnable into an interceptor (which is what it is actually as it implements a subset of operations and let some of them go through to the delegate). The change I intend to make are : for each PortletInvoker operation (except action/render), create a subclass of PortletInvocation that contains the method parameters. | public class GetPropertiesInvocation extends PortletInvocation | { | private PortletContext portletContext; | private Set keys; | // etc... | } | Provide a portlet invoker that detypes all operations and one that can dispatch all operations to the portlet invoker interface. I know it is very similar to what AOP does, but I don't want to use AOP for the reason that I don't want to lose type safety which can break so easily in refactorings. There should be no impact on the codebase except in portlet container and in the wiring of the different services that will need to be updated. I will most likely do that next Thursday/Friday. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993330#3993330 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993330

19 years, 3 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 December 2006