March 2008 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Maven and Eclipse (Transitive) Dependencies

by adrian＠jboss.org

On a related issue, we could perhaps look at making the jbossxb dependency of the kernel project "optional". It isn't a requirement to use xml parsing to deploy beans in the Microcontainer. ;-) Similarly, the metatype/managed projects could have an optional dependency on jboss-reflect, because it is only if you are using the factories/builders that you need the refection support. You can just construct the types/values/managed objects by hand if you want. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135063#4135063 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135063

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Maven and Eclipse (Transitive) Dependencies

by adrian＠jboss.org

EXPORTED DEPENDENCIES I've been through all the projects and fixed up all the dependncies such that we are not exporting stupid things during the compile. NOTE: Some of these really need fixing in the original project. i.e. making them optional Others are because the projects are using older versions Examples are common-core | <dependency> | <groupId>org.jboss</groupId> | <artifactId>jboss-common-core</artifactId> | <version>2.2.3.GA</version> | <exclusions> | <exclusion> | <groupId>jboss</groupId> | <artifactId>jboss-common-logging-spi</artifactId> | </exclusion> | <exclusion> | <groupId>apache-httpclient</groupId> | <artifactId>commons-httpclient</artifactId> | </exclusion> | <exclusion> | <groupId>apache-slide</groupId> | <artifactId>webdavlib</artifactId> | </exclusion> | <exclusion> | <groupId>apache-xerces</groupId> | <artifactId>xml-apis</artifactId> | </exclusion> | </exclusions> | </dependency> | jboss-test - also made optional: | <dependency> | <groupId>org.jboss</groupId> | <artifactId>jboss-test</artifactId> | <optional>true</optional> | <exclusions> | <exclusion> | <groupId>jboss</groupId> | <artifactId>jboss-common-core</artifactId> | </exclusion> | <exclusion> | <groupId>jboss</groupId> | <artifactId>jboss-common-logging-spi</artifactId> | </exclusion> | <exclusion> | <groupId>jboss</groupId> | <artifactId>jboss-common-logging-log4j</artifactId> | </exclusion> | <exclusion> | <groupId>ant</groupId> | <artifactId>ant</artifactId> | </exclusion> | <exclusion> | <groupId>ant</groupId> | <artifactId>ant-junit</artifactId> | </exclusion> | <exclusion> | <groupId>log4j</groupId> | <artifactId>log4j</artifactId> | </exclusion> | </exclusions> | </dependency> | aop | <dependency> | <groupId>org.jboss.aop</groupId> | <artifactId>jboss-aop</artifactId> | <exclusions> | <exclusion> | <groupId>ant</groupId> | <artifactId>ant</artifactId> | </exclusion> | <exclusion> | <groupId>apache-xerces</groupId> | <artifactId>xml-apis</artifactId> | </exclusion> | <exclusion> | <groupId>javassist</groupId> | <artifactId>javassist</artifactId> | </exclusion> | <exclusion> | <groupId>org.jboss</groupId> | <artifactId>jboss-common-core</artifactId> | </exclusion> | <exclusion> | <groupId>jboss</groupId> | <artifactId>jboss-common-logging-spi</artifactId> | </exclusion> | <exclusion> | <groupId>jboss</groupId> | <artifactId>jboss-common-logging-log4j</artifactId> | </exclusion> | <exclusion> | <groupId>org.jboss.microcontainer</groupId> | <artifactId>jboss-container</artifactId> | </exclusion> | <exclusion> | <groupId>org.jboss.microcontainer</groupId> | <artifactId>jboss-dependency</artifactId> | </exclusion> | </exclusions> | </dependency> | TODO: I've done this for the test compilation. I'm still seeing things like xerces-2.7.1 leeking in via jboss-test? in some places instead of 2.9.1 defined by JBossXB (see below). TRANSITIVE DEPENDENCIES Additionally I've allowed more transitive dependencies. i.e. I don't put common-core commons-logging in every project, I just let it transitively depend on an earlier project I've done the same thing for eclipse's .classpath files by making earlier projects use export="true" so it reduces the number of places to make a version change. EXTERNAL TRANSITIVE DEPDNENCIES Finally, in some cases I allow external projects to define the version. This makes sense in limited cases where that project is the core user of that artificat. e.g. I just let jbossxb define the xerces-impl, stax, jaxb versions to use e.g.2. I let aop define trove and qdox (I think qdox should be optional in aop?) We could also do some others? e.g. jboss-common-core defines common-jboss-logging-spi? e.g.2. jboss-test defines junit? In other cases it is more difficult. e.g. jboss-common-core and javassist are entering as dependencies from multiple paths so we have to explicitly define them multiple times at the entry points to get a consistent version Taking jboss-common-core as the example, it enters in our depdendency tree by a number of roots (which get excluded) and in practice we have to define it mulitple times in dependency, classloader, deployers-core-spi View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135061#4135061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135061

18 years, 1 month

1
0
0 / 0

[Design of EJB 3.0] - Re: What Versions of AS5 Will EJB3 Plugin Support?

by ALRubinger

None of this is related to the topic. "bdecoste" wrote : The "magical plugin" is a stopgap until we are thirdparty jars like everything else. ...and we are now. :) But the Plugin may also be used for EJB3 upgrades. "anil.saldhana(a)jboss.com" wrote : Nobody is stopping you from making the ejb3 core code coming into AS as thirdparty. As was the subject of about a month of AS Status calls, there were a series of barriers preventing this. Bottom line is you do not have to run the Plugin now, just build AS per usual. "anil.saldhana(a)jboss.com" wrote : What I do not understand is why should the interceptors (which as AS integration code) sit in the externalized project? Like Adrian said, interceptors etc are integration code and should be in AS, tomcat or any other container workspace. Please stop hijacking my Thread. "anil.saldhana(a)jboss.com" wrote : Additionally, the ejb3 tests that require AS, should be in the AS workspace. The external project that houses the core ejb3 code should just test ejb3 code with junit/JBossTest. Please stop hijacking my Thread. Dude, at some point we have to stop refactoring and actually release a compliant implementation. I'm not disagreeing with your points, big picture, big picture. We can always move tests around later. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135044#4135044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135044

