Somewhat related, looking into https://svn.jboss.org/repos/repository.jboss.org/maven2/org/jboss/jboss-c...
a) I can see version 2.2.3.GA missing. Given this one was used by other components, I conclude the maven-metadata.xml is not necessary?
b) Anyone knows if ordering is important?
c) What's the meaning of v2.0.5.GA as it is recorded below?
After a quick search, I didn't much about the maven-metadata schema.
| <?xml version="1.0" encoding="UTF-8" ?>
Another problem I noticed is the moment you are doing the 'mvn release:perform' you need to have checked all the versions of a component, in-order to get access to the maven-metadata.xml, so the new version is correctly added. That means a lot of garbage in your local filesystem, just to do a simple release.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140074#4140074
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140074
anonymous wrote : You ignore the fact that JSF knowledge is much wider spread. Which means that buiding the site in JSF makes it easer for us to deliver JSF components which will be an interesting asset for our project. Also JSF related expertise is easier to find/get/manage.
I absolutely agree with that statement! I see JSF Knowledge growing everywhere, and it makes sense, it is a Java EE 5 standard! By the way, JSF is a full day in the JBoss and EJB 3 Training, so it should be a direction JBoss is going...
And the approach started with the current console (providing facelets for reusable components) is perfectly the right one I would say.
And currently there is some effort going on to integrate JSF applications into portals as portlets (again standards everywhere!), so I think this will make it easy for customers to leverage the console also as starting point for own web guis....
Since EJB3 seems to be seen as too limiting, I would vote for POJO + JPA. In the implementation, this can be also annotated to be a EJB3 app if the container supports it (at least it works in my mind at the moment ;-)).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140067#4140067
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140067
"jmorgan" wrote : Any suggestions on how to marshall the FileInputStream or how that'd work?
This is not possible in the current architecture as FileInputStreams are not serializable and will therefore fail as soon as the message needs to be marshalled.
At present the only solutions are to pass the contents through an out of band mechanism (such as including the filename or storing in a database) or to split up the content into small messages at the gateway.
Transparent handling of streams is on the roadmap for a future release.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140031#4140031
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140031
"bstansberry(a)jboss.com" wrote : As part of my recent adventures in testsuite housecleaning, I saw that the testsuite jrmp-invoker target isn't executed during a testsuite run. The target runs a set of EJB2 tests with the JRMPInvoker replacing UnifiedInvoker.
| Any particular reason those aren't executed? If yes, any other good coverage of JRMPInvoker in the testsuite? If no, can we chuck the JRMPInvoker from AS 5 and require use of UnifiedInvoker? :-)
| As part of the testsuite cleanup, I got the jrmp-invoker target to run properly so if we want to keep JRMPInvoker we can add the target to the regular testsuite run.
| Further to all of the above, there is no "pooled-invoker" target that performs the same tests with the PooledInvoker. Same questions re: other coverage or dropping PooledInvoker apply.
If we delete the JRMPInvoker, how does JBoss4 talk to JBoss5 and vice versa
(other than using Corba? :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140022#4140022
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140022
"anil.saldhana(a)jboss.com" wrote : Your tests should just be setting the principal/cred. Why are you trying to get the callerPrincipal from SecurityAssociation? What happened to ejbcontext.getCallerPrincipal? When will the spaghetti ejb3 layer look edible? :)
As soon as you stop mucking in ejb3-core and create a clean separation in ejb3-security. EJBContext.getCallerPrincipal() should delegate to the security component (either directly or via plugin).
The only question is whether it is possible to test ejb3-security stand alone. (It should only be a question of how.)
"anil.saldhana(a)jboss.com" wrote : Regarding getting the latest principal on the securitycontext, the api that you quote looks good. But I still am at a loss as to why you are trying to retrieve the principal/caller principal in the tests. Please point me to the tests that are trying to do this. :)
I would rather see:
Hashtable<?, ?> environment = new Hashtable<?, ?>();
| environment.put(InitialContext.SECURITY_PRINCIPAL, "me");
| environment.put(InitialContext.SECURITY_CREDENTIALS, "creds"); // TODO: String?
| InitialContext ctx = new InitialContext(environment);
but that is a nice to have.
As to the 'why' in some tests, don't bother. As long as the test is valid it must work!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139996#4139996
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139996