[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme
by alesj
OK, let me see if I get this ManagedOperation invocation. :-)
ManagementViewImpl loads profile == prepares Managed objects (props, operations). This means preparing proxies to expose to client via Dispatcher.singleton.
Once the ManagedOperation is invoked on the client side, it goes through the ProfileService subsystem via Connector(MBean) over ProfileServiceInvocationHandler which checks if it's actually ManagedOperation invocation (oid starting with ProfileService.ManagedOperation@ as it was set in proxy wrapper), which then delegates to ManagementViewImpl.invoke().
What I'm missing is that ManagementViewImpl.createOperationProxies(Set ops) is missing actual runtime component ref (name of the bean/service in MC or the bean/service itself).
Or how/where did you intend to get it?
Via ManagementObjectID --> ManagedObject.name?
| ManagementObjectID id = (ManagementObjectID) annotations.get(ManagementObjectID.class.getName());
| if (id != null)
| {
| if (value == null || value.getMetaType().isSimple() == false)
| {
| log.warn("Cannot create String name from non-Simple property: "
| +property+", value="+value);
| continue;
| }
| SimpleValue svalue = (SimpleValue) value;
| String name = "" + svalue.getValue();
| managedObject.setName(name);
| }
|
What we should be adding is aspect(s) for every bean/service that we intend to be managed?
So that we know what is the whole chain of events that the actual change triggers, e.g. changing the DS url should flush the pool of connections, create new ones, ...
Right?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086276#4086276
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086276
18 years, 6 months
[Design of EJB 3.0] - Re: Component Proposal - Configurable Service Locator
by ALRubinger
"Need" is pretty subjective, I suppose.
I'm trying to alleviate the confusion prevalent on the user's forums regarding "where is my EJB?" and "why can't I cast this properly?" by abstracting the JNDI calls from EJB clients.
In short, I think making an enterprise client should be as simple as configuring a number of remote application server(s), and requesting services of them.
ServiceLocator.getStatelessService(MyServiceRemote.class).goService();
Compared to:
Properties props = [configuration];
| Context ctx = new InitialContext(props);
| MyServiceRemote myService = null;
| Object obj = ctx.lookup([some JNDI address that could be transparent to the developer]);
| myService = (MyServiceRemote)PortableRemoteObject.narrow(obj,MyServiceRemote.class);
| myService.goService();
...which at first glance really only looks like a few lines of code, but really:
* The client has to know ahead of time the JNDI Address of the remote service. What if this changes on the app server? I can imagine more than a few cases of repackaging/changing EAR names across different versions, and then the client code/configs would have to be updated as well.
* SLSB and JMX stubs should be cached to avoid the overhead of JNDI trips; why not make a lib that'll do this for the developer rather than imposing this responsibility on the community?
The "need" comes into play the second an application developer wants to do any of the things not addressed by JEE Application Clients (above post). There are plenty of cases in my current application where I'm not running a main class, or I'd like to invoke a Service from a non-EJB component (where injection isn't available even in-container).
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086271#4086271
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086271
18 years, 6 months
[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOP asintegration WITHOUT the integration :-)
by kabir.khan@jboss.com
"adrian(a)jboss.org" wrote : "kabir.khan(a)jboss.com" wrote :
| | Are you saying "don't use it", or "use it and we'll retrofit an SPI"? :-) As far as I can tell I will need information from the ClassLoaderPolicy.
|
| I'm saying any use of the classloading metadata for the AOP domain construction
| would be a hack until we have a real solution based on metadata context
| rather than the classloader of the aspectized class/aspect class/joinpoint.
|
| The latter (classloader solution) is just a temporary solution to reproduce
| what jboss4 does. I don't think we need to create a SPI (which we will need to
| support forever) for something that is a temporary hack.
|
| If we created a SPI, it wouldn't be the Unified ClassLoader or the new classloader
| it would have to cover all possible classloading models that people might want
| to plugin to the deployers.
I am thinking about if we need to create special classpools understanding the new loaders. Let's ignore this for now until I am sure that these pools will be needed
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086258#4086258
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086258
18 years, 6 months
[Design of JBoss Build System] - Cannot see uploaded common-core snapshot
by dimitris@jboss.org
Currently, common-core is configured to build a 2.2.2-SNAPSHOT version.
https://svn.jboss.org/repos/common/common-core/trunk/pom.xml
Doing an 'mvn deploy' I can see stuff getting uploaded, nevertheless, I don't see a 2.2.2-SNAPSHOT directory here:
https://snapshots.jboss.org/maven2/jboss/jboss-common-core/
| [INFO] [jar:jar]
| [INFO] Building jar: X:\cvs\jboss-public\common\common-core\target\jboss-common-
| core-2.2.2-SNAPSHOT.jar
| [INFO] Preparing source:jar
| [WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
| [INFO] No goals needed for project - skipping
| [INFO] [source:jar {execution: attach-sources}]
| [INFO] Building jar: X:\cvs\jboss-public\common\common-core\target\jboss-common-
| core-2.2.2-SNAPSHOT-sources.jar
| [INFO] [install:install]
| [INFO] Installing X:\cvs\jboss-public\common\common-core\target\jboss-common-cor
| e-2.2.2-SNAPSHOT.jar to c:\home\tools\maven-repos\org\jboss\jboss-common-core\2.
| 2.2-SNAPSHOT\jboss-common-core-2.2.2-SNAPSHOT.jar
| [INFO] Installing X:\cvs\jboss-public\common\common-core\target\jboss-common-cor
| e-2.2.2-SNAPSHOT-sources.jar to c:\home\tools\maven-repos\org\jboss\jboss-common
| -core\2.2.2-SNAPSHOT\jboss-common-core-2.2.2-SNAPSHOT-sources.jar
| [INFO] [deploy:deploy]
| altDeploymentRepository = null
| [INFO] Retrieving previous build number from snapshots.jboss.org
| WAGON_VERSION: 1.0-beta-2
| Uploading: https://snapshots.jboss.org/maven2/org/jboss/jboss-common-core/2.2.2-
| SNAPSHOT/jboss-common-core-2.2.2-20070919.153817-2.jar
| [INFO] Retrieving previous metadata from snapshots.jboss.org
| [INFO] Uploading project information for jboss-common-core 2.2.2-20070919.153817
| -2
| [INFO] Retrieving previous metadata from snapshots.jboss.org
| [INFO] Uploading repository metadata for: 'snapshot org.jboss:jboss-common-core:
| 2.2.2-SNAPSHOT'
| [INFO] Retrieving previous metadata from snapshots.jboss.org
| [INFO] Uploading repository metadata for: 'artifact org.jboss:jboss-common-core'
|
| [INFO] Retrieving previous build number from snapshots.jboss.org
| Uploading: https://snapshots.jboss.org/maven2/org/jboss/jboss-common-core/2.2.2-
| SNAPSHOT/jboss-common-core-2.2.2-20070919.153817-2-sources.jar
| [INFO] ------------------------------------------------------------------------
| [INFO] BUILD SUCCESSFUL
| [INFO] ------------------------------------------------------------------------
| [INFO] Total time: 2 minutes 55 seconds
| [INFO] Finished at: Wed Sep 19 18:39:23 EEST 2007
| [INFO] Final Memory: 8M/15M
| [INFO] ------------------------------------------------------------------------
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086223#4086223
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086223
18 years, 6 months