[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme
by alesj
I've added the following code to KernelBus:
| public Object invoke(Object name, KernelRegistryEntryJoinpoint joinPoint) throws Throwable
| {
| KernelRegistryEntry entry = registry.getEntry(name);
| if (joinPoint.applyEntry(entry) == false)
| throw new IllegalArgumentException("Cannot apply joinpoint " + joinPoint + " to entry " + entry);
| return joinPoint.dispatch();
| }
|
And the 2 impls:
| public class InvokeKernelRegistryEntryJoinpoint extends JBossObject implements KernelRegistryEntryJoinpoint
| {
| private String methodName;
| private Object[] args;
| private String[] signature;
| private InvokeDispatchContext context;
|
| public InvokeKernelRegistryEntryJoinpoint(String methodName, Object[] args, String[] signature)
| {
| this.methodName = methodName;
| this.args = args;
| this.signature = signature;
| }
|
| public boolean applyEntry(KernelRegistryEntry entry)
| {
| if (entry instanceof InvokeDispatchContext)
| {
| context = (InvokeDispatchContext)entry;
| return true;
| }
| return false;
| }
|
| public Object dispatch() throws Throwable
| {
| if (context == null)
| throw new IllegalArgumentException("Cannot dispatch null context.");
| return context.invoke(methodName, args, signature);
| }
|
| public String toHumanReadableString()
| {
| return methodName + "," + context;
| }
| }
|
| public class AttributeKernelRegistryEntryJoinpoint extends JBossObject implements KernelRegistryEntryJoinpoint
| {
| private String getterName;
| private AttributeDispatchContext context;
|
| public AttributeKernelRegistryEntryJoinpoint(String getterName)
| {
| this.getterName = getterName;
| }
|
| public boolean applyEntry(KernelRegistryEntry entry)
| {
| if (entry instanceof AttributeDispatchContext)
| {
| context = (AttributeDispatchContext)entry;
| return true;
| }
| return false;
| }
|
| public Object dispatch() throws Throwable
| {
| if (context == null)
| throw new IllegalArgumentException("Cannot dispatch null context.");
| return context.get(getterName);
| }
|
| public String toHumanReadableString()
| {
| return getterName + "," + context;
| }
| }
|
|
I'll change the ManagementView invocation later this evening with the KernelBus invocation.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086693#4086693
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086693
18 years, 6 months
[Design of POJO Server] - Re: Unifying metadata
by alex.loubyansky＠jboss.com
"adrian(a)jboss.org" wrote : "scott.stark(a)jboss.org" wrote :
| | 1. The existing ObjectModelFactoryDeployer based deployers producing legacy metadata need to be converted to SchemaResolverDeployer type deployers that produce the new metadata, and then create the legacy wrapper using the new metadata as the delegate. The JBossXBBuilder would be used to create the SchemaBinding for the new metadata.
| |
| | One little issue here is that the SchemaResolverDeployer does not have a SchemaBindingResolver getResolver() method to allow subclasses to easily extend the default resolver.
| |
|
| This was something I asked Alex to look at.
| I'm not sure how much he has done?
I haven't looked into the deployer issues above.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086684#4086684
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086684
18 years, 6 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Need Notification when message is dropped due to max size
by jhowell＠redhat.com
I have a customer that wants to put in an aspect to do some sort of notification if a message is dropped due to the maxsize. I can see in ChannelSupport that the max size is handed via
protected Delivery handleInternal(DeliveryObserver sender, MessageReference ref,
| Transaction tx, boolean persist)
| {
| if (ref == null)
| {
| return null;
| }
|
| if (trace) { log.trace(this + " handles " + ref + (tx == null ? " non-transactionally" : " in transaction: " + tx)); }
| if (maxSize != -1 && getMessageCount() >= maxSize)
| {
| //Have reached maximum size - will drop message
| log.warn(this + " has reached maximum size, " + ref + " will be dropped");
| return null;
| }
|
and the Delivery gets returned as null. I don't see anything that I can use to figure out if the message is dropped.
I do see later on that if the delivery is null that we generate a JMSException in ServerConnectionEndpoint this....
if (del == null)
| {
| throw new JMSException("Failed to route " + ref + " to " + dest.getName());
| }
|
My guess is that theres nothing that they can do except catch the exception. Because we throw a JMSException and not a MessagingJMSException, it makes it hard. Should we throw a typed exception, like MaxMessageReachedException or throw a MessagingJMSException with a specific error code in it. I notice that there are several cases that can return a null delivery. I would recommend that we throw a specific exception in ChannelSupport? That way we could write an aspect that would catch the specific exception. Don't know what the impact would be, but I'm guessing that there is a reason that we return null for the delivery in ChannelSupport.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086677#4086677
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086677
18 years, 6 months
[Design of POJO Server] - Re: Unifying metadata
by scott.stark＠jboss.org
"adrian(a)jboss.org" wrote :
| Currently there is a POJO/MBean that lets you specify
| schema -> SchemaBindingInitializer
| (there are factory settings)
|
| What's required for the JBossXBBuilder is instead
| schema -> annotated class name (the root class)
| and build the schemabinding from that.
|
| In fact, since the annotated class name contains the schema name
| as an annotation, all that's really required is being able to add classes
| (unless we also want to specify aliases as well).
|
| Also, JBossXB needs updating so we can do
| dtd -> annotated class name
| or
| dtd -> schema
| so we can parse xmls with legacy dtds using the schema binding.
|
| This requires a change to JBossXB's SAXParser to trap the dtd event
| and store it somewhere for when the schema handling tries to resolve
| schema. i.e. resolve using the dtd public/system id instead of the non-existant
| xmlns declaration.
So it seems the jbossxb and jbossxb-builder projects need to be merged, and the DefaultSchemaResolver/SchemaResolverConfig updated to support these mappings. With this there would be no need to sublcass the SchemaResolverDeployer resolver. I can work on that today if we agree to merge these since both projects are dependencies of the metadata project.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086670#4086670
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086670
18 years, 6 months
[Design of JBoss Web Services] - Re: WS-RM Sender/Receiver Location Within JBossWS Stack
by palin
Hi Richard,
first of all, just to be clear, I'm not saying clustering rm is a must neither it's easy to implement it. I actually believe it would be very usefull in a real application and that it can be obtained with less pain if the whole rm subsystem it designed keeping it in mind.
So... just a couple of ideas, imho we should open another thread on this in future if needed.
anonymous wrote : * use cookies aware loadbalancer in the front of cluster
| * all your RM endpoints (hosted on cluster nodes) must be cookies aware
Are cookies really needed for rm? In any case the user loadbalancer choice is not our business ;-)
anonymous wrote : * your cluster must be able to replicate the sessions and cookies
| * use clustered database (where RM messages are stored)
For example jboss cache /pojo cache could be used to access and replicate the sessions / rm store on all cluster nodes.
Once again... I'm just wondering if this could be done if the whole system is designed with this issue in mind.
Regarind the original post subject i.e. the RMChannel location:
anonymous wrote : RM subsystem will be hooked to the whole invocation framework, it will consists of handlers, transport wrappers, database based store and other entities. It won't be implemented on the transport layer only.
OK, now I get it. I'll be glad to share ideas about this when you'll think about the server side. I'll think about the handler issue you wrote in the meantime.
Bye
Alessio Soldano
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086663#4086663
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086663
18 years, 6 months
[Design of POJO Server] - Re: Unifying metadata
by adrian＠jboss.org
"scott.stark(a)jboss.org" wrote :
| 1. The existing ObjectModelFactoryDeployer based deployers producing legacy metadata need to be converted to SchemaResolverDeployer type deployers that produce the new metadata, and then create the legacy wrapper using the new metadata as the delegate. The JBossXBBuilder would be used to create the SchemaBinding for the new metadata.
|
| One little issue here is that the SchemaResolverDeployer does not have a SchemaBindingResolver getResolver() method to allow subclasses to easily extend the default resolver.
|
This was something I asked Alex to look at.
I'm not sure how much he has done?
Currently there is a POJO/MBean that lets you specify
schema -> SchemaBindingInitializer
(there are factory settings)
What's required for the JBossXBBuilder is instead
schema -> annotated class name (the root class)
and build the schemabinding from that.
In fact, since the annotated class name contains the schema name
as an annotation, all that's really required is being able to add classes
(unless we also want to specify aliases as well).
Also, JBossXB needs updating so we can do
dtd -> annotated class name
or
dtd -> schema
so we can parse xmls with legacy dtds using the schema binding.
This requires a change to JBossXB's SAXParser to trap the dtd event
and store it somewhere for when the schema handling tries to resolve
schema. i.e. resolve using the dtd public/system id instead of the non-existant
xmlns declaration.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086657#4086657
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086657
18 years, 6 months
[Design of JBoss Build System] - Re: aop-mc-int tests failing
by kabir.khan＠jboss.com
That was probably not enough
| Kabir@KabirDell ~/sourcecontrol/microcontainer-beta4/aop-mc-int
| $ mvn surefire-report:report -Pant-tests-weave
| [INFO] Scanning for projects...
| [INFO] Searching repository for plugin with prefix: 'surefire-report'.
| WAGON_VERSION: 1.0-beta-2
| [INFO] ----------------------------------------------------------------------------
| [INFO] Building JBoss Microcontainer AOP MC INT
| [INFO] task-segment: [surefire-report:report]
| [INFO] ----------------------------------------------------------------------------
| [INFO] Preparing surefire-report:report
| [INFO] artifact org.apache.maven.plugins:maven-antrun-plugin: checking for updates from jboss
| [INFO] [resources:resources]
| [INFO] Using default encoding to copy filtered resources.
| [INFO] [compiler:compile]
| [INFO] Nothing to compile - all classes are up to date
| [INFO] [resources:testResources]
| [INFO] Using default encoding to copy filtered resources.
| [INFO] [compiler:testCompile]
| [INFO] Nothing to compile - all classes are up to date
| [INFO] [surefire:test]
| [INFO] Tests are skipped.
| [INFO] [surefire:test {execution: weave}]
| [INFO] Tests are skipped.
| [INFO] [surefire:test {execution: weave-secure}]
| [INFO] Tests are skipped.
| [INFO] [surefire:test {execution: no-weave}]
| [INFO] Tests are skipped.
| [INFO] [surefire:test {execution: no-weave-secure}]
| [INFO] Tests are skipped.
| Downloading: http://repository.jboss.org/maven2/junit/junit/3.8.2/junit-3.8.2.jar
| [WARNING] Unable to get resource 'junit:junit:jar:3.8.2' from repository jboss (http://repository.jboss.org/maven2)
| Downloading: http://repository.jboss.org/maven2//junit/junit/3.8.2/junit-3.8.2.jar
| [WARNING] Unable to get resource 'junit:junit:jar:3.8.2' from repository repository.jboss.org (http://repository.jboss.org/maven2/)
| Downloading: http://repository.jboss.org/maven2/junit/junit/3.8.2/junit-3.8.2.jar
| [WARNING] Unable to get resource 'junit:junit:jar:3.8.2' from repository jboss (http://repository.jboss.org/maven2)
| Downloading: http://repo1.maven.org/maven2/junit/junit/3.8.2/junit-3.8.2.jar
| 117K downloaded
| [INFO] [antrun:run {execution: ant-tests-weave}]
| [INFO] Executing tasks
| [mkdir] Created dir: C:\cygwin\home\Kabir\sourcecontrol\microcontainer-beta4\aop-mc-int\target\surefire-reports\ant-weave
| [mkdir] Created dir: C:\cygwin\home\Kabir\sourcecontrol\microcontainer-beta4\aop-mc-int\target\log
| [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.797 sec
| java.io.FileNotFoundException: C:\cygwin\home\Kabir\sourcecontrol\microcontainer-beta4\aop-mc-int\junitvmwatcher2026226667.properties (The system cannot find the file specified)
| at java.io.FileInputStream.open(Native Method)
| at java.io.FileInputStream.<init>(FileInputStream.java:106)
| at java.io.FileReader.<init>(FileReader.java:55)
| at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeAsForked(JUnitTask.java:1028)
| at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:817)
| at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1657)
| at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:764)
| at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
| at org.apache.tools.ant.Task.perform(Task.java:348)
| at org.apache.tools.ant.Target.execute(Target.java:357)
| at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:108)
| at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
| at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:896)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:739)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:510)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
| at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
| at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
| at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
| at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
| at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
| at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
| [junit] Running org.jboss.test.aop.junit.MicrocontainerJunitSmokeTestCase
| [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
| [junit] Test org.jboss.test.aop.junit.MicrocontainerJunitSmokeTestCase FAILED (crashed)
| [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.453 sec
| java.io.FileNotFoundException: C:\cygwin\home\Kabir\sourcecontrol\microcontainer-beta4\aop-mc-int\junitvmwatcher951093570.properties (The system cannot find the file specified)
| at java.io.FileInputStream.open(Native Method)
| at java.io.FileInputStream.<init>(FileInputStream.java:106)
| at java.io.FileReader.<init>(FileReader.java:55)
| at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeAsForked(JUnitTask.java:1028)
| at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:817)
| at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1657)
| at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:764)
| at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
| at org.apache.tools.ant.Task.perform(Task.java:348)
| at org.apache.tools.ant.Target.execute(Target.java:357)
| at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:108)
| at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
| at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:896)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:739)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:510)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
| at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
| at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
| at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
| at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
| at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
| at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086648#4086648
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086648
18 years, 6 months