[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
[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
[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
[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 <!-- Using the following <invoker> element instead of the InvokerLocator above because specific attributes needed. -->
| 495 <!-- If wanted to use any of the parameters below, can just add them as parameters to the url above if wanted use the InvokerLocator attribute. -->
| 496 <config>
| 497 <!-- Other than transport type and handler, none of these configurations are required (will just use defaults). -->
| 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 <!-- This will be port on which the marshall loader port runs on. -->
| 503 <!-- <attribute name="loaderport" isParam="true">4447</attribute> -->
| 504 <!-- The following are specific to socket invoker -->
| 505 <!-- <attribute name="numAcceptThreads">1</attribute>-->
| 506 <!-- <attribute name="maxPoolSize">303</attribute>-->
| 507 <!-- <attribute name="clientMaxPoolSize" isParam="true">304</attribute>-->
| 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