I just stumbled over that EMB JSR (http://jcp.org/en/jsr/detail?id=086) and
also found /docs/examples/media/jboss-media-entity-ejb.jar that looks like an
implementation. I just can't find any more docs or hints on it's fitness. Is
this still worked on? Can it be used? Does it work?
Thanks for
I cann't compile jboss-jmx module in tag-name jboss-4.0.
In my opinion, there is no some class needing when compile.
for example, org.jboss.mx.server.ServerConstants
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3874276#3874276
Reply to the post :
In addition, build.xml is wrong.
library.classpath property have no sun.jmx.classpath property.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3874277#3874277
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3874277
Is it possible to apply a point cut to an entire branch of packages, like for
example pointcut=... and within(java.*) for all class in package java and the
subpackages aso.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3874280#3874280
Reply to the post :
Had the same problem with the example file downloaded on the site.
Added a / in the helloworld-pages.xml
pages
|portal-namedefault/portal-name
|page
| page-namehelloworld/page-name
| window
| window-nameHelloWorldPortletWindow/window-name
|
see http://www.jboss.org/index.html?module=bbop=viewtopict=62557
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3874306#3874306
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3874306
You mean the jmx module stand-alone? It compiles fine as part of the jboss
checkout. AFAIK it's been a couple of years since the last stand-alone realease
(jboss-mx v1.1.2)
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3874310#3874310
Reply to the post :
I believe the aspects belong in the module that implements them.
This is the only approach that will allow the aspect to evolve across versions
rather than trying to maintain a monolithic single integration package
jboss-aspects.
The aspect requires the rest of the implementation anyway, e.g.
It has actually been much easier to package it as this monolithic aspect
library over the past few years. If there is a bug or feature addition in any
of the aspects in the library, I can easily patch any version of JBoss. It
would actually be more monolithic if the code was part of
A standalone release of aop which includes a security aspect depending on the
implementation details of jboss-4.0.x makes no sense.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3874332#3874332
Reply to the post :
[EMAIL PROTECTED] wrote : It has actually been much easier to package it as
this monolithic aspect library over the past few years.
Ok, one contra example is code to integrate the deployer/classloader across
versions:
The integration point is the annotation (which also belongs in JBossSX)
and that needs to be consistent with the features provided by each version.
| @SecurityDomain(other)
| @NewSecurityFeatureNotAvailableInJBoss32 // Shouldn't compile under 3.2.x
| public void doSomething()
| {
| }
There should be no change by the jmx - mbeans. All I did was move code.
Can you tell me how to reproduce the problem (report it on JIRA).
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3874338#3874338
Reply to the post :
We discussed this in Boston, but I want to make sure you agree with my summary.
http://jira.jboss.com/jira/browse/JBAOP-82
Do you plan to support proxies on non-weaved code?
I had a look at the current proxy implementation, the EJB3 and new JMS
usage (which all do different but similar things).
Look at the EJB3 code for examples, but it uses something called a
ClassContainer. (I know the names are confusing).
My thinking was a proxy (java.lang.reflect or a javassist one) that creates an
invocation and delegates to this ClassContainer.Eventually, the InstanceAdvisor
will be
[EMAIL PROTECTED] wrote : Look at the EJB3 code for examples, but it uses
something called a ClassContainer. (I know the names are confusing).
|
| My thinking was a proxy (java.lang.reflect or a javassist one) that creates
an invocation and delegates to this ClassContainer.Eventually,
[EMAIL PROTECTED] wrote : BTW, why don't you finish GenericBeanFactory
instead of looking at this stuff?
Because it is already done:
http://jira.jboss.com/jira/browse/JBMICROCONT-21
[EMAIL PROTECTED] wrote :
| What I want to do inside registerMBean is use an AOP domain configuration
| to wrap the MBean in advices, but regardless of the advisor implementation.
|
Well actually, going forward, this will more annotation driven rather than the
| public class XXX
[EMAIL PROTECTED] wrote :
| BTW, why don't you finish GenericBeanFactory instead of looking at this
stuff?
To more completely answer your question, I am at an impass waiting for:
AOP integration
JBossXB parsing
and to a lesser extent classloading.
So I've moved up the stack and I'm now
[EMAIL PROTECTED] wrote :
|
| My thinking was the class adapter would go through something like the
following logic:
|
| Object implements Advised - InstanceAdvisor
| (!Object implements Advised) canWeave - Runtime Weaving
| (!Object implements Advised) canWeave == false -
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-testsuite?log=log20050417173123
BUILD FAILEDAnt Error Message:/home/cruisecontrol/work/scripts/build-jboss-head.xml:66: The following error occurred while executing this line:
The hard part about the GenericBeanFactory is creating all the metadata. Also,
how about all the metadata overrides? I think this should be a separate API
with the ClassAdapter instead of the way we proposed it in Boston. Not only
would this get rid of the need for javassist to preprocess
anonymous wrote :
| In your example the Class adaptor not only has to do the above, but also is
it already woven. We do not want to do all this pre-processing at class load
time or this lightweight container will take forever to boot up. The slow
pre-processing is the same reason I did not
[EMAIL PROTECTED] wrote : The hard part about the GenericBeanFactory is
creating all the metadata. Also, how about all the metadata overrides? I
think this should be a separate API with the ClassAdapter instead of the way we
proposed it in Boston. Not only would this get rid of the need for
Simple usecase tests for AOP/MC integration:
http://jira.jboss.com/jira/browse/JBAOP-109
Assigned to me
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3874361#3874361
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3874361
I wan't to configure portal authentication to be made via user certificate.
Where I configure this?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3874362#3874362
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3874362
I have not tried yet but I don't see any reason why it would not work.
I think that first you must enable client cert in web.xml of
portal-core.sar/portal-server.war/WEB-INF/web.xml
the entry for this scheme is not yet here (we only put form and basic auth) so
you must add it
then to make
If you're trying to use ssl auth, then you need to modify this file:
jboss-portal-2.0\core\src\resources\portal-core-war\WEB-INF\web.xml
Look for this block:
| param-valuehttp://localhost:8080/webdav/files/param-value
| !-- Comment out for SSL communication between Portal and
Not sure how to do it. Tried this:
| AbstractBeanMetaData metaData1 = new AbstractBeanMetaData(aspect,
GenericBeanFactory.class.getName());
| ArrayList constructor1 = new ArrayList();
| constructor1.add(new
AbstractParameterMetaData(KernelConfigurator.class.getName(),
It is a bug/typo: AbstractMapMetaData:
I just committed the fix...
|
|public Iterator getChildren()
|{
| ArrayList children = new ArrayList(map.keySet());
| - children.add(map.values());
| + children.addAll(map.values());
| return
[EMAIL PROTECTED] wrote :
| I should warn you that I haven't done anything except basic config tests
(no injection/dependency tests) on the collections because I was waiting to see
| what Alex could handle in the XML mapping. :-(
The same is true for the GenericBeanFactory, except there I
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2?log=log20050418185341Lbuild.330
BUILD COMPLETE-build.330Date of build:04/18/2005 18:53:41Time to build:44 minutes 19 secondsLast changed:04/18/2005 12:27:49Last log entry:Remove the references to the
I'll dig further, but another problem Seems that controller and such doesn't
get set on the AbstractDependency in the Map sent into th
| java.lang.NullPointerException
| at
Ok, everything is working now. Fixed one thing in AbstractValueMEtaData... in
getChildren, actually look to see if value is a valueMetaData, then pass it
back.
Added test to PlainDependencyTestCase
View the original post :
Done:
http://jira.jboss.com/jira/browse/JBJMX-92
Before trying to reproduce the problem, please do a CVS update in the
transaction and iiop subdirs. I have just committed some changes in those
subdirs.
The NPE does not happen if I copy jboss-transaction.jar and jboss-iiop.jar (the
modules
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk-matrix?log=log20050419004835
BUILD FAILEDAnt Error Message:/home/cruisecontrol/work/scripts/build-jboss-head.xml:63: The following error occurred while executing this line:
36 matches
Mail list logo
