I did checkin in cvs.
It works with version jboss-3.2.0beta3 so far.
Don't work with cvs Branch3.2 (but sure
later), not tried with RC1 because of deploy
bugs under windows.
how-to step by step :
first get a jboss-3.2.0beta3 somewhere on your disk space
set env variable JBOSS_HOME pointing to it.
get a copy of nukes with : cvs co nukes, let's call it NUKES
install mysql connector on jboss by copying the connector rar in jboss deploy dir.
copy $NUKES/thirdparty/mysql-mysql/lib/mysql-connector-java-3.0.0-beta-bin.jar $JBOSS_HOME/server/default/deploy
install nukes datasource :
copy $NUKES/nukes/src/resources/mysql/mysql-ds.xml $JBOSS_HOME/server/default/deploy
create nukes tables by sourcing the file $NUKES/nukes/src/etc/mysql.ddl
build nukes :
build.bat or build.sh
you can deploy journal module also :
I hope it will be enough and I hope also that
sf.net anonymous cvs works as well. If not
we'll do some kinf of alpha release.
Interception would be great. I think it would be a good place to put a validating interceptor similar to what they have in webwork. I am working on a small validation framework for a project at work, it should be general enough to incorporate as an interceptor if you like.
I prefer to wait for JBoss AOP framework.
In addition I think validation must be part
of nukes in the business code, being
explicit. Not something hidden, beginners
would not understand easyly.
Creating a nukes component must be simple.
Though we will not prevent module developpers
from bringing their own things.
Now there's an interception stack. The same
in jboss model mbean. One custom interceptor
to integrate lifecycle management.
The stack begin from invoke operation
defined in DynamicMBean and forward
to methods developped by module creator.
Last interceptor is the dispatcher that does
the job. All these come from org.jboss.mx to
avoid reiventing the wheel.
Since we are using JMX it fits very well.
the roadmap sounds very interesting, so I will do another small module:
Admin_Messages : allow the admin to leave a message visible to all users on website
another thing I was thinking abput was Flash Integration (I am involved at another project with EJB and JMX invocation from flash client via decoded binary Macromedia AMF protocol) . With this, flash-designer community could drop in GUI components for WYSIWYG-Editor, Instant Messaging, and similar. Or is there any reason Nukes should stick just to HTML ?
very cool rsacon, I am glad to see you there.
flash thing seems interesting, could
you explain more what it does and how ?
would that be possible to have both : html and flash ?
I did not watch that module carrefully, so I don't know hoe messages are provided within nukes. is the message broadcaster component a Block ?
please explain it sounds great
first, the admin module has nothing to do with the flash-ideas, that would be an overkill.
About flash, I will try to explain:
It can be mixed with HTML, (like for example www.macromedia.com), of course main part should be HTML, because Flash is bad to bookmark and for search engine indexing). But cool things can be done with flash (for example flash petshop: http://examples.macromedia.com/petmarket/flashstore_800.html)
Flash accepts incoming XML-data socket connection from the server where it was downloaded, this makes it a candidate for a Nukes instant messaging component (and JMS on the serverside) and what else is interesting is flash remoting, for remote invocation of EJB's, POJOs and JMX. Its using propietary binary protocol called AMF, but the protocol is no mystery, several sourceforge projects have decoded AMF, I am a developer of one of them (Open AMF). And flash is on 98% of all Browsers.
To sum up: applets have completly failed, HTML is ugly beacuse of the page refreshes and flash is propietary stuff.
ok, I understand.
your idea is simply great.
What we can do is two front end for messaging, one in flash and a simple one in HTML. user then can set its preference.
I am not sure for JMS we have top discuss about it. I like the idea to have async call for messaging.
How do you see JMS integrated here ? is that really a need ? please explain it. We cannot create a queue per user (I am not a JMS specialist)
I see only interest in JMS with async call, but I am not usre it would be helpfull there.
If we create a MessageEJB with a field containing target userId it would be enough, wouldn't be ?
Then we can use finder + ORDER BY in JBossQL :
findMessagesByUserId(). We can even get a subset with limit/offset support in JBossQL.
When page reload, does flash reload component as well or does stay in the same state ? I would prefer second of course.
Nukes security could play a great role there also.
There's supposed to be a messaging module in postnuke I think.
Anyway I am very excited about it. If you need help I can work on it with you, though I have many other things to do.
I have just finished another Module, the admin messages module, it's attached.
How do I fix a bug in the lostPassword module ? Do you give me CVS access (my sourceforge username is rsaccon) ? Because only now I have understood the nukes security and string externalization concept.
About the flash integration. When page reloads, flash looses state, therefore its not usable for heavy-input-stuff like WYSISYG-Editor. The messaging maybe can be based on the upcomig JB4 remoting async invocation, I agree that JMS would be an overkill. Well, my next module will contain some experimental flash stuff, and then we can see how or whether at all it fits into nukes.
now it should be attaches