[Beginners Corner] - Re: Running JBoss 5 within Eclipse with a different set of p
by Oberiko
Thanks Peter. Using what you said I think I found the solution.
Instead of editing the launch configuration though, you can actually just double-click on the server from either the "Servers" or "JBoss Server View" views to open up the "Overview" window.
>From there, select "Open launch configuration" and add the ports-01 parameter to the "Arguments" tab. After that, you can modify the "Server Properties" on the main "Overview" window you have to adjust the port to "8180" and the JNDI Port to "1199" (I'd guess more if you use ports-02 etc.).
While my server starts up fine (and is recognized as starting), I find that it doesn't shutdown properly. At first I was getting a whole heap of errors (it was still looking for 1099), but now I don't get any messages at all. It does shutdown and restart without a hitch, but it's still a little worrisome.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226067#4226067
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226067
17 years, 2 months
[Microcontainer] - Re: Deployer test framework (Ruby and RSpec)
by bob.mcwhirter
Following up to myself...
I also have a handle DSL that's usable within the actual test-case to build a deployment and apply some structure.
| it "should use the unit's root as RAILS_ROOT" do
| deployment = deploy do
| root do
| dir 'config', :metadata=>true do
| file 'rails-env.yml', :read=>'rails-env/simple-rails-env.yml'
| end
| end
| end
| unit = deployment_unit_for( deployment )
| meta_data = unit.getAttachment( RailsApplicationMetaData.java_class )
|
| meta_data.should_not be_nil
| meta_data.getRailsRoot().should eql( unit.getRoot() )
| meta_data.getRailsEnv().should eql( 'simply-an-env' )
| end
|
This creates a vfsmemory:// deployment which contains a directory config/ which is both a metadata directory and contains a file named rails-env.yml which is actually read from one of the test resources of a different name.
Basically, just a handy way to construct a tree VFS from a variety of sources, and jacking some StructureMetaData around it at the same time.
Thoughts?
fwiw, if you prefer, the alternate Ruby syntax using curlies would be
| deployment = deploy {
| root {
| dir( 'config', :metadata=>true ) {
| file 'rails-env.yml', :read=>'rails-env/simple-rails-env.yml'
| }
| }
| }
|
-Bob
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226050#4226050
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226050
17 years, 2 months
[JNDI/Naming/Network] - How to locate MDB MXbean via JNDI? (crosspost from EJB/JBoss
by tajh
Sorry for the duplication; this is a cross-post from the EJB/JBoss Forum because I am not sure which one is the right forum.
Original post is here:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154082
I've searched the documentation and the forums, wasn't able to find this particular issue addressed anywhere.
I have a MDB (called MyMDB) deployed in a JAR, and I have a custom JMX bean deployed in a SAR. I would like to access the org.jboss.ejb.plugins.jms.JMSContainerInvokerMBean corresponding to my MDB so that the custom JMX bean can call the startDelivery() and stopDelivery() methods on the JMSContainerInvokerMBean. So far, I have been unable to locate the JMSContainerInvokerMBean in JNDI from within the SAR.
I have tried the following JNDI contexts, to no avail:
anonymous wrote : java:/comp/env/MyMDB
| java:/com/MyMDB
| java:/MyMDB
| local/MyMDB
| /MyMDB
| MyMDB
|
The JNDIView service in the JMX Console reports the following:
anonymous wrote : Ejb Module: MyMDB.jar
|
| java:comp namespace of the MyMDB bean:
|
| +- HandleDelegate (class: org.jboss.proxy.ejb.handle.HandleDelegateImpl)
| +- ORB (class: org.jacorb.orb.ORB)
| +- env (class: org.jnp.interfaces.NamingContext)
|
And of course I can access the desired JMSContainerInvokerMBean via the JMX console also, at something like the following:
anonymous wrote : jboss.j2ee
|
| * binding=message-driven-bean,jndiName=local/MyMDB@9049759,plugin=invoker,service=EJB
|
That number following the @ sign seems to be different every time I start JBoss, and this JNDI name seems to only apply from within the MDB's JAR scope itself. At first, I wasn't sure I could get access to the JMSContainerInvokerMBean from outside the MDB's JAR, but if the JMX Console can do it, I should be able to do it from within my custom JMX bean in my SAR.
So does anyone know the correct JNDI path to construct to get a handle to this?
For reference, I am running the following:
JBoss AS 4.2.2 GA
JBoss Messaging 1.0
Java SDK 1.5.0_12
And this is what my client JNDI lookup code looks like:
JMSContainerInvokerMBean mbean = null;
| try {
| Context context = new InitialContext();
| mbean = (JMSContainerInvokerMBean)context.lookup(jndiName);
| } catch (NamingException ne) {
| log.error("Unable to retrieve JMSContainerInvokerMBean at JNDI context " + jndiName, ne);
| } catch (ClassCastException ce) {
| log.error("Object at JNDI context " + jndiName + " is not instance of JMSContainerInvokerMBean", ce);
| }
Any help is appreciated.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226046#4226046
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226046
17 years, 2 months
[Microcontainer] - Deployer test framework (Ruby and RSpec)
by bob.mcwhirter
For my rails deployers, I wanted to be able to write tests using RSpec. I've been reworking the rspec-maven-plugin so that this will eventually work in your normal mvn test build.
RSpec itself is a BDD testing tool, and tries to be fairly useful and self-documenting of tests.
Here's what I've got so far to spin up a basic VFS-enabled MC, jam in 1 deployer, and deploy a file.
| require 'deployers/deployer_test_helper'
|
| import org.jboss.rails.core.deployers.AppRailsYamlParsingDeployer
| import org.jboss.rails.core.metadata.RailsApplicationMetaData
|
| describe AppRailsYamlParsingDeployer do
|
| include DeployerTestHelper
|
| def create_deployers
| [
| AppRailsYamlParsingDeployer.new
| ]
| end
|
| before( :each ) do
| setup_microcontainer
| end
|
| it "should create a sub-deployment with pre-attached RailsApplicationMetaData" do
| deployment = deploy( "#{BASE_DIR}/src/test/resources/deployments/toplevel/simple-rails.yml" )
| unit = deployment_unit_for( deployment )
|
| sub_deployment = unit.getAttachment( "jboss.rails.root.deployment" )
| sub_deployment.should_not be_nil
| sub_unit = deployment_unit_for( sub_deployment )
|
| meta_data = sub_unit.getAttachment( RailsApplicationMetaData.java_class )
| meta_data.should_not be_nil
| meta_data.getRailsRootPath().should eql( '/Users/bob/oddthesis/oddthesis' )
| meta_data.getRailsEnv().should eql( 'development' )
| end
|
| end
|
For example, in the above test, the AppRailsYamlParsingDeployer actually doesn't attach meta-data, but triggers a sub-deployment of another VFS, and attaches the sub-deployment to the unit of the root deployment. While this might not be "awesome" in terms of VDF usage, it just shows the ease of mucking about in all the innards from the Ruby end of things.
If there's any further interest in this, I can break this framework out of the jboss-rails project into a more generally useful deployer-testing add-on for RSpec users.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226032#4226032
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226032
17 years, 2 months
[EJB 3.0] - Re: @RunAs doesn't work in JBossAS 4.2.3?
by amcdowell
I researched this a little more. My example above is actually wrong. I tried to simplify my actual problem, and simplified it too far.
According to EJB 3.0 Section 17.2.5.2:
anonymous wrote :
| Note that isCallerInRole(String roleName) tests the principal that represents the
| caller of the enterprise bean, not the principal that corresponds to the run-as security identity
| for the bean, if any.
|
So my above example will never print true in a compliant container.
However my real problem is actually the more complex example (properly using RunAs):
| public interface CalleeSessionBean {
| public void execute();
| }
|
| @Stateless
| @TransactionManagement(TransactionManagementType.CONTAINER)
| @Remote(CalleeSessionBean.class)
| @Local(CalleeSessionBean.class)
| public class CalleeSessionBeanImpl implements CalleeSessionBean {
| @Resource
| private SessionContext context;
|
| public void execute() {
| System.out.println("CallerPrincipal: " + context.getCallerPrincipal().getName());
| System.out.println("CallerInRole(testRole): " + context.isCallerInRole("CallerRole"));
| }
| }
|
| public interface CallerSessionBean {
| public void execute();
| }
|
| @Stateless
| @TransactionManagement(TransactionManagementType.CONTAINER)
| @Remote(CallerSessionBean.class)
| @Local(CallerSessionBean.class)
| @RunAs("CallerRole")
| public class CallerSessionBeanImpl implements CallerSessionBean {
| @Resource
| private SessionContext context;
|
| public void execute() {
| InitialContext initialContext = new InitialContext();
| CalleeSessionBean callee = initialContext.lookup("CalleeSessionBean/local");
| callee.execute();
| }
| }
|
In this case, the Callee still prints false, despite the fact it should have aquired the RunAs CallerRole.
I traced through the code and the problem is due to https://jira.jboss.org/jira/browse/EJBTHREE-741, a defect in the RunAsSecurityInterceptor. Even though the issue claims it was applied to AS 4.2.0, it does not appear to be. It is however applied to the 5.0.0+ branches.
Bottom Line: the answer to my own question is: The @RunAs EJB 3.0 annotation is broken in the 4.2.x branches, but does work correctly in the 5.x branches.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226028#4226028
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226028
17 years, 2 months