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

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Use jboss.partition.udpGroup in NamingContext

by scott.stark＠jboss.org

The Naming service related elements are in need of refactoring for better integration with the mc configuration semantics, and jboss remoting. The hajndi integration is also rather hacky. We should discuss this as part of http://jira.jboss.com/jira/browse/JBAS-3151,JBAS-3927. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991794#3991794 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991794

17 years, 6 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: JSR88 updated with a StreamingTarget implementation

by scott.stark＠jboss.org

The streaming upload handler is a new subsystem added to the unified invoker Connector configuration: | <mbean code="org.jboss.remoting.transport.Connector" | name="jboss.remoting:service=Connector,transport=socket" | display-name="Socket transport Connector"> | ... | <handlers> |  | <handler subsystem="invoker">jboss:service=invoker,type=unified</handler> |  | <handler subsystem="JSR88">org.jboss.deployment.remoting.DeployHandler</handler> | </handlers> | </config> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991787#3991787 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991787

17 years, 6 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - JSR88 updated with a StreamingTarget implementation

by scott.stark＠jboss.org

As part of the profile service crud support for deployments, I added a new StreamingTarget implementation that uses the remoting streaming capability to allow uploads via any protocol remoting supports. The default target implemention is still the JMXTarget. To select the StreamingTarget, a targetType=remote query param would be added to the | /** | * Obtain a DeploymentManager using a deployURI of the form | * http://org.jboss.deployment/jsr88?targetType=targetType | * Valid targetType values are: | * jmx - Use the JMXTarget RMIAdaptor based deployment target | * remote - Use the StreamingTarget remoting based deployment target | * @return JSR88 DeploymentManager | * @throws Exception | */ | protected DeploymentManager getDeploymentManager(String targetType) | throws Exception | { | // Get the deployment manager and the distribution targets | String mgrURI = DeploymentManagerImpl.DEPLOYER_URI+"?targetType="+targetType; | DeploymentManager manager = factory.getDeploymentManager(mgrURI, null, null); | return manager; | } | See the org.jboss.test.deployment.{JMXDeploymentTestCase,StreamingDeploymentTestCase}s in the jbossas/testsuite module for examples. Right now this is just uploading content to the DeploymentManagerService uploadDir (tmp/jsr88) and is not really integrated with the ProfileService. Adding a proper deployment repository notion to the ProfileService is next. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991784#3991784 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991784

17 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: Recent tests

by alex.loubyansky＠jboss.com

I've implemented handling of complex type with simple content that have only attributes of type xsd:ID as simple types. And created a config option for this simpleContentWithIdAsSimpleType which is true by default. But if there is a ClassMetaData associated with the type, the value of the option is ignored. I don't like the fall back approach, i.e. if the type is complex and the class resolution failed then try handling it as a simple type. Is there a real use-case where it's useful? Haven't committed yet. Still thinking. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991769#3991769 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991769

17 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Source artifacts and jbossas version

by scott.stark＠jboss.org

I added a jboss-remoting-src.zip artifact to the remoting build that should be included in the repository artifacts to simplify testing for other projects, and added jboss-remoting-src.zip artifacts to the 2.2.0.Alpha2 and 2.2.0.Alpha4. I see there are two Alphas past the current jbossas version. Is there a reason for that? Just testing an update to 2.2.0.Alpha4. I see that jbossws is not marked as being compatible with anything past 2.2.0.Alpha2. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991767#3991767 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991767

17 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Proposed new package structure

by thomas.diesler＠jboss.com

I don't care about where the code lives. If we have virtually identiacal code in trunk and branch(es) thats fine with me. This is the methodology that we use for the jaxrpc testsuite. Consolidation is my concern. If we do not consolidate the tools,metadata, raxrpc codebase to a degree where I can more or less brainlessly merge stuff, I don't see a chance (for myself) to get future releases off the ground in a timely manner. The UMDM might be in flux it is still part of the contract. The curernt issue is that we have multiple code bases that work off diffent UMDMs which is unneccessary and MUST be fixed. Lets, take this discussion off-line - this will be more productive. The aim is to decide upon a clear migration path towards a maintainable code base, which we currently do not have. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991760#3991760 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991760

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - JoinpointTest is broken

by scott.stark＠jboss.org

In checking the vfs changes by running the ContainerAllTestSuite, I see all of the org.jboss.test.joinpoint.test.JoinpointTest fail with this type of compile error: | javassist.CannotCompileException: by java.lang.IllegalAccessError: tried to access class sun/reflect/MagicAccessorImpl from class org/jboss/reflect/plugins/javassist/JavassistMethod1 | at javassist.ClassPool.toClass(ClassPool.java:904) | at javassist.ClassPool.toClass(ClassPool.java:847) | at javassist.ClassPool.toClass(ClassPool.java:805) | at javassist.CtClass.toClass(CtClass.java:1037) | at org.jboss.reflect.plugins.javassist.JavassistReflectionFactory$1.run(JavassistReflectionFactory.java:237) | at org.jboss.reflect.plugins.javassist.JavassistReflectionFactory$1.run(JavassistReflectionFactory.java:1) | at org.jboss.reflect.plugins.javassist.JavassistReflectionFactory.createMethod(JavassistReflectionFactory.java:233) | at org.jboss.reflect.plugins.javassist.JavassistMethodInfo.invoke(JavassistMethodInfo.java:150) | at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) | at org.jboss.test.joinpoint.test.JoinpointTest.testObjectMethodInvoke(JoinpointTest.java:113) | at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) | at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;J)Ljava.lang.Object;(Unknown Source) | at junit.framework.TestCase.runTest(TestCase.java:154) | at junit.framework.TestCase.runBare(TestCase.java:127) | at junit.framework.TestResult$1.protect(TestResult.java:106) | at junit.framework.TestResult.runProtected(TestResult.java:124) | at junit.framework.TestResult.run(TestResult.java:109) | at junit.framework.TestCase.run(TestCase.java:118) | at junit.framework.TestSuite.runTest(TestSuite.java:208) | at junit.framework.TestSuite.run(TestSuite.java:203) | at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) | at junit.extensions.TestSetup$1.protect(TestSetup.java:19) | at junit.framework.TestResult.runProtected(TestResult.java:124) | at junit.extensions.TestSetup.run(TestSetup.java:23) | at junit.framework.TestSuite.runTest(TestSuite.java:208) | at junit.framework.TestSuite.run(TestSuite.java:203) | at junit.framework.TestSuite.runTest(TestSuite.java:208) | Caused by: java.lang.IllegalAccessError: tried to access class sun/reflect/MagicAccessorImpl from class org/jboss/reflect/plugins/javassist/JavassistMethod1 | at java.lang.ClassLoader.defineClass(Ljava.lang.String;[BIILjava.security.ProtectionDomain;)Ljava.lang.Class;(Unknown Source) | at java.lang.ClassLoader.defineClass(Ljava.lang.String;[BII)Ljava.lang.Class;(Unknown Source) | at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) | at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;J)Ljava.lang.Object;(Unknown Source) | at javassist.ClassPool.toClass2(ClassPool.java:916) | at javassist.ClassPool.toClass(ClassPool.java:898) | at javassist.ClassPool.toClass(ClassPool.java:847) | at javassist.ClassPool.toClass(ClassPool.java:805) | at javassist.CtClass.toClass(CtClass.java:1037) | at org.jboss.reflect.plugins.javassist.JavassistReflectionFactory$1.run(JavassistReflectionFactory.java:237) | at org.jboss.reflect.plugins.javassist.JavassistReflectionFactory$1.run(JavassistReflectionFactory.java:1) | at org.jboss.reflect.plugins.javassist.JavassistReflectionFactory.createMethod(JavassistReflectionFactory.java:233) | at org.jboss.reflect.plugins.javassist.JavassistMethodInfo.invoke(JavassistMethodInfo.java:150) | at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) | at org.jboss.test.joinpoint.test.JoinpointTest.testObjectMethodInvoke(JoinpointTest.java:113) | ... | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991725#3991725 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991725

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Nested jars are broken