18 years, 1 month

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Duplicate mbean removal

by ron.sigal＠jboss.com

"snasto" wrote : I get the same error when shutting down | jboss4.3 | | "org.jboss.jms.wireformat.JMSWireFormat is not registered" | Is any fix for it available? That's not related to Remoting or the issue in this thread. Try the JBoss Messaging forum (http://www.jboss.com/index.html?module=bb&op=viewforum&f=238). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135042#4135042 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135042

18 years, 1 month

1
0
0 / 0

[Design of EJB 3.0] - Re: What Versions of AS5 Will EJB3 Plugin Support?

by anil.saldhana＠jboss.com

"bdecoste" wrote : The "magical plugin" is a stopgap until we are thirdparty jars like everything else. Nobody is stopping you from making the ejb3 core code coming into AS as thirdparty. What I do not understand is why should the interceptors (which as AS integration code) sit in the externalized project? Like Adrian said, interceptors etc are integration code and should be in AS, tomcat or any other container workspace. Additionally, the ejb3 tests that require AS, should be in the AS workspace. The external project that houses the core ejb3 code should just test ejb3 code with junit/JBossTest. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135039#4135039 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135039

18 years, 1 month

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: PortUtil - Hits Max Will Always Hand Out 65535

by ron.sigal＠jboss.com

Good catch. Thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135038#4135038 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135038

18 years, 1 month

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: PortUtil - Hits Max Will Always Hand Out 65535

by jcreynol

Thanks once again. I do see that this shows as timeout in the jmx-console for the Connector. Looks like the .xml and the docs need to be updated. http://labs.jboss.com/jbossremoting/docs/guide/ch05.html#d0e2491 Note that all the server side socket invoker configurations will be set to their default values in this case. Also, it is important to add CDATA to any locator uri that contains more than one parameter. | | The other way to configure the Connector and its server invoker in greater detail is to provide an invoker sub-element within the config element of the Configuration attribute. The only attribute of invoker element is transport, which will specify which transport type to use (e.g.. socket, rmi, http, or multiplex). All the sub-elements of the invoker element will be attribute elements with a name attribute specifying the configuration property name and then the value. An isParam attribute can also be added to indicate that the attribute should be added to the locator uri, in the case the attribute needs to be used by the client. An example using this form of configuration is as follows: | | | <mbean code="org.jboss.remoting.transport.Connector" | name="jboss.remoting:service=Connector,transport=Socket" | display-name="Socket transport Connector"> | | <attribute name="Configuration"> | <config> | | <invoker transport="socket"> | <attribute name="numAcceptThreads">1</attribute> | <attribute name="maxPoolSize">303</attribute> | <attribute name="clientMaxPoolSize" isParam="true">304</attribute> | <attribute name="socketTimeout">60000</attribute> | <attribute name="serverBindAddress">192.168.0.82</attribute> | <attribute name="serverBindPort">6666</attribute> | <attribute name="clientConnectAddress">216.23.33.2</attribute> | <attribute name="clientConnectPort">7777</attribute> | <attribute name="enableTcpNoDelay" isParam="true">false</attribute> | <attribute name="backlog">200</attribute> | </invoker> | | <handlers> | <handler subsystem="mock"> | org.jboss.remoting.transport.mock.MockServerInvocationHandler | </handler> | </handlers> | </config> | </attribute> | | </mbean> | [/url][url] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135036#4135036 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135036

18 years, 1 month

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: PortUtil - Hits Max Will Always Hand Out 65535

by ron.sigal＠jboss.com

Hmmm. Actually, that's an oversight in jboss-service.xml, since "socketTimeout" hasn't been used for quite a while. The current parameter is "timeout", so setting "socketTimeout" wouldn't have any effect. The default values are 60000 on the server and 1800000 on the client. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135035#4135035 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135035

18 years, 1 month

1
0
0 / 0

[Design of EJB 3.0] - Re: What Versions of AS5 Will EJB3 Plugin Support?

by bdecoste

The "magical plugin" is a stopgap until we are thirdparty jars like everything else. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135034#4135034 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135034

18 years, 1 month

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: PortUtil - Hits Max Will Always Hand Out 65535

by jcreynol

Got it. Need to step through that a little slower. Thanks for the reply. Before I post another thread, I see that the docs say Connector has a default "socketTimeout" of 60000, but the default jboss-service.xml -- at least the one that was packaged with the 4.2.0 and 4.2.2 that I have, has this set at 600000. Beginning to think that's my issue and going to try a 60000 setting to see if that cleans things up a bit and more quickly frees up the WorkerThreads for re-use. http://labs.jboss.com/jbossremoting/docs/guide/ch05.html#d0e2491 493 <attribute name="Configuration"> | 494  | 495  | 496 <config> | 497  | 498 <invoker transport="socket"> | 499 <attribute name="dataType" isParam="true">invocation</attribute> | 500 <attribute name="marshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationMarshaller</attribute> | 501 <attribute name="unmarshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationUnMarshaller</attribute> | 502  | 503  | 504  | 505  | 506  | 507  | 508 <attribute name="socketTimeout" isParam="true">600000</attribute> | Should a Jira issue be created to modify the socketTimeout in jboss-service.xml that ships in the default distribution? (or maybe the docs need to change?) Thanks again for the speedy reply! -John View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135033#4135033 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135033

18 years, 1 month

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 March 2008