November 2007 - jboss-dev-forums - Jboss List Archives

[Design of Security on JBoss] - Re: AS 4.2.0 binding to localhost

by 0bshaffer

Can anyone recommend a fix for wuschelz's question? I've created a JBoss service using javaservice.exe and I've run into the same issue, where it only binds to the localhost address. TIA View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102711#4102711 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102711

18 years, 5 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Bringing together an unified security view

by julien＠jboss.com

I always heard from Scott that this ACL stuff is deprecated and useless code... at least this is the answer I had when I asked him the question 3 or 4 years ago. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102706#4102706 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102706

18 years, 5 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Bringing together an unified security view

by anil.saldhana＠jboss.com

Stefan, the JDK already has an API for ACL. We can leverage it, rather than creating a separate API for ACL. http://java.sun.com/j2se/1.5.0/docs/api/java/security/acl/package-summary... Of course, we can add extensions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102704#4102704 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102704

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Instance annotations from Object Models

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | ... with something that loads into the INSTANCE mutable metadata. | | My preference would be to make this a visitor pattern over the metadata itself, | e.g. | | | MutableMetaData mmd = deploymentUnit.getMutableMetaData(); | | MetaDataVisitor visitor = new MetaDataVisitor(mmd, ...); | | visitor.visit(enterpriseBean); | | | | Which is much more extensible/maintainable and OO than the current EJB3 sutff. | Each part of the JavaEE/JBoss metadata can decide if/where it goes in the | annotation view. I see, which really just ends up replacing code like this: | private void addClassAnnotation(EJBContainer container, Class<? extends Annotation> annotationClass, Annotation annotation) | { | log.debug("adding class annotation " + annotationClass.getName() + " to " | + container + " " + annotation); | container.getAnnotations() | .addClassAnnotation(annotationClass, annotation); | } | where container.getAnnotations() is returning the AnnotationRepository. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102695#4102695 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102695

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: BSH script from client

by scott.stark＠jboss.org

That is really a debatable operation on the management interface of some remote deployer component. I would not even port this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102692#4102692 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102692

18 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ManagedObject support in next messaging release

by scott.stark＠jboss.org

This won't work because it requires the mbean code to use the annotations. The point of the indirection was to allow the deployment descriptor to specify the class to parse for the annotations, and to provide that as part of the server integration code. So, a queue would use the mbean/annotation to indicate the class to pass to the AbstractManagedObjectFactory: | <mbean code="org.jboss.jms.server.destination.QueueService" | name="jboss.messaging.destination:service=Queue,name=DLQ" | xmbean-dd="xmdesc/Queue-xmbean.xml"> | <annotation>@org.jboss.system.deployers.managed.ManagementObjectClass(code="org.jboss.jms.server.destination.QueueServiceMO")</annotation> | <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends> | <depends>jboss.messaging:service=PostOffice</depends> | </mbean> | The org.jboss.jms.server.destination.QueueServiceMO class would be in the jbossas/messaging integration codebase. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102688#4102688 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102688

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Leaking annotation API

by scott.stark＠jboss.org

"bstansberry(a)jboss.com" wrote : | Problem with this is the name of the annotation is @org.jboss.annotation.ejb.Clustered -- not a very generic name. Yes, should just be recreated using a transport/remoting oriented package name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102686#4102686 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102686

18 years, 5 months

1
0
0 / 0

[QA of JBoss Portal] - Re: Portlet Container test framework update

by julien＠jboss.com

So finally I chosed an intermediary solution for now and I migrated all test cases to it. A test case looks like @TestCase({Assertion.JSR168_ABC,Assertion.JSR168_XYZ}) | public class MyTestCase | { | public MyTestCase(PortletTest seq) | { | seq.addAction(0, MyPortlet.RENDER_JOINPOINT, new PortletRenderTestAction() | { | protected DriverResponse run(Portlet portlet, RenderRequest request, RenderResponse response, PortletTestContext context) | { | // Code test case here | return new EndTestResponse(); | } | }); | } | } So each test case is now in a single class and it reference (optionally) an Assertion which is an enum class containing all the test case meta data, here is an excerpt: public enum Assertion | { | | JSR168_4(new TCK(4), "After the portlet object is instantiated, the portlet container must" + | " initialize the portlet before invoking it to handle requests"), | | JSR168_31(new TCK(31), "", Status.jbossUntestable("why?")), | | JSR168_33(new TCK(33), "", Status.duplicate(JSR168_36, "")), | | JSR168_49(new TCK(49), "", Status.postponed("spec?")), | | } So each test case has a precise description in one single place which allow to easily make reporting and have a unified view. I still need to do a couple of refactorings on it, basically cleaning up up the joinpoint declaration mechanism. Also finally I did not chose to have one method per joinpoint and I still use the same old model, but for now it seems enough as it can access the test case state. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102673#4102673 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102673

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Leaking annotation API

by bstansberry＠jboss.com

"scott.stark(a)jboss.org" wrote : "ALRubinger" wrote : | | @Clustered depends on org.jboss.ha.framework.interfaces.LoadBalancePolicy from trunk/cluster | | | This is also specific to a particular invocation implementation. This really can't be generically in ejb3 since its an aspect related to remoting. Its possible the server does not support anything but local ejbs, so ejb3 should not be providing this aspect. | There's 2 issues here: 1) The use of org.jboss.ha.framework.interfaces.LoadBalancePolicy in this annotation leaks the legacy org.jboss.invocation.Invocation class. My plan for dealing with this is to introduce a parent interface that doesn't include the method that leaks that type. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=120423. I need to do a serialization/deserialization test to confirm that won't break compatibility with existing clients. This I'll get done this week. 2) Where does @Clustered go? To me it seems like it would go in the ha-client library that I started to break out of the main AS codebase a while back. That breakout was going to have to be done when we break ejb3 out of the AS codebase, and can be done sooner if need be. Problem with this is the name of the annotation is @org.jboss.annotation.ejb.Clustered -- not a very generic name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102643#4102643 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102643

18 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ManagedObject support in next messaging release

by dimitris＠jboss.org

In my local workspace I can add an annotation in the mc/managed api like: | package org.jboss.managed.api.annotation; | ... | @Target({ElementType.TYPE}) | @Retention(RetentionPolicy.RUNTIME) | public @interface ManagementObjectClass | { | /** The class annotated with ManagementObject */ | Class code(); | } | Then update the mc/org.jboss.managed.plugins.factory.AbstractManagedObjectFactory to handle the indirection from the ManagementObjectClass annotation to the real ManagedObject one. Will this be picked up whoever calls the ServiceMetaDataICF.getManagedObjectClass(ServiceMetadata md) method? If yes, no change would be need there. Or have I missunderstood what you want? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102642#4102642 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102642

18 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2007