[JBoss JIRA] Created: (JBAS-3703) Update JRMPInvoker to not cast exported object to RemoteStub
by Scott M Stark (JIRA)
Update JRMPInvoker to not cast exported object to RemoteStub
------------------------------------------------------------
Key: JBAS-3703
URL: http://jira.jboss.com/jira/browse/JBAS-3703
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Remoting
Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.3 SP1
Reporter: Scott M Stark
Assigned To: Tom Elrod
Fix For: JBossAS-4.0.6.CR1
If one runs with the jdk5 java.rmi.server.ignoreStubClasses dynamic stub override to force the server to generate stubs for exported objects, the JRMPInvoker fails to start with the following exception:
[starksm@succubus bin]$ run.sh -D-Djava.rmi.server.ignoreStubClasses=true
=========================================================================
...
11:55:52,477 WARN [ServiceController] Problem starting service jboss:service=invoker,type=jrmp
java.lang.ClassCastException: $Proxy13
at org.jboss.invocation.jrmp.server.JRMPInvoker.exportCI(JRMPInvoker.java:437)
at org.jboss.invocation.jrmp.server.JRMPInvoker.startService(JRMPInvoker.java:359)
at org.jboss.invocation.jrmp.server.JRMPInvoker$1.startService(JRMPInvoker.java:136)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:274)
The reason is that the code creating the remote object is explictly casting the export result to a RemoteStub:
protected void exportCI() throws Exception
{
this.invokerStub = (RemoteStub) UnicastRemoteObject.exportObject
(this, rmiPort, clientSocketFactory, serverSocketFactory);
}
even though the public contract for this stub only requires a Serializable instance. The type of the invokerStub should just be relaxed to Serializable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (JBAS-3630) JMSTransportSupport is not portable across different JMS providers.
by Darran Lofthouse (JIRA)
JMSTransportSupport is not portable across different JMS providers.
-------------------------------------------------------------------
Key: JBAS-3630
URL: http://jira.jboss.com/jira/browse/JBAS-3630
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: JBossAS-4.0.4.GA
Reporter: Darran Lofthouse
Assigned To: Thomas Diesler
Fix For: JBossAS-4.0.6.CR1
JMSTransportSupport is not portable across different JMS providers, the queue name is retrieved using the following code: -
String fromName = null;
Destination destination = message.getJMSDestination();
if (destination instanceof Queue)
fromName = "queue/" + ((Queue)destination).getQueueName();
if (destination instanceof Topic)
fromName = "topic/" + ((Topic)destination).getTopicName();
For JBossMQ this is fine and it results in a name that matches the JNDI name of the queue, for WebSphereMQ this returns the name of the queue as configured on WebSphere not the JNDI name the queue is bound to in JBoss.
The Javadoc for Queue describes the getQueueName as not being suitable for portable clients: -
http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Queue.html
A more portable solution could be to lookup a variable in the ENC that contains the name of the web service, this could either be provided by the user deploying the MDB or the web service deployer could bind a value to the ENC of the message driven bean as the web service is deployed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBRULES-432) DSL aware editor
by Michael Neale (JIRA)
DSL aware editor
----------------
Key: JBRULES-432
URL: http://jira.jboss.com/jira/browse/JBRULES-432
Project: JBoss Rules
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Michael Neale
In this editor, drop downs will be provided to choose expressions from the lists of templates (it won't be a text editor), with the "data" being populated with a text box.
The work for parsing can be done server side, the editor only has to display+capture data values from the user.
A basic implementation would be something like:
* A DSL aware editor would be good. This works as the following (assuming Google GWT):
- Is implemented as a subclass of Widget or Composite in GWT (refer to the GWT manual)
-Takes in a DSL via public methods: setDSLConditionList(String[] list) and setDSLActionList(String[] list) for completion lists.
-Takes in rule in the form of:
-setLHS(String[]) -lists of conditions
-setRHS(String[]) - list of actions
-After a rule has been edited, the resulting text can be obtained by String getLHS(), getRHS etc.
-User can chose an icon to popup a list of conditions to add, actions to add (chosing from respective list)
-User can chose to remove a condition, or an action (by clicking on a "-" next to a condition or action)
COMPLEX BITS:
-User can choose to edit a line of the rule (if they are allowed to). In this case, it may get a bit complicated. It may go back to the server and get a list of labels/fields which it can then display to the user so they only edit the fields. An alternative, is to do some processing on the server before the rule is loaded, and provide all the lines not as a string, but as a list of labels/fields.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] Created: (JBRULES-428) Access Control List - each node to be protected
by Michael Neale (JIRA)
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: http://jira.jboss.com/jira/browse/JBRULES-428
Project: JBoss Rules
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Michael Neale
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity. First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership) can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if that is not feasable, it would be acceptable to list it, but not show the contents.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month