Apart from the ones listed in your post, while trying to get the EJB injection working (through -launcher org.jboss.ejb3.client.ClientLauncher) in application client https://www.jboss.org/community/docs/DOC-12835, i also had to add:
%JBOSS_HOME%\client\jboss-metadata.jar
%JBOSS_HOME%\lib\jboss-kernel.jar
%JBOSS_HOME%\lib\jboss-xml-binding.jar
%JBOSS_HOME%\lib\jboss-vfs.jar
%JBOSS_HOME%\server\default\lib\jboss-ejb3-core.jar
I had to add the %JBOSS_HOME%\server\default\lib\jboss-ejb3-core.jar because the %JBOSS_HOME%\client\jboss-ejb3-core-client.jar does not contain one of the required classes present in jboss-ejb3-core.jar.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183065#4183065
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183065
We also need some core integration tests that test the new browsing implementation.
This is a general thing when writing new stuff on core - we need integration tests. As I mentioned before don't worry too much about the easymock tests, they're not so important.
For browsing I would expect to see:
Browsing with and without selectors.
Verifying messages don't get acknowledged
Browsing with multiple browsers on same queue
Verifying calling acknowledge on message does nothing
etc
Replication with browsing is also currently broke, although this will be hard to get it working with the copying technique - we'll have to wait for the iterator for that.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183059#4183059
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183059
There were a few more issues too:
1) The copy queue was being created using the createQueue method which would also bind it in the post office. This is unnecessary - all we want is a simple in memory copy we can browse
2) The queueCopyLock was unnecessary - the list() method on Queue is already synchronized.
3) New references were being created before adding them to the copy queue. Since the browser queue refs would never get acknowledged, this would prevent the messages from ever getting deleted from the journal.
I have fixed the code and committed.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183042#4183042
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183042
Looking at your latest commit, I notice you added a method on the public client session api "createQueueCopy" - why is this necessary?
Whilst, as a temporary measure the queue needs to be copied before browsing, there is no need for this to be exposed on the client or the wireformat, this should just be an internal implementation detail, when creating the browser on the server.
I'm a bit baffled as to why you chose to do it this way.......
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183041#4183041
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183041
Thinking more about this, the conflict can arise even when there are 2 beans with the same classname (but different package names) in the same jar.
Ex:
MyApp.ear/Single.jar
package org.myapp.business;
|
| @Stateless
| public class ManagerBean implements org.myapp.business.Manager {
|
| }
package org.myapp.persistence;
|
| @Stateless
| public class ManagerBean implements org.myapp.persistence.Manager {
|
| }
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183030#4183030
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183030