[Design of JBoss Build System] - Re: Strange dependency issue
by adrian@jboss.org
"pgier" wrote : "adrian(a)jboss.org" wrote :
| |
| | It certainly allows you to be very explict about what you want and understand
| | what your real dependencies are. :-)
| |
| | e.g. I don't care that JBossXB defines apache-xxx:1.2.3, I want to use apache-xxx:2.3.4
| | Currently I don't even know that it using it at all without some nontrivial investigation. ;-)
|
| If you define apache-xxx:2.3.4 as a direct dependency,it should be using that one.
|
| We had some problems with microcontainer in the past because the dependency's groupId changed, so maven didn't know they were the same dep, and that caused the older one to be used.
It still doesn't unless you exclude versions from transitives
which takes some effort (e.g. the -X flag to figure out where versions
are really coming from).
anonymous wrote :
| You can also use the project info report
| mvn project-info-reports:dependencies
|
| And that should show what your project is actually using.
|
Yes, that looks more complete. This also shows the container
project as undeclared in aop-mc-int which is not true.
It still doesn't give a way to verify or resolve dependencies consistently
in one place across an assembly. Running the same thing in the
microcontainer/build project showed no dependencies at all.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107877#4107877
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107877
18 years, 4 months
[Design of JCA on JBoss] - Re: Mbeans defined in a datasource descriptor should be star
by adrian@jboss.org
Guys, your completely off base. Don't raise bug reports based on
guesses and lack of knowledge, ask somebody who knows what is happening.
The bug report is just wrong, as is Anil's guess.
This question is also not an issue for the JCA Developers forum
it is a HELP request not a design topic.
Although I've left it here because of the discussion at the end my post.
ANSWER TO HELP REQUEST:
If you want to use a heuristic mbean dependency rather than a real one,
move the mbean configuration before the datasource.
JBoss deploys things in the order of the xml.
But this is still not a real dependency and will break if other dependencies cause the
ordering to change. e.g. if the MBean has other satisfied dependencies it will still
get deployed later.
REAL PROBLEM:
The real problem is that the JCA connection manager depends upon a jndi lookup
of the security domain, not an MBean.
The correct fix(es) would be to either:
1) Define it as a jndi dependency - which is possible in JBoss5, but its still a hack
2) Fix the dependency to be a real dependency - i.e. inject a SubjectFactory
into the JCA connection manager that really does depend upon the lifecycle
of the SecurityDomain.
This is not possible as far as I know using the current architecture of jboss-security.
Although we could implement an MC DependencyItem to make it possible
(like the way JNDI dependencies work).
A complication further being it will default to "other' when the domain doesn't exist
so in practice the dependency is technically always satisfied.
Solution (2) would also remove the bogus login modules from the JCA project
that should not be there. The real contract is give me a Subject, not do a
JAAS login (implementation detail).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107862#4107862
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107862
18 years, 4 months
[Design of POJO Server] - Re: Proper definition of embedded jboss
by newtonm
Hi Bill, Scott,
Having looked at the Embedded JBoss documentation in the wiki and from my current work on the JBoss Microcontainer User Guide I think that we could benefit from a change in name for the project.
Given that Embedded JBoss is all about using JBoss enterprise services and our EJB3 container in different runtime environments (by allowing them to be loaded by different classloaders) how about:
JBoss Reloaded
This carries on the tradition of naming releases after the Matrix and hints at the fact that you are 'reloading' JBoss services through different classloaders. In addition it starts with the prefix 'JBoss' and does not lend itself to being used as a noun which is helpful since Embedded JBoss is really a way of packaging up the microcontainer with some integration code so that it can be used in other runtimes. In this sense it isn't a product as such.
The JBoss Reloaded project would therefore contain distributions and docs to explain how to configure JBoss services and the EJB3 container in Tomcat, GlassFish, standalone Java SE apps, etc...
I already have a part in the JBoss Microcontainer User Guide called 'Integration' where I intend to explain how the microcontainer is used within JBoss AS. We could also add in here explanations of how to use it in Tomcat and GlassFish if necessary.
I ultimately would like to develop a single story with which to explain our technology all the way from JBoss Microcontainer through to JBoss AS. Seen in this light the JBoss Reloaded project would sit nicely in the middle, demonstrating uses of our technology that gradually become more and more integrated with different runtimes until we arrive at JBoss AS 5 which is the best of the bunch :)
what do you think?
Mark Newton
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107825#4107825
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107825
18 years, 4 months