by scott.stark＠jboss.org

The org.jboss.test.virtual.test.FileVFSUnitTestCase.testFindResourceInFilesOnlyJar reproduces the problem. The url for jar entries with a SynthenticDirEntryHandler parent is not a jar url. I'm fixing this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991711#3991711 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991711

17 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Proposed new package structure

by jason.greene＠jboss.com

Also, isn't the purpose of the integration API to support not only multiple containers, but also multiple versions of JBossAS? I think this is the proper abstraction to use (rather than dividing our stack in the middle), and we can reduce our workload by not introducing new branches for every AS release, and instead just adding a new integration module. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991702#3991702 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991702

17 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Switching to JAX-WS 2.1

by jason.greene＠jboss.com

"heiko.braun(a)jboss.com" wrote : The latest spec and API for JAX-WS include significant changes that we need to implement. I realized it when i was looking at the MTOM impl. for JAX-WS. | | I.e. there are new Binding URI's that indicate the use of MTOM: | | | | Enable using @BindingType on the endpoint (SEI) implementation class | | | | * @BindingType(value=javax.xml.ws.SOAPBinding.SOAP11HTTP_MTOM_BINDING) will enable MTOM on the deployed endpoint for SOAP 1.1 binding | | | | | | Is there any reason to stick to the current version? I.e. with regard to CTS? These aren't new, they are part of the 2.0 spec. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991696#3991696 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991696

17 years, 6 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 December 2006