Re: [forge-dev] OSGi
by Lincoln Baxter
Thanks Jason. Good to know, any way to disable it explicitly?
----- Original Message -----
From: "Jason Greene" <jgreene(a)redhat.com>
To: "Lincoln Baxter" <lbaxter(a)redhat.com>
Sent: Saturday, January 12, 2013 5:27:52 PM
Subject: OSGi
Saw your message in irc. Latest master disables OSGi for that very reason. We now require it to be explicitly enabled
Sent from my iPhone
11 years, 10 months
Problem with beanManager.getReference(InjectionPoint, CreationalContext)
by Lincoln Baxter, III
Hey all,
I have a problem with "Faking an injection point," with the current Weld 2
code, seems to be throwing an NPE instead of using the InjectionPoint that
I am providing the BeanManager with.
This can be reproduced right now by checking out the forge core repository
branch 2.0. Just run, mvn clean install.
https://github.com/forge/core/tree/2.0
The crux of the matter, we have a producer method in a CDI instance A:
@Produces
public static Coverter<?,?> produceRemoteConverter(AddonRegistry registry,
InjectionPoint ip)
There are, however, no injection points actually consuming this
type/producer method from within CDI instance A. (And adding one would not
really help.)
In CDI instance, B, however, we are using the following code, with a
reference to the BeanManager from CDI instance A, to get an instance of a
Converter:
Bean<R> bean = (Bean<R>) manager.resolve(manager.getBeans(type));
context = manager.createCreationalContext(bean);
Object delegate = manager.getInjectableReference(injectionPoint, context);
We have an InjectionPoint for the Converter type in CDI instance B, and are
delegating to container A to get the instance (using an extension.)
However, even though we are passing in our own InjectionPoint(B) into CDI
instance A, CDI instance A still tries to look up the InjectionPoint on its
internal stack, and throws a NullpointerException.
I think this is a bug, since InjectionPoint is an interface, (but obviously
very edge case if so.)
Any help would be appreciated. Otherwise, we have no way to support looking
up beans for types which are produced with Producer Methods requiring an
injection point (those without work fine, and normal type lookups obviously
work fine.)
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
11 years, 10 months
Idea from G+ back in December
by Jason Porter
Here's the idea I was talking about on Google Plus, I know not everyone was
on that but I know Lincoln and George were.
The idea is to have interfaces or some sort of contract (interfaces came up
because those and abstract classes are the only thing we have in Java to do
this) that defines some way of retrieving front end resources (JSF pages,
HTML, etc) for a specific functionality like login. That may be an
oversimplification, but that's the main idea.
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
11 years, 10 months
Forge meeting minutes - 01-10-2013
by ggastald＠redhat.com
==============
#forge Meeting
==============
Meeting started by gastaldi at 15:07:10 UTC. The full logs are available
at
http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2013/forge.20...
.
Meeting summary
---------------
* Repository Split (gastaldi, 15:07:52)
* each forge2 addon that we build should have its own repo in the
forge org (gastaldi, 15:24:54)
* AGREED: each forge2 addon that we build should have its own repo in
the forge org (lincolnthree, 15:25:27)
* IDEA: addons repository should be named forge-xxx-addon (gastaldi,
15:25:40)
* AGREED: each forge2 addon that we build should have its own repo in
the forge org (lincolnthree, 15:25:46)
* IDEA: name forge-hibernatetools something different :) forge-reveng
? (maxandersen, 15:28:41)
* LINK: https://gist.github.com/4497003 (lincolnthree, 21:13:45)
Meeting ended at 15:46:41 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* lincolnthree (496)
* gastaldi (267)
* maxandersen (111)
* mbenson (100)
* vineetreynolds (62)
* koentsje (42)
* pmuir (29)
* stalep (23)
* jbossbot (11)
* maxaway (7)
* sblanc (4)
* ivannov (4)
* kenfinnigan (3)
* jbott (3)
* mbenson_grabbing (1)
* rbenevides (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
11 years, 10 months
What is the command for creating a pojo in forge?
by Robb Greathouse
Hi,
I am trying to create a POJO in a Forge script.
I tried java new-class --named Credentials --package xxxx but get error no type found. Then tried --type java.lang.Object. But no joy.
Robb Greathouse
Partner Enablement
Middleware Business Unit
JBoss, a Division of Red Hat
cellphone 505-507-4906
11 years, 10 months
non-CDI object hook into CDI
by Thomas Frühbeck
Hi,
I have objects under control of a non-CDI framework and want to hook
into CDI.
What is the shortest / most elegant / best way hook into CDI _aside_ of
(BeanManager) InitialContext.lookup()?
Thanks,
Thomas
11 years, 10 months
Forge 2 Eclipse Integration - Update
by Lincoln Baxter, III
Hey All,
We've started working on the Forge 2 Eclipse UI integation - please see the
latest work here:
https://github.com/forge/forge2-eclipse-ui
Forge is booting and running from Eclipse (currently rigged up through "New
-> Forge Addon", just so we have an easy way to start the runtime.) Forge
may then be queried for Addon services via:
forge.getAddonRegistry().getRemoteInstance(MyServiceClass.class);
*Next step:*
- Get UICommand objects working to build Eclipse Wizards, see UI API
here:
https://github.com/forge/core/tree/2.0/ui/api/src/main/java/org/jboss/for...
Addons may depend on the *org.jboss.forge:ui* addon and implement the
UICommand interface and UIWizard interfaces to make functionality available
to the host environment (like Eclipse or the CLI Shell.) These
implementations are then retrieved via the AddonRegistry, as exampled above.
Set<UICommand.class> commands =
forge.getAddonRegistry().getRemoteInstances(UICommand.class);
*Questions:*
1. How should the Forge integration in Eclipse look and feel?
2. Where should the UI interactions begin? Menu, hotkey, etc? (I
personally favor the CTRL-4 shortcut to bring up a forge command selector
menu, like what currently is done in JBoss Tools.
That's all for now. This is all a prototype so now is the time to fix
things if they need to chance. Please send your feedback! We want this to
work as well as possible so are very open to feedback.
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
11 years, 10 months
On the topic of the impedance mismatch between Forge and IDE's
by Max Rydahl Andersen
Hi guys,
Returning from JBDS face-2-face last week I'm realising we got a few old known challenges and wondering what/how we can fix or at least make the issues non-issues.
The primary usecase for Forge from my POV is being able to reuse scaffolding and code generation as a replacement of Seam Gen functionality we have in Eclipse and
right now Forge is not there yet and I fear it won't be there within the next 1-2 months where we actually need to make progress on scaffolding and generation for things like
HTML5 and more. I'm wondering if we need to readjust our approach to how we use forge and its addons - maybe the "old" approach of sharing code/templates is a better one
instead of requiring a full running Forge to make it work ?
I actually started writing a long email about the various issues but I realised that wouldn't be read by anyone, so I'm wondering if someone could give me quick summary
of what are happening in context of Forge 1 or even 2 when it comes to making it easier/better to utilize Forge addons from something like Eclipse ?
To give an idea of my main concerns here is a quick list:
* startup time
* how to keep forge addons uptodate/in-sync to keep working together
* Support a "multi-step wizard" approach for one and combined forge commands
* How to not have too many hard requirements of the sequence or if possibly any need of Forge setup commands to use Forge to simply generate code
(i.e. today I have to wait for Forge to parse and understand maven metamodel and more to just use its generate code functionality - meaning if I just have a plain
eclipse project or even a gradle project or ant project I can use Eclipse tooling to generate wizards, but Forge are not possible (or at least very slow in comparison, even when ignoring startup time))
/max
11 years, 10 months